[ntp:questions] Re: polling algorithm
Richard B. Gilbert
rgilbert88 at comcast.net
Fri Sep 2 02:08:14 UTC 2005
David Schwartz wrote:
>"Richard B. Gilbert" <rgilbert88 at comcast.net> wrote in message
>news:oI2dnWTcdIc744reRVn-gw at comcast.com...
>
>
>
>>I don't think I understand. The local clock does not normally get a
>>vote. The OP described a situatation in which he had two servers and one
>>client. Three servers work as long as all three are in reasonably close
>>agreement; let one die or malfunction somehow and you are in trouble.
>>
>>
>
> If you have three servers, other than yourself, and one goes nuts, the
>other two will agree and outvote it.
>
> DS
>
>
>
>
Why do you assume that two out of three servers will agree? My
experience with network servers suggests that no two servers will ever
be in exact agreement. I would estimate that the best you could
absolutely count on would be that three network servers will be within
+/- 50 milliseconds of the correct time. Now their clocks may agree
within +/- 50 nanoseconds but the times actually received at your site
will not agree anywhere near that closely!!
Here's an example:
sunblok_$ ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l 1385 16 0 0.000 0.000
4000.00
+sunburn .WWV. 1 u 115 128 377 0.468 -0.027
0.783
*NAVOBS1.MIT.EDU .PSC. 1 u 78 128 377 18.915 2.320
7.684
+209.51.161.238 .CDMA. 1 u 86 128 377 26.879 1.684
2.202
-louie.udel.edu 128.175.60.175 2 u 112 128 377 15.012 3.109
6.656
+hickory.cc.colu 192.5.41.209 2 u 94 128 377 16.507 0.102
2.633
LOCAL(0) LOCAL(0) 10 l 40 64 377 0.000 0.000
0.001
The offsets cover a range of 3.136 milliseconds though, in principle
each of the servers has the correct UTC time. It's the vagaries of the
network that account for most of the differences. This example was
taken at ca. 21:36 EDT. Had I taken it at local noon, the delay
figures would have been much higher and the spread would have been much
larger. Poor louie might be thirty to fifty milliseconds distant from
the others. If the GPS clock happened to be working at that instant,
we could safely assume that its time was correct and the servers would
be distributed around the GPS time. If I configured the NIST servers
in Maryland and took a snapshot of the offsets, the NIST servers might
well be five to ten milliseconds different from the GPS and the network
should take the blame. The NIST servers are at the same site in
Maryland and even they might disagree with each other by a few
milliseconds.
Here's another snapshot taken at 21:58 EDT:
sunblok_$ ntpq -p
remote refid st t when poll reach delay offset
jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l 1110 16 0 0.000 0.000
4000.00
+sunburn .WWV. 1 u 52 128 377 0.506 -3.216
0.526
*NAVOBS1.MIT.EDU .PSC. 1 u 19 128 377 21.639 -0.935
7.052
-209.51.161.238 .CDMA. 1 u 31 128 377 20.769 2.413
4.933
+louie.udel.edu 128.175.60.175 2 u 68 128 377 14.909 0.049
5.794
+hickory.cc.colu 192.5.41.209 2 u 37 128 377 18.127 -3.150
14.517
LOCAL(0) LOCAL(0) 10 l 49 64 377 0.000 0.000
0.001
Note that the spread has widened to 5.629 milliseconds and that no two
of the five servers shows the same offset.
If I configured three servers and one became insane I would have two
working servers that disagreed with each other and ntpd would have no
means of determining which was most nearly correct!
More information about the questions
mailing list