hmurray at megapathdsl.net
Sun Dec 29 03:52:59 UTC 2019
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.
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.
More information about the devel