Cloudflare Time

[gattaca]

I concur, there is nothing wrong with stratum 3, my point of bringing it up was the article writer has you believing one thing, but what actually is there is another. Stratum 3 can be good while being used along with other servers. I use the option POOL in my .conf vs. Server for the failover options. While using Server works it will not stop trying to use that specified server if it fails , where as if you told it to pool it will allow it to break away from a failed connection and move onto a different one.

Ah.. OK Great to know. We still need to encourage using multiple entries and multiple pools. In theory, you could just list the pools multiple times and hopefully, get a different NTP server each time. Sweet!

 

[sfx2000]

Great discussion. There's a wide range of needs, opinions, facts and speculations outlined in these nearly 60 posts. After working on/off with NTP for nearly 3 decades, I've encountered many misunderstandings about NTP and how to operate NTP effectively. I'll add the following comments for your Sunday AM entertainment. YMMV

Very good post - not much I can add here other than one needs to have more that two trusted sources. Even today, ships at sea have either 1 or 3 independent time sources - because if one only has two, which one do you trust (answer here is neither).

Personally - I don't see a need for more than four entries in the server/pool lists. More than that just creates more work for ntpd, and doesn't improve accuracy or precision.

My background in the way back is Telecom, and there, time is extremely important across all elements of the network, from the core to the handsets themselves - most cell sites could be considered Stratum 0, as they have a Rubidium Standard that is disciplined by GPS, so for example with IS95 CDMA, many Reference Vendors may include a CDMA radio.

I was a bit surprised that CloudFlare is Stratum 2 vs. Google Public NTP (which is considered Stratum 1) - I'm curious to know if CloudFlare smears time like Google (and Amazon if one is using Amazon's reference inside the AWS cloud).

