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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
