ntpMerlin ntpMerlin - NTP Daemon for AsusWRT Merlin

[L&LD]

Can you check the size of ntpdstats_rrd.rrd please? I inadvertently introduced a bug for new installs last night, which I have rolled back. Existing installs should have remained intact.

Jack Yaz, the size of that file is 126KB.

Just checked the graphs again, most of them are showing info now!

739.3 offset current
0.0 jitter current
391.9 offset last 7 days current
0.0 jitter last 7 days current
8.37 drift last 7 days current

 

[EmeraldDeer]

A further question for the NTP users here: what effect in terms of accuracy have when I choose a GPS, CDMA or PPS based NTP server?

Again, these are all public Stratum 1 Network Time Protocol (NTP) servers, above.

Theoretically: Yes
Practically: Maybe

• Network delay and to/from asymmetry reduce or remove the advantage of a stratum 1 NTP server
• GPS, CDMA and radio are sources of time. GPS is more accurate than CDMA which is more accurate than radio.
• Radio (WWVB in USA, DCF in Germany) nowadays is typically used by standalone clocks
• NTP (via network) and PPS (via pulse over serial port) are used to synchronize time between devices

Close NTP servers over a quality internet connection should allow NTP to settle the clock in the single digit milliseconds. Tens of milliseconds is not good.

PPS over a serial port with serial to USB 1.1 converter should allow NTP to settle the clock to under a millisecond.

PPS over a serial port should allow NTP to settle the clock to about a microsecond.

 

[EmeraldDeer]

I doubt that time being too accurate could be the cause of graphing issues

 

[daviworld]

Renaming /jffs/scripts/ntpmerlin will break the automated calls

mv /jffs/scripts/ntpmerlin /jffs/scripts/ntpmerlin.bak

as well as running

killall ntpmerlin

Not sure how your router has got locked up though...

So, I have been working on this issue all evening yesterday and I think I have some clue as to what may have locked up my configuration.

I initialized the router and formatted my jffs.

In this order, I set-up router, add changes. enabled jffs, add amtm script.
install ntpmerlin, and redirect all time....(wait's for something to break)... nothing break's so I install diversion, skynet, pixelserv-tls and evrything is smooth sailing.

At this point, I have not set-up my vpn's again or added any tweaks to the wireless settings. enabling DNSSEC(with strict unsigned) then that breaks the connection, cause local ISP doesn't support DNSSEC... So, I add 9.9.9.9, and that fixes everything.

At this point, I install Stubby, caches DNSSEC(yes), redirect all DNS(yes), proxy-dnssec(yes). I change the server it uses to get time for pool.ntp.org to 9.9.9.9 and exit out to check on connection. Then everything shirts the bed lol.

When I get home, I am gonna try installing ntpmerlin last to see if Stubby is conflicting with ntpmerlin in my environment

 

[heysoundude]

No, sorry, it isn't. High accuracy, non-temperature-controlled or compensated clocks have a error of roughly 1 PPM, which is .000001 seconds (1 us), and that's just the clock itself without taking into account the inevitable degradation due to the network connection. For reference, an error of 1 PPM is 31.5 seconds/year. Typical accuracy over the internet is .001 seconds (1 ms / 1000 PPM), and I've seen around 10 us error with a reference clock connected directly to the router through a usb port. I get 50 us or so accuracy on my router with my Raspberry Pi GPS setup that includes Pulse Per Second clock discipline on my local network. I know for a fact that kvic's graphs autoscale at least down to 1 us steps, because I've seen it. You cannot possibly get results that won't display.

well, I suppose we'll see when 5G gets to be more prevalent/fully launched. If what I've come to understand about it is correct, I can understand the political uproar: it's a potential major disrupter.
I'll have to dig into your links in a bit to understand if and/or where I'm off base here...and I suspect you understand the maths better than I do, so I may also have to develop a taste for crow

 

[XIII]

Trying this for the first time.

The default config tells you to find nearest NTP servers on http://twiki.ntp.org/bin/view/Servers/NTPPoolServers

However, that link gives a redirect (that Firefox 66.0.2 could not handle for me) to http://support.ntp.org/bin/view/Servers/NTPPoolServers

Maybe the config should use the latter? Or is there a reason for keeping the previous one?

(the redirect led to a 400 Bad Request for http://support.ntp.org/bin/view/Mai...pport.ntp.org/bin/view/Servers/NTPPoolServers)

 

[Jack Yaz]

Trying this for the first time.

The default config tells you to find nearest NTP servers on http://twiki.ntp.org/bin/view/Servers/NTPPoolServers

However, that link gives a redirect (that Firefox 66.0.2 could not handle for me) to http://support.ntp.org/bin/view/Servers/NTPPoolServers

Maybe the config should use the latter? Or is there a reason for keeping the previous one?

(the redirect let to a 400 Bad Request for http://support.ntp.org/bin/view/Mai...pport.ntp.org/bin/view/Servers/NTPPoolServers)

Fixed in develop https://github.com/jackyaz/ntpMerlin/commit/53e9af9ba8dd71302f3785ff4e08a0d323d1c505

 

[XIII]

Installed on my AC86U and rebooted. After that I no longer had internet connectivity and the router's date/time was set to May 5 2018 (which I usually see in the logs right after a firmware update).

After logging in using PuTTY and manually setting the date/time my internet connectivity returned.

Might this be related to the fact that I use unbound for DNS over TLS and its init script has a lower number (61) than ntpd (77)?

How can I fix this?

 

[EmeraldDeer]

It would appear that we now have enough anectodal reports to add code to S77ntpd to wait on the built in NTP client to set ntp_ready to 1. Here is what Stubby does.

# Wait for NTP before starting
ntptimer=0
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "300" ]; do
        ntptimer=$((ntptimer+1))
        sleep 1
done
if [ "$ntptimer" -ge "300" ]; then logger -st S77ntpd "[*] NTP Client Failed To Start After 5 Minutes - Please Fix Immediately!"; echo; exit 1; fi

 

[Jack Yaz]

It would appear that we now have enough anectodal reports to add code to S77ntpd to wait on the built in NTP client to set ntp_ready to 1. Here is what Stubby does.

# Wait for NTP before starting
ntptimer=0
while [ "$(nvram get ntp_ready)" = "0" ] && [ "$ntptimer" -lt "300" ]; do
        ntptimer=$((ntptimer+1))
        sleep 1
done
if [ "$ntptimer" -ge "300" ]; then logger -st S77ntpd "[*] NTP Client Failed To Start After 5 Minutes - Please Fix Immediately!"; echo; exit 1; fi

https://github.com/jackyaz/ntpMerlin/commit/8827697efcedcb25433795a1c71dc128877b6bab

 

[XIII]

https://github.com/jackyaz/ntpMerlin/commit/8827697efcedcb25433795a1c71dc128877b6bab

You might want to replace "S61stubby" by "S77ntpd"?

 

[Jack Yaz]

1.2.0 has been released

Fix URL for list of servers in ntp.conf
Wait for built-in NTP to sync before starting ntpd
Rename menuTree.js for compatibility with another project

 

[RMerlin]

The reason why so far I haven't added ntpd to Asuswrt-Merlin (even tho the busybox applet is already there, it's just not used yet) is the fact that Asuswrt has a very outdated timezone database, meaning the wrong start/end date for DST in many countries. Don't you guys worry that this could cause ALL of your LAN devices to end up with the wrong time if you failed to manually set the correct start/end DST dates?

 

[Jack Yaz]

The reason why so far I haven't added ntpd to Asuswrt-Merlin (even tho the busybox applet is already there, it's just not used yet) is the fact that Asuswrt has a very outdated timezone database, meaning the wrong start/end date for DST in many countries. Don't you guys worry that this could cause ALL of your LAN devices to end up with the wrong time if you failed to manually set the correct start/end DST dates?

