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
