ntpMerlin Hardware or software

[sbsnb]

I'm using Chrony and my drift has a very discernible pattern, both daily and over the long run. The graph shows that each day the drift reaches a low point in the afternoon and climbs back higher in the evening and overnight hours. This pattern repeats every single day. It is also clear to see the upward trend over the long term. I'm dubious that this is due to hardware, but I can't figure what would give such a clear pattern to the drift value.

 

[sbsnb]

This graph makes things more clear, I think. The time offset doesn't change much, but those patterns in the drift pique my interest.

 

[chongnt]

Looking at the scale, your drift in a month is less than 0.5ppm which I think is pretty good. Mine daily fluctuates more than 1ppm. My one month drift is opposite of yours, the drift is getting lower and lower. Then I realized my router is getting dirty with the fan blowing in and daily average temperature is slowly on the rise. After clean up the router I get around 8-9 degree Celsius drop in average temperature and noticed the drift raised roughly more than 2ppm. Router cleanup on 22nd Aug.
Is your overall temperature getting lower over the past 30 days?

 

[sbsnb]

No. The inside "weather" hasn't changed. I'm hoping it's not a slowly ticking clock documenting the decline of the ICs on my board. It seems to be drifting upward at 0.3 ppm per month.

 

[heysoundude]

Seriously - forget the graphs and look at the "latest timeserver stats" chart and the columns. with one exception in the past 90 min, my offset (3 significant digits) is always 0.00ms, and drift (2 significant digits for the finer resolution) is consistent at 3.4ppm...beyond this, we're dealing with noise, frankly.

what you REALLY should be paying attention to is the offset. If that shows a trend of increasing, that's indicative of a true problem. In your case it is stable, or coming to a very nice equilibrium

ppm = parts (pulses in the case of a clock) per million.
Drift of a half or a third of one pulse over a 30 day timeframe is...ridiculously accurate. 0.5ppm is 5 pulses in 10 million...5/10,000,000. 0.3ppm is 3/10,000,000...over 30 days
how many clock pulses in a minute? or second?
(do you have new respect now for how hard your router is working? you'd get hot too if you were juggling on that magnitude with similar timing requirements)

You don't have any problems - your offset seems to be narrowing to +/- 0.2ms or less -two tenths of a thousand milliseconds, two milliseconds every 10,000 above or below an average of ZERO, and THAT is only "incorrect" by 3-5 clock pulses every 10 million...over the month you recorded data. take a snapshot every month for the next 12, line them up and THEN look at any trend.

You are now free to roam about the internet ;-) You might want to get over to the chrony manpages and then adjust your .conf file. then there is the examination of sources to be considered...
but I wouldn't bother wasting that precious time - this is a tempest in a very small teapot unless you are requiring an atomic clock..in which case, why are you timing your network with a $200 router?

 

[sbsnb]

I've thought about building a little stratum 1 server with a Raspberry Pi and a GPS antenna, but I've never been motivated enough to actually do it.

 

[heysoundude]

life is too short to waste time geeking out over things that are already well enough in hand...this is a SOHO router, not the Greenwich observatory or the CERN supercollider.

 

[sbsnb]

But it's fun.

 

[festus77]

Best explanation I've seen as to why I was spending to much time fussing with NTP.

ntpMerlin - ntpMerlin v3.x

