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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