(for those who don't dive deep into NTP, occasionally there is a leap second inserted, which typically results in a hard bump in time, and this can be disruptive to some applications - "Smearing Time" is where there is a slight shift in a predictable manner to "hide" the leap second over a period of time and then get back on track)

Fun fact - given a solid platform - one can actually observe the wobble of the GPS constellation, and it shows up on a high precision setup as minute shifts in time....

 

[sfx2000]

this is my most recent information collection from the great ntpmerlin.

ntpq -4 -c rv | grep jitter
mintc=3, offset=0.300546, frequency=7.128, sys_jitter=0.171691,
clk_jitter=0.358, clk_wander=0.063, tai=37, leapsec=201701010000,

you have to thank @Jack Yaz for his amazing scripts.

Jitter actually has not much impact on NTP...

Root Dispersion is a better indication of reliability and trust of both the client and server...

If a server gets its time from an external clock, its root dispersion is the estimated maximum error of that clock. If it gets its time from another NTP server, its root dispersion is that server's root dispersion plus the dispersion added by the network link between them
​

Here's a snapshot of a BSD based server running NTPd - this one is not disciplined via GPS...

ntpq -p -c rv
remote refid st t when poll reach delay offset jitter
==============================================================================
+time1.google.co .GOOG. 1 u 320 512 377 35.987 3.781 0.747
+time2.google.co .GOOG. 1 u 278 512 377 74.228 -9.910 0.769
*time3.google.co .GOOG. 1 u 514 512 377 35.833 3.862 0.377
-time4.google.co .GOOG. 1 u 341 512 377 75.027 -10.065 0.490

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p13@1.3847-o Fri May 10 20:05:13 UTC 2019 (1)",
processor="amd64", system="FreeBSD/11.2-RELEASE-p10", leap=00, stratum=2,
precision=-22, rootdelay=35.833, rootdisp=38.925, refid=216.239.35.8,
reftime=e0ba5d37.e73e976b Sun, Jun 23 2019 13:19:03.903,
clock=e0ba6140.02dd47ae Sun, Jun 23 2019 13:36:16.011, peer=13523, tc=9,
mintc=3, offset=0.491552, frequency=0.188, sys_jitter=12.048831,
clk_jitter=0.417, clk_wander=0.013​

Same device over time (two days in this example)... and this device would be perfectly fine to provide time source for a small business network.

 

[Dabombber]

Ah.. OK Great to know. We still need to encourage using multiple entries and multiple pools. In theory, you could just list the pools multiple times and hopefully, get a different NTP server each time. Sweet!

No need for that, pool.ntp.org has prefixes for 4 different random servers. It also works for any of the regional subdomains, although

Note, however, that the country zone might not exist for your country, or might contain only one or two timeservers

0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

0.north-america.pool.ntp.org 1.north-america.pool.ntp.org 2.north-america.pool.ntp.org 3.north-america.pool.ntp.org

0.us.pool.ntp.org 1.us.pool.ntp.org 2.us.pool.ntp.org 3.us.pool.ntp.org

 

[gattaca]

I love it, some of the very first lines show Windows ITers how to use multiple entries!

I thought these are equal.. either way you need multiple a MINIMUM of 3 and preferably 5 so you can lose 3 before you are down. My recommendation of 10 comes from dealing with both corporate internal NTP and public facing. We wanted to have NTP sources both inside and outside the company as a larger failsafe and to make sure the ntp.conf files worked whether they were "internal" or "external" deployments. In some cases port 123 is blocked for one or the other.

https://www.ntppool.org/en/use.html

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

equal to
server 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

The goal is multiple reliable, accurate and available entries. that would get you 4... Later.

 

[Swistheater]

Ah.. OK Great to know. We still need to encourage using multiple entries and multiple pools. In theory, you could just list the pools multiple times and hopefully, get a different NTP server each time. Sweet!

I love it, some of the very first lines show Windows ITers how to use multiple entries!

I thought these are equal.. either way you need multiple a MINIMUM of 3 and preferably 5 so you can lose 3 before you are down. My recommendation of 10 comes from dealing with both corporate internal NTP and public facing. We wanted to have NTP sources both inside and outside the company as a larger failsafe and to make sure the ntp.conf files worked whether they were "internal" or "external" deployments. In some cases port 123 is blocked for one or the other.

https://www.ntppool.org/en/use.html

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

equal to
server 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

The goal is multiple reliable, accurate and available entries. that would get you 4... Later.

here is my current entries

pool time.nist.gov iburst
pool time.cloudflare.com iburst

 

[Swistheater]

Jitter actually has not much impact on NTP...

Root Dispersion is a better indication of reliability and trust of both the client and server...

If a server gets its time from an external clock, its root dispersion is the estimated maximum error of that clock. If it gets its time from another NTP server, its root dispersion is that server's root dispersion plus the dispersion added by the network link between them
​

Here's a snapshot of a BSD based server running NTPd - this one is not disciplined via GPS...

ntpq -p -c rv
remote refid st t when poll reach delay offset jitter
==============================================================================
+time1.google.co .GOOG. 1 u 320 512 377 35.987 3.781 0.747
+time2.google.co .GOOG. 1 u 278 512 377 74.228 -9.910 0.769
*time3.google.co .GOOG. 1 u 514 512 377 35.833 3.862 0.377
-time4.google.co .GOOG. 1 u 341 512 377 75.027 -10.065 0.490

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p13@1.3847-o Fri May 10 20:05:13 UTC 2019 (1)",
processor="amd64", system="FreeBSD/11.2-RELEASE-p10", leap=00, stratum=2,
precision=-22, rootdelay=35.833, rootdisp=38.925, refid=216.239.35.8,
reftime=e0ba5d37.e73e976b Sun, Jun 23 2019 13:19:03.903,
clock=e0ba6140.02dd47ae Sun, Jun 23 2019 13:36:16.011, peer=13523, tc=9,
mintc=3, offset=0.491552, frequency=0.188, sys_jitter=12.048831,
clk_jitter=0.417, clk_wander=0.013​

Same device over time (two days in this example)... and this device would be perfectly fine to provide time source for a small business network.

View attachment 18370

Good to know here is my spread sheet with same commands

ntpq -p -c rv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare .POOL.          16 p    -   64    0    0.000    0.000   0.002
 time.nist.gov   .POOL.          16 p    -   64    0    0.000    0.000   0.002
-2610:20:6f97:97 .NIST.           1 u  384  512  377   61.401    2.449   4.229
+2606:4700:f1::1 10.155.8.4       3 u   35   64  377    9.732    0.108   1.261
*2606:4700:f1::1 10.155.8.4       3 u   20   64  377   10.543    0.741   1.337
+time-e-wwv.nist .NIST.           1 u   68  256  377   55.993   -0.360   4.170
+162.159.200.123 10.155.8.4       3 u   29   64  377    9.768    0.541   1.469
+162.159.200.1   10.155.8.4       3 u   11   64  377    9.721    0.133   1.395
-2610:20:6f97:97 .NIST.           1 u   17  512  377   60.195    2.346   0.851
+utcnist2.colora .NIST.           1 u   80  256  377   54.721    0.162   1.150

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p13@1.3847-o Fri May 24 19:54:06 UTC 2019 (1)",
processor="armv7l", system="Linux/2.6.36.4brcmarm", leap=00, stratum=4,
precision=-19, rootdelay=41.208, rootdisp=10.543, refid=207.197.87.124,
reftime=e0ba7ffb.0223cb2f  Sun, Jun 23 2019 22:47:23.008,
clock=e0ba811f.cd850eb6  Sun, Jun 23 2019 22:52:15.802, peer=51946, tc=8,
mintc=3, offset=0.205306, frequency=7.294, sys_jitter=0.517256,
clk_jitter=0.701, clk_wander=0.064, tai=37, leapsec=201701010000,
expire=201912280000

 

[sfx2000]

I love it, some of the very first lines show Windows ITers how to use multiple entries!

I thought these are equal.. either way you need multiple a MINIMUM of 3 and preferably 5 so you can lose 3 before you are down. My recommendation of 10 comes from dealing with both corporate internal NTP and public facing. We wanted to have NTP sources both inside and outside the company as a larger failsafe and to make sure the ntp.conf files worked whether they were "internal" or "external" deployments. In some cases port 123 is blocked for one or the other.

https://www.ntppool.org/en/use.html

server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

equal to
server 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

The goal is multiple reliable, accurate and available entries. that would get you 4... Later.

Use the pool, not server directives...

pool 0.us.pool.ntp.org iburst
pool 1.us.pool.ntp.org iburst
pool 2.us.pool.ntp.org iburst
pool 3.us.pool.ntp.org iburst​

For most folks, this is good enough for people in the US

 

[sfx2000]

Good to know here is my spread sheet with same commands

In your example - the cloudflare servers are not counted at all - Stratum 16

Might as well be noselect...

 

[sfx2000]

@kvic - would be happy for you to step in for AsusWRT charting...

I don't need to reinvent that wheel...

 

[Swistheater]

In your example - the cloudflare servers are not counted at all - Stratum 16

Might as well be noselect...

+162.159.200.123 10.155.8.4 3 u 29 64 377 9.768 0.541 1.469
+162.159.200.1 10.155.8.4 3 u 11 64 377 9.721 0.133 1.39
these are counted

 

[sfx2000]

+162.159.200.123 10.155.8.4 3 u 29 64 377 9.768 0.541 1.469
+162.159.200.1 10.155.8.4 3 u 11 64 377 9.721 0.133 1.39
these are counted

Respectfully - no, they are not according to your NTPQ response...

 

[Swistheater]

Respectfully - no, they are not according to your NTPQ response...

i suppose that + means it is negated

 

[sfx2000]

i suppose that + means it is negated

Indeed it is - one has to grok the NTPQ on what it's thinking at the moment.

If there is a (*) - that's the reference, and the (+) is a peer, the (-) is a close peer, but not considered - and anything else is informational, but not counted into what NTPd has to do.

One of the risks with pools is getting locked on to a stratum 3, but with ntpd that will sort itself over time - busybox's ntp might not..

 

[heysoundude]

While my experience with atomic clocks and Internet transmission is quite rudimentary compared to some around here, I'm pretty confident saying clocking/sync can make or break systems that rely on datastreams moving efficiently between/among themselves.

I'm sure it bugs everyone when their eyes see someone's lips move, but that picture doesn't jive with the sound their ears hear. servers/routers/client devices are no different

I'll take the hits to whatever respect or credibility I might've had to have some light shone on a fairly significant (AFAIC) piece of the puzzle that gets taken for granted more often than not...until something is just not right.
If that something can be made better with tuning, tweaking, re-jigging, hacking...it's why we're here on this forum, after all. Isn't it?

 

[sfx2000]

Anyway - for all the "experts" out there - I'm the only one that has provided charting and logs, and that's proof of work... and I have the lab equipment to back it up.

I'm in communication right now with the NTPSEC team for portable Stratum 1 devices as an affordable solution.

Anyways - I suspect that @thiggins is probably going to ping me to chill out - I've been nice so far...

 

[Swistheater]

i would provide you with charts if my internet hasn't been flaky lately (service provider issue)

 

[sfx2000]

i would provide you with charts if my internet hasn't been flaky lately (service provider issue)

With NTP - shouldn't be an issue - would be happy to see what you have on-hand.

As I mentioned earlier - if it can't be visualized - it doesn't exist.

 

[Swistheater]

 

[Swistheater]

i just added google as servers to test it out

ntpq -p -c rv
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.nist.gov   .POOL.          16 p    -   64    0    0.000    0.000   0.002
 time.cloudflare .POOL.          16 p    -   64    0    0.000    0.000   0.002
*time1.google.co .GOOG.           1 u    6   64  377   27.276    1.752   2.117
+time2.google.co .GOOG.           1 u   10   64  377   54.019    0.953   1.990
-time3.google.co .GOOG.           1 u    6   64  377   39.799   -1.837   1.544
+time4.google.co .GOOG.           1 u   68   64  377   26.962    1.956   1.216
-time-e-wwv.nist .NIST.           1 u    2   64  377   60.585    2.034   2.406
-time-d-wwv.nist .NIST.           1 u   66   64  377   55.729   -0.160   1.066
-2606:4700:f1::1 10.155.8.4       3 u    3   64  377    9.833    0.085   1.873
-2606:4700:f1::1 10.155.8.4       3 u    1   64  377   10.235    0.622   1.085
-162.159.200.123 10.155.8.4       3 u    1   64  377    9.742    0.211   2.103
-162.159.200.1   10.155.8.4       3 u   66   64  377   10.292    0.721   1.649

associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd 4.2.8p13@1.3847-o Fri May 24 19:54:06 UTC 2019 (1)",
processor="armv7l", system="Linux/2.6.36.4brcmarm", leap=00, stratum=2,
precision=-19, rootdelay=27.276, rootdisp=7.366, refid=35.73.197.144,
reftime=e0ba9217.eb14e108  Mon, Jun 24 2019  0:04:39.918,
clock=e0ba9262.3cd18132  Mon, Jun 24 2019  0:05:54.237, peer=14404, tc=6,
mintc=3, offset=1.639031, frequency=6.387, sys_jitter=1.123822,
clk_jitter=1.901, clk_wander=0.289, tai=37, leapsec=201701010000,
expire=201912280000