[ntp:questions] high precision tracking: trying to understand sudden jumps

Maarten Wiltink maarten at kittensandcats.net
Sun Mar 30 22:21:07 UTC 2008


"Unruh" <unruh-spam at physics.ubc.ca> wrote in message
news:VLTHj.7067$pb5.722 at edtnps89...
> "Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>> Forcing the poll interval to 16 seconds is not always a good idea!
>> Ntpd will select a poll interval, generally starting at 64 seconds,
>> and ramping up to as long as 1024 seconds as the clock is beaten
>> into submission!
>
> It is his network, he is not going to overload it. So, if he wants a
> 16 sec poll interval that is up to him.
> I agree it is not a good idea for remote servers, but on his own system
> it is fine.
[...]
> ??? The longer polls are in order not to swamp the remote server whith
> 10000 people all polling every 16 sec ( or 1 sec) There is nothing in
> ntp itself that mandates a longer poll interval. In fact a shorter poll
> interval makes ntp much more responsive to changes ( clock drifts, etc)

>> The very short poll intervals correct large errors quickly and the
>> very long intervals correct small errors very accurately!
>
> No for a properly designed system both should be corrected.

You seem to be missing the point. Once the large errors have been
corrected, NTP goes on to the small errors. For that, it _needs_ a
longer poll interval. That this gives the server more air is a
happy coincidence, but not why it does it.

Given the measurement error, you need to let the small error
accumulate over a longer period. Otherwise it would simply be
lost in the noise.

Do the math: assume the (constant!) measurement error to be +/- 1 ms,
the frequency error in my local host to be 1000 PPM (1/1000). With a
1 s polling interval, the real value is 1 ms and the measurement
will be between 0 and 2 ms. Not very good. With a 1000 s polling
interval, the real value is 1 s and the measurement will be between
0.999 and 1.001 s. Now that's useful to correct your clock with.

Now use more realistic numbers, like 50 PPM to start with, a polling
interval of 64 s and I'm not exactly sure what for the measuring
jitter. But the gist should be clear: that 50 PPM will go down, the
SNR will worsen, and the polling interval should go up to improve it
again.

Starting with a short interval is good to correct large errors
quickly. Backing off once you've done so is good to avoid pestering
the server, but it's also good to correct small errors accurately,
and _that_ is why it's done. And of course, once a larger than
expected offset is measured, the polling interval is shortened
again.

Groetjes,
Maarten Wiltink





More information about the questions mailing list