Hello!
What you say is that the "frequency" value is the currently applied
"frequency compensation", e.g. a negative value means that the system
clock had to be slowed down in order to synchronize with the reference
clock. That explains why this value is referred to as "drift_comp"
internally.
So calling this value "frequency error" - as I did - is misleading. The
"frequency error" is the offset I measure in comparison to the reference
clock, e.g. a negative value implies that the system clock runs too slow
and that it's clock frequency has to be increased in order to
synchronize. "frequency errror" thusly has the same magnitude but
reversed sign as "frequency compensation". Is this Nitpicking?
I'm still puzzled that I could not find above information on either
http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html
or the FAQ at http://www.ntp.org/ntpfaq/NTP-a-faq.htm
But I rest assured it's in the RFC somewhere - as the Big Lebowski said:
"It's uh... it's down there somewhere, let me take another look."
:-)
Cheers
Daniel
Maarten Wiltink wrote:
"Maarten Wiltink" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[...]
The frequency offset is scaled from PPM to clock precision and added
to the increment. So a value of +40 would result in 1.040 ms being
added to the internal time on every tick, ...
No, wait, that's not right. Since it's added to the clock 1000 times
per second, it should be 1.000040 ms to come out at 40 PPM (µs/s) after
a thousand ticks.
Groetjes,
Maarten Wiltink
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
