Threads

[Sanjeev Gupta]

Hal, newbie question.

What use case on the internet would be saturating a Gb link with NTP?
Surely, before that, we should be recommending a second server closer to
the clients?

Assume a large University campus, with 30000 nodes (5k students, each with
a tablet and phone, etc).  Assume all nodes (including the IOT coffee
maker) run an NTP client.  With a poll of 100 secs (to make life easier),
that is 3000 pkts/s .

I have an ancient Pentium 4, from 2005 or earlier.  4GB RAM, 32-bit.  ntp
-n -c monlist says 67000 slots.  It is in the pool, since 2009 or so.  CPU
load is 1% on each core, except when I run updates, etc.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane


On Wed, Apr 7, 2021 at 12:43 PM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> There are 4 places that might be the limiting factor.
>
>   1) The wire might be full
>   2) The Ethernet chip might not be able to process packets at full wire
> speed.
>   3) The kernel's input dispatcher thread might run out of CPU cycles.
>   4) The client threads might run out of CPU cycles.
>
> I don't have a good setup to demonstrate the Ethernet chip being the
> limiting
> factor.  I could probably make one by plugging in a junk card.  The
> gigabit
> chips that come on Dell motherboards are OK.  They can get close to full
> wire
> speed, close enough that I'm missing under 100 bits between packets.
>
> The other limits are reasonably easy to demo.
>
> I have a box with an Intel E5-1650v3.  It has 6 cores at 3.5 MHz.  With
> HyperThreading, that's 12 CPUs.
>
> My standard test setup is an echo server.  The kernel SoftIRQ thread gets
> one
> CPU.  The other half of that core is left idle.  There is an echo server
> thread on each of the other 10 CPUs.
>
> Measured NTP throughput:
> pkts/sec  uSec/pkt
>    426K      2.3    NTP (simple)  48 bytes
>    320K      3.1    NTP + AES     68 bytes
>     93K     10.7    NTP + NTS    232 bytes
>
> The wire limit for NTP+NTS (232 UDP bytes) is 407K packets per second.
> That's
> 2.5 uSec per packet.  With 10 CPUs, we have 25 uSec per packet.  We only
> need
> 11 so this processor chip should be able to keep up with a gigabit link
> running at full speed.
>
> Note that a workstation with 4 cores can probably keep up.  That leaves 6
> worker threads so we only get 15 uSec of CPU time for each packet, but
> that's
> still more than 11.  I don't know how much running both CPUs of a core
> will
> slow things down.  We'll have to wait and measure that.
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210407/7b24669b/attachment.htm>