HD sata transfer speeds on a Banana Pi are slow

I use this Banana Pi - http://wiki.banana-pi.org/Banana_Pi_BPI-M1 - as my media server from which I play using OSMC.

In general it works fine and does what I want it to do. I have a hard drive attached to its SATA port. However my data transfer speeds to this hard drive from my desktop PC are not what I would expect from a SATA connection.

The banana pi is connected directly to my router on ethernet, as is my PC. Iperf3 between the two has speeds around 900Mbps in both directions.

When I transfer a file to the server hard drive on it from my PC the transfer speed usually tops out at 7MBps so about 56Mbps. I would have thought a SATA drive would be able to accommodate faster speeds than that? Or is the data bottle necking through its CPU or something?

The banana pi is running Bananian linux (I think). And I think the hard drive is NTFS formatted.

It is getting frustrating as the transfer time for a multi gigabyte file is so long! Is there something that is likely to be hindering the SATA speed on the B Pi? Or is it at an expected speed given the hardware?

If there’s no way of improving it, and I replaced it with a Raspberry Pi 4, and attached the HD via USB 3, would I expect faster transfer speeds then?

NTFS isn’t going to help. That will rely on FUSE and kill your performance.

I’m not sure the SATA controller is a real controller and not just something hooked up to the USB

Other than I know there are different types of drive format, I do not know what each one does or is for. I presume NTFS is more a windows thing, and not great with Linux based systems?

I can presently access the media server’s hard drive over my network from windows. If the drive was formatted to EXT4, would I still be able to do that? And would formatting to that likely improve transfer speeds?

And given the hassle of doing that, would the RPi4 option and connecting via USB3 (I have a sata to USB3 conversion cable) improve transfer speeds?

Yes.

Not necessarily.

Hmm. I’d kind of hoped the RPi4 via USB3 was going to be the way forward, as that would be the simplest option!

Ok, so if I choose to go the EXT4 route, I can format the drive in that format, and recopy over all my data, as I have it all backed up. Plugging it back in to my BananaPi over sata, would it be recognised as the same drive in the same path, or if not straight away, could it be setup/re-mounted to the same path so that my OSMC library is unaffected?

Thanks again for all the help and responses Sam.

That would depend on how the OS on the BananaPi does the mounting of the drive. E.g. OSMC uses the lable of the drive to mount it, so as long as you give the partition the same lable after formating it would be mounted the same path.
But for BananaPi you would ned to check there.

That’s very slow. A search for data online suggests that you should be getting 25+ MB/s. I also read that the internal SATA power interface might provide insufficient power for some disks, so that’s worth checking.

You need to keep the disk testing separate. Choose a reasonably large file (say 100+ MB) (that you haven’t read before, so shouldn’t be cached in memory) and run this command in an SSH session:

dd if=<large file> of=/dev/null bs=4M

If it’s still very slow, open a separate SSH session and run top. Then repeat the dd command with a fresh, uncached file. See how much CPU it’s using.

Thanks, I’ll try those later on the BPi when I finish work for the day.

Power shouldn’t be the issue as I’m using an external power supply to power the HDD. I’m using the front face of a powered HDD enclosure to supply the power to the HDD, and then have connected the data ports between the HDD and the BPi.

I did this part on a film, and got this output:
224+1 records in
224+1 records out
943687680 bytes (944 MB) copied, 13.5862 s, 69.5 MB/s

That seems a more acceptable speed, at approx 70MB/s?

That’s pretty respectable.

Could you repeat the iperf3 figures for us? Run the server on the BPi and the client on the OSMC side. Run the client side with and without the -R option and show us the output.

Ok, iperf3 ran, with the Bpi as the server. Got this for -R -c on my PC:

> Reverse mode, remote host 192.168.1.8 is sending
> [  4] local 192.168.1.50 port 53038 connected to 192.168.1.8 port 5201
> [ ID] Interval           Transfer     Bandwidth
> [  4]   0.00-1.00   sec  57.1 MBytes   479 Mbits/sec
> [  4]   1.00-2.00   sec  61.8 MBytes   519 Mbits/sec
> [  4]   2.00-3.00   sec  68.8 MBytes   577 Mbits/sec
> [  4]   3.00-4.00   sec  83.2 MBytes   698 Mbits/sec
> [  4]   4.00-5.00   sec  88.2 MBytes   740 Mbits/sec
> [  4]   5.00-6.00   sec  88.8 MBytes   745 Mbits/sec
> [  4]   6.00-7.00   sec  87.8 MBytes   736 Mbits/sec
> [  4]   7.00-8.00   sec  80.3 MBytes   674 Mbits/sec
> [  4]   8.00-9.00   sec  90.7 MBytes   761 Mbits/sec
> [  4]   9.00-10.00  sec  90.0 MBytes   755 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth       Retr
> [  4]   0.00-10.00  sec   797 MBytes   669 Mbits/sec   83             sender
> [  4]   0.00-10.00  sec   797 MBytes   669 Mbits/sec                  receiver
>

And this for just -c`

> Connecting to host 192.168.1.8, port 5201
> [  4] local 192.168.1.50 port 53082 connected to 192.168.1.8 port 5201
> [ ID] Interval           Transfer     Bandwidth
> [  4]   0.00-1.00   sec  51.0 MBytes   428 Mbits/sec
> [  4]   1.00-2.00   sec  97.4 MBytes   817 Mbits/sec
> [  4]   2.00-3.00   sec   103 MBytes   861 Mbits/sec
> [  4]   3.00-4.00   sec   102 MBytes   854 Mbits/sec
> [  4]   4.00-5.00   sec   105 MBytes   878 Mbits/sec
> [  4]   5.00-6.00   sec   101 MBytes   850 Mbits/sec
> [  4]   6.00-7.00   sec   102 MBytes   852 Mbits/sec
> [  4]   7.00-8.00   sec   104 MBytes   876 Mbits/sec
> [  4]   8.00-9.00   sec   103 MBytes   868 Mbits/sec
> [  4]   9.00-10.00  sec   100 MBytes   840 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval           Transfer     Bandwidth
> [  4]   0.00-10.00  sec   968 MBytes   812 Mbits/sec                  sender
> [  4]   0.00-10.00  sec   968 MBytes   812 Mbits/sec                  receiver

Think that’s a little slower than it was the other day, as I’m sure I was hitting 900+ in one of the directions, but I guess it isn’t notably different.

Since you were having problems writing to the disk, try this on the BPi:

dd if=/dev/zero of=<file on SATA disk> bs=4M count=100

The output file you’ll need to name yourself and should (obviously) be written to the SATA disk. It’ll create a 400MB file, so ensure you have enough space, or, alternatively, adjust the count.

Since it’s an NTFS volume, and I’m not sure what sync options to use, I’m playing safe and not using anything.

Done, and this is what I got out:

100+0 records in
100+0 records out
419430400 bytes (419 MB) copied, 40.0018 s, 10.5 MB/s

So around 10+MB for writes. It’s probably a combination of NTFS being slow on Linux together with the limitations of spinning discs. I don’t see write performance improving if you stick with NTFS.

Ok, so in theory, what speeds am I potentially going to get if I switch to EXT4?

I have as much chance of predicting the future as I have of knowing what write speeds you’re going to get from ext4. The best answer I can honestly give is that it should be noticeably faster.

1 Like

If you ask on the BananaPi forums they might be able to tell you.

1 Like

You could try to attach the drive directly to your pc, just to check if it gets better performance.
Then just try copying a fairly large file 500+ mb to it and see what transferspeed it gets.

if the performance is the same then its the drive that is slow and changing filesystem will make less of a difference.

Good idea. I will do that before reformatting in EXT4.

Just connected the hdd via a USB3 to SATA converter, to save the hassle of opening my PC up and connecting it to one of the SATA headers. Not sure what speeds connecting directly to the SATA headers would give, but I was getting 115MB/s with the USB3-SATA converter method.

So a much faster speed, which makes me sure it is not the drive.

Guess I’m going the EXT4 route!