Comments on: Real Life NTP https://pthree.org/2013/11/05/real-life-ntp/ Linux. GNU. Freedom. Tue, 31 Oct 2017 18:00:46 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42127 By: Links 2 | Sandzwerg.de https://pthree.org/2013/11/05/real-life-ntp/#comment-132106 Sat, 22 Mar 2014 22:09:38 +0000 https://pthree.org/?p=3301#comment-132106 […] Real Life NTP  Beitrag über die Funktionsweise und Einrichtung von NTP Servern und Clienten. […]

]]>
By: Network Time Protocol | Share our secret https://pthree.org/2013/11/05/real-life-ntp/#comment-131157 Thu, 12 Dec 2013 20:18:49 +0000 https://pthree.org/?p=3301#comment-131157 […] Real Life NTP (pthree.org) […]

]]>
By: Aaron Toponce https://pthree.org/2013/11/05/real-life-ntp/#comment-130869 Wed, 27 Nov 2013 21:39:23 +0000 https://pthree.org/?p=3301#comment-130869 Case in point:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-174.127.117.113 216.218.254.202  2 u  173  256  377   53.934    6.253   1.208
-209.236.69.170  231.146.174.254  3 u  164  256  377   53.804   15.409   6.325
-66.241.101.63   132.163.4.103    2 u  172  256  377   62.746    4.980  44.817
+199.104.120.74  85.29.25.171     2 u  183  256  377   64.776   -0.644   1.587
-63.211.239.58   128.138.140.44   2 u   61  256  377   62.611    7.154   4.624
*166.70.136.41   .GPS.            1 u  187  256  377   65.279   -0.343   0.797
+198.60.22.240   .GPS.            1 u   90  256  377   64.965   -0.444  14.843
+166.70.136.35   166.70.136.41    2 u   94  256  377   64.926   -0.288  17.398
-204.2.134.163   129.250.35.250   3 u   58  256  377   68.616    1.991  11.210
-178.18.16.124   204.235.61.9     3 u   95  256  377   70.709    3.189  23.020

Notice that the stratum 3 servers have high offsets, and high jitters. Even some of the stratum 2 servers are exhibiting high offsets with high jitters. This is fairly common.

]]>
By: Aaron Toponce https://pthree.org/2013/11/05/real-life-ntp/#comment-130866 Wed, 27 Nov 2013 16:37:46 +0000 https://pthree.org/?p=3301#comment-130866

1) A stratum 1 (2 or 3 or so on) server is only as good as its stratum 0 server. Just because the server is labelled as a stratum 0 server, doesn't mean it necessarily has an excellent time source that it is collecting information from.

Can you show me where I'm claiming that a stratum 0 is keeping True Time? I thought I made it clear that even stratum 0 clocks drift.

Multiple time servers listed for collecting out time information. With 3 servers, you can potentially find 1 bad clock ( "falseticker" ). With 7 servers, you can potentially find 2 bad clocks in your entire server list.

Not as I understand it. NTP needs a quorum to set the time. This means a majority. 1 false ticker in 3, 2 in 5, 3 in 7, 4 in 9, etc. The number of false tickers must be less than half of the total sources.

Regarding point #2, I see how I can clarify my post. A stratum 4 server might certainly be more accurate than an authoritative stratum 0 source. I'll adjust the language. I also agree with not taxing stratum 1 time sources. However, in practice, I have found stratum 3 and stratum 4 time sources to exhibit a great deal of unnecessary jitter. Sure, at the moment, a stratum 4 server might be more accurate than a stratum 1, but in practice, I rarely see NTP use lower stratum servers when higher are configured.

Again, I agree with not unnecessarily burdening stratum 1 servers. However, if you have your server listed as "OpenAccess" without notification at http://support.ntp.org/bin/view/Servers/StratumOneTimeServers, then I see no problem with finding stratum 1 servers close to you with low latencies, and using them for your time source. I would much prefer to take authoritative, reliable, and low latency servers from this list, then sync with some random stratum 3 and stratum 4 time sources in the NTP pool, especially where they restrict queries from outside sources.

