[ntp:questions] Re: [Bug 177] Clock stepping messes up frequency. (fwd)

David L. Mills mills at udel.edu
Fri Oct 24 02:30:43 UTC 2003


You have a classic case of huf-n'-puffitis. The delay varies throughout
the day starting at moderate values near day's beginning rising to 0.8
second near second 70000 then falling to a few tens of milliseconds
until day's end. Note the offset follows the delay very roughly a factor
of two below it. This is classic assymetric delay characteristic the
huff-n'-puff filter was specifically designed to deal with.

The peerstats data show the surges are not isolated spikes, but a
sustained delay/offset regime lasting well over an hour. A more refined
frequency adjustment algorithm would not help here. I would be
interested to see what happens if switch in the h-f filter.

But, here's the rub. With regimes like yours, I didn't expect folks
would use poll intervals as large as yours nor did I expect the poll
interval to change much. The filter attempts to measure the minimum
delay (bottom fisher) over intervals from minutes to hours using
mulitple samples; however, you might have only one or two polls during
that interval. That might work as long as the interval is long enough
that one of the samples is during the quiet hours. So, "tinker huffpuff
10" would probably do it. But, if the clock was stepped, the poll
interval might sink so low that the 10 polls could occur in only a few

This tells me the huffpuff design needs to be improved so that it is not
the number of polls that is the parameter but the interval length in
seconds. While I put that on the todo list, you should try the tinker as
given. Then set up "minpoll 10", which will force the poll to at least
1024 s and give the h-f filter some interval to chew on.


Roy wrote:
[deleted by fascist news system]

More information about the questions mailing list