On Friday 28 September 2007 21.25:37 Todd wrote: > remote refid st t when poll reach delay offset jitter > == ================================================================== > +66.218.191.215 [..] 2 u 34 64 377 0.314 275.345 60.958 > +66.36.239.104 [..] 2 u 19 64 377 24.400 215.636 61.105 > *130.236.254.17 [..] 1 u 39 64 377 125.250 227.845 59.225 > -66.226.73.89 [..] 2 u 37 64 377 73.314 306.056 77.870
Why is your poll at 64? Unless your machine has an extremely unstable
clock, the poll values should go up to 1024s (ntpd default config) quickly.
I usually don't look at the jitter and offset until this has happened,
which means that ntpd has stabilised.
If you only just started this ntpd: give it time. If your poll values don't
go up to 1024s, either your internet connection has a huge jitter, or your
clock is seriously too fast/too slow so that ntpd cannot cope (it won't
correct for more than 500ppm clock wander afaik. You'll have to play
around with tickadj to correct the kernels idea of the clock speed to get
the clock within +/-500ppm, then ntpd will be able to sort out the
remaining difference.)
Quite a bit of math behind this, and I have no idea how good newer Linux
kernels are at timekeeping (don't know if you're running Linux, obviously),
I strongly suspect that the new tickless timer system has not improved
matters. But note that this is pure speculation - anyonoe did any testing?
(OTOH I have the impression that tickless has definitiely improved desktop
snappiness here, and I'm eagerly awaiting CFS - and to me, this is more
important than sub-microsecond timekeeping :-)
cheers
-- vbi
--
"It blows my mind that you can't get 3.5 ounces of toothpaste on a
plane," he said, "yet somebody can sneak on a plane and take a nap."
-- http://www.newsobserver.com/102/story/523482.html
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
