Ropieee boot time 4,5 minutes —> cause: waiting for ntp synchronization —> how to speed up boot time?

Audio Gear Talk RoPieee
1

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

Orbi RBR50 router, hardwired to Roon endpoint

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Raspberry pi 4 with hifiberry DIGI + pro and Ropieee latest stable build Roon bridge 1.7 build 571

Description Of Issue

Booting Ropieee hangs on: waiting for ntp synchronization. Only after 4,5 minutes this synchronization is succesful and Roon endpoint becomes available.

It used to boot in about 1 minute but for several months the boot time has gone up to 4,5 minutes and today I found out waiting for ntp synchronization is causing it.

What can I do to speed up boot time?

2

Figure out what’s going on in your infrastructure, because clearly something is wrong. This should not take that much amount of time.

Just to be clear: are you running the latest version?

3

Thank you for your quick reply.

Yes I am running the latest version: 2.956 stable. I’ve downloaded the latest image and flashed a new SD card today, because I thought it was the SD card that caused the bootup delay.

But today I connected a monitor to the raspberry pi 4 and saw that it hangs in stage 3 after reporting “Waiting for NTP synchronization”.

I tried to bypass a switch connecting the rb pi straight to my router. Other devices do NTP sync well.

Then I enabled wifi and connected Ropiee to my smartphone enabled as a hotspot with 4G connection. Sync succeeded within 1 minute.

Than I retried with ethernet connection and wlan on but disconnected (hotspot off)

Ropieee reports after 4,5 minute:

Sync failed
Trying over https
Synced!

So it seems NTP can’t be reached over http on my router. Probably a security setting. I use default settings and would rather keep it.

Can I configure Ropiee to sync over https from the start in order to avoid waiting 4,5 minutes?

4

That’s not’s what happening.

What happens is that it is not able to sync NTP (which does not use HTTP or HTTPS) and falls back to sync time over HTTPS.

Probably NTP is blocked. Either by your firewall, the router’s firewall, or worse: your internet provider.

5

Ah that’s what is happening. Thank you.

Is it possible to have Ropiee try syncing time over https first or (much) earlier to solve the problem?

6

On my linksys RBR50 router I’ve found a setting for Nat-filters in the WAN section. If it is set to “secure” ropieee can’t find the NTP server and boots in 4,5 minutes. If I set it to “open” Ropieee finds the NTP server and boots in 1 minute.

But the help section of my router warns that setting this setting to “open” results in a much weaker firewall increasing the risk of getting hacked.

Since I don’t want to do that I hope there is a way to have RoPieee use https for NTP sync straightaway. Is it possible to set this up in the configuration, using SSH to login and change some settings (I’ve managed to login successfully)?

If so can you maybe help me telling me which settings I have to change to make it work?

7

Right now you can’t change this, as configuration is rewritten upon a configure.

There is really no need to block NTP.

it should be possible to only open your firewall for NTP (port 123).

8

Yes, opening port 123 is the simple and elegant solution to your problem.

Now, you want the “sledgehammer” solution :wink:
You can run your own internal NTP server in your home. Even a standard Windows PC can be a NTP server. It’s built in to Windows, but disabled by default.

This is assuming that Ropieee would detect one on the same subnet.

9

Where does Windows get its time from? If it needs NTP then…

1 Like
10

Thank you for your support. I’ve restarted my router, main switch and cable modem. It solved the problem: Ropieee now finds the external NTP server within 20 seconds.

If the problem comes back often, I might try the internal NTP server workaround.

Thanks!

11

Well, does it really matter if the Windows PC can’t reach the external NTP server? The point was to get the Ropieee to get past the NTP sync. Ropieee will sync to whatever time the Windows PC has.

12

It does not. RoPieee syncs with a dedicated pool outside your own infrastructure.

13

And again, all the excitement and outrage is solved by a simple router reboot! Some routers have a function to automatically schedule a reboot, which goes to telling how often you need to do it.

14

Ha! for me that ‘scheduled reboot functionality’ is a hard requirement when looking for a new router.

15

I am resurrecting this old thread because I’m experiencing symptoms very similar to the original poster.

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)

American Megatrends Inc.fanless PC running OPNsense 22.7_4-amd64, hardwired Roon server running on Dell Optiplex PC (Intel(R) Core™ i5-6500 CPU @ 3.20GHz, 8 GB RAM, Windows 10 Pro.

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)

Four separate Raspberry pi 4’s running RoPieeeXL 2022.06.4 (0459) / 5.15.53-SPCKFSH-v7l → USB → RME ADI-2 FS

Description Of Issue

Booting Ropieee fails NTP synchronization, then hangs 4 minutes waiting for https synchronization. Only after ~ 5 minutes, the Roon endpoint becomes available.

It used to boot in about 1 minute but using the latest RoPiee image the boot time has gone up to 4,5 minutes.

The orignal poster found that rebooting his router fixed the issue. That’s not the case for me. I’ve verified that NTP is operational from various P5.15.53-SPCKFSH-v7lCs on my local network using the command below from the Windows command shell:

C:\Users\Jim>w32tm /monitor /computers:0.pool.ntp.org
0.pool.ntp.org[217.180.209.214:123]:
ICMP: 95ms delay
NTP: +1.0074193s offset from local clock
RefID: 'GPS [0x00535047]
Stratum: 1
Variations of this command work for all four pool.ntp.org servers.

This leads me to conclude that my router is configured properly to allow NTP access. So, I don’t understand why the Raspberry Pi’s running RoPieeeXL fail to fetch time via NTP. More importantly, I don’t understand why fetching time via HTTPS takes four minutes or more.

16

I had something similar happen to me which I resolved by assigning a fixed IP address. Could be something else, but may be worth a look. It is discussed here: RoPieee Boot Up Time Excessive

17

The fallback scenario (using time sync over HTTPS) was not working because of a change in RoPieee’s infrastructure. That has been resolved now (see other thread).

The reason why NTP is not working in the first place is still under investigation. I’ve seen a few logs and right now I’ve got a hunch it is related to ipv6.

18

I did assign fixed IPs to all my RoPieee endpoints, but this did not alter the failure mode.

1 Like
19

Thank you for investigating. Feel free to send me beta images for experimentation.

20

I’m building a beta for you to test as we speak.

But to be clear: the fallback scenario (sync-over-https) is working now again, right?