How much do we care about high-load scenarios?

[Eric S. Raymond]

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
deployments).

> 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>