[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second

Terje Mathisen "terje.mathisen at tmsw.no" at ntp.org
Fri Mar 23 17:12:11 UTC 2012


Miroslav Lichvar wrote:
> On Fri, Mar 23, 2012 at 11:49:19AM +0100, Terje Mathisen wrote:
> 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.

Oh but it can!

Check out "huff-puff"!

You can easily tell ntpd to coast past multi-hour periods of excessive 
delays/traffic.

>
>> 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.

They keep the best sample from each of four periods, each period can be 
up to 10+ hours, then they do a second set of validity checks on the 
four surviving samples, before the final curve fitting to determine the 
actual drift rate.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"



More information about the questions mailing list