Ok, I'm back and I had some time to further pursue this question. |
Thanks to tkaiser for pointing me into the right direction. I reached a point now, where the read speed almost matches the write performance (~29MB/s reading and 29-30MB/s writing).
But a few steps back to help others understand, too.
1) I tested Samba 4.1 from from wheezy-backports (actually for reasons completely unrelated to the performance tests in this thread). Debian Wheezy is still on Samba 3.6 if you use the standard repositories. But some simple performance tests showed that 4.1 actually performs much worse on Banana Pi. Transfer speeds were around 20MB/s but I didn't spend any time trying to optimize this. Just as a sidenote. And since 4.1 didn't help me with the other issue I was testing it for, I went back to Samba 3.6.
2) I checked the interrupts as tkaiser suggested. It seems almost all interrupts are handled by the first CPU core, including usb and eth0.
So, I ran these commands to assign some work to the second core:
And this resulted in getting read speeds of ~29MB/s which is almost the same than the write performance. That's a point where I think it's not worth spending additional time into further tweaking (this may be different for someone who uses sata instead of usb). Copy the Code
- echo 2 > /proc/irq/$(cat /proc/interrupts | grep eth0 | cut -f 1 -d ":" | tr -d " ")/smp_affinity
- echo 2 > /sys/class/net/eth0/queues/rx-0/rps_cpus
- echo 2 > /sys/class/net/eth0/queues/tx-0/xps_cpus
3) I'm using a different harddrive now (still USB, not SATA). hdparm in direct mode shows maximum read speads of 30-31MB/s. So, even if I'd test further tweaks, I'm almost at the limit here anyway.
@LaurensBER: My clients are mostly Windows 7. Therefore, and for better ontrol over security parameters, I prefer Samba over NFS.
And one more question to tkaiser: Why do you set smp_affinity for sw_ahci during boot as well? Do IRQs change after rebooting the system if you don't set this to a fixed value?