[ntp:questions] Thoughts on huff and puff

David L. Mills mills at udel.edu
Sat Oct 11 13:04:10 UTC 2008


David,

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.

Dave

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 mailing list