Howdy!
When performing TCP tests, one has to keep in mind also available
bandwidth in other direction due to TCP ACK packets. Or, more precisely,
combination of bandwidth and latency, combined with TCP transmit window
size.
In case of your dual test the solaris host (the one connected to 1Gbps
ethernet switch port) transmits data for the transmit test as fast as
possible and in the same time transmits ACK packets for the receive
test. As the bottleneck (100 Mbps) is in the ethernet switch, that
switch affects performance considerably as it needs to buffer ethernet
frames for quite log time. This alone causes slow-downs and the effect
depends also on TCP TX window size. If packets get delayed for too long,
TX side times out waiting for ACK and does retransmit.
It might happen that ethernet switch drops packets, which you could
only see if you'd check traffic on the slow side (LInux) with some
sniffer tool (eg. wireshark). Dropped packets have serious effect on
throughput both ways. If data packets (downstream) get dropped, then
throughput in downstream gets reduced. If ACK packets get dropped, then
throughput in the other direction (upstream) gets reduced.
In your test you can observe slow throughput in direction from slow
towards fast host in case of bi-directional tests. This indicates that
ACK packets (sent by fast side) get either much delayed or even dropped
in the ethernet switch. Probably they get dropped or else TCP would have
throttled Window size up and you'd still get somehow better performance.
You can check for dropped ACKs by running wireshark on the slow side. If
you examine ACK packet contents, you'll see sequence numbers of packets
being ACKed ... if packets with same sequence number get TXed more than
once before ACK has been received, then you see packet loss.
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 #161:
monitor VLF leakage
Daniel Taylor je dne 17/07/10 16:41 napisal-a:
Hello,
I've been building an OpenSolaris based NAS and I've spotted something
a bit odd with the bi-directional iperf results and I was hoping
someone could explain?
Here's a linux -> linux test, that shows (what are to me) good results
on our 100mb LAN.
# iperf -c 192.168.1.185 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.185, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.52 port 55191 connected with 192.168.1.185 port 5001
[ 4] local 192.168.1.52 port 5001 connected with 192.168.1.185 port 59746
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 109 MBytes 91.1 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.2 sec 108 MBytes 88.9 Mbits/sec
Now here we have linux -> opensolaris (server running on solaris, but
I get same results the other way around as I will show)
# iperf -c 192.168.1.150 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.1.150, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.52 port 34412 connected with 192.168.1.150 port 5001
[ 4] local 192.168.1.52 port 5001 connected with 192.168.1.150 port 32944
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 13.3 MBytes 11.1 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 113 MBytes 93.5 Mbits/sec
It's down the 11.1Mbits/sec and I don't know why?
(server on linux, client on solaris)
#iperf -c 192.168.1.52 -d
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 125 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to web.trinity, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.150 port 58255 connected with 192.168.1.52 port 5001
[ 6] local 192.168.1.150 port 5001 connected with 192.168.1.52 port 58691
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 113 MBytes 94.5 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 6] 0.0-10.1 sec 12.4 MBytes 10.3 Mbits/sec
Again its slow. Is that up or down speed?
So what's happening? I'm guessing its solaris?
The NIC's in all servers are 1gb, but the linux servers going into
100mb switch ports and the solaris machine goes into a 1000mb port
(same switch). Other than that there's no environmental factors I can
think off.
On the solaris server its broadcom NIC, managed with the BGE driver.
I'll try putting the solaris server onto a 100mb port tomorrow and
replacing its network cable (its only about 2 days old anyway, bought
not hand-built).
Until then, does anyone have any ideas?
I should say that the 'normal' tests are perfect. run at ~94mb. It's
just the bi-directional test (-d).
Thanks!
- Daniel
------------------------------------------------------------------------
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
------------------------------------------------------------------------
_______________________________________________
Iperf-users mailing list
[email protected]
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 #181:
Atilla the Hub
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Iperf-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/iperf-users
