Howdy!
It seems like nobody answered this question. Or I never got the answer. Anyhow
...
Hickman, Mark je dne 15/02/13 22:56 napisal-a:
We are confused about the inner workings of iperf which raises questions of
the validity of the reports under these conditions.
1.Does the iperf client measure the interval bandwidth by the amount of data
it wrote do a buffer per interval or by the amount of data the radio pulled
out of the buffer per interval or the amount of data the radio put on the
air? The first two should be equivalent.
2.The other question I should ask but cannot think of.
iperf as a perfect userland application does not have any idea about physical
layer connectivity. Hence sending party measures bandwidth of pushing data
into send buffers. It is known to iperf if layers below that (TCP/UDP; IP;
ethernet or any other L2 technology; wire, wireless or any other L1
technology) drop data.
The above statement does not imply which of the cases you enumerated is
actually the correct. However, if the transmit device behaves (ie does not
drop data due to buffer full), then one an observe typical behaviour: a surge
of UL data with high peak throughput at the beginning and a drop to real L2
speed afterwards. Hence conclusion: iperf client measures the interval
bandwidth by the amount of data it wrote do a buffer per interval
If it was the second (iperf client measures the interval bandwidth by the
amount of data the radio pulled out of the buffer per interval), one could not
see the spike right at the beginning of test.
The visibility of this spike is proportional to the size of transmit buffer
size (wmem in linux) and inversely proportional to the first leg link speed.
Now to the drops: I have extensive experience with broadband wireless
(WCDMA/HSPA and LTE) devices and most of them are transparent in a sense that
they don't buffer data. A few of them buffer data (and few of them even act as
a kind of router performing NAT etc) and those are more than happy to drop
packets.
When using the former breed one can see the TX speed at the sending side with
no (or seldom) dropped packets while when using the later ones one can only
see the real throughput on the receiving (iperf server) side ... and there are
plenty of dropped packets, amount depends on the ratio between iperf tx
bandwidth versus real link bandwidth.
In case of high buffering on the way, reports from iperf server tend to be too
late for the client to make note of them. All in all, it's safest to only rely
on reports from the receiving side (server for uplink and client for downlink).
BR,
Metod
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
