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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
