Mailing List for the Bandwidth Testing Tool Iperf

Tobi Hofer | 3 Dec 2009 16:34

UDP Delay Problem

Hello together

I have some problems with the Delay, Jitter from Iperf.

How does Iperf calculate the Jitter Delay? When I measure with UDP the Jitter 
Delay over a 100Mb-Ethernet, the results are ok (avg delay: 124us, avg jitter 
31us).

I'm on my Bachelor-Thesis and I have to measure the Delay, Jitter and Packet 
loss ratio over a PPP-Device (3G) to a Server in the Internet in both ways, 
up- and downlink.

Iperf UDP downlink, 1800k (no loss):
avg Delay: 8.35ms
avg Jitter: 0.43ms (standard deviation).

When I variate the bitrate, the change is about 1 or 2ms.

This result can't be correct, because with thrulay the udp delay is avg 75ms.
With NDT I have an avg RTT 1142ms

After Internet research the Delay over 3G is between 70ms.....180ms

How does Iperf calculate the Delay? Is it a problem over 3G UMTS?

I work with Iperf 2.0.4-4 for UDP, on the computers is Ubuntu 9.04 installed.

Thanks

Regards

(Continue reading)

headers

Metod Kozelj | 4 Dec 2009 09:12

Re: UDP Delay Problem

Hi!

I tried to replicate your tests ... using 3G HSPA+, iperf 2.0.4 on debian on internet side and jperf (iperf 2.0.2) on windows xp on dial-up side.

