Re: high precision tracking: trying to understand sudden jumps

"Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx> writes:

"Unruh" <unruh-spam@xxxxxxxxxxxxxx> wrote in message
news:VLTHj.7067$pb5.722@xxxxxxxxxxx
"Richard B. Gilbert" <rgilbert88@xxxxxxxxxxx> 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
again.

??? What you are descibing in one of the key problems with the ntp
algorithm.



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.

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.



Groetjes,
Maarten Wiltink


.

Relevant Pages

  • Re: high precision tracking: trying to understand sudden jumps
    ... ntp itself that mandates a longer poll interval. ... interval makes ntp much more responsive to changes (clock drifts, ... Given the measurement error, you need to let the small error ... Now use more realistic numbers, like 50 PPM to start with, a polling ...
    (comp.protocols.time.ntp)
  • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
    ... Uses NTP to modify the clock frequency value rather then just ... > adjustment, which should be applied every f cycles. ... Your design seems to suggest keeping an NTP calculated reference time ...
    (Linux-Kernel)
  • Re: ntp discipline of local time?
    ... Principles and Precision Time Synchronization briefings on the NTP project page are old but applicable. ... The details you are asking for are carefully explained in the NTPv4 spec. ... like the clock state machine and poll-adjust algorithm continue in the daemon. ... factor from CPU cycles to time) and get rid of the offset. ...
    (comp.protocols.time.ntp)
  • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
    ... >> The basic idea behind this is that ntp defines the frequency of the ... >> adjustment, which should be applied every f cycles. ... >> which allows for a very stable clock. ... >> resolution is still well within the practical limits of the clock. ...
    (Linux-Kernel)
  • Re: ntp discipline of local time?
    ... Principles and Precision Time Synchronization briefings on the NTP ... does two things-- set the system clock frequency (ie adjust the conversion ... factor from CPU cycles to time) and get rid of the offset. ... frequency and phase errors. ...
    (comp.protocols.time.ntp)