Dave,
I don't think that is right. The adjtime() call can be in principle
anything, accoridng to the Solaris and FreeBSD man pages, but the rate
of adjustment is fixed at 500 PPM in the Unix implementation. If the
Linux argument is limited to 500 microseconds, Linux is essentially
unusable with NTP. I would be surprised if this were the case.
Dave
Dave Hart wrote:
On Wed, Nov 3, 2010 at 09:24 UTC, Miroslav Lichvar <[email protected]> wrote:
On Tue, Nov 02, 2010 at 10:03:30PM +0000, David L. Mills wrote:
I ran the same test here on four different machines with the
expected results. These included Solaris on both SPARC and Intel
machines, as well as two FreeBSD machines.
[...]
Ok, I think I have found the problem. The adj_systime() routine is
called from adj_host_clock() with adjustments over 500 microseconds,
which means ntpd is trying to adjust the clock at a rate higher than
what uses the Linux adjtime(). It can't keep up and the lost offset
correction is what makes the ~170ppm frequency error.
Congratulations on isolating the problem. If adjtime() is returning
failure, ntpd will log that mentioning adj_systime. Do you see any of
those?
Is it a feature or a bug that FreeBSD and Solaris can apparently slew
faster than 500 PPM using adjtime()?
If it's a feature, is there a way we can detect at configure time what
the adjtime() slew limit is without actually trying it? We don't want
to require root for configure.
Thanks for all the attention you've been putting towards the reference
implementation recently, Miroslav. You have found a bunch of issues
and reported them, usually shortly after the inducing changes. You've
helped keep the quality up despite a lot of development churn.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
