standard results for gigabit ethernet iperf

Question

I can't achieve good transfer rate through scp and I wonder if the network configuration isn't tuned up correctly. I've noticed some differences when running iperf through tcp vs udp. Are these results normal for two PC's in the same gigabit ethernet lan? This is the output from the server:

./iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.91.150 port 5001 connected with 192.168.91.164 port 50651
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec   599 MBytes   501 Mbits/sec


./iperf -s -u -w 64K
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 64.0 KByte
------------------------------------------------------------
[  3] local 192.168.91.150 port 5001 connected with 192.168.91.164 port 39694
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-30.0 sec   179 MBytes  50.0 Mbits/sec   0.386 ms    0/127660 (0%)
[  3]  0.0-30.0 sec  1 datagrams received out-of-order

when transfering through scp:

129MB   4.6MB/s   00:28  

Are these results coherent? Why is so much difference between UDP/TCP/SCP ( is scp supposed to go over tcp?)

Thanks

Answer 1

iperf testing over UDP requires the client to specify what bandwidth to send at (-b option). So for your UDP test results listed, your iperf client was configured to push data to your server at a rate of 50 Mbits/sec.

iperf testing over TCP sometimes requires that you adjust the TCP Window Size option (-w) to fully saturate a fast link. Try using "-w 256k" on both the iPerf client and iPerf server and test again.

=-=-=-=

scp runs over TCP. scp can be configured to encrypt and/or compress data before sending it. Your bottleneck may be the CPU on one side of your link (do you have a way to check CPU utilization?). You can try specifying a different encryption method or (if you trust your link) even disable encryption altogether. You can also confirm that compression is disabled.

Are you trying to transfer many small files over scp? If so, you may get better performance if you 'tar' up the small files into one big file before sending over scp.