Frank Schuster | 2 Nov 08:30 2009
Picon

Re: How iperf works?

Hello Alfredo,

thank you for your response. I think for TCP (and I think SCTP) you are right.
But I tried this for UDP with the "-i 1" option and I get reports to every second.
I sniffer the packets from and to the server via wireshark and there is only one packet after 10 sec from
server to the client.
How is it there possible that the Client can calculate the correct bandwidth every second, because it get no
ACKs or something else?

Regards
Frank

> -----Ursprüngliche Nachricht-----
> Von: "Alfredo Alcantara" <alfredoealcantara@...>
> Gesendet: 30.10.09 21:27:56
> An: Frank Schuster <frank.schuster01@...>
> Betreff: Re: [Iperf-users] How iperf works?

Hi Frank, this is what i think
> 
> iperf through this command iperf -c x.x.x.x 
> is sendind tcp packets
> tcp packets always receive ACK's from the server so that's is how
> he knows that the data is reaching his destiny
> the throughput is being calculate by the average of 
> throughput in every sec if you type 
> iperf -c x.x.x.x -i 1 you can see what i'm talking
> best of regard and hoping this solve the problem
> 
> Alfredo Alcantara
(Continue reading)

Marc Herbert | 2 Nov 10:03 2009
Picon

Re: How iperf works?

2009/11/2 Frank Schuster <frank.schuster01@...>:
> thank you for your response. I think for TCP (and I think SCTP) you are right.
> But I tried this for UDP with the "-i 1" option and I get reports to every second.
> I sniffer the packets from and to the server via wireshark and there is only one packet after 10 sec from
server to the client.
> How is it there possible that the Client can calculate the correct bandwidth every second, because it get
no ACKs or something else?

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.

To verify all this simply unplug the network cable during a test. Be
careful to unplug the cable of the *receiving* side, because some
operating systems on the sending side will brutally close all sockets
and indirectly interrupt iperf (not even giving you a chance to plug
the cable back). You can also try to change the socket buffer size
using the "-w" option.

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.

Cheers,

Marc

(Continue reading)

Frank Schuster | 3 Nov 09:58 2009
Picon

Re: How iperf works?

> 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.

> 
> To verify all this simply unplug the network cable during a test. Be
> careful to unplug the cable of the *receiving* side, because some
> operating systems on the sending side will brutally close all sockets
> and indirectly interrupt iperf (not even giving you a chance to plug
> the cable back). You can also try to change the socket buffer size
> using the "-w" option.
>

I have unplugged the cable and I see that the bandwidth is going down.
But iperf hold the connection by TCP somehow and ignores the -t option. I think that he will transmit the data
outstanding data and will end after this the retransmission.  
(Continue reading)

Owain Davies | 3 Nov 10:03 2009

Re: Fwd: Error using UDP

Hi Alfredo,
 
I am sorry I do not know how the jitter is actually calculated in iperf. I do know that there are very many ways of doing so. I can be calculated over an interval of various sizes, or as a running average using a sliding window of packets.  I have forwarded your question to the iperf-users list, maybe somebody there can help.
 
Kind regards,
 
Owain

