With minor corrections and new subject title:
* 1) we limit the configuration to burst size, packet size and gap
indicating the number of UDP bytes/bits sent at each burst/gap
* 2) we limit the configuration of the burst size to a maximum
reasonable value, say 50-100 packets
* 3) we limit the gap to me a minimum reasonable value, say 1 ms, 10 ms,
100 ms or 1 sec
* 4) we show the estimated peak bandwidth on the client side based on
configured burst size, packet size and gap (if it is not possible to show
actual BW)
* 5) we use always use the realtime option -z meaning we are hoping that
each burst will be sent at line rate in most cases
* 6) we limit use case for Ethernet driver if wifi-driver is known to be
problematic
-Steve B
From: Steve Baillargeon
Sent: January-08-15 3:37 PM
To: 'Bob (Robert) McMahon'
Cc: iperf-users@lists.sourceforge.net<mailto:iperf-users@lists.sourceforge.net>
Subject: RE: [Iperf-users] iperf 2.0.8beta
Hi Bob
Thank you for the detailed response!
Regardless of what is requested/configured by user, is there a way to
measure/show the actual burst size and gap transmitted on the wire by the
client?
What if we put "certain limits" on the client configuration and system
performance, for instance:
* 1) we limit the configuration to burst size and packet size indicating
the number of UDP bytes/bits sent at each burst
* 2) we limit the configuration of the burst size to a maximum
reasonable value, say 50-100 packets
* 3) we limit the gap to me a minimum reasonable value, say 1 ms, 10 ms,
100 ms or 1 sec
* 4) we show the estimated peak bandwidth on the client side based on
calculation from #1 and #2 (if it is not possible to show actual BW)
* 5) we use always use the realtime option -z meaning we are hoping that
each burst will be sent at line rate in most cases
* 6) we limit use case for Ethernet driver if wifi-driver is known to be
problematic
On the server side, we would also configure the test to be UDP burst mode with
expected burst size.
I don't know the content of the iperf2 UDP payload but I suspect it has a
sequence number. Can you send me a description of the iperf UDP message content
if it if possible? Then we could divide the sequence number in two parts: 1)
burst number and 2)packet number in the burst. The server could just measure
the number of packet loss for each burst and measure the received average
bandwidth (burst) based on the total number of packets/bits received in-order .
If received packets are out of order, then we could simplify the reporting and
treat them as packet loss or preferably have a separate counter for it.
Regards
Steve B
From: Bob (Robert) McMahon [mailto:rmcma...@broadcom.com]
Sent: January-08-15 2:48 PM
To: Steve Baillargeon
Cc: iperf-users@lists.sourceforge.net<mailto:iperf-users@lists.sourceforge.net>
Subject: RE: [Iperf-users] iperf 2.0.8beta
Hi Steve,
I considered adding a burst mode feature but didn't do so because guaranteeing
interpacket and interburst gaps at the application level is not certain for the
following reasons:
o) The delay call to create the gaps provides for an "at least" value. For
example, if the client requests a delay of 100 microseconds the OS guarantees
that at least 100 microseconds of delay occurs. But it could also be 10
milliseconds. http://man7.org/linux/man-pages/man2/nanosleep.2.html
o) The write call can suspend the thread causing an unexpected gap within the
burst (though the -z or -realtime option can help with this)
o) Application timing need not be preserved by the kernel nor network driver.
The underlying driver can aggregate write calls (very common in wi-fi drivers)
losing application gap timing.
Since there is no way for the iperf client to know the actual gap(s) on the
wire and because of the above, I decided adding support for bursts was sketchy
and could mislead the user.
Also, in previous versions of iperf the code tried to preserve the minimum
interpacket gap vs maintaining the requested UDP rate. One can see this when
running 2.0.5 where the actual transmit rate is slower than the requested rate.
We decided that was a poor choice, i.e. if the user asks for 100Mbs then the
client should do its best to provide that load. Since the gap delay calls are
minimums it means that the client needs to speed up after a longer than then
expected delay, effectively bursting for a short period allowing the client to
converge on the requested (-b) transmit value.
With all that said, adding support for bursts is relatively easy to do. The
easiest way I can think of would be providing the burst size in the length (-l)
field, e.g. -l 1470/16 -b 100M which says the user would like a load of 100Mbs
using 16 back to back writes of 1470 bytes (which is the UDP payload size.)
While adding the realtime option (-z) would help there could be no hard
guarantee and no feedback to the user on the actual bursts and gaps. Also, I
am not sure if the goal of achieving the requested load loses priority to
preserving bursts, i.e. don't speed up when an application level burst delay is
longer than expected.
Comments welcome and helpful,
Thanks,
Bob
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
