[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