✘sys_fuzz * ntp_random()

[Gary E. Miller]

Yo Achim!

On Wed, 25 Jan 2017 18:36:13 +0100
Achim Gratz <Stromeko at nexgo.de> wrote:

> Gary E. Miller writes:
> > Dr. Mills did not put it there.  This was added in 2011 by Dave
> > hart. See my previous email that probably crossed by yours in
> > flight.  
> 
> The way I read things, Dave Hart's patches were to ascertain
> monotonicity on top of the already existing fuzzing.

Yes.  I was saying that sys_fuzz was new then, and the algorithm
had a serious complexity upgrade then.  So what happened before 2011
not very relevant anymore.

> > It proves that sys_fuzz does nothing on a RasPi.  At least
> > undetectable over 4 days.  I give you it proves nothing about other
> > systems.  
> 
> The fuzz we are talking about is added to outgoing timestamps, so when
> it did something it wouldn't be discernible on the server, but on the
> client receiving that timestamp.  In other words, you are looking at
> the wrong end of the data (I think).

No, the fuzz we are talking about is added to everything.  One
place the fuzz is added is in libntp/systime.c in normalize_time()
which is called from get_systime().  Everyplace ntpd gets a time it
now uses get_systime().  Except two oddball drivers: jjy and oncore.



> > I'll once again raise the challenge to someone else to prove it
> > actually does something, somewhere.  No point involving deities or
> > more bike shedding, give me data!  
> 
> You can make such requests ad inifinitum, but it won't help.  Unless
> you know what exactly the problem was that fuzzing solves, you won't
> be able to pick out that set of data that shows you whether it is or
> is not still needed.

And by your own argument, you are not adding anything either, until you
find a real problem space.

> > Now knowing more about bug 2037 I'm also confident that the
> > characteristics of the RasPi clock where not those being fixed in
> > bug 2037.  
> 
> That bug was about monotonicity of the timestamps, not the fuzzig
> itself, IIRC.

Yes, but it caused the creation of sys_fuzz and the current fuzzing
scheme.

> Again, you need to know what problem this code was solving (before the
> patches from Dave Hart, which were solving a different and probably
> more specific problem most likely) in order to know if the
> assumptions that made it necessary or useful still hold.

I thought bug 2037 , and the bug 2037 fixed, explained that nicely.  Do
you know something else not 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/20170125/eb2e7f8d/attachment.bin>