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. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
