[ntp:questions] Re: ntpdc 'sysinfo' output inconsistent with ntpq-p output

David L. Mills mills at udel.edu
Tue Jul 25 18:58:47 UTC 2006


At cold start (no frequency file) the daemon sets the clock at the first 
update, then waits 15 minutes, measures and corrects the frequency 
(usually within 1 PPM) and assumes normal operation. This saves many 
hours to converge the frequency within 1 PPM, especially if the 
intrinsic frequency error is large, like 200 PPM.

Until the frequency is corrected, the machine can have serious offset 
and frequency errors that would drive dependent clients nuts. Up to now, 
the leap bits and stratum were not initialized until the frequency was 
corrected. However, the clock was set and local clients were free to 
believe or not believe the clock. After review, the external behavior is 
only mildly worse than without the initial training period, so the leap 
bits and stratum are now set at the first update. The billboards should 
now be consistent with the Principle of Least Astonishment.

Having revealed thus, the billboards on both ntpq and ntpdc should be 
the same, since they are derived from the same data. However, ntpdc has 
not been properly maintained for many years and there could well be bugs 
in that program. If ntpq and ntpdc disagree, use ntpq.

If the kernel discipline is available and the frequency file is not 
present, the kernel offset and frequency should be set to zero (ntptime 
-o 0 -f 0) first. This is the approved way to restart from scratch.


Richard B. Gilbert wrote:
> Tripathi, Anurag wrote:
>> Here is ntpq -crv output: ----
>> assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
>> event_peer/strat_chg,
>> version="ntpd 4.2.0a"?, processor="i686",
>> system="Linux/", leap=11, stratum=16, precision=-20,
>> rootdelay=0.000, rootdispersion=10.965, peer=17460, refid=INIT,
>> reftime=00000000.00000000  Thu, Feb  7 2036 11:58:16.000, poll=6,
>> clock=0xc86f5eb1.a257a786, state=3, offset=9.887, frequency=0.000,
>> noise=3.628, jitter=2.328, stability=0.000
>> ------
>> As suggested earlier after 30mins 'ntpdc sysinfo' starts showing the
>> correct information i.e. 'synched'.
>> But isn't 30mins too long a delay for show an information which ntpq
>> declares within seconds?
>> More importantly is there anyway I can reduce/minimize this time lag?
>> (some keyword or configuration?)
>> This would be helpful!
>> Regards,
>> Anurag
>> Other requested info:
>> Ntpq version: "ntpq 4.2.0a at 1.1196-r Thu Mar 16 13:07:10 IST 2006 (1)"
>> Ntpdc version: "ntpdc 4.2.0a at 1.1196-r Thu Mar 16 13:07:07 IST 2006 (1)"
> Ntpd can select a synchronization source very quickly, especially if you 
> use "iburst" on your server lines in ntp.conf.
> It can take far longer for ntpd to bring your local clock into close 
> agreement with UTC where "close" means < 20 milliseconds.
> You can reduce the time required by using the -g option when you start 
> ntpd.  That will cause ntpd to set the clock unconditionally to 
> something close to the correct time.  Ntpd will still require some time 
> to adjust the speed of your local clock so that it neither gains nor 
> loses time.
> A "cold" start (no drift file) of ntpd can take many hours to reach a 
> stable state with both the correct time and the correct frequency 
> adjustment.  A warm start is faster but can still require twenty or 
> thirty minutes to beat your local clock into submission. :-)
> You can probably see similar results from ntpq and ntpdc in far less 
> time than thirty minutes.  As nearly as we could tell, you had allowed 
> less than two minutes since startup.

More information about the questions mailing list