[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