server reported UDP rate fluctuates, when NIC stats & client sender reports indicate constant Tx rate

[GoogleCodeExporter]

What steps will reproduce the problem?
1. download latest released version & build locally
2. update 'arbitrary constants' = send timer schedule interval etc to maximise 
client transmit rate; re-build
3. run UDP server on 1 PC, cabled to 2nd identical PC running client, client 
parameters = -u -Z -i 10 -t 3600 -l 64 -b 980

What is the expected output? What do you see instead?

server to report more or less constant received rate; possibly less than Tx 
rate depending on machine capability; & htop to show 1 CPU core is 'busy' with 
iperf.

ACTUAL OBSESRVATION: the server reported rate drops at random times by ~50%, 
then some later will increase (rapidly, back to max rate); using ifconfig can 
confirm that client is still sending at constant original rate; htop indicates 
that BOTH CPUs are busy (no other programmes running); EXCEPT when server 
reported rate drops,when only 1 CPU is 'busy'

What version of the product are you using? On what operating system?

iperf version 3.0-RC5 (07 November 2013)
Linux HP-Lab2 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

iperf3 app is single threaded; the -A switch only binds the user land part of 
iperf code to a specific core.

SO what seems to be happening is that the NIC driver code (Realtek; I am using 
the latest r8168 from their web-site in place of the Ubuntu supplied version) 
and maybe associated kernel netif_receive etc code can run on multiple cores.

Need a way to control/fix this behaviour; otherwise it is impossible to tell 
from a set of measurements whether some network condition caused a drop in 
throughput, or was it the server 'having a holiday'.

NOTE: profiling the server code with 'perf' indicates ~25 - 30% of the cycles 
are spent in memcpy; next highest item is @ ~5% (some piece of kernel code, not 
specific iperf code).

Original issue reported on code.google.com by CharlesA...@gmail.com on 28 Nov 2013 at 12:32

[GoogleCodeExporter]

To control the core that the NIC interrupts go to, you have to do something 
like what is described here:

http://fasterdata.es.net/host-tuning/interrupt-binding/

There is no way to control that from the application.

You might want to try the -Z option too.

Original comment by bltier...@es.net on 6 Dec 2013 at 2:16

[GoogleCodeExporter]

The rate fluctuation could just be buffering.

Original comment by jef.posk...@gmail.com on 10 Dec 2013 at 7:39

[GoogleCodeExporter]

Original comment by bltier...@es.net on 18 Dec 2013 at 9:47

• Changed state: WontFix