How much do we care about high-load scenarios?

[Dan Drown]

Quoting Kurt Roeckx <kurt at roeckx.be>:
:
>> From my own testing with iperf high rate 64 byte UDP packets, max rate
>> before 1% receive packet loss:
>>
>> i3-540 / Intel 82574L nic: ~469kpps
>> Athlon(tm) 64 X2 4400+ / RTL8168 gig nic: ~64kpps
>> Odroid C2: ~62kpps
>> Raspberry Pi 2: ~19kpps
>> Beaglebone Black: ~9kpps
>> Raspberry Pi B+: ~4kpps
>
> Is there a way to make this ntp packets, or where those ntp
> packets?
>
> My guess is that you'll have plenty of CPU to process the maximum
> packets the nic can handle.  Once you add crypto this might change
> slightly.

Right, these were iperf tests, so ntp processing will lower those  
numbers.  Those numbers are "maximum theoretical" which will be higher  
than what's actually practical.

Quoting Achim Gratz <Stromeko at nexgo.de>:
> These are throughput numbers, not response time distributions.  I think
> it's an established fact from even a back-of-the-envelope calculation
> that NTP doesn't saturate a network link.  There's a glimpse of the delay
> distribution getting a fatter tail in the RADclock papers, but that data
> is sadly quite out of date by now.

Correct, my numbers don't include a measure of response time.  Proper  
measurement of response time (perhaps by using the IEEE1588 timers)  
would be nice.

> The average user can't tell the difference since he doesn't know where
> the variability in the remote NTP server comes from.  As anecdotal
> evidence, I've had to re-connect my VDSL this past weekend and now one
> of the two PTB servers shows a 100µs difference in offset, while the
> other hasn't changed, for a total of 200µs average difference between
> them.  I've moved the PPS offset on the GPS so that on average I'm
> keeping it in the middle of these two.  Due to the sequence of events
> it's clear that the network somehow produces this result and not some
> load on a server, but I couldn't know that in the general case.

Yes, network effects when dealing with a WAN can have very significant  
effects.  From equal-cost multipath routes to other sources of  
asymmetric latency, absolute offset numbers get fuzzier as the latency  
goes up.