[ntp:questions] drift value very large and very unstable
Rob Neal
hundoj at comcast.net
Thu Mar 6 13:49:57 UTC 2008
On Wed, 5 Mar 2008, Andy Helten wrote:
>
> I think I have been giving it enough time to stabilize -- any test I
> consider legitimate was allowed to run for at least 8 hours. Most tests
> ran overnight for 18-24 hours and some tests ran over weekends for
> nearly 72 hours. Results were always the same (very large drift). In
> fact, if allowed to run long enough, the drift almost always reached the
> +/-500 max.
The drift only tells part of the story. What is the offset
doing? Does it cross zero and continue to diverge, or is
it still headed to zero?
>
> The tinker commands are also necessary (at least disabling the step) due
> to some commercial software that has serious problems with backward time
> steps. This problem should be fixed in a future version, but that may
> not be soon enough for us. Even then, we may not want time to step
> backwards.
There is a reason they are options. Try setting your clock
by hand an hour or so off, and starting ntpd. Watch the
time it reports while it plays catch-up. Scary.
Your call, but it would probably fail an audit.
>
> Regarding the kernel's HZ value and its relation to time loss/gain, is
> there a way to determine the actual value at runtime? I want the value
> of HZ that is actually in use in the running kernel. I wasn't able to
> find a way to do this. By the HZ macro in /usr/include, I get a value
> of 100 and by the "/boot/config-*" file I see a value of 250. This is
> why I would like a sysctl type value or /proc entry with the actual HZ
> value, not a macro or config file. Any ideas?
Kernel sysctl of some sort. Consult the Linux kernelmongers.
>
> Thanks,
> Andy
>
> sbc1 root 31->ntpq
> ntpq> pe
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *GPS_BANC(0) .BTFP. 0 l 4 16 377 0.000 9.121
> 3.489
Jitter is ugly for an attached refclock. You have something
bad happening, this should be much lower.
> ntpq> as
>
> ind assID status conf reach auth condition last_event cnt
> ===========================================================
> 1 13451 9614 yes yes none sys.peer reachable 1
> ntpq> rv &1
> assID=13451 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
> srcadr=GPS_BANC(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
> stratum=0, precision=-21, rootdelay=0.000, rootdispersion=0.000,
> refid=BTFP, reach=377, unreach=0, hmode=3, pmode=4, hpoll=4, ppoll=10,
> flash=00 ok, keyid=0, ttl=64, offset=9.121, delay=0.000,
> dispersion=0.236, jitter=3.489,
> reftime=c0311460.c183a17a Wed, Mar 6 2002 17:19:12.755,
> org=c0311460.c183a17a Wed, Mar 6 2002 17:19:12.755,
> rec=c0311460.c18428f8 Wed, Mar 6 2002 17:19:12.755,
> xmt=c0311460.c1831775 Wed, Mar 6 2002 17:19:12.755,
> filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
> filtoffset= 9.12 9.76 10.44 11.20 12.02 12.93 13.86 14.90,
> filtdisp= 0.00 0.24 0.48 0.74 0.99 1.26 1.52
1.79
Looks like the offset is still trending to zero, with a
long way to go.
Rob
More information about the questions
mailing list