Re: How iperf works?
Howdy!
Frank Schuster wrote:
iperf knows only what the operating system tells it, so the answer to
this question does not depend on iperf but on the operating system.
For both UDP and TCP what the sending side reports is what has been
sent, NOT what has been received. So it can differ between the sending
and receiving side. But for TCP it cannot differ for long, because in
case of a network problem the TCP socket buffer on the sending side
will fill up and eventually block the sender.
Do I understand it right that iperf on the client site doesn't calculate the true bandwidth?
Because the client sends a lot of data but it doesn't know, if the server receives this packages.
Only by TCP and SCTP the client will a little bit regulate by the ACKs but it has no effect on the measurement on the client site.
Is this correct or is there someting wrong, what I have written?
If it correct, I get the true bandwidth only from the server site?
Because there I can see all packages which have reached the server.
Let's get a bit theoretical here: take a look at diagram of 7 OSI
layers. iperf is an ordinary application which talks to the other end
(iperf on server) through several network layers. This means that iperf
as an application doesn't have accurate idea about what happens in
lower layers.
When one runs TCP tests, there are 2 things that block iperf from
having clear view of real throughput: buffering on sender's side
(TCP/IP stack) and TCP behaviour itself (acking). What iperf can
measure is the pace with which it sends data to TCP/IP stack; TPC/IP
stack will only accept data from application when buffers are not full.
If the buffer is huge, iperf will see hisgh throughput initially, then
it will drop. If there's congestion or retrasmission going on, iperf
will see it as lower throughput. Receiving is a bit better as Rx
buffers tend to be more or less empty (assuming receiver has enough CPU
power to consume all packets thrown at it). Application can be pretty
sure that receiver got data as TCP itself takes care of reliable
delivery of data, so client can more or less reliably tell the
throughput. Acknowledgement of TCP, on the other hand, means that
theoretical throughput can almost never be achieved due to latency,
asimetricity and other problems.
When one runs UDP tests, only buffering blocks iperf from having clear
view of throughput. But: UDP doesn't guarantee end-to-end delivery, so
if there's some congestion, UDP packets get dropped. Sender only knows
the pace it's own IP stack transmits packets and doesn't have any idea
about wether they are being delivered to receiver or not. Unless
receiver reports that to sender, but that's application's task. Iperf
does that every now and then (eg. every 10 seconds or so).
One example: say you have one host (A) with giga-ethernet connectivity
and another one host (B) with slow dial-up connectivity. You can
instruct iperf on host A to run UDP test against host B and send data
with 500 Mbps. Most of it will get dropped (unless some routers in
between are buggy enough to get overflowed) and host B will receive
data at, say, 50 kbps. Iperf on host A doesn't know it unless iperf on
host B tells it. Reporting UDP throughput frequently goes against whole
UDP idea, hence reporting every now and then.
Iperf on host B, however, has perfect idea about real throughput A
-> B iff it can process all packets that arrive. While it might be
possbile to insert giga-ethernet card into a slow PII machine I
sincerely doubt it could even receive data at wire speed, hence iperf
wouldn't see whole truth.
I think there is also some additional iperf magic handshake at the end
of the test, not sure. The source code is your friend here.
Yeah, I think really there are some "magic" Handshakes but nobody no which.
There's a lot of magic handshake goind on. Most of it is probably
hidden inside dummy data being sent between client and server.
Similar to well known ping command: it prints out round trip delay. It
can do it only because it actually sends time stamp when sending ICMP
ECHO REQUEST inside the packet payload and the other end includescopies
the same payload into ICMP ECHO REPLY packet. After receiving, ping can
calculate time difference. There's one limitation: requested payload
size must be at least 16 bytes to fit timestamp.
--
Peace!
Mkx
-- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
-- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
BOFH excuse #277:
Your Flux Capacitor has gone bad.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
RSS Feed