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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David L. Mills Sent: Wednesday, July 26, 2006 12:29 AM To: questions@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 [EMAIL PROTECTED] Thu Mar 16 13:07:10 IST 2006 (1)" >> Ntpdc version: "ntpdc [EMAIL PROTECTED] 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@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. _______________________________________________ questions mailing list questions@lists.ntp.isc.org https://lists.ntp.isc.org/mailman/listinfo/questions
