I'm not sure switching to Ethernet will "fix" the issue nor that wi-fi is
problematic (each operates as expected given the physical medium.)
The core of the issue is that iperf is an application that hands packets (or
udp payloads) via write calls to the kernel. There is a network stack and a
driver between that and the wire. There are no rules per se that require
either of those to preserve application level timing. Also, there is no way
for the iperf client as an app to know physical wire xmit details. A tool
like wireshark connected to a mirrored switch port is probably the best way to
get an idea of what a wire looks like or, for wi-fi, a promiscuous mode device
near the iperf client.
I 'd prefer not to expose a minimum gap via the user cli unless it's really
needed as I think it's confusing particularly with the -b. But if there is a
real need it's not hard to add. In that context, the idea of limiting bursts
to a min/max might be the approach. The min/max would say, send at most max
packets before inserting the delay as defined by the minimum and the -b
requested rate. If the client is "at requested rate" then insert a gap after
minimum packets. If below requested rate, go to the maximum before inserting
the gap. Then the client code could add burst number and burst count in the
payload (per your suggestion), something like this is the 13th burst and 5th
packet in the 13th burst (where defining the time value delimiter between the
burst would be done by per the above min and -b.)
To your question of the current UDP payload, there is a microsecond timestamp
(taken from the client's clock) and a sequence number.
Note, the iperf client does show it's actual transmit rate though it's defined
by the speed the client writes packets from application level to the kernel's
network stack or, from an inverse perspective, how fast the OS accepts writes
from the client.
Bob
From: Steve Baillargeon [mailto:steve.baillarg...@ericsson.com]
Sent: Thursday, January 08, 2015 12:46 PM
To: Bob (Robert) McMahon
Cc: iperf-users@lists.sourceforge.net
Subject: [Iperf-users] iperf UDP burst mode
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
