Fuzz, Numbers

[Hal Murray]

I found the missing line of code that was breaking no-FUZZ.  I found several 
other quirks while browsing the code.

I'm starting to work on performance numbers.

With no-FUZZ:

A Pi 3 can support 18-19K packets/sec.  22-23K with monitoring turned off.

An Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz is good for 160K packets/second.  
225K with monitoring turned off.

The with-monitoring (default) numbers are slightly optimistic since there is 
only one client.  Lots of clients would increase the working set.

Things were slightly faster a few days ago.  I don't know why.  I've seen 
similar quirks before.

On my to-do list is numbers with NTS.

--------

A major contribution to sloth was ntp_random().  Once upon a time, ntp had its 
own pseudo random number generator.  Back in 2015, that was changed to use the 
one in libsodium.  In Jan 2017, it was changed to use OpenSSL and the 31 bit 
limit was lost.

Anybody object if I get rid of libntp/ntp_random.c?  POSIX has random()  We 
can use it where we don't need crypto quality randomness.

Similarly, is there any reason not to use CLOCK_GETTIME() for timing?  
get_systime() has fuzzing which includes a call to randomness.

--------

The fuzzing code doesn't cleanly handle SO_TIMESTAMP (no NS).  Suppose you 
want to fuzz by 1/2 microsecond.  Your raw data has already been truncated to 
a whole microsecond.  Fuzzing might be appropriate if it were limited to the 
current time so we don't get packets leaving before they arrive.

FreeBSD has their own quirky ways to get more accurate time stamps.  I don't 
know why they didn't implement SO_TIMESTAMPNS.  ???  We should investigate.

-- 
These are my opinions.  I hate spam.