I can see delay jitter reported by receiving side (in my case it's around 7.5ms in average in either direction when pushing 1.8Mbps of UDP), but I don't see any information about delay? Perhaps your version of iperf is wording output wrongly or something? 8.35ms seems fine for delay jitter.

Ping RTT is 36.06+-4.82 ms (100 pings) with small packets in my case. It varies a lot depending on 3G technology used (R99 UMTS vs. HSPA+), particular terminal in use (make and firmware) and packet size (see graphs http://www.mkx.si/ping-rtt.png (3G UMTS) and http://www.mkx.si/ping-hs-rtt.png (3G HSPA)).
The most interesting feature of the two graphs is min RTT as shown in red colour on 3G UMTS graph. It clearly show the 10ms TTI nature of 3G (steps are 20ms, 10ms in each direction). Which explains quite large proportion of delay jitter as measured by iperf.
Another interesting feature is missing data on HSPA graph for packet sizes between around 1300 and 1500 bytes: it is due to one particular IP stack implementation that didn't want to respond to ICMP echo request if the packet size was in that range.

The problem with measuring RTT is that results get messy if rquired bandwidth (for packets send forth and back - usually ICMP) exceeds bandwidth available. Then packets get buffered and times start to get real high which skews statistics.

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 #127: Sticky bits on disk.

Tobi Hofer wrote:

Hello together I have some problems with the Delay, Jitter from Iperf. How does Iperf calculate the Jitter Delay? When I measure with UDP the Jitter Delay over a 100Mb-Ethernet, the results are ok (avg delay: 124us, avg jitter 31us). I'm on my Bachelor-Thesis and I have to measure the Delay, Jitter and Packet loss ratio over a PPP-Device (3G) to a Server in the Internet in both ways, up- and downlink. Iperf UDP downlink, 1800k (no loss): avg Delay: 8.35ms avg Jitter: 0.43ms (standard deviation). When I variate the bitrate, the change is about 1 or 2ms. This result can't be correct, because with thrulay the udp delay is avg 75ms. With NDT I have an avg RTT 1142ms After Internet research the Delay over 3G is between 70ms.....180ms How does Iperf calculate the Delay? Is it a problem over 3G UMTS? I work with Iperf 2.0.4-4 for UDP, on the computers is Ubuntu 9.04 installed. Thanks Regards Tobias ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

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

headers

Aaron Brown | 4 Dec 2009 14:28

Re: UDP Delay Problem

I'm not sure if you've looked into it, but there's another tool, OWAMP, that can be used to measure delay, jitter and packet loss unidirectionally ( http://www.internet2.edu/performance/owamp/ ). The thing with unidirectional packet measurement is that the hosts need to have their clocks well synchronized since the method for calculating one-way delay is to take a timestamp on the sender, and take a timestamp on the receiver and compare the two. Configuring NTP on both hosts to synchronize against 4 different good NTP servers is usually adequate for making sure the hosts are reasonably well synchronized. There are a load of other things that can affect the precision of timings (how good the clocks are, what other software is running on the host, etc), but having synchronized clocks is probably good enough for basic measurements of delay/jitter/loss.

Cheers,

Aaron

On Dec 3, 2009, at 10:34 AM, Tobi Hofer wrote:

Hello together

I have some problems with the Delay, Jitter from Iperf.

How does Iperf calculate the Jitter Delay? When I measure with UDP the Jitter
Delay over a 100Mb-Ethernet, the results are ok (avg delay: 124us, avg jitter
31us).

I'm on my Bachelor-Thesis and I have to measure the Delay, Jitter and Packet
loss ratio over a PPP-Device (3G) to a Server in the Internet in both ways,
up- and downlink.

Iperf UDP downlink, 1800k (no loss):
avg Delay: 8.35ms
avg Jitter: 0.43ms (standard deviation).

When I variate the bitrate, the change is about 1 or 2ms.

This result can't be correct, because with thrulay the udp delay is avg 75ms.
With NDT I have an avg RTT 1142ms

After Internet research the Delay over 3G is between 70ms.....180ms

How does Iperf calculate the Delay? Is it a problem over 3G UMTS?

I work with Iperf 2.0.4-4 for UDP, on the computers is Ubuntu 9.04 installed.

Thanks

Regards
Tobias

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

Winter 2010 ESCC/Internet2 Joint Techs

Hosted by the University of Utah - Salt Lake City, UT
January 31 - February 4, 2010

http://events.internet2.edu/2010/jt-slc/

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

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

headers

Travis Foschini | 4 Dec 2009 17:14

Public Iperf Servers

Can anyone recommend Iperf servers publicly available for evaluating internet connections? I found a
couple hosted by educational institutions, but each appears to have limitations. A few more would be nice.

Travis Foschini

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

headers

Metod Kozelj | 7 Dec 2009 09:11

Re: UDP Delay Problem

Howdy!

Actually clock synchronization is quite tough job when one needs sub-millisecond acuracy. Here's output of one host:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
10.101.10.189   10.13.4.30       2 u 70h 1024    0    0.216   -0.477   0.000
+10.101.10.188   10.13.4.30       2 u 569 1024 377    0.285   -2.188   0.208
*10.101.10.168   172.25.2.3       2 u 403 1024 377    0.210   -1.147   0.094
+10.13.4.168     10.101.10.188    3 u 339 1024 377    5.583   -3.031   2.734
-10.101.10.97    10.101.10.188    3 u 525 1024 377    0.223   -1.086   0.014
-10.13.4.1       10.101.10.1      3 u 301 1024 377    0.257   -8.948   4.490
-10.101.10.1     10.13.4.30       2 u 511 1024 377    0.706    4.535   9.706

All of hosts are on one LAN (VLAN segmented) and you can see that delay and jitter wildly differ between different NTP servers. Alas, it's offset that matters: it varies in order of several milliseconds which is simply too much if one wants to measure delay of the same order of magnitude.

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 #42: spaghetti cable cause packet failure

Aaron Brown wrote:

I'm not sure if you've looked into it, but there's another tool, OWAMP, that can be used to measure delay, jitter and packet loss unidirectionally ( http://www.internet2.edu/performance/owamp/ ). The thing with unidirectional packet measurement is that the hosts need to have their clocks well synchronized since the method for calculating one-way delay is to take a timestamp on the sender, and take a timestamp on the receiver and compare the two. Configuring NTP on both hosts to synchronize against 4 different good NTP servers is usually adequate for making sure the hosts are reasonably well synchronized. There are a load of other things that can affect the precision of timings (how good the clocks are, what other software is running on the host, etc), but having synchronized clocks is probably good enough for basic measurements of delay/jitter/loss.

Cheers,

Aaron

On Dec 3, 2009, at 10:34 AM, Tobi Hofer wrote:

Hello together

I have some problems with the Delay, Jitter from Iperf.

How does Iperf calculate the Jitter Delay? When I measure with UDP the Jitter
Delay over a 100Mb-Ethernet, the results are ok (avg delay: 124us, avg jitter
31us).

I'm on my Bachelor-Thesis and I have to measure the Delay, Jitter and Packet
loss ratio over a PPP-Device (3G) to a Server in the Internet in both ways,
up- and downlink.

Iperf UDP downlink, 1800k (no loss):
avg Delay: 8.35ms
avg Jitter: 0.43ms (standard deviation).

When I variate the bitrate, the change is about 1 or 2ms.

This result can't be correct, because with thrulay the udp delay is avg 75ms.
With NDT I have an avg RTT 1142ms

After Internet research the Delay over 3G is between 70ms.....180ms

How does Iperf calculate the Delay? Is it a problem over 3G UMTS?

I work with Iperf 2.0.4-4 for UDP, on the computers is Ubuntu 9.04 installed.

Thanks

Regards
Tobias

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Iperf-users mailing list
Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/iperf-users

Winter 2010 ESCC/Internet2 Joint Techs

Hosted by the University of Utah - Salt Lake City, UT
January 31 - February 4, 2010

http://events.internet2.edu/2010/jt-slc/

------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Iperf-users mailing list Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org https://lists.sourceforge.net/lists/listinfo/iperf-users

--
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 #87: Password is too complex to decrypt

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev

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

headers

Reynolds, Matthew | 11 Dec 2009 12:02

Iperf UDP Packet size

To all,

I am currently a student at Oklahoma State University. I am doing a Research project on an Enterprise network with Iperf. I am encountering an anomaly that I haven't been able to figure out. When I run a UDP test at a packet size of 1470 the test will consistently fail (Warning: ack of last datagram not received after 10 tries). If I lower the packet size below 1273 then the test will consistently pass but still fail occasionally. Is there anything particular about the way Iperf creates the packets and/or socket that may be seen as suspicious or unallowable on a typical large campus network? I am aware of the overhead created by Iperf and the MTU on the routers the packets have to cross are set to 1500. The DF bit is also turned off on the routers. The packets are also travelling by way of a GRE tunnel which also creates its own overhead. I am not much of a programmer so I can't really determine what I need to know by looking at the source code. Any help on this matter would greatly appreciated. Thanks.

Matthew Reynolds
(405)613-1016

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev

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

headers

aurelien solo | 21 Dec 2009 13:00

iperf ipv6

Hello my nanes is Orel I'm french.

I don't sure that if you are the good personn to ask my question, if it is
i'm sorry.

I have a problems with the utilisation of iperf on my IPv6 network. I
utilise the -V option but the soft take the address like a name , and
make a wins request.
My PCs are on windows XP.

Thanks for your help and excuse me for my language.

Au revoir et Merci

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

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

headers

Karthik Balaguru | 26 Dec 2009 19:11

1024 & 1000

Hi,
I wonder why Iperf uses 1024*1024 for megabytes and 1000*1000 for megabits ?

I think, It should follow either 1000 * 1000 (International System of Units)convention or 1024 *1024 convention.
Any specific reason for such a methadology ? Any ideas ?

Thx in advans,
Karthik Balaguru

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

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

headers

Stephen Hemminger | 26 Dec 2009 20:30

Re: 1024 & 1000

On Sat, 26 Dec 2009 23:41:03 +0530
Karthik Balaguru <karthikbalaguru79@...> wrote:

> Hi,
> I wonder why Iperf uses 1024*1024 for megabytes and 1000*1000 for megabits ?
> 
> 
> I think, It should follow either 1000 * 1000 (International System of
> Units)convention or 1024 *1024 convention.
> Any specific reason for such a methadology ?  Any ideas ?

It is confusing, but older standard practice is to use 1024 for storage and
1000 for communication. http://en.wikipedia.org/wiki/Megabyte

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

headers

Marc Herbert | 27 Dec 2009 17:51

Re: 1024 & 1000

2009/12/26 Karthik Balaguru <karthikbalaguru79@...>:
> I wonder why Iperf uses 1024*1024 for megabytes and 1000*1000 for megabits ?
>
> I think, It should follow either 1000 * 1000 (International System of
> Units)convention or 1024 *1024 convention.
> Any specific reason for such a methodology ?  Any ideas ?

I think the historical reason is that memory relies on binary
addresses while telecommunication does not.

A byte is by definition the smallest addressable unit of memory,
typically an octet. On the other hand, many wires are just pushing an
un-interrupted stream of bits. I guess that is why memory is usually
measured in *bytes* while throughput is often measured in *bits/s*.

Memory addresses are binary. Take for instance a memory address with
10 bits: it ranges from 0 to 1111111111 (1023). Since this is
accidentally very close to 1000, memory people have historically
abused the "kilo" prefix to mean 1024. While telecommunication people
have stick to the correct meaning.

I'm afraid the "kibi" and "mebi" prefixes come too late. Would iperf
for instance switch to them where appropriate?

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
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