How much do we care about high-load scenarios?
Eric S. Raymond
esr at thyrsus.com
Wed Sep 14 22:00:45 UTC 2016
Dan Drown <dan-ntp at drown.org>:
> Quoting "Eric S. Raymond" <esr at thyrsus.com>:
> >Achim Gratz <Stromeko at nexgo.de>:
> >>…or move the refclocks out of ntpd altogether and use some shared memory
> >>or mailbox system to have ntpd have a look at the timestamp stream from
> >>each refclock.
> >Yeah, this is one of my longer-term plans. It was in the original technical
> >proposal I wrote 18 months ago, labeled REFCLOCKD.
> I'll add my +1 to this, setting the local time is a logical process split
> from serving time to clients.
One good reason to do this that I've just realized recently is that if
we moved PPS handling to a refclockd we could take the timer tick out
of ntpd. This would lower power consumption in the pure-client case,
which I think is significant (consider embedded and mobile
> 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
> Even these low end machines would be able to serve thousands (or millions
> even, if the clients are mostly nice) of NTP clients each.
Thanks, that's good data. I had a suspicion that the reason the
high-load dog wasn't barking is that NTP's computations are really
cheap and light. This seems to more than confirm that.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
More information about the devel