HI,
i have extreme slow network transfer rate when copy to or from the pi 4. only 2-4mb/s.
SMB/CIFS option in OMV6
min receivefile size = 16384
write cache size = 524288
getwd cache = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
read raw = yes
write raw = yes
Write/read disk speed
/dev/md127:
Timing cached reads: 2058 MB in 2.00 seconds = 1030.87 MB/sec
Timing buffered disk reads: 1052 MB in 3.00 seconds = 350.59 MB/sec
Any suggestions? any ideas.
What kind of drive are you using. If they are all SSD;s then you might be using ones that are causing the issue.
Yes they are all ssd drives
I am having same issue but I know that this is a known issue " Slow transfer speed due to SSD cache acceleration" and just need to be more selective when it comes the the drives that we use.
I remove the ssd and add hdd and we will see the result.
Please keep us posted.
2 HDD - Raid 0, no changes.
/dev/md127:
Timing cached reads: 1748 MB in 2.00 seconds = 875.06 MB/sec
Timing buffered disk reads: 42 MB in 8.19 seconds = 5.13 MB/sec
Transfer copy speed from win to pi - 4 MB/s max.
@Sentinel is this network transfer rate testing being performed with your Argon EON connected via 1Gbps (wired) Ethernet (and if so, have you verified 1Gbps full-duplex network connectivity back to the source)?
Also - your most recent buffered disk reads values of 5.13 MB/s seem extremely sluggish.
actually I am having the same issue. if I do a data transfer using dd from one disk to another, I get fast speeds. If I do a network transfer with filezilla, it is very slow.
Yes full 1gb Network connection.
With the ssd was 350/s and the same result.
Ok it was my mistake, I didn’t know that the windows device also needs a 1gbit connection when copying from one server to another.
If I copy within a server, it makes no difference, i.e. from hdd to hdd.
Why does the device also need the 1gbit?
It just executes the command!
Server1—PC----Server2
1gbit — WLAN ---- 1gbit = 4mbit/s
1gbit — CABLE — 1gbit = 100mbit/s
There is no difference between cable or WLAN
PC ------ Server1 --HDD1 to HDD2
WLAN – 1gbit — ----100mbit ----
The slowest device within the “chain” will always be the “bottleneck”. : which could be an older hub (hopefully this isn’t the case) , networking switch, older/misconfigured WiFi access point, or even a lower quality networking cable (that wasn’t manufactured to properly perform at 1Gbos speeds).
If you are interested in testing the maximum performance, you should ensure that both the source (server) and target are connected to the same switch at 1Gbps (full-duplex) and I would also recommend testing via Linux ssh (e.g. using your preferred Linux file manager via ssh://192.168.1.100/Movies) as SMB also has various protocol versions + settings that can often introduce significant performance differences during testing.
The notebook is the only device with poor wlan connection.
All other devices are 1gbit eth connected to GB switch.
I buy a new long cable, and then I have no problems 
I had transfer rates of 10-20MB/sec via WinSCP from my PCIe4.0 SSD onto the RAID0 (consisting of 2x virgin 18TB exos formatted yesterday via mkfs), both network devices connected via gigabit ethernet. I checked the tranfer options in WinSCP and it states it does encrypt new files when transferring. switching this encryption off didnt alter the transfer rate.
Would I be better of if I just had them run via a JBOD/linear array?
Is GPT and ext4 the best choice for setting up those drives?
What would be the critical parameters in the drive-formatting-procedure?
Is anybody able to tell me what file system would you choose, and what determines which parameter one should choose formatting.
I read btrfs is the file system of choice by OMV, but would I use it on the formatting of the drives or the formatting of the RAID? I had the RAID made via the Ricmedia-tutorial posted by argon40-staff and saved.
sudo mkfs.ext4 -v -m .1 -b 4096 -E stride=32,stripe-width=64 /dev/md/vol1
what options are there to better the data transfer rate and how would I go about to test them?
I ran into something disturbing.
The setup of a RAID0 went according to Ricmedia tutorial and I could use it for quite some time.
Today, I plugged an external HDD to the remaining USB3 port beneath the EON-HDD-adapter-bridge.
I mounted the drive at a newly created /mnt/wd directory and filled it. I noticed very bad speeds, below 10MB/s. What I realized later was, that the RAID0, that had previously been working as a samba drive from /mnt, as shown in the Ricmedia tutorial that was propagated through one argon staff member, did show three directories I created, but no files anymore. I shut the pi down, unplugged the external USB3-HDD to reboot the pi. RAID was running again and the files were accessible again but the speed dropped to below 10MB/s, where before that it was able to handle full Gbit/s ethernet speed.
I soft and hard rebooted only to see that this doesnt resolve itself.
I am very irritated by that and did not find anything related.
Would anybody be able to help me with fixing the teransfer speeds? Did raspian mix something up over the two different USB-HDD controllers (the one EON uses and the other one for external HDD)?
I would gladly welcome any suggestions, where to look.
is anyone of the argon staff still around? I find it unpleasant that there is no official support for the last three weeks now.
From your description it looks like when YOU plugged in an additional device to the system via the external adapters, this effected the device ordering… and OMV got confused.
Removing the device made OMV happy.
As for the slow performance, something may still be out of whack.
Remember when dealing with drives, never refer to the device as /dev/sd[abcde], as devices can (and will) be mounted differently on the next boot, depending on how long it takes for devices to startup, and scan order.
Usually /dev/disk/by-id, or /dev/disk/by-uuid/ works much better.
On my system:
pinas:/dev/disk/by-id $ ls -al
total 0
drwxr-xr-x 2 root root 200 May 18 11:18 .
drwxr-xr-x 7 root root 140 May 18 11:18 ..
lrwxrwxrwx 1 root root 9 May 18 11:18 ata-MICRON_M510DC_MTFDDAK960MBP_15170FAB1DD5 -> ../../sdd
lrwxrwxrwx 1 root root 9 May 18 11:18 ata-MICRON_M510DC_MTFDDAK960MBP_153511F380DE -> ../../sdb
lrwxrwxrwx 1 root root 9 May 18 11:18 usb-JMicron_Generic_0123456789ABCDEF-0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 May 18 11:18 usb-JMicron_Generic_0123456789ABCDEF-0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 18 11:18 usb-JMicron_Generic_0123456789ABCDEF-0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 9 May 18 11:18 usb-Pinas_SATA_0000000000EC-0:0 -> ../../sdc
lrwxrwxrwx 1 root root 9 May 18 11:18 wwn-0x500a07510fab1dd5 -> ../../sdd
lrwxrwxrwx 1 root root 9 May 18 11:18 wwn-0x500a075111f380de -> ../../sdb
As you can see;
/dev/disk/by-id/wwn-0x500a075111f380de is currently mounted as /dev/sdb
So… instead of /dev/sdb, I should use /dev/disk/by-id/wwn-0x500a075111f380de
thanks for your reply. I am not using OMV as I am running this device as a storage unit only and have snapcast-server running as the only other service besides SSH and SMB.
I wanted to minimize the load, also, because the Pi is a 2GB one of the latest series.
By now, the first few GB of a transfer (50-80GB daily volume) run smoothly at Gbps, then, somewhere at 5-10GB volume, the transfer speeds break down.
I entered the UUID in fstab so as to auto-mount the RAID0 on reboot. The RAID is mounted directly in /mnt/, which I have not known was possible but was described in the tutorial. There is one thing I find odd. For mounting the drive, I needed to create a folder, which I did. After unmounting, the folder should still be there. Not so after the reboot. The folder /mnt/wd/ is gone. Only the three folder from the RAID. Is that something that could have interfered?
pi@pi4-EON:~ $ ls /dev/disk/by-uuid -al
total 0
drwxr-xr-x 2 root root 100 May 18 08:24 .
drwxr-xr-x 8 root root 160 May 18 08:24 ..
lrwxrwxrwx 1 root root 15 May 18 08:24 37E2-62C3 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 May 18 08:24 6a932c1f-7335-42d9-9351-1b1b2ca538d4 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 11 May 18 08:24 9967d386-efe6-44f3-b852-a5d3395f0a90 -> ../../md127
pi@pi4-EON:~ $ ls /dev/disk/by-id -al
total 0
drwxr-xr-x 2 root root 300 May 18 08:24 .
drwxr-xr-x 8 root root 160 May 18 08:24 ..
lrwxrwxrwx 1 root root 9 May 18 08:24 ata-ST18000NM000J-2TV103_WR500L6S -> ../../sda
lrwxrwxrwx 1 root root 10 May 18 08:24 ata-ST18000NM000J-2TV103_WR500L6S-part1 -> ../../sda1
lrwxrwxrwx 1 root root 9 May 18 08:24 ata-ST18000NM000J-2TV103_WR500LZL -> ../../sdb
lrwxrwxrwx 1 root root 10 May 18 08:24 ata-ST18000NM000J-2TV103_WR500LZL-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 11 May 18 08:24 md-name-pi4-EON:md -> ../../md127
lrwxrwxrwx 1 root root 11 May 18 08:24 md-uuid-21f6a988:8a317d6d:1d0dcb15:ced6a523 -> ../../md127
lrwxrwxrwx 1 root root 13 May 18 08:24 mmc-SD32G_0x0000011c -> ../../mmcblk0
lrwxrwxrwx 1 root root 15 May 18 08:24 mmc-SD32G_0x0000011c-part1 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 May 18 08:24 mmc-SD32G_0x0000011c-part2 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 9 May 18 08:24 wwn-0x5000c500e027f679 -> ../../sdb
lrwxrwxrwx 1 root root 10 May 18 08:24 wwn-0x5000c500e027f679-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 9 May 18 08:24 wwn-0x5000c500e0283066 -> ../../sda
lrwxrwxrwx 1 root root 10 May 18 08:24 wwn-0x5000c500e0283066-part1 -> ../../sda1
Do not create folders under /mnt, create your folder someplace else.