vignesh venkateswaran | 16 Jul 12:10 2012
Picon

Iperf TCP Hangs

I am using Iperf 2.0.4 on linux 2.6.32.10 loaded in two Mikrotik Routerboards 411AR.
I tried to run iperf in these two boards through serial connections from the
boards to my laptop via minicom and measure the 802.11 performance.
When I run iperf tcp test setting one board as server and another as client, I can see only
the following message:

root <at> OpenWrt:/# iperf -s
------------------------------

------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.20 port 5001 connected with 192.168.1.6 port 41061


root <at> OpenWrt:/# iperf -c 192.168.1.20
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 41061 connected with 192.168.1.20 port 5001


At this point, the client hangs and the results are not displayed, not even much later
than 10 secs. Sometimes, the results are displayed after arbitrary time intervals like
17.4 secs, 1092.2 secs and so on.

UDP works fine. I get the results exactly after 10 secs.

Can somebody identify the problem behind this and also suggest an appropriate
solution?


Vignesh

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Aaron Brown | 16 Jul 13:46 2012

Re: Iperf TCP Hangs

Hi Vignesh,

The way iperf works is the client makes a tcp connection to the server, and sends 10 seconds worth of data. However, the client-side kernel is buffering that data up, and sending it, and, in the case of loss, resending it. If you have a very lossy connection, it may take far more than 10 seconds for the server to receive '10 seconds' worth of data. If you add a '-i 2' to the server side command-line, you can see the rate it's receiving the data at every 2 seconds which should help you see what's happening.

Cheers,
Aaron

On Jul 16, 2012, at 6:10 AM, vignesh venkateswaran wrote:

I am using Iperf 2.0.4 on linux 2.6.32.10 loaded in two Mikrotik Routerboards 411AR.
I tried to run iperf in these two boards through serial connections from the
boards to my laptop via minicom and measure the 802.11 performance.
When I run iperf tcp test setting one board as server and another as client, I can see only
the following message:

root <at> OpenWrt:/# iperf -s
------------------------------
------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.20 port 5001 connected with 192.168.1.6 port 41061


root <at> OpenWrt:/# iperf -c 192.168.1.20
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 41061 connected with 192.168.1.20 port 5001


At this point, the client hangs and the results are not displayed, not even much later
than 10 secs. Sometimes, the results are displayed after arbitrary time intervals like
17.4 secs, 1092.2 secs and so on.

UDP works fine. I get the results exactly after 10 secs.

Can somebody identify the problem behind this and also suggest an appropriate
solution?


Vignesh

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Iperf-users mailing list
Iperf-users-5NWGOfrQmncRDUWM+popnw@public.gmane.orgforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users

ESCC/Internet2 Joint Techs
July 15-19, 2012 - Palo Alto, California
Hosted by Stanford University
http://events.internet2.edu/2012/jt-stanford/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
vignesh venkateswaran | 16 Jul 15:33 2012
Picon

Re: Iperf TCP Hangs

I tried your suggestion. I guess you are right. This was the output when I added -i 2 to the client side command.

root <at> OpenWrt:/# iperf -c 192.168.1.20 -i 2 -o root/tcp.txt

------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 48178 connected with 192.168.1.20 port 5001
write2 failed: Connection timed out
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-962.0 sec  21.4 KBytes    182 bits/sec

However, there is some anomalous behavior. I received the final output only after almost 15 min ( anyways, it is close to the interval mentioned above) and not a report every 2 secs and nothing was written to the file.

Then I tried the same command. This time I didn't write the output to a file but captured it in minicom which I have attached.
Kindly take a look at it.

In the file, in the first 2 secs 24KB is transferred and everywhere else it is zero. However, the summary at the end reports a transfer of
29.9 KB. This is another odd occurrence.

Anyways, the iperf tcp generally reports the throughput results after around 15 mins and the throughput is usually low in 100's of bits/sec. So, as you pointed out i guess the connection may be lossy. However, I don't think there would be any environmental losses as I have placed the boards close enough.

Any ideas why this doesn't happen with UDP?
And, any views about these odd behavior and low throughput?

Moreover, if can you explain how the client-side kernel decides how much data to send ( as you had mentioned '10 secs worth of data')
it will helpful.

Vignesh

On Mon, Jul 16, 2012 at 6:55 PM, vignesh venkateswaran <vvinindia-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I tried your suggestion. I guess you are right. This was the output when I added -i 2 to the client side command.