Engineers/Administrators hear that a stratum 3 server is potentially microseconds different than a stratum 0 server, and they freak out. Many people forget, that a microsecond is 1/1000000 of a second. These engineers hear that, and it immediately goes to their head, that it is minutes apart as far as accuracy is concerned.

Sure, but even stratum 1 servers are already a few microseconds off, and stratum 2 servers frequently show several hundred microsecond to dozens of millisecond offsets. I've seen stratum 3 servers with hundreds of milliseconds offsets. At that point, yes, I'm freaking out. I expect my DNS and SQL logs to be spot on to the exact millisecond. I don't have the luxury of +/- 100ms offsets for my logs.

In practice, it's trivially easy to setup a local stratum 1 for your office, and have your workstations and servers get your time from it. You can build a stratum 1 syncing with GPS for ~$150 using a Raspberry Pi. And even with 300+ computers getting their time from it, it's hardly "taxed". I have yet to see the load for my Raspberry Pi, which is part of the NTP pool project, exhibit a load of anything more than 0.3, and that's with ~100 Kbps network traffic.

]]>
By: MikeDawg https://pthree.org/2013/11/05/real-life-ntp/#comment-130521 Fri, 08 Nov 2013 04:03:51 +0000 https://pthree.org/?p=3301#comment-130521 Your article is very informative, however, I would like to point a couple things out (from my reddit post):

Going to go on a short rant here.
Overall, this page was very informative; however, there are a couple blaring problems and/or mistakes.

1) A stratum 1 (2 or 3 or so on) server is only as good as its stratum 0 server. Just because the server is labelled as a stratum 0 server, doesn't mean it necessarily has an excellent time source that it is collecting information from.
Fix> Multiple time servers listed for collecting out time information. With 3 servers, you can potentially find 1 bad clock ( "falseticker" ). With 7 servers, you can potentially find 2 bad clocks in your entire server list.

2) A stratum 1 .. 4 server isn't as accurate as a stratum 0 server.

Fix> A stratum 1 .. 4 server can be more accurate than a stratum 0 server. Again, the important thing, is to maintain a solid list (I generally recommend 3 - 7) of servers. I also recommend only using stratum 2 or 3 servers. There is no reason to tax stratum 1 or stratum 0 servers more than they already are. I hate having to explain this to senior level engineers/administrator at my work. The key is to have a good, reputable number of servers you can sync time to, NOT making sure you connected to a stratum 0 server. As an administrator, if you can verify that your time source is connected to 7 reputable time sources, with relatively low network latency, then you are going to be extremely accurate. We're talking micro seconds. You know, 1/1000000 of a second. Your RTC is going to waver more than that based upon voltage irregularities in your system.

Engineers/Administrators hear that a stratum 3 server is potentially microseconds different than a stratum 0 server, and they freak out. Many people forget, that a microsecond is 1/1000000 of a second. These engineers hear that, and it immediately goes to their head, that it is minutes apart as far as accuracy is concerned.

NTP servers are smart, and they are generally programmed quite well, they detect latency, drift, and a whole lot of other things that you don't really need to be concerned with; but they are accurate.

In the end, this is purely about quantity over quality (for the most part). I would take seven stratum 3 servers, with an acceptable amount of network latency over a single stratum 0 server, with questionable authority, and questionable network latency.

]]>
By: MAS https://pthree.org/2013/11/05/real-life-ntp/#comment-130501 Thu, 07 Nov 2013 01:14:31 +0000 https://pthree.org/?p=3301#comment-130501 Nice writeup. Debian provides the package ntpdate which is just a client to set the date and time of the machine on which it is run. Per the info:

...
ntpdate is a simple NTP client that sets a system's clock to match
the time obtained by communicating with one or more NTP servers. It
is not sufficient, however, for maintaining an accurate clock in the
long run. ntpdate by itself is useful for occasionally setting the
time on machines that do not have full-time network access, such as
laptops.

]]>