[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
mlichvar at redhat.com
Fri Mar 23 13:07:48 UTC 2012
On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote:
> unruh wrote:
> >No I would not. That is not what ntpd does. It really does throw away 7
> >of the samples and never uses them. The whole question is what is the
> >best statistic to use. I do not believe that the "shortest roundtrip
> >time" is that best statistic. If you could convince me it is, I would be
> >more than happy to have ntp use it.
> In _some_ scenarios, keeping only the minimum rttsample is indeed
> the best approach:
Yes, it depends on the network jitter and clock stability. But ntpd
doesn't try to estimate the stability and uses a fixed dispersion rate
and Allan intercept in the filter algorithm (15 ppm and 1024 sec by
default). By tweaking the constants you can change the ratio of
But I think a much bigger problem with the clock filter and PLL
combination is that it can't drop more than 7 samples. When the
network is saturated, it's usually better to drop much more than. If
the increase in delay is 1 second and the clock is good to 10 ppm, it
could wait for days before accepting another sample.
> In order to be considered OK, we can't accept more than 50 ppb
> frequency offset.
> Handling this with up to 50 ms sawtooth variation (with periods up
> to several hours) in the one-way latency means that the vendor
> require sampling periods of up to 10+ hours, with multiple
> packets/second and then keeping a single packet at the end.
That seems excessive. Do they set the frequency directly just from the
last two samples? With PLL or similar, increasing the time constant
accordingly might be a better approach.
More information about the questions