Mailing List for the Bandwidth Testing Tool Iperf

Jason Frisvold | 8 Aug 2008 21:30

UDP Problem

Hi all,

I've done some digging into my UDP problems and here's what I've
found.  I have a custom script that launches iperf at regular
intervals and parses the results, placing them into a database.  I
have some sanity checks in there to ensure that iperf doesn't spin
forever if there is a problem.  In short, it adds an additional minute
to the time the test is run for and kills the process if it exceeds
that time.

What appears to be happening is that when doing UDP testing
(dualtest), the final packets do not always make it to the server, so
the server leaves the socket open indefinitely.  The client side seems
to finish up with no problems, issuing an error about the final
results missing.  In subsequent tests, the time recorded for upstream
tests increases and we end up with something insane like this :

[friz <at> bvlab ~]$ iperf-2.0.2 -c <ip address> -d -l 90 -b 90000 -u
WARNING: option -b implies udp testing
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 90 byte datagrams
UDP buffer size:   107 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to <ip address>, UDP port 5001
Sending 90 byte datagrams
UDP buffer size:   107 KByte (default)
------------------------------------------------------------
[  4] local 192.168.254.1 port 33547 connected with <ip address> port 5001

(Continue reading)

headers

Alin Hra | 14 Aug 2008 13:11

iperf jitter question

Hello,

I tried to use iperf in order to get some sort of statistics for a udp stream.

root <at> video:/# iperf -s -u -B 239.15.101.10 -i 1 -T 32 -l 60k -p 49410
------------------------------------------------------------
Server listening on UDP port 49410
Binding to local address 239.15.101.10
Joining multicast group 239.15.101.10
Receiving 61440 byte datagrams
UDP buffer size:   107 KByte (default)
------------------------------------------------------------
[ 3] local 239.15.101.10 port 49410 connected with 10.11.99.160 port 1481
[ ID] Interval   &nbs p;   Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 29.6 KBytes    242 Kbits/sec 998109480388.430 ms 1195394312/1195394335 (1e+02%)
[ 3] 0.0- 1.0 sec 19 datagrams received out-of-order
[ 3] 1.0- 2.0 sec    185 KBytes 1.52 Mbits/sec 1326472440288.818 ms    0/    0 (nan%)
[ 3] 1.0- 2.0 sec 144 datagrams received out-of-order
[ 3] 2.0- 3.0 sec    193 KBytes 1.58 Mbits/sec 1219396600280.480 ms    0/    0 (nan%)
[ 3] 2.0- 3.0 sec 150 datagrams received out-of-order
[ 3] 3.0- 4.0 sec    184 KBytes 1.51 Mbits/sec 1597225692679.626 ms    0/    0 (nan%)
[ 3] 3.0- 4.0 sec 143 datagrams received out-of-order
[ 3] 4.0- 5.0 sec    186 KBytes 1.53 Mbits/sec 1334942497621.720 ms    0/    0 (nan%)
[ 3] 4.0- 5.0 sec 145 datagrams received out-of-order
[ 3] 5.0- 6.0 sec    184 KBytes 1.51 Mbits/sec 1256119644323.133 ms    0/    0 (nan%)
[ 3] 5.0- 6.0 sec 143 datagrams received out-of-order
[ 3] 6.0- 7.0 sec    179 KBytes 1.46 Mbits/sec 1201240315355.291 ms    0/    0 (nan%)
[ 3] 6.0- 7.0 sec 139 datagrams received out-of-order
[ 3] 7.0- 8.0 sec    177 KBytes 1.45 Mbits/sec&nbsp ; 1688932541123.746 ms    0/    0 (nan%)
[ 3] 7.0- 8.0 sec 138 datagrams received out-of-order
[ 3] 8.0- 9.0 sec    170 KBytes 1.39 Mbits/sec 1704649324905.287 ms    0/    0 (nan%)
[ 3] 8.0- 9.0 sec 132 datagrams received out-of-order
[ 3] 9.0-10.0 sec    200 KBytes 1.64 Mbits/sec 1772745478056.681 ms    0/    0 (nan%)
[ 3] 9.0-10.0 sec 156 datagrams received out-of-order
[ 3] 10.0-11.0 sec    173 KBytes 1.42 Mbits/sec 1531515308575.511 ms    0/    0 (nan%)
[ 3] 10.0-11.0 sec 135 datagrams received out-of-order
[ 3] 11.0-12.0 sec    172 KBytes 1.41 Mbits/sec 1265015314995.091 ms    0/&nbsp ;   0 (nan%)
[ 3] 11.0-12.0 sec 134 datagrams received out-of-order
[ 3] 12.0-13.0 sec    172 KBytes 1.41 Mbits/sec 1835649298860.555 ms    0/    0 (nan%)
[ 3] 12.0-13.0 sec 134 datagrams received out-of-order
[ 3] 13.0-14.0 sec    167 KBytes 1.37 Mbits/sec 1401992039555.385 ms    0/    0 (nan%)
[ 3] 13.0-14.0 sec 130 datagrams received out-of-order
[ 3] 14.0-15.0 sec    168 KBytes 1.38 Mbits/sec 1275102950555.581 ms    0/    0 (nan%)
[ 3] 14.0-15.0 sec 131 datagrams received out-of-order
[ 3] 15.0-16.0 sec    167 KBytes 1.37 Mbits/sec 1687206638067.240 ms    0/    0 (nan%)
[ 3] 15.0-16.0 sec 130 datagra ms received out-of-order
[ 3] 16.0-17.0 sec    162 KBytes 1.33 Mbits/sec 1521373244192.683 ms    0/    0 (nan%)
[ 3] 16.0-17.0 sec 126 datagrams received out-of-order
[ 3] 17.0-18.0 sec    154 KBytes 1.26 Mbits/sec 1447920255147.208 ms    0/    0 (nan%)
[ 3] 17.0-18.0 sec 120 datagrams received out-of-order
[ 3] 18.0-19.0 sec    176 KBytes 1.44 Mbits/sec 1252136486881.482 ms    0/    0 (nan%)
[ 3] 18.0-19.0 sec 137 datagrams received out-of-order
[ 3] 19.0-20.0 sec    157 KBytes 1.28 Mbits/sec 1755323381362.654 ms    0/    0 (nan%)
[ 3] 19.0-20.0 sec 122 datagrams received out-of-order
[ 3] 20.0-21.0 sec    157 K Bytes 1.28 Mbits/sec 1463161910162.867 ms    0/    0 (nan%)
[ 3] 20.0-21.0 sec 122 datagrams received out-of-order
[ 3] 21.0-22.0 sec    173 KBytes 1.42 Mbits/sec 1304977333660.666 ms    0/    0 (nan%)
[ 3] 21.0-22.0 sec 135 datagrams received out-of-order

