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

Tripathi, Anurag Anurag.Tripathi at symbol.com
Fri Jul 28 10:25:30 UTC 2006


David,

In the latest NTPd the leap bits and stratum will get updated at the
first time update from the server. So theoretically there shouldn't be
any discrepancy between ntpdc and ntpq outputs? 

BTW, I'm using a tarball with following version/timestamp :
ntp-stable-4.2.0a-20050816. 

Should the below mentioned change be there in this?

Thankyou,
Anurag

-----Original Message-----
From: questions-bounces at lists.ntp.isc.org
[mailto:questions-bounces at lists.ntp.isc.org] On Behalf Of David L. Mills
Sent: Wednesday, July 26, 2006 12:29 AM
To: questions at lists.ntp.isc.org
Subject: [ntp:questions] Re: ntpdc 'sysinfo' output inconsistent with
ntpq-poutput

Richard,

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.

Dave

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/2.6.13.4-ws-symbol", 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.

_______________________________________________
questions mailing list
questions at lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

________________________________________________________________________
This email has been scanned for computer viruses.

________________________________________________________________________
This email has been scanned for computer viruses.



More information about the questions mailing list