[ntp:questions] Thoughts on huff and puff

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sat Oct 11 10:09:07 UTC 2008


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