Oh, but I had no intention of causin' the boss extra work. He has other thing on his head now anyway. I was just curious about the default drift value. And I'm here to learn so I feel free to ask. As for the temperature, I recently did some research (well, actually, I DuckDuckGo'd a bit...

www.snbforums.com

 

[heysoundude]

Well, AFAIC, it IS an important thing to try to get as close to optimal as you can, because it will have an affect -a small one- on your network's connection to the greater interweb...but there's a point of diminishing returns where you start chasing your tail in circles and losing sight of the forest for the trees.

But if someone wants to be the uber-geek on their network, Jeff Geerling has a video on YouTube about building your own atomic clock...stratum 0 for your home or something crazy like that. smh

 

[EmeraldDeer]

I do have a daily drift pattern where drift is higher with higher ambient temperature. My daily variation is five times larger than @sbsnb
I do not have a long term pattern, it is holding steady.
I do not have any theories which could explain a long term linearly increasing drift.
I do have a GPS connected NTP server on my LAN.

 

[heysoundude]

Just out of curiosity, what poll rate are you people using?
I've set mine at 6, so every 2^6 (64) sec chrony goes looking for a reference...might be why I'm steady:
The more often it looks, the less chance it has to wander

 

[festus77]

Just out of curiosity, what poll rate are you people using?
I've set mine at 6, so every 2^6 (64) sec chrony goes looking for a reference...might be why I'm steady:
The more often it looks, the less chance it has to wander

Mine is showing 10 (1024 seconds). Isn't this controlled by chronyd based on conditions?

MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^+ usatl4-ntp-001.aaplimg.c> 1 10 377 594 +1404us[+1376us] +/- 26ms
^+ usscz2-ntp-002.aaplimg.c> 1 10 377 965 +807us[ +780us] +/- 37ms
^* usdal4-ntp-001.aaplimg.c> 1 10 377 384 +1639us[+1610us] +/- 17ms
^+ usdal4-ntp-002.aaplimg.c> 1 10 377 989 +1597us[+1570us] +/- 18ms
^+ time-a-wwv.nist.gov 1 10 377 188 -1587us[-1587us] +/- 20ms
^+ time-e-b.nist.gov 1 10 377 649 -1847us[-1875us] +/- 20ms
^+ time-b-b.nist.gov 1 10 377 2 -2032us[-2032us] +/- 20ms
^+ time-e-wwv.nist.gov 1 10 377 909 -1701us[-1728us] +/- 20ms
^+ ntp2.wiktel.com 1 10 377 979 +1896us[+1869us] +/- 35ms
^- any.time.nl 2 10 377 876 +1543us[+1516us] +/- 56ms
^- srcf-ntp.stanford.edu 2 10 377 1018 +1529us[+1502us] +/- 61ms
^- 38.229.57.9 2 10 377 607 +1537us[+1509us] +/- 187ms

 

[chongnt]

Well, AFAIC, it IS an important thing to try to get as close to optimal as you can, because it will have an affect -a small one- on your network's connection to the greater interweb...

Actually our router and internet access will work just fine even if the system clock is not sync and way off. Of course it is good that system clock is sync in case we need to check syslog so that the event time is correct to ease troubleshooting. On top of that, some addons like ntpmerlin, unbound require correct system time to work. Otherwise it has no effect on internet access.

Mine is showing 10 (1024 seconds). Isn't this controlled by chronyd based on conditions?

You can edit chrony.conf file and play around with minpoll and maxpoll options. If I’m not mistaken maxpoll is 10 by default. It is not recommended to poll too often to public ntp server. Default is just fine.

 

[XIII]

Actually our router and internet access will work just fine even if the system clock is not sync and way off.

Depends on how “way off” it is (for example TLS/https and 6 digit OTP codes may fail).

 

[chongnt]

Depends on how “way off” it is (for example TLS/https and 6 digit OTP codes may fail).

I suppose this is something between server and client. In such case, client is our pc or mobile device. Thus router system clock is transparent.

 

[ColinTaylor]

Depends on how “way off” it is (for example TLS/https and 6 digit OTP codes may fail).

As an experiment I tried various time offsets on my PC and then tested HTTPS connections, including logging into to my bank. I found the HTTPS connections only failed when the time was out by more than 5 days!

Even when using something more time critical like Kerberos authentication the margin is normally about 5 minutes.

So as said above, the time on the PC being out by a few minutes (let alone seconds) will not have any effect on internet connectivity.

Bear in mind that a typical PC will only sync it's time about once a day, or once a week in some versions of Windows. Which indicates just how unimportant it is to have a super-accurate time of day set.

 

[XIII]

Yes, TLS is indeed not the best example… (days/weeks?)

For TOTP the allowed difference is probably much smaller (they change every 30 seconds, but a few older/newer might be accepted)

 

[EmeraldDeer]

From the chrony FAQ

Generally, if the sourcestats command usually reports a small number of samples retained for a source (e.g. fewer than 16), a shorter polling interval should be considered. If the number of samples is usually at the maximum of 64, a longer polling interval might work better.

This refers to the NP column in the output of chronyc sourcestats

 

[heysoundude]

Actually our router and internet access will work just fine even if the system clock is not sync and way off. Of course it is good that system clock is sync in case we need to check syslog so that the event time is correct to ease troubleshooting. On top of that, some addons like ntpmerlin, unbound require correct system time to work. Otherwise it has no effect on internet access.


You can edit chrony.conf file and play around with minpoll and maxpoll options. If I’m not mistaken maxpoll is 10 by default. It is not recommended to poll too often to public ntp server. Default is just fine.

I disagree that the default of 2^10 (1024) seconds is "fine" - that's every 17 minutes. And ONE device, the router, is polling the public ntp server rather than all the devices connected to it. a poll setting of 6 means it's checking once every 64 sec.

Further, let me clarify what I meant re: having a small effect on network connectivity - every WAN connection has an MTU, right? a certain number of bytes per packet, and when that's off, the systems have to negotiate and compromise and speeds are affected by that process. same thing happens when a receiver is expecting an on/off signal (1 or zero digital pulse/wavefront) at a particular point in TIME - it starts to spend time looking for the reference it was expecting to get "back on track". when that is corrected on both ends in a similar timely fashion (in my proposed case, every minute or so), there's no "stopping to figure out where we are" every 17 minutes.

I am NOT advocating polling a public ntp server every second or fraction of a second (yes, we can set negative poll numbers in the config for 2^-x; x<=10 IIRC) but we're not doing rocket surgery or quantum physics on most of our home networks or have legal a legal requirement to log THAT accurately, but we probably keep netflix and spotify streaming a little more easily (less buffering) or might actually snag that ebay bid in the last second.

smaller corrections more often: 20 minutes at gigabit speed is quite a lot of "oops" potential. It's a small thing, but I am confident it makes a small, likely imperceptible, difference except in speed and throughput metrics if you care to look deep into the decimal places.