Dan Drown <dan-...@drown.org>:
> Quoting "Eric S. Raymond" <e...@thyrsus.com>:
> >Achim Gratz <strom...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