root <at> OpenWrt:/# iperf -c 192.168.1.20 -i 2 -o root/tcp.txt
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 48178 connected with 192.168.1.20 port 5001
write2 failed: Connection timed out
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-962.0 sec  21.4 KBytes    182 bits/sec

However, there is some anomalous behavior. I received the final output only after almost 15 min ( anyways, it is close to the interval mentioned above) and not a report every 2 secs and nothing was written to the file.

Then I tried the same command. This time I didn't write the output to a file but captured it in minicom which I have attached.
Kindly take a look at it.

In the file, in the first 2 secs 24KB is transferred and everywhere else it is zero. However, the summary at the end reports a transfer of
29.9 KB. This is another odd occurrence.

Anyways, the iperf tcp generally reports the throughput results after around 15 mins and the throughput is usually low in 100's of bits/sec. So, as you pointed out i guess the connection may be lossy. However, I don't think there would be any environmental losses as I have placed the boards close enough.

Any ideas why this doesn't happen with UDP?
And, any views about these odd behavior and low throughput?

Moreover, if can you explain how the client-side kernel decides how much data to send ( as you had mentioned '10 secs worth of data')
it will helpful.

Vignesh.


On Mon, Jul 16, 2012 at 5:16 PM, Aaron Brown <aaron-H4aWS73dXup+qImEYqgU8Q@public.gmane.org> wrote:
Hi Vignesh,

The way iperf works is the client makes a tcp connection to the server, and sends 10 seconds worth of data. However, the client-side kernel is buffering that data up, and sending it, and, in the case of loss, resending it. If you have a very lossy connection, it may take far more than 10 seconds for the server to receive '10 seconds' worth of data. If you add a '-i 2' to the server side command-line, you can see the rate it's receiving the data at every 2 seconds which should help you see what's happening.

Cheers,
Aaron

On Jul 16, 2012, at 6:10 AM, vignesh venkateswaran wrote:

I am using Iperf 2.0.4 on linux 2.6.32.10 loaded in two Mikrotik Routerboards 411AR.
I tried to run iperf in these two boards through serial connections from the
boards to my laptop via minicom and measure the 802.11 performance.
When I run iperf tcp test setting one board as server and another as client, I can see only
the following message:

root <at> OpenWrt:/# iperf -s
------------------------------
------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.20 port 5001 connected with 192.168.1.6 port 41061


root <at> OpenWrt:/# iperf -c 192.168.1.20
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 41061 connected with 192.168.1.20 port 5001


At this point, the client hangs and the results are not displayed, not even much later
than 10 secs. Sometimes, the results are displayed after arbitrary time intervals like
17.4 secs, 1092.2 secs and so on.

UDP works fine. I get the results exactly after 10 secs.

Can somebody identify the problem behind this and also suggest an appropriate
solution?


Vignesh

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Iperf-users mailing list
Iperf-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/iperf-users

ESCC/Internet2 Joint Techs
July 15-19, 2012 - Palo Alto, California
Hosted by Stanford University
http://events.internet2.edu/2012/jt-stanford/




--
V.Vignesh
B.Tech.,(3rd Yr.)
Electrical Engineering
IIT Mandi
PH: +91 8894180065




--
V.Vignesh
B.Tech.,(3rd Yr.)
Electrical Engineering
IIT Mandi
PH: +91 8894180065

root <at> OpenWrt:/# ls root/root <at> OpenWrt:/# lsroot <at> OpenWrt:/# iperf --helproot <at> OpenWrt:/# iperf -c
192.168.1.20 -i 2
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 52242 connected with 192.168.1.20 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 2.0 sec  24.0 KBytes  98.3 Kbits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  2.0- 4.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  4.0- 6.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  6.0- 8.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  8.0-10.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 10.0-12.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 12.0-14.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 14.0-16.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 16.0-18.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 18.0-20.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 20.0-22.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 22.0-24.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 24.0-26.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 26.0-28.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 28.0-30.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 30.0-32.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 32.0-34.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 34.0-36.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 36.0-38.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 38.0-40.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 40.0-42.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 42.0-44.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 44.0-46.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
.
.
.
.
.
.							//It goes on like this till 602 secs and then directly jumps on to print a summary for 964.5 secs
[ ID] Interval       Transfer     Bandwidth
[  3] 572.0-574.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 574.0-576.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 576.0-578.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 578.0-580.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 580.0-582.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 582.0-584.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 584.0-586.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 586.0-588.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 588.0-590.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 590.0-592.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 592.0-594.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 594.0-596.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 596.0-598.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 598.0-600.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3] 600.0-602.0 sec  0.00 Bytes  0.00 bits/sec
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-964.5 sec  29.9 KBytes    254 bits/sec
root <at> OpenWrt:/# 
root <at> OpenWrt:/# 
root <at> OpenWrt:/# 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
vignesh venkateswaran | 17 Jul 10:59 2012
Picon

