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