[ntp:questions] Can't Understand NTP behaviour,

[Richard B. Gilbert]

On 6/24/2011 2:45 AM, Pranay Kumar Srivastava wrote:
> In our NTP client-server setup which is done locally, we've 3 servers each made to synchronize with its own local clock only.
>

First mistake!!  The local clock is an extremely poor time keeper.

> The client is having the entries of these 3 servers. The following is the output snippet of ntpq -p taken over a period of 1 hour at regular intervals of 5 seconds.
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   10.58.80.9      .STEP.          16 u   66   64    0    0.000    0.000   0.001
>   10.58.80.3      .STEP.          16 u  272   64    0    0.000    0.000   0.001
>   10.58.80.65     LOCAL(0)         6 u   11   64    1    0.279  -144779   0.001
>   LOCAL(0)        .LOCL.          10 l    3   16    1    0.000    0.000   0.001
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   10.58.80.9      LOCAL(0)         4 u  192   64    3    0.261  144785.   0.330
>   10.58.80.3      LOCAL(0)        11 u  164   64    3    0.261  2183.05   4.762
>   10.58.80.65     LOCAL(0)         6 u  191   64    3    0.263   -1.117   0.689
> *LOCAL(0)        .LOCL.          10 l  156   16   77    0.000    0.000   0.001
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> x10.58.80.9      LOCAL(0)         4 u   13   64   17    0.320   -1.480   0.638
> *10.58.80.3      LOCAL(0)        11 u    2   64   17    0.248  -142506  10.778
>   10.58.80.65     LOCAL(0)         6 u   38   64    7    0.245  -144793   0.993
>   LOCAL(0)        .LOCL.          10 l   15   16  377    0.000    0.000   0.001
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *10.58.80.9      LOCAL(0)         4 u  170   64   17    0.339  144797.   0.612
> x10.58.80.3      LOCAL(0)        11 u  188   64   17    0.248  2385.51  10.642
> x10.58.80.65     LOCAL(0)         6 u  147   64   37    0.210   -3.332   1.887
>   LOCAL(0)        .LOCL.          10 l  154   16  377    0.000    0.000   0.001
>
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> x10.58.80.9      LOCAL(0)         4 u    1   64   37    0.316   -1.978   0.782
> x10.58.80.3      LOCAL(0)        11 u   26   64   37    0.212  -142314  13.185
> *10.58.80.65     LOCAL(0)         6 u   53   64   37    0.197  -144806   2.011
>   LOCAL(0)        .LOCL.          10 l    4   16  377    0.000    0.000   0.001
>
>
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *10.58.80.9      LOCAL(0)         4 u  197   64   77    0.318  144810.   0.976
> x10.58.80.3      LOCAL(0)        11 u  208   64   77    0.209  2567.32  16.049
> x10.58.80.65     LOCAL(0)         6 u  148   64  177    0.277   -4.718   2.614
>   LOCAL(0)        .LOCL.          10 l  160   16  377    0.000    0.000   0.001
>
>
>
>
> The client chooses the server with a high value of offset initially. Then, when the offset lowers down, it discards it as a falseticker but chooses another server with high offset value. Why is this toggle taking place and the synchronization is being done with a server having high offset value any reason for this?
>
> Ntpdate wasn't run on the client before starting the ntp daemon. It's not possible for us to run ntpdate on the client that's one of the constraints. Please advise on this behaviour of ntp.
>

Try using real NTP servers that KNOW WHAT TIME IT IS!

The best source of time IMHO is a GPS Timing Receiver.  Note that GPS 
Receivers can also be designed for navigation.  For timing service you 
should take care to get a receiver designed for the purpose!  Either 
kind necessarily knows what time it is but a receiver designed for 
Navigation is concerned with latitude, longitude, and elevation and 
delivering this information.  Delivering accurate time is its lowest 
priority.