Test and Maximize network thruput

I had to transfer lots (LOTS) of video files from my IMAC where I had catptured a bunch of older DV tapes. Since space ran out (iMovie doesnt compress the video when capturing so a standard DV hour of video took 11-12GB which means the disk fills pretty fast (only 256GB SSD in my case).

So I moved the files to a NAS I have created. It’s really an old PC which have Linux (Ubuntu 16.10) installed. I stuffed it with all the drives I could find laying around, so it has 4 drives with sizes between 500GB and 3TB. Also a couple of USB external drives. Everything shared using Samba.

I thought nothing of that setup until I noticed that when rsyncing (which I thought was the fastest way of copying – silly me!) showed the following report:

Number of files: 38547
Number of files transferred: 25955
Total file size: 185.06G bytes
Total transferred file size: 150.97G bytes
Literal data: 150.97G bytes
Matched data: 0 bytes
File list size: 1359369
File list generation time: 0.435 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 130.08G
Total bytes received: 646.55K

sent 130.08G bytes received 646.55K bytes 9.28M bytes/sec

Since I have a Gigabit network, and nothing else using the network while I did this, I expected more like 100MB/s.  (Since you can estimate the MB/s by dividing the Mbit/s by 10)

So, I started to investigate. The mighty Google informed me that many others had asked the same question.

So where to start? I checked the network. Only one Gigabit switch (cheap brand but hey…). One Cat6 cable of about 5 meters, one Cat5e cable of 1 meter. Not much to complain about there!

So, I found this little tool called “iperf” which I installed on the two Linux-servers and on my Imac.

sudo apt-get install iperf
brew install iperf

Starting server on Linux:

mint[~/dev] >iperf -s
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
[ 4] local port 5001 connected with port 53679
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.10 GBytes 940 Mbits/sec

Starting the client on OSX:

Peters-iMac-2 peter ~>iperf -c
Client connecting to, TCP port 5001
TCP window size: 129 KByte (default)
[ 4] local port 53679 connected with port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec

So, there we go, full speed ahead! Absolutely nothing to complain about.

Except…. that copying real files took 10 times as long…..

I tried setting up a NFS share, but to cut a long story short is that the net result was the same as with Samba. About 11-12MB/s.

Then I read that FTP was a no-thrills protocol that delivered raw speed.  SMB is very “chatty” they say.

So I quickly setup a FTP server:

sudo apt install vsftpd

changed write-enable to YES and restarted

sudo restart vsftpd

then I needed a file to transfer.  This nifty command creates a 1GB file full of zeroes.

mint[~/dev] >dd if=/dev/zero of=file.txt count=1024 bs=1048576
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 8,4619 s, 127 MB/s

(Note the write speed: 127MB/s. I ran it several times and the speed was around that figure)

Then I tried a transfer

mint[~/dev] >ftp
 Connected to
 220 (vsFTPd 3.0.2)
 Name ( alpha
 331 Please specify the password.
 230 Login successful.
 Remote system type is UNIX.
 Using binary mode to transfer files.
 ftp> put file.txt
 local: file.txt remote: file.txt
 200 PORT command successful. Consider using PASV.
 150 Ok to send data.
 226 Transfer complete.
 1073741824 bytes sent in 17.85 secs (57.3761 MB/s)

OK That was a little better! But why only 57MB/s?? Why not 100?

Could it be the hard drives of the server?

So I tried the dd command above, but on the server:

fsh-199 alpha ~ >dd if=/dev/zero of=file.txt count=1024 bs=1048576
 1024+0 records in
 1024+0 records out
 1073741824 bytes (1,1 GB) copied, 15,9475 s, 67,3 MB/s

There we go! Apparently the disks are not the fastest, so 67MB/s was the max, and FTP used 57 of those.

Next step will be to get Samba and NFS to shape up! How? I have no idea. Will have to Gooogle it….

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.