I tried this on 2 machines using the package provided by Debian (iperf version 2.0.4 (7 Apr 2008) pthreads), 2.0.4 compiled from source and 2.0.2 from source, and also tried 2 different sources.
Can anyone tell me why the jitter is reported this way, and also why all the datagrams are out of order. As I understand it, the clocks on the sender and receiver don't have to br syncronized for jitter calculation.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

headers

Alin Hra | 14 Aug 2008 13:16

iperf jitter question

Hello,

I tried to use iperf in order to get some sort of statistics for a udp stream.

root <at> video:/# iperf -s -u -B 239.15.101.10 -i 1 -T 32 -l 60k -p 49410
------------------------------------------------------------
Server listening on UDP port 49410
Binding to local address 239.15.101.10
Joining multicast group 239.15.101.10
Receiving 61440 byte datagrams
UDP buffer size:   107 KByte (default)
------------------------------------------------------------
[ 3] local 239.15.101.10 port 49410 connected with 10.11.99.160 port 1481
[ ID] Interval   &nbs p;   Transfer     Bandwidth       Jitter   Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 29.6 KBytes    242 Kbits/sec 998109480388.430 ms 1195394312/1195394335 (1e+02%)
[ 3] 0.0- 1.0 sec 19 datagrams received out-of-order
[ 3] 1.0- 2.0 sec    185 KBytes 1.52 Mbits/sec 1326472440288.818 ms    0/    0 (nan%)
[ 3] 1.0- 2.0 sec 144 datagrams received out-of-order
[ 3] 2.0- 3.0 sec    193 KBytes 1.58 Mbits/sec 1219396600280.480 ms    0/    0 (nan%)
[ 3] 2.0- 3.0 sec 150 datagrams received out-of-order
[ 3] 3.0- 4.0 sec    184 KBytes 1.51 Mbits/sec 1597225692679.626 ms    0/    0 (nan%)
[ 3] 3.0- 4.0 sec 143 datagrams received out-of-order
[ 3] 4.0- 5.0 sec    186 KBytes 1.53 Mbits/sec 1334942497621.720 ms    0/    0 (nan%)
[ 3] 4.0- 5.0 sec 145 datagrams received out-of-order
[ 3] 5.0- 6.0 sec    184 KBytes 1.51 Mbits/sec 1256119644323.133 ms    0/    0 (nan%)
[ 3] 5.0- 6.0 sec 143 datagrams received out-of-order
[ 3] 6.0- 7.0 sec    179 KBytes 1.46 Mbits/sec 1201240315355.291 ms    0/    0 (nan%)
[ 3] 6.0- 7.0 sec 139 datagrams received out-of-order
[ 3] 7.0- 8.0 sec    177 KBytes 1.45 Mbits/sec 1688932541123.746 ms    0/    0 (nan%)
[ 3]&n bsp; 7.0- 8.0 sec 138 datagrams received out-of-order
[ 3] 8.0- 9.0 sec    170 KBytes 1.39 Mbits/sec 1704649324905.287 ms    0/    0 (nan%)
[ 3] 8.0- 9.0 sec 132 datagrams received out-of-order
[ 3] 9.0-10.0 sec    200 KBytes 1.64 Mbits/sec 1772745478056.681 ms    0/    0 (nan%)
[ 3] 9.0-10.0 sec 156 datagrams received out-of-order
[ 3] 10.0-11.0 sec    173 KBytes 1.42 Mbits/sec 1531515308575.511 ms    0/    0 (nan%)
[ 3] 10.0-11.0 sec 135 datagrams received out-of-order
[ 3] 11.0-12.0 sec    172 KBytes 1.41 Mbits/sec 1265015314995.091 ms    0/    0 (nan%)
[ 3] 11.0-12.0 sec 134 datagrams received out-of- order
[ 3] 12.0-13.0 sec    172 KBytes 1.41 Mbits/sec 1835649298860.555 ms    0/    0 (nan%)
[ 3] 12.0-13.0 sec 134 datagrams received out-of-order
[ 3] 13.0-14.0 sec    167 KBytes 1.37 Mbits/sec 1401992039555.385 ms    0/    0 (nan%)
[ 3] 13.0-14.0 sec 130 datagrams received out-of-order
[ 3] 14.0-15.0 sec    168 KBytes 1.38 Mbits/sec 1275102950555.581 ms    0/    0 (nan%)
[ 3] 14.0-15.0 sec 131 datagrams received out-of-order
[ 3] 15.0-16.0 sec    167 KBytes 1.37 Mbits/sec 1687206638067.240 ms    0/    0 (nan%)
[ 3] 15.0-16.0 sec 130 datagrams received out-of-order
[ 3] 16.0-17.0 sec    162 KBy tes 1.33 Mbits/sec 1521373244192.683 ms    0/    0 (nan%)
[ 3] 16.0-17.0 sec 126 datagrams received out-of-order
[ 3] 17.0-18.0 sec    154 KBytes 1.26 Mbits/sec 1447920255147.208 ms    0/    0 (nan%)
[ 3] 17.0-18.0 sec 120 datagrams received out-of-order
[ 3] 18.0-19.0 sec    176 KBytes 1.44 Mbits/sec 1252136486881.482 ms    0/    0 (nan%)
[ 3] 18.0-19.0 sec 137 datagrams received out-of-order
[ 3] 19.0-20.0 sec    157 KBytes 1.28 Mbits/sec 1755323381362.654 ms    0/    0 (nan%)
[ 3] 19.0-20.0 sec 122 datagrams received out-of-order
[ 3] 20.0-21.0 sec    157 KBytes 1.28 Mbits/sec 1463161910162.867 ms  & nbsp; 0/    0 (nan%)
[ 3] 20.0-21.0 sec 122 datagrams received out-of-order
[ 3] 21.0-22.0 sec    173 KBytes 1.42 Mbits/sec 1304977333660.666 ms    0/    0 (nan%)
[ 3] 21.0-22.0 sec 135 datagrams received out-of-order

