> Ulrich,
>
> Have you tried xntp lately? I'm running xntp 3-5.89 under linux kernel
Well, aehm, have you read the Changelog? I contributed several xntp
patches to make it work well. I'm running 3-5.89.1 at home if you
care.
> 2.0.28, Red Hat 4.0 distribution plus the updates, and it is truly a gem.
> I'm very impressed. I'm cc:'ing Dave Mills; thank you, Dave, for not giving
> up on us! It really is running smoothly, almost like clockw--um,
> whatever... :) This is one user who's taking xntp out of the `active issues'
> file---it is so helpful to have a solid clock again! :)
Your special thanks should go to Harlan Stenn, the big integrator ;-)
He really tried hard to satisfy everyone, and he did a good job on
autoconf and maintaining the sources. Also unified diffs and gzipped
files are accepted now ;-)
> >frequency: 0.000 ppm
> >stability: 27.473 ppm
For a remote clock the values aren't bad, but I experienced several
and severe frequency jumps like -136ppm. I'm afraid the main source
is some latency in scheduling that I can't explain. Maybe things will
be getting better once Linux has a real-time scheduler and bounded
scheduling delays.
> >xntpdc> kerninfo
> >
> >pll offset: 0 us
> >pll frequency: -104.919 ppm
With that drift you might adjust your tick value to 9999 (on ix86).
Then your drift should be only 4.9ppm.
> >maximum error: 150904 us
> >estimated error: 96000 us
That error isn't too good; about 0.1 seconds; that's almost 10 timer
interrupts. I'm afraid you won't get much more with remote NTP
servers.
> >xntpdc>loopinfo
> >
> >offset: -0.081265 s
> >frequency: -77.857 ppm
Aha! You are having a severe problem: Due to tickadj being set to 1
the drift compensation is limited to the value seen above (and
displayed when xntpd starts up). To improve quality you can either
increase tickadj (which is 5 in reality) in ./configure, or you can
adjust the value of tick (see the util directory of xntp).
Ulrich