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

Jan Ceuleers janspam.ceuleers at skynet.be
Mon Jul 24 16:02:35 UTC 2006


Tripathi, Anurag wrote:
> 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?)

Just to avoid it being missed: a similar issue exists with ntptrace, 
which is a perl script that relies on ntpq -n -c rv being consistent 
across the trace.

An example of the contrary:

# ntptrace localhost ; ntpq -p localhost
localhost: stratum 1, offset 0.000087, synch distance 0.461839, refid '
'
      remote           refid      st t when poll reach   delay   offset 
  jitter
==============================================================================
  LOCAL(0)        .LOCL.          10 l   52   64  377    0.000    0.000 
   0.001
  GENERIC(0)      .DCFa.           0 l  976   64    0    0.000   -2.266 
   0.001
+cerber.obs.coe. 145.238.110.68   3 u  386 1024  377   67.058    0.866 
  0.244
*chronos.zedat.f .GPS.            1 u  363 1024  377   31.280    0.905 
  0.440
-salukes.opensou 185.55.101.136   2 u  324 1024  377   14.834    2.596 
  1.284
-217.71.122.144  80.190.252.238   3 u  327 1024  377   15.051   -4.640 
  3.759
+ntp1.belbone.be 195.13.23.250    2 u  337 1024  377   10.421    1.627 
  0.385
-time.ijs.si     193.2.4.2        2 u  331 1024  377   50.810    0.121 
  0.045
-bear.zoo.bt.co. 194.81.227.227   2 u  327 1024  375   23.634    5.755 
  1.546
  skr03.xperim.be 192.168.1.1      2 u  379 1024  377    0.760   -3.400 
   5.686


This shows that ntptrace (and hence ntpq -n -c rv localhost) is 
inconsistent with ntpq -p localhost. This is perfectly reproduceable on 
my system. Note that in this case the refclock has last produced a valid 
sample 976 seconds ago.

Note also that this issue causes ntptrace to incorrectly output the 
refid. In this particular case what is output seems to be a line feed, 
but sometimes it's a bit messier than that (e.g. Ctrl-E, causing my ssh 
client to output its ID string (PuTTY)).

Cheers, Jan




More information about the questions mailing list