jitter = 1304977333660.666 ms                * these are the results that don't make sense to me
135 datagrams received out-of-order         *

I tried this on 2 machines using the package provided by Debian (iperf version 2.0.4 (7 Apr 2008) pthreads), 2.0.4 compiled from source and 2.0.2 from source, and also tried 2 different sources.
Can anyone tell me why the jitter is reported this way, and also why all the datagrams are out of order. As I understand it, the clocks on the sender and receiver don't have to br syncronized for jitter calculation. Is there another way i can determine these values, or maybe a way check if the sender is the problem.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

headers

Llewellyn, Ted | 18 Aug 2008 22:28

IP TOS on Windows -- any update?

Has there been any update on the -S problem with Windows? I see that someone volunteered to work on it, but I have seen no update (I think this option was not their highest priority). Has anybody determined whether the problem is related to the raw socket restriction in XP SP2, or some issue in the iperf code?

Ted Llewellyn

ted.llewellyn at frontiercorp.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

headers

Roberto Lumbreras | 28 Aug 2008 15:14

100% CPU usage in UDP mode

Hi all...

I've tried the iperf from the SVN that uses nanosleep() instead of
gettimeofday...
but  I'm seeing the same results: iperf in UDP mode uses all cpu idle,
both server and client.

Is this supposed to be fixed, or there are other issues remaining?
Stracing iperf I'm seeing still
some sched_yield in server mode (but not in client mode).

Any ideas?

Regards,
Roberto Lumbreras

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

1	May 2013
1	April 2013
3	March 2013
4	February 2013
2	January 2013
8	December 2012
3	November 2012
1	October 2012
3	September 2012
6	August 2012
6	July 2012
6	May 2012
9	April 2012
1	March 2012
3	January 2012
4	December 2011
9	November 2011
11	October 2011
4	September 2011
4	August 2011
9	July 2011
10	June 2011
4	May 2011
15	April 2011
17	March 2011
9	January 2011
6	December 2010
5	November 2010
2	October 2010
9	September 2010
8	August 2010
10	July 2010
11	June 2010
15	May 2010
39	April 2010
27	March 2010
16	February 2010
12	December 2009
11	November 2009
7	October 2009
2	September 2009
6	August 2009
5	July 2009
5	June 2009
4	May 2009
5	April 2009
5	February 2009
3	January 2009
5	December 2008
8	November 2008
1	October 2008
5	August 2008
15	July 2008
10	June 2008
33	May 2008
27	April 2008
21	March 2008
3	February 2008

Mon	Tue	Wed	Thu	Fri	Sat	Sun

				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31