Gary E. Miller writes:
> Poll=2s is still the bast for this hardware, but there is a little
> tradeoff between offset and jitter. Since NTP is about time, not
> frequency, we go with the best time.
You 've made this argument before, but I think it's circular reasoning.
You make the local clock fo
Quoting Kurt Roeckx :
:
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+:
k...@roeckx.be said:
> Isn't the timer also used for the PI loop? Or has much of that design been
> changed?
The timer goes off each second, and then calls various routines to see if they
have any work to do. Many of those routines decrement a counter each time they
get called and then do th
On Wed, Sep 14, 2016 at 06:00:45PM -0400, Eric S. Raymond wrote:
> Dan Drown :
> > Quoting "Eric S. Raymond" :
> > >Achim Gratz :
> > >>…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 r
On Wed, Sep 14, 2016 at 04:40:57PM -0500, Dan Drown wrote:
>
> This page from cloudflare does a nice job of describing the limitations of a
> single process UDP receive model:
> https://blog.cloudflare.com/how-to-receive-a-million-packets/
>
> The limit they hit with their hardware was around 370
