sys_fuzzMime-Version: 1.0

[Gary E. Miller]

Yo Fred!

On Tue, 24 Jan 2017 15:22:20 -0800 (PST)
Fred Wright <fw at 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
	gem at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170124/7faf3b9e/attachment.bin>