Slow write speeds over samba - looking for optimisation advice

Troubleshooting
1

I’ve got a little gigabyte minipc with a J1900 celeron processor and 4 gb of ram. I’ve got a 4gb disk in a 6GBps caddy. There’s also an internal drive. The 4gb drive I let rockstor format it to btrfs and the internal drive I let it format as the install disk.

I think I should be getting faster transfer rates over samba and just want to know if there is anything I can do to optimise. Right now I’m only getting about 11MBps.

I’ve included a few outputs below. If you need any other outputs let me know.

The output of my write test to the external drive is

dd if=/dev/zero of=/mnt2/Media/test1.img bs=1MB count=10000
10000+0 records in
10000+0 records out
10000000000 bytes (10 GB) copied, 63.0068 s, 159 MB/s

LSPCU

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 55
Model name:            Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz
Stepping:              8
CPU MHz:               1678.039
CPU max MHz:           2415.7000
CPU min MHz:           1332.8000
BogoMIPS:              3998.40
Virtualization:        VT-x
L1d cache:             24K
L1i cache:             32K
L2 cache:              1024K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch epb tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat

LSPCI

00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 0e)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 0e)
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series SATA AHCI Controller (rev 0e)
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI (rev 0e)
00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0e)
00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller (rev 0e)
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 1 (rev 0e)
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 2 (rev 0e)
00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 3 (rev 0e)
00:1c.3 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI Express Root Port 4 (rev 0e)
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 0e)
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus Controller (rev 0e)
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

LSUSB

Bus 002 Device 002: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 13d3:3410 IMC Networks
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

hdparm

 Timing cached reads:   3158 MB in  2.00 seconds = 1579.75 MB/sec
 Timing buffered disk reads: 528 MB in  3.00 seconds = 175.76 MB/sec

btrfs fi show

Label: 'rockstor_rockstor'  uuid: 0aa80e9c-887c-41f1-831c-a061c1f156b8
        Total devices 1 FS bytes used 2.30GiB
        devid    1 size 219.21GiB used 21.02GiB path /dev/sda3

Label: 'MainShare'  uuid: 4a3311ec-e8cd-44aa-bde3-09bbd83f87cf
        Total devices 1 FS bytes used 44.63GiB
        devid    1 size 3.64TiB used 47.02GiB path /dev/sdb
2

@Bee_rii Welcome to the Rockstor community.

My initial suspicion here is that you have a USB bottleneck as 11MBps seems to ring a bell re older USB max throughput. I know you state 6GBps but that is only if plugged into an appropriate port.
The output of the following command might help to see the USB arrangement:

lsusb

Apologies if I’ve got the wrong end of the stick here.

Also your could run the following command to asses drive performance below the file system (very basically):

hdparm -tT /dev/sda

where “/dev/sda” is the name of the disk you want to test.
You can also use the by-id names displayed in Rockstor’s Web-UI. The full path to them is “/dev/disk/by-id/whatever”

And to get a better idea of your btrfs pool arrangement the following command should help:

btrfs fi show

Hopefully the output of those command will help other forum members chip in.

1 Like
3

Thanks for the quick response. I’m pretty sure the USB is USB3. It’s the only blue slot on the box. I have edited my post to include your suggested outputs. I also just realised I didn’t include the most important part of the dd test, the throughput, which I have now added.

4

It seems my slow samba speeds were due to the network cable. I’ve switched the cable and now I’m getting around 70MBps. I’ve also ran tuned with the throughput-performance. I’m pretty happy now but if anyone has any further advice to increase performance let me know.

5

@Bee_rii Thanks for the updated and glad you got it sorted.

It would be good if Rockstor’s network page reported the sync speed achieved by at least the local port. That might help to diagnose such instances. At least if they were local to the plugged in cable. E.g via ethertool:

ethtool p4p2

or whatever the device is called.

I recently myself spent ages tracking down, and initially working around, a long DHCP delay only to find I’d inadvertently used a single switch port previously configured as part of a Link Aggregation Group (LAG) via Link Aggregation Control Protocol (LACP). See the following forum post where I tested this setup in Rockstor:

Switched to a regular port and, as if by magic, the delay returned to normal. I’ll not go into the initial work around as it was embarrassingly deep for the sake of using the wrong port. @Flox I’d meant to update you on this finding by the way re our PM on this recent issue :blush:. Sometimes, (read mostly), it’s fairly easy to over think stuff. Especially when our technology is so deep these days.

Still your should be able to near saturate that ethernet link. You could try the iperf trick to double check you have a descent lower level connection, just in case.

Hope that helps.