# [ntp:questions] Re: Interpretation of frequency error / drift_comp

Daniel Kabs daniel.kabs at gmx.de
Thu Mar 2 08:39:17 UTC 2006

```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" <maarten at kittensandcats.net> wrote in message
> news:43fdf0b8\$0\$11070\$e4fe514c at news.xs4all.nl...
> [...]
>
>>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

```