Fuzz, Numbers

[Mike Yurlov]

The synthetic load with only one client is far away from real production 
load of thousands of requests per second from around the world. As the 
owner of the production server from the ntppool, I am very interested in 
performance.

I suggest using the following realistic test mode: big source address 
subnet (i.e. /8 or 'all internet'); queries per sec 3-10-20k; duration 
5-30 minutes. Warming up, filling and overflow monlist plays a big role 
in CPU load. For me, a monlist size that fills in about 5 minutes is 
optimal.

I have not tried it myself, but Google say ntpperf 
(https://github.com/mlichvar/ntpperf) can generate such a stream of 
requests "from subnet".

--
Mike



29.12.2019 6:52, Hal Murray via devel пишет:
> 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.
>