[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