Yo Fred! On Tue, 24 Jan 2017 15:22:20 -0800 (PST) Fred Wright <f...@fwright.net> wrote:
> On Tue, 24 Jan 2017, Gary E. Miller wrote: > > > Last week we had a discussion on sys_fuzz and the value of adding > > random noise to some measurements. The code defi2nes sys_fuzz asL > > > > "* The sys_fuzz variable measures the minimum time to read the > > system > > * clock, regardless of its precision." > > > > Rondomness of half the sys_fuzz is then added to some values, like > > this: > > > > fuzz = ntp_random() * 2. / FRAC * sys_fuzz > > > > Makes no sense to me. Adding randomness helps when you have > > hysteresis, stiction, friction, lash and some other things, but > > none of those apply to NTP. > > Basing it on the time to *read* the clock definitely makes no sense, > although I suspect one would have to dig back fairly far in the > history to determine the source of that confusion. Just look at that commit, and compare to the bug report. The confusion is obvious there... > If one is dithering, the amount of dither should be based on the > clock's actual resolution, *not* the time required to read it. In a > sampled system, one would add dither equal to the quantization > interval, in order to produce results statistically similar to > sampling with infinite resolution. For time values, one would add > dither equal to the clock's counting period, to produce results > statistically similar to a clock running at infinite frequency. Possibly, but that is not how it works now. And would it be an improvement? Bring on the experiments! > > There is an additional worm in this can. Some OSes with crappy > > clocks bumped the clock by a tiny bit each time you read it so that > > all clock-reads returned different results and you could use it for > > making unique IDs. > > That's not uncommon, but it's a really bad idea. Demanding that a > clock always return unique values is an unwarranted extension of the > job description of a clock. Well then, you just said the current NTP implementation is a bad idea. In practice, with nano Second resolution clocks doing CLOCK_MONOTOMIC is not hard. > The proper way to derive unique values > from a clock is to wrap it with something that fudges *its* values as > needed, without inflicting lies on the clock itself. Sorta circular since NTP reads the system clock, applies fudge, then adjusts the sysclock t match. > Also note that in some contexts it's reasonable to extend the > resolution of a "coarse" clock (without breaking "fine" clocks) by > reading the clock in a loop until the value changes. This approach > is completely neutered by a uniqueness kludge. I do not see how that helps NTP, just adds latency. > 1) If it's a "coarse" clock, then dithering destroys monotonicity. Did you read the bug report? That is exactly what was happening, and worse, Thus the fix. > 2) Determining the proper amount of dither isn't necessarily easy. Yup. > The clock_getres() function is supposed to report the actual clock > resolution, which is what should determine the amount of dither, but > in practice it's rarely correctly implemented. E.g., in the Linux > cases I've tested, it ignores the hardware properties and just retuns > 1ns. And it probably can not even determine the hardware properties. > I'm not convinced that sub-microsecond dithering is worthwhile, > anyway. If the dithering code is retained at all, it might make sense > to have a configure test that reads clock_getres(), and only enables > dithering support if the result is more than a microsecond. That > test would be unaffected by the aforementioned lies in > clock_getres(). Though there'd need to be a way to force dithering > on for testing, since it's unlikely that any test platforms would use > it naturally. And those sorts of configure tests are problematic for > cross-building. Even the clock_getres() man page warns the return values may return "bogus results". Next... > BTW, if the only use for randomness is for computational dithering, > and not for security, then there's no need for crypto-quality > randomness. So far that looks like the case, plus adding a nonce in the LSB's of timestamps. But that will not last, the autokey replacement should be here 'soon'. This year or next. > In that case, why not just read /dev/urandom directly > and dispense with the whole libsodium mess? All ntpd uses libsodium for is to read /dev/urandom, and for the many cases that /dev/urandom does not exist, or better exists, then some other way. I'd rather see it go too, but I see no easy path to get there. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin
pgp6E8rMkP7mt.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel