Dave,
Notice toward the end of the calibration period adjtime() is called with
only a small offset, so issues like the slew rate and residual offset
are moot. Those calls should minimize the residual and the actual clock
time should be within the measuement offset. Apparentyl, at least the
FreeBSD mechanizm does not forget prior requests as the Solaris
mechanism does. I tried it with the kernel disabledd with the same result.
In the original precision time modifications for SunOS, Ultrix, OSF/1,
HP-UX and Solaris some fifteen years ago, the kernels conformed to the
original BSD semanitcs and all this claptrap about measuring clock
frequency worked just fine. From recent experiments with initial clock
offset in the 30-50 ms and hardware clock errors to 40 PPM, all this
worked fine. I storngly suspect at least the Solaris and Tru64 precision
time kernels have not been modified, but the adjtime() semantics has, at
least for relativley large initial offsets. It is not an issue of
limiting the slew rate to less than 500 PPM, as that is in fact the
result shown in the looopstats trace. It seems at least some kernels do
not forget past programmed offsets when presented with new ones. For
that reason if no other, the mission to measure the intrinsic clock
offset with large initial offsets is dead in the water.
The source will be modified to entirely avoid all such initial training.
Dave
Dave Hart wrote:
On Mon, Nov 8, 2010 at 05:14 UTC, David L. Mills <mi...@udel.edu> wrote:
Thanks for the test. I verified the same thing. Note that the measured
offset at the end of the frequency measurement phase was very small, so the
net frequency measurement should be the same as Solaris. Obviously, FreeBSD
is doing something very different than Solaris. I suspect Linux is doing
something completely different as well. At this point I am prepared to
abandon the mission entirely, as I don't want to get bogged down with the
specifics of each idiosyncratic operating system. Accordingly, I will back
out all the changes and revert to the bad old ugly algorithms.
That is disappointing but I understand your frustration. I was hoping
the remainder returned by adjtime() would allow ntpd to know exactly
how much the OS had in fact slewed the clock, adapting to differing
adjtime() implementations.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