Nope, 1st thing I set after a factory reset. Set it and forget

 

[JDB]

Nope, 1st thing I set after a factory reset. Set it and forget

This!

People this obsessed by time make sure the DST settings are correct!


Sent from my iPhone using Tapatalk

 

[EmeraldDeer]

The reason why so far I haven't added ntpd to Asuswrt-Merlin (even tho the busybox applet is already there, it's just not used yet) is the fact that Asuswrt has a very outdated timezone database, meaning the wrong start/end date for DST in many countries. Don't you guys worry that this could cause ALL of your LAN devices to end up with the wrong time if you failed to manually set the correct start/end DST dates?

My understanding is that NTP server and client only understand UTC and completely leave it to the operating system to display time zone/daylight saving corrected time.

Hypothetically, a misconfigured router would only impact the router.

 

[RMerlin]

My understanding is that NTP server and client only understand UTC and completely leave it to the operating system to display time zone/daylight saving corrected time.

Hypothetically, a misconfigured router would only impact the router.

Even if the router's own clock doesn't store it internally in GMT?

 

[cmkelley]

well, I suppose we'll see when 5G gets to be more prevalent/fully launched. If what I've come to understand about it is correct, I can understand the political uproar: it's a potential major disrupter.
I'll have to dig into your links in a bit to understand if and/or where I'm off base here...and I suspect you understand the maths better than I do, so I may also have to develop a taste for crow

So, a little bit of googling found this right from the horse's mouth (ntp.org) http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm

Also, and IEEE paper summary says 5G will "only" need 130 ns (130 PPM) at the phone, which means their biggest problem is the network. https://ieeexplore.ieee.org/document/7885239

And it's not about eating crow. I've certainly made enough wrong statements here based on bad information. It's about learning. If I don't learn something new in a day, the day is a loss.

 

[EmeraldDeer]

Even if the router's own clock doesn't store it internally in GMT?

I do not have the perspective that you do with regards to what is happening under the hood, so I am guessing.

When I boot my router the time is May 5 01:05 AM until NTP client sets it. So regardless of what TZ/DST the clock is supposed to be, it is being set from the perspective of NTP which is UTC.

 

[RMerlin]

I do not have the perspective that you do with regards to what is happening under the hood, so I am guessing.

When I boot my router the time is May 5 01:05 AM until NTP client sets it. So regardless of what TZ/DST the clock is supposed to be, it is being set from the perspective of NTP which is UTC.

Only way to know for sure would be the set the wrong DST period on the router, then see what the clients get from the router's ntpd daemon.