From: Alfredo Alcantara [mailto:alfredoealcantara-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 02 November 2009 20:57
To: Owain Davies
Subject: Re: [Iperf-users] Fwd: Error using UDP

Hello Owain I´m using your direction because the iperf-users keeps sending me an error

if there is not to much truble i would ask you the following and if you PLEASE can re-send it to ipefr-users, better


Good day,

I´m sending this email to talk about this doubt

when testing with UDP iperf shows me some time representing jitter, but

i know that jitter is the variation of time between every incoming packet, that
variation can be either in advance or delay so, how iperf calculates that value?,
it has a buffer? or is just the delay calculation?. And that value is the maximun
Jitter, delay whatever or it is a medium value.

thank you very much in advance for your help and best of regards

Alfredo Alcantara

2009/10/28 Owain Davies <Owain.davies-3etTQGT7qQvQT0dZR+AlfA@public.gmane.org>

Looks like you are overloading the connection. There is no good way to get the server to stay up. I can only suggest running some kind of watchdog script. I used DITG instead which is much more reliable.

 

Owain

 

From: Alfredo Alcantara [mailto:alfredoealcantara-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: 28 October 2009 16:43
To: iperf-users-IlAC/IgH3vHkIehEPBwdNw@public.gmane.org
Subject: [Iperf-users] Fwd: Error using UDP

 

 

Good day,

I'm using iperf version 1.7 for Windows and i'm having a problem with the UDP transmision

with this command on the server

iperf -s -p 5300 -u

and this on the client

iperf -c x.x.x.x -u -p 5300 -b 10m

I am receiving the following error

read falied: Connection reset by peer    x4 times

WARNING: ack of laswt datagram failed after 10 tries
recvfrom failed: Connection reset by peer

I do not now what the problem is, and i need the server to stay up  and listening for iperf connection
If by any chance is a new version of iperf for windows, please let me now

Thanks in advanced and best of regards

Alfredo Alcantara

 




This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies within the Detica Limited group of companies.

Detica Limited is registered in England under No: 1337451.

Registered offices: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.

------------------------------------------------------------------------------
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
Metod Kozelj | 3 Nov 11:30 2009
Picon

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
Frank Schuster | 9 Nov 11:24 2009
Picon

Netperf vs. IPerf Performance

Hello,

I have done some test between iperf and netperf.
I get very different results in throughput if I am using the same configuration for the tools.

I sniffer the packets from both tools and I can see that netperf sends 7 times packages more than iperf.
The second thing what I see is that the payload of the most packages are in iperf between 40 and 159 and in
netperf is one half of the packages between 40 and 79 and the other on between 1280 and 2559 ( I tink up to the MTU).

I know I am in the iperf mailing list, but perhaps anybody can tell me, what iperf do during the tcp test and if
anybody use netperf, perhaps he can give me an explaination about the behaviour of netperf?

Regards
Frank
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Frank Schuster | 11 Nov 08:42 2009
Picon

TCP Windowsize wrong?

Hello,

I did an iperf-test with an TCP windowsize on the serversite of 32768 Bytes (iperf -s -w 32768)
The client use the command: iperf -c ip-address -t 1 -l 32768 -w 32768.

I sniffer the data flow with (tshark/wireshark) and there I can see that the server offers a windowsize in
maximum of 47712!

Is there a reason for it, that the windowsize raise about 15000 Bytes?

Regards
Frank
_____________________________________________________________
DSL-Preisknaller: DSL-Komplettpakete von WEB.DE schon für 
16,99 Euro/mtl.!* Hier klicken: http://produkte.web.de/go/02/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Andrew Gallatin | 11 Nov 15:55 2009
Picon

Re: TCP Windowsize wrong?

On Wed, Nov 11, 2009 at 2:42 AM, Frank Schuster <frank.schuster01@...> wrote:
> Hello,
>
> I did an iperf-test with an TCP windowsize on the serversite of 32768 Bytes (iperf -s -w 32768)
> The client use the command: iperf -c ip-address -t 1 -l 32768 -w 32768.
>
> I sniffer the data flow with (tshark/wireshark) and there I can see that the server offers a windowsize in
maximum of 47712!

You don't mention the OS, but from your previous emails to the iperf
and netperf lists,  I suspect that you're runnnig on Linux.  If so, be
aware that  Linux doubles the requested socket buffer / TCP window
sizes for resource accounting reasons.  So when an application
requests a 32KB socket buffer, the kernel actually allows up to 64KB.
This is a fairly well known quirk of the Linux stack.

The Linux TCP window auto-tuning is quite good, and in general it is
best not to try to manually tune the window size.  Eg, it is often
best to avoid specifying the -w argument on Linux.

Drew

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Frank Schuster | 12 Nov 08:36 2009
Picon

Re: TCP Windowsize wrong?

> You don't mention the OS, but from your previous emails to the iperf
> and netperf lists,  I suspect that you're runnnig on Linux.  If so, be
> aware that  Linux doubles the requested socket buffer / TCP window
> sizes for resource accounting reasons.  So when an application
> requests a 32KB socket buffer, the kernel actually allows up to 64KB.
> This is a fairly well known quirk of the Linux stack.
> 
> The Linux TCP window auto-tuning is quite good, and in general it is
> best not to try to manually tune the window size.  Eg, it is often
> best to avoid specifying the -w argument on Linux.
> 
> Drew
> 

Yeah, I run it on Linux.
I can understand what you say. So I can't exactly say use only xxx Bytes because the stack do some things...
My problem is that I want to compare the behaviour of TCP and SCTP.
And if I use the -w option in iperf or in netperf with the sctp protocol that is really the maximum advertised
received window size.
But now I want to do the same in TCP and I configured it so and the throughput is much better because the server
can receive more bytes than the sctp.

Perhaps do you have an idea how I can do the test? I think to set the windowsize to the half that the kernel than
double this value is not really a solution. Because in my test the windowsize of the server never reach the
maximum values and I tried is with a lot of differents.

Regards
Frank

______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Frank Schuster | 16 Nov 11:39 2009
Picon

sctp low throughput with different window sizes

Hello togehter,

I have a question again to the SCTP protocol.
I did a test with a constant message size and a variable buffer size on sender an receiver:
The result is shown below:
"Win Sender";"Win Receive";"Throughput in Mbit/s"
1024;128;0,01
1024;256;0,01
1024;512;0,01
1024;1024;0,01
2048;128;0,02
2048;256;0,01
2048;512;0,02
2048;1024;0,01
2048;2048;0,02
4096;128;0,02
4096;256;0,02
4096;512;0,02
4096;1024;0,02
4096;2048;0,03
4096;4096;0,06
8192;128;21,05
8192;256;23,9
8192;512;0,03
8192;1024;0,02
8192;2048;0,02
8192;4096;0,07
8192;8192;16,68

Only with a sender buffer size at 8192 Byte I get throughputs which are greater one. Perhaps I can understand
this but , why it is only with three receiver buffer sizes and not all?
I'm very confuse...I'm using Debian 5.0 as OS.

Is there any explaination for this behaviour?
I can't find out, if it is a problem of iperf or from the sctp stack.

Regards
Frank
_____________________________________________________________
DSL-Preisknaller: DSL-Komplettpakete von WEB.DE schon für 
16,99 Euro/mtl.!* Hier klicken: http://produkte.web.de/go/02/

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users


Gmane