MBL 3TB - slow transfer speed

I can’t get any data written to the MBL with more than 14 MB/s (FTP) - this is pretty annoying. Using scp, the speed is nearly 30 percent lower and ends up at 10MB/s. Network led shows green, 1000 Mb/s is confirmed by ethtool.

Logged in via SSH I can see, a top shows, that in both cases the cpu is used up to 100 percent, either by sshd or vfsftpd and a small share of md1_raid1. Any idea what I could do? And why is a raid process running? The device is no duo, so there should be no need for a raid1 process.

Musikpirat wrote:

…why is a raid process running? The device is no duo, so there should be no need for a raid1 process.

The OS volume is a RAID1 array made of two partitions on the same drive for redundancy.

Musikpirat wrote:
the cpu is used up to 100 percent, either by sshd or vfsftpd 

sshd gets high CPU because it’s doing software encryption of the datastream.   SCP will be slow as a result.

That said, I don’t know why your FTP would be so slow.  I’m getting more than 40 megabytes per second for WRITES

ftp> put Fedora-12-x86_64-DVD.iso
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
ftp: 3537600512 bytes sent in 88.22Seconds 40097.94Kbytes/sec.

 … and READS around 50:

ftp> get Fedora-12-x86_64-DVD.iso trash.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for Fedora-12-x86_64-DVD.iso (3537600512 bytes).
226 Transfer complete.
ftp: 3537600512 bytes received in 71.26Seconds 49642.17Kbytes/sec.

 It would be much faster than that, but I happened to have Twonky running a rebuild and twonkymediaserver process was chewing up 70% of the CPU.  

When I was doing a ftp READ, the CPU used by vsftpd was only 4%.  After I killed twonky & mediacrawler, and redid the test, I got 45 megabytes per second WRITE, but I got 84 megabytes per seconds READ:

ftp> get Fedora-12-x86_64-DVD.iso trash.iso
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for Fedora-12-x86_64-DVD.iso (3537600512 bytes).
226 Transfer complete.
ftp: 3537600512 bytes received in 42.37Seconds 83496.99Kbytes/sec.

A virtual raid on a single drive? That sounds indeed redundand. How does that help to survive a crash of the drive? Or shall this protected against failures of single blocks?

Tried a put and get of the same file:

Using binary mode to transfer files.
ftp> put 15M\ Excelente.\ Revulsivo\ ImportanteH264\ v.1.7.mp4
local: 15M Excelente. Revulsivo ImportanteH264 v.1.7.mp4 remote: 15M Excelente. Revulsivo ImportanteH264 v.1.7.mp4
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
456158533 bytes sent in 64.59 secs (6896.5 kB/s)

ftp> get 15M\ Excelente.\ Revulsivo\ ImportanteH264\ v.1.7.mp4
local: 15M Excelente. Revulsivo ImportanteH264 v.1.7.mp4 remote: 15M Excelente. Revulsivo ImportanteH264 v.1.7.mp4
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for 15M Excelente. Revulsivo ImportanteH264 v.1.7.mp4 (456158533 bytes).
226 Transfer complete.
456158533 bytes received in 15.63 secs (28504.7 kB/s)

Some hdparm testings:

hdparm -T /dev/sda

/dev/sda:
 Timing cached reads: 638 MB in 2.00 seconds = 319.05 MB/sec

hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 206 MB in 3.00 seconds = 68.56 MB/sec

hdparm -t --direct /dev/sda

/dev/sda:
 Timing O_DIRECT disk reads: 430 MB in 3.01 seconds = 142.97 MB/sec

 It seems, that using the system buffer greatly reduces the performance. But the read speed it still much faster than the ftp read delivery speed.

uname -a
Linux MyBookLive 2.6.32.11-svn70860 #1 Thu May 17 13:32:51 PDT 2012 ppc GNU/Linux

Wow, this one is pretty ancient.

cat /proc/cpuinfo 
processor	: 0
cpu : APM82181
clock : 800.000008MHz
revision	: 28.131 (pvr 12c4 1c83)
bogomips	: 1600.00
timebase	: 800000008
platform	: PowerPC 44x Platform
model : amcc,apollo3g
Memory : 256 MB

Do you have the same cpu?

Last but not least a simple write test of the drive:

dd if=/dev/zero of=/shares/foo bs=100M count=1 oflag=direct
1+0 records in
1+0 records out
104857600 bytes (105 MB) copied, 1.38896 s, 75.5 MB/s

Also much faster than the ftp write speed.

Musikpirat wrote:

A virtual raid on a single drive? That sounds indeed redundand. How does that help to survive a crash of the drive? Or shall this protected against failures of single blocks?

Mostly for block (sector) errors. 

Musikpirat wrote:

 

uname -a
Linux MyBookLive 2.6.32.11-svn70860 #1 Thu May 17 13:32:51 PDT 2012 ppc GNU/Linux

Wow, this one is pretty ancient.

Yeah, well, the MBL is close to three years old…

Why is your clock wrong?   Is your MBL not able to get internet access?

Musikpirat wrote:

Do you have the same cpu?

Of course.

MBL has internet access - thats how it got the current firmware. But I disable the ntp access. I had guessed, that in the process of updating the firmware a new kernel would have been a nice feature.

I asked for the cpu, because that’s the last thing I can think off, that would explain such a significant difference in speed.

Do you have any other suggestions I could try?

You seem to know your way around Linux. So I would suggest looking for network/transport layer errors, high TCP retransmit levels, etc.