Re: [Cfrg] network traffic

[Kurt Roeckx <[e-mail]>]

On Mon, Feb 23, 2015 at 03:21:02AM -0000, D. J. Bernstein wrote:
> Kurt Roeckx writes:
> > Depending on who you ask you might get a different
> > answer, but I doubt many people here care about bandwidth.
> 
> I care very much about network traffic---although it has to be
> quantified and put into context, just like CPU time.
> 
> As a concrete example, suppose your server resources are ten quad-core
> 3GHz CPUs and a 100Mbps network connection. Each microsecond the CPUs
> will perform a total of 120000 cycles of computation while the network
> connection will transmit 100 bits, i.e., 12.5 bytes.

I'm just going adjust your example a little.

> Case study 1: Suppose you save 20000 cycles of computation by replacing
> a compressed 32-byte point with an uncompressed 64-byte point. You're
> 
>    * saving 0.17 microseconds of computation but

If we assume it took 1 microseconds, it would then take 0.83.

>    * costing 2.56 microseconds of network capacity.

If we take the average connection to be 10.000 bytes, it would now
increase to 10.032.

If we start from assuming we're bandwidth limited, I was able to
do 10000 connections per second transfering 10 kB, but now
I can only do 9968.1.  That would also mean that I now spend 5.32
microseconds / s less CPU time on ECC.

So I would reduce the user visible performance by 0.32% and
reduce my cpu time by 0.00053%.  (That's a factor of 600.)

On the other hand if I assume I'm CPU limited I was spending 100
microseconds of CPU time per connection and had that reduced by
0.17.  I would then be able to do 10017 connections per second,
and bandwidth would increase to 100.49 mbit.  So a 0.17% increase
in user visible performance but also 0.49% increase in bandwidth.

(This all assumes no other overhead.)

As you can probably see, there are a lot of factors.


Kurt