[ntp:questions] high precision tracking: trying to understand sudden jumps
unruh-spam at physics.ubc.ca
Mon Mar 31 04:50:00 UTC 2008
"Maarten Wiltink" <maarten at kittensandcats.net> writes:
>"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.
I have no idea what this means. ntp simply runs a second order feedback
network It does not do anything for "large and small" errors.
>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.
No idea what you mean.
>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.
You are not talking about large and small errors, you aree talking about
phase and frequency errors. And no computer has fixed eitehr phase of
frequency errors. They keep changing. Thus integrating for a longer time
does not help if the frequency errors ( drift) keeps changing.
>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
??? What you are descibing in one of the key problems with the ntp
>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
Anyway, that is not his problem. He is getting ms spikes in the loopfilter.
Those wipe out anything else he does. It destroys all attempts by ntp to
discipline the clock.
More information about the questions