When testing a metropolitan-Ethernet link the following was repeatably observed. (Repeatably means over several test days with different test laptops and each test repeated 5+ times in either direction and bidirectionaly) This is supposed to be 100Mbps bridged Ethernet so numbers around 90Mbps are fine.
Unidirectionally the links check out fine: A->B 90Mbps B->A 90Mbps Bidirectionally one of them is slow: A<-=>B (A: iperf -s B: iperf -c A -d) A->B 86Mbps B-A> 55MbpsB<-=>A (A: iperf -c B -d B: iperf -s) A->B 86Mbps B-A> 55Mbps (yes, that's right, with client/server flipped the B->A side is still the slow one)
Thinking this clearly indicated a lack of bandwidth on the return leg (B->A) we've been working with the carrier. However, today, for the sake of further testing, I moved the testset to the local LAN separated only by gigabit switches and both A and B on 100Mbps FDX ports. I got the same test results.
I then downloaded tcpperf, which claims to be a very simple test used for simulation modeling (perfect!) from http://wand.cs.waikato.ac.nz/~stj2/nsc/software.html and ran it. tcpperf showed 90Mbps A->B, B->A and A<->B
This leaves me with two baffling questions: 1. What am I doing wrong with iperf?2. Why is it the B->A path is always the one that suffers in the bidirectional test no matter who is acting as client and who is acting as server?
I spent hours yesterday and today googling everything iperf and bidirectional, and then just plain iperf (which is how I found tcpperf) and got no information.
Any ideas? Thanks in advance, EhudPS iperf -r (instead of -d) performs the same as the unidirectional tests above.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
