[ntp:questions] Thoughts on huff and puff
David L. Mills
mills at udel.edu
Sat Oct 11 13:04:10 UTC 2008
The huff-'n-puff scheme was never intended to be universally applicable.
It is intended for the poor bloke with an overloaded DSL line to an ISP
and very little else. It could be further engineered as you propose and
others are welcome to do that. You should understand that would be a
difficult and complex project.
The the local clock driver (and modem driver) is not used unless all
outside connectivity is lost and even in that case the orphan mode is
preferable. Using a radio reference clock with an overloaded DST backup
is not a good idea. If the reference clock fails, the server continues
to be a good source for many hours until the distance threshold is
exceeded. Even after that orphan mode would be preferable over a highly
congested DSL link.
You claim that a method to designate which inbound/outbound link
congestion is preset. The h-f scheme is expressly design to determine
that and adapt accordingly, especially when the congestion surge
switches from one direction to the other. If you examine the mathematics
carefully, you will discover the sign determination is necessary in
order to determine which limb of the scattergram is congested. See my
book for further discussion and especially the experiments with Malaysia.
Your comment that NTP handles startup and temperature changes badly may
very well be the case. But, you present only anecdotal evidence, no
simulation, no statistical analysis and no quantitative comparison with
alternative methods. I have no problem with alternative methods as long
as they are justified by analysis, statistical justification and proof
by experiment or simulation.
David Woolley wrote:
> I had cause to look at tinker huffpuff recently and a number of things
> concern me.
> 1) It is applied globally, and that seems to include reference clocks,
> including the local clock (which you can expect to find on most real
> world configurations, even though it is often inappropriate for them).
> That means that the presence of a reference clock as a reference, or the
> use of another source on the same LAN may artificially depress the
> estimate of the minimum delay.
> Ideally it should be done per association, and if that is too expensive,
> one should be able to opt servers into the the mechanism, which one
> would, probably, only then do for ones LAN servers. It should not be
> applied to reference clocks in general and certainly should not be
> applied to the local clock.
> 2) Its method for determining the sign of the correction is
> oversimplistic. It would probably work if the actual clock error was
> small, but, as we've seen discussed recently, ntpd handles real world
> startup and temperature change transients poorly, which could result in
> huff and puff trying to increase the error.
> In many cases where huffpuff would be useful, one knows that the
> asymmetry is overwhelmingly in one direction and there needs to be a way
> of conveying that information.
More information about the questions