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