Daniel,
Yes.
Dave
Daniel Kabs wrote:
Hello!
David L. Mills wrote:
I'm not making sense with your mission. The measurements you qoute are
quite reasonable in that they argree to within a fraction PPM. That's
what I would expect.
You are referring to Plan B, I guess:
My tests show that acquiring the time offset using either ntpdate
(remotely) or the offset value (locally) and then least-squares fitting
both data sets gives a slope that agrees within the sub-PPM regime.
However, what's with the 500 ms per day?
That's the 6 PPM difference I get comparing the results from Plan A
(have ntpd record the drift file) and Plan B (use the time offset and do
a least-squares fit). I wonder if this is the expected precision in
measuring the system clock's frequency error.
There is no such provision or expectation in the specification or
implementation. The maximum frequency tolerance is 500 PPM, which
works out to about 43 seconds per day. Your measurements about 23
seconds per day are well within that tolerance.
What's the "frequency tolerance" you are referring to? I reckon that's
the system clocks's maximum frequency error that ntpd can compensate.
Cheers
Daniel
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