Iperf TCP Hangs

I tried your suggestion. I guess you are right. This was the output when I added -i 2 to the client side command.

root <at> OpenWrt:/# iperf -c 192.168.1.20 -i 2 -o root/tcp.txt

------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 48178 connected with 192.168.1.20 port 5001
write2 failed: Connection timed out
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-962.0 sec  21.4 KBytes    182 bits/sec

However, there is some anomalous behavior. I received the final output only after almost 15 min ( anyways, it is close to the interval mentioned above) and not a report every 2 secs and nothing was written to the file.

Then I tried the same command. This time I didn't write the output to a file but captured it in minicom (The capture file is in the previous post)
Kindly take a look at it.

In the file, in the first 2 secs 24KB is transferred and everywhere else it is zero. However, the summary at the end reports a transfer of
29.9 KB. This is another odd occurrence.

Anyways, the iperf tcp generally reports the throughput results after around 15 mins and the throughput is usually low in 100's of bits/sec. So, as you pointed out i guess the connection may be lossy. However, I don't think there would be any environmental losses as I have placed the boards close enough.

Any ideas why this doesn't happen with UDP?
And, any views about these odd behavior and low throughput?

Moreover, if can you explain how the client-side kernel decides how much data to send ( as you had mentioned '10 secs worth of data')
it will helpful.


Vignesh
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Aaron Brown | 17 Jul 14:28 2012

Re: Iperf TCP Hangs

Hey Vignesh,

On Jul 17, 2012, at 4:59 AM, vignesh venkateswaran wrote:

I tried your suggestion. I guess you are right. This was the output when I added -i 2 to the client side command.

root <at> OpenWrt:/# iperf -c 192.168.1.20 -i 2 -o root/tcp.txt
------------------------------------------------------------
Client connecting to 192.168.1.20, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.6 port 48178 connected with 192.168.1.20 port 5001
write2 failed: Connection timed out
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-962.0 sec  21.4 KBytes    182 bits/sec

Don't look at the send side, look at the receive side. The send side numbers are going to be skewed since it's a combination of writing to the kernel buffers, and the data actually sent. The receive side will have just the data that was received. Note the error message in the above: "write2 failed: Connection timed out". Something is going wrong. I've no clue what, but it looks like the connection is dying.

However, there is some anomalous behavior. I received the final output only after almost 15 min ( anyways, it is close to the interval mentioned above) and not a report every 2 secs and nothing was written to the file.

Then I tried the same command. This time I didn't write the output to a file but captured it in minicom (The capture file is in the previous post)
Kindly take a look at it.

In the file, in the first 2 secs 24KB is transferred and everywhere else it is zero. However, the summary at the end reports a transfer of
29.9 KB. This is another odd occurrence.

Anyways, the iperf tcp generally reports the throughput results after around 15 mins and the throughput is usually low in 100's of bits/sec. So, as you pointed out i guess the connection may be lossy. However, I don't think there would be any environmental losses as I have placed the boards close enough.

Any ideas why this doesn't happen with UDP?
And, any views about these odd behavior and low throughput?

Not a clue. My only guess would be an MTU issue where the sender is trying to send at a higher MTU than is supported by the network, and the UDP sending is being done with a smaller packet size.

Moreover, if can you explain how the client-side kernel decides how much data to send ( as you had mentioned '10 secs worth of data')
it will helpful.

Cheers,
Aaron



Vignesh

ESCC/Internet2 Joint Techs
July 15-19, 2012 - Palo Alto, California
Hosted by Stanford University
http://events.internet2.edu/2012/jt-stanford/

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users
Guravaiah Prathipati | 28 Jul 21:37 2012
Picon

Procedure and list of changes to build iperf2.0.5b1 with visualstudio

Hi Chuck, 


Sorry for wide distribution.

Can you please send me procedure you followed to build iperf2.0.5b1 on windows as well as all source chanegs/function calls you changed to build iperf with visual studio.

Thanks,
Guru.
 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Iperf-users mailing list
Iperf-users@...
https://lists.sourceforge.net/lists/listinfo/iperf-users

Gmane