[ntp:questions] Re: synchronization

Richard B. Gilbert rgilbert88 at comcast.net
Fri Mar 10 18:47:44 UTC 2006


Ron Croonenberg wrote:

> Richard B. Gilbert wrote:
> 
>>> noquery
>>
>>
>>
>> noquery, on a line by itself is invalid!!!!  If it were valid, you 
>> would be shooting yourself in the foot because "noquery" means "do not 
>> respond to querys" which means your server couldn't serve time anyway!!!!
> 
> 
> Well..  I took the "default" config file and it was in there..  so I 
> left it there.
> 
>>> ============================================================================== 
>>>
>>> +time-b.nist.gov .ACTS.           1 u   43   64  377   36.473  
>>> 3598.51 33.187
>>> *tick.usnogps.na .USNO.           1 u   50   64  377  107.202  
>>> 3594.40 31.645
>>> +NAVOBS1.MIT.EDU .PSC.            1 u   43   64  377   36.762  
>>> 3596.60 32.328
>>> ********************************************************
>>
>>
>>
>> This is a pretty dismal looking ntpq banner!!  The offsets say that 
>> your clock is off by more than three seconds.  At the maximum slew 
>> rate of 500 parts per million, it will take several hours to bring 
>> your clock into synchronization.
> 
> 
> yes I know..  that's why I noticed there to be a problem
> 
>> How are you starting ntpd?  What options are you using?  If you use 
>> the -g option, ntpd should set the clock unconditionally at startup; 
>> e.g. it should query the servers to find out what time it is and then 
>> set your clock to that time.
> 
> 
> I start it with : 'service ntpd start"
> That results into : ntpd -U ntp -p /var/run/ntpd.pid
> 
>> Next, the three servers you are using appear poorly chosen.   You 
>> should not be using stratum 1 servers unless you will be serving time 
>> to several hundred clients!  All the public stratum 1 servers are 
>> generally loaded to the breaking point and should be avoided if 
>> possible.  The figures for round trip delay are quite high!  107 
>> milliseconds is downright unreasonable!  36 is not very good either.  
>> The highest delay I have is 19 milliseonds.   Look for servers closer 
>> to you; e.g. with shorter round trip delays.
> 
> 
> Ok..  so how do I find different servers ?

http://ntp.isc.org/bin/view/Servers/WebHome
has lists of all public stratum 1 and stratum 2 servers.  Look for 
servers near you in geographical space and test them for nearness in net 
space (low round trip delays).  The last time I looked, there were about 
200 stratum 1 and 200 stratum 2 servers listed.

Also see http://ntp.isc.org/bin/view/Servers/NTPPoolServers
You have little choice of pool servers; you can ask for one in "Europe" 
or "US", etc. but if you are in New York, you may be assigned a pool 
server in California.  The pool is intended to supplement, not replace 
your choice of servers.

As others have pointed out; I forgot to bash Linux for its handling of 
clock interrupts and to suggest a hardware problem with your client's clock.

Some versions of Linux default to updating the clock at rates of 250, 
1000, or 2000 HZ which makes it likely that device drivers will mask or 
disable the clock interrupt long enough to lose more than one clock 
interrupt.  Setting the update frequency to 100 Hz has been known to 
work wonders.

ntpd cannot correct a frequency error greater than 500 PPM which 
translates to about 43 seconds per day of clock drift.  It's rare for a 
computer clock to be that far off but it has been known to happen.  Most 
  clocks fall in the +/- 50 PPM range.  If your system, without ntpd 
running, gains or loses more than 43 seconds per day, ntpd can't do a 
thing for it.  Possible fixes include replacing the mother board or 
tinkering with the tick rate via the adjtimex command.




More information about the questions mailing list