Quoting Kurt Roeckx <k...@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 <strom...@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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
