[netperf-talk] Which is the best hardware configuration for Netperf-Server?

[Rick Jones]

Krishna Kumar2 wrote:
>> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance
> 
> 
> When I run the "recommended" netperf command, I get this output:
> 
> # netperf -c -C -t TCP_STREAM -H 10.0.0.2 -i 10
> TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.0.0.2
> (10.0.0.2) port 0 AF_INET : +/-2.500% @ 99% conf.
> !!! WARNING
> !!! Desired confidence was not achieved within the specified iterations.
> !!! This implies that there was variability in the test environment that
> !!! must be investigated before going further.
> !!! Confidence intervals: Throughput      : 11.474%
> !!!                       Local CPU util  : 21.881%
> !!!                       Remote CPU util : 38.258%
> 
> Recv   Send    Send                          Utilization       Service
> Demand
> Socket Socket  Message  Elapsed              Send     Recv     Send    Recv
> Size   Size    Size     Time     Throughput  local    remote   local
> remote
> bytes  bytes   bytes    secs.    10^6bits/s  % S      % S      us/KB
> us/KB
> 
>  87380  16384  16384    10.00      6401.47   19.40    36.07    0.993
> 1.835

I'd start with two things - first make it -i 30,3 and second make the length of 
individual runs more like 30 seconds, so that would become:

netperf -c -C -t TCP_STREAM -H 10.0.0.2 -l 30 -i 30,3

If that doesn't "fix" it then we need to look into other sources of variability 
- perhaps shoot irqbalanced in the head (I always do) and make sure the IRQs 
aren't bouncing around.  For my single-instance testing, I tend to bind all the 
IRQs of the NUT (NIC Under Test :) to one core on either system and then use -T 
to bind netperf/netserver - either to the same core (maximum efficiency) or to 
another core (maximum throughput when one core isn't enough).

The bind to same, bind to different core than IRQ also lets one examine the 
difference in service demands.

> And for 4 netperfs, the Throughput confidence number shoots upto
> 100-150% (at the end of this post). What is the reason for this
> and how can I get better confidence numbers?

Assuming you used the same -i 10, I would go with -i 30 (and ditch the ,3 since 
you don't want any instance terminating early. I'd also increase the iteration 
length to at least 30 seconds, and might end-up taking it to 120.

For "aggregate" tests I either don't shoot irqbalanced in the foot, or I do and 
I spread the IRQs around.  I don't though try to bind netperf/netserver processes.

happy benchmarking,

rick jones

> 
> Thanks,
> 
> - KK
> 
> !!! WARNING
> !!! Desired confidence was not achieved within the specified iterations.
> !!! This implies that there was variability in the test environment that
> !!! must be investigated before going further.
> !!! Confidence intervals: Throughput      : 98.061%
> !!!                       Local CPU util  : 13.321%
> !!!                       Remote CPU util : 17.084%
> 
>  87380  16384  16384    10.02      1649.86   28.18    94.69    7.558
> 26.078
> !!! WARNING
> !!! Desired confidence was not achieved within the specified iterations.
> !!! This implies that there was variability in the test environment that
> !!! must be investigated before going further.
> !!! Confidence intervals: Throughput      : 68.653%
> !!!                       Local CPU util  : 13.178%
> !!!                       Remote CPU util : 17.078%
> 
>  87380  16384  16384    10.02      1805.35   28.18    94.69    5.789
> 19.662
> !!! WARNING
> !!! Desired confidence was not achieved within the specified iterations.
> !!! This implies that there was variability in the test environment that
> !!! must be investigated before going further.
> !!! Confidence intervals: Throughput      : 83.480%
> !!!                       Local CPU util  : 13.334%
> !!!                       Remote CPU util : 17.100%
> 
>  87380  16384  16384    10.02      1678.17   28.18    94.69    6.422
> 21.321
> !!! WARNING
> !!! Desired confidence was not achieved within the specified iterations.
> !!! This implies that there was variability in the test environment that
> !!! must be investigated before going further.
> !!! Confidence intervals: Throughput      : 104.539%
> !!!                       Local CPU util  : 13.308%
> !!!                       Remote CPU util : 17.085%
> 
>  87380  16384  16384    10.02      1583.23   28.18    94.70    9.894
> 35.032