Sure, can run the test again, here’s the output. Tested a bit more in both receiving and transmitting direction to limited it further down, and gladly there was a difference I wasn’t aware of before. Maybe that helps to find the root cause in my setup…
iperf for reference - using a dedicated 5GHz for testing
osmc@vero: iperf3 -c diskstation
Connecting to host diskstation, port 5201
[ 4] local 192.168.100.50 port 41357 connected to 192.168.100.30 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 21.9 MBytes 183 Mbits/sec 0 438 KBytes
[ 4] 1.00-2.00 sec 25.2 MBytes 212 Mbits/sec 0 477 KBytes
[ 4] 2.00-3.00 sec 24.7 MBytes 207 Mbits/sec 0 498 KBytes
[ 4] 3.00-4.00 sec 25.5 MBytes 214 Mbits/sec 0 498 KBytes
[ 4] 4.00-5.00 sec 24.9 MBytes 208 Mbits/sec 0 498 KBytes
[ 4] 5.00-6.00 sec 25.4 MBytes 213 Mbits/sec 0 498 KBytes
[ 4] 6.00-7.00 sec 25.3 MBytes 212 Mbits/sec 0 498 KBytes
[ 4] 7.00-8.00 sec 25.3 MBytes 212 Mbits/sec 0 498 KBytes
[ 4] 8.00-9.00 sec 25.2 MBytes 211 Mbits/sec 0 498 KBytes
[ 4] 9.00-10.00 sec 25.4 MBytes 212 Mbits/sec 0 498 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 249 MBytes 209 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 247 MBytes 207 Mbits/sec receiver
iperf Done.
So the Vero can send out data nicely and saturate the connection almost. The connection itself is a bit higher if I look from the AP’s point of view. But doesn’t matter.
osmc@Vero:~$ iperf3 -c diskstation -R
Connecting to host diskstation, port 5201
Reverse mode, remote host diskstation is sending
[ 4] local 192.168.100.50 port 44230 connected to 192.168.100.30 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 12.2 MBytes 103 Mbits/sec
[ 4] 1.00-2.00 sec 16.3 MBytes 137 Mbits/sec
[ 4] 2.00-3.00 sec 12.3 MBytes 103 Mbits/sec
[ 4] 3.00-4.00 sec 13.0 MBytes 109 Mbits/sec
[ 4] 4.00-5.00 sec 12.1 MBytes 101 Mbits/sec
[ 4] 5.00-6.00 sec 12.3 MBytes 103 Mbits/sec
[ 4] 6.00-7.00 sec 13.1 MBytes 110 Mbits/sec
[ 4] 7.00-8.00 sec 13.6 MBytes 114 Mbits/sec
[ 4] 8.00-9.00 sec 14.0 MBytes 118 Mbits/sec
[ 4] 9.00-10.00 sec 12.2 MBytes 102 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 132 MBytes 110 Mbits/sec 169 sender
[ 4] 0.00-10.00 sec 131 MBytes 110 Mbits/sec receiver
iperf Done.
If going reverse you see the first problem, that the Vero4K seems only to receive half the data rate it can send out. So more or less topping out at 100MBit/s. Still I could live with that performance, which brings WLAN on par with wired.
Note the Pi tops out around 165ish Mbit/sec over WLAN, so a tad slower, but about the same in both directions. Well technically it is not a Pi, it’s another SOB that runs an ARM Debian. Tests on Ubuntu on a Notebook show also no Problems at all and are in line with what’s happening on the SOB.
CIFS on the Pi
twenty@pi: dd if=/dev/zero of=/mnt/test_smb/zzz.tmp bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 54.5467 s, 15.4 MB/s
twenty@pi: dd if=/mnt/test_smb/zzz.tmp of=/dev/null bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 52.1232 s, 16.1 MB/s
About what to expect, nothing special to see here. Reading a tad faster than writing.
NFS on the Pi
twenty@pi: dd if=/dev/zero of=/mnt/test_nfs/zzz.tmp bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 79.7751 s, 10.5 MB/s
Yes, writing NFS is significantly slower from the Pi. Never cared. Was not a network glitch. Probably something else I have running there. So let’s ignore this anomaly for now as it is specific to that installation.
twenty@pi: dd if=/mnt/test_nfs/zzz.tmp of=/dev/null bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 50.3636 s, 16.7 MB/s
As expect slightly faster than SMB. But absolutely negligible difference.
CIFS on the Vero4K
osmc@vero: dd if=/dev/zero of=/mnt/test_smb/zzz.tmp bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 36.3009 s, 23.1 MB/s
Yes, writing to a CIFS mount is absolutely no problem!
osmc@vero: dd if=/mnt/test_smb/zzz.tmp of=/dev/null bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 143.909 s, 5.8 MB/s
Meh, this sucks! Huge Problem. That is way too slow for no reason. Even with the diminished capabilities of receiving data compared to sending out (as iperf3 reports) this should not drop so significantly. It should be about double. It’s like it’s getting cut in half of what one expects given tests on other systems and the iperf3 results.
NFS on the Vero4K
osmc@vero: dd if=/dev/zero of=/mnt/test_nfs/zzz.tmp bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 32.4093 s, 25.9 MB/s
As expect slightly faster than SMB. But absolutely negligible, in the 10-15% range. That’s fine, no one should care about that.
osmc@vero: if=/mnt/test_nfs/zzz.tmp of=/dev/null bs=8M count=100
100+0 records in
100+0 records out
838860800 bytes (839 MB, 800 MiB) copied, 67.865 s, 12.4 MB/s
As pointed out, it seems the Vero4K cannot receive data faster here, so it tops out in accordance what iperf3 reported.
Other Notes
The Synology got its regular security updates. Also not RAID related, the test was done with a single disk to rule out any IOPS releated stuff as well. To rule the NAS out I also tested with CIFS shares from a Windows Server. . Same deal. I also thought maybe it is related to wireless on the Vero4K and plugged in a cable. Same deal, reading over the network tanks with SMB shares (no using SMB2 or so makes it even worse, dropping to 2MBit/s compared to SMB3). Though of course with the Vero4K the wired speed is slower as compared to wireless as it is only a 100Mbit/s port. But I am perfectly fine just thinking in 100MBit/s max here. Still SMB should reach 10Mbit/s easily, as it did in the past. So what changed? I could playback 1080p flawless for over a year, now it is nearly impossible. And no, no jumbo frames or anything here in the network. Plain old MTU of 1500. No firewalling or anything in place on the NAS, Switch or AP. As you see no issues from the Pi.
What Now?
Does this help? Any suggestions or ideas? Can you confirm the Vero4K cannot receive data faster than 100MBit/s but sends out faster over WLAN? If not, then we might have found the first thing that needs investigation.
I could understand that the hardware of the Vero4K is limited here and it maybe just can’t receive faster than 100MBit/s (never checked before as there were no problems). Still that should not give me half the performance with CIFS, It should be close to what the Pi does here. And this has recently started that it dropped so drastically that I barely can play 1080p files anymore.
So any ideas where to look? Can you reproduce this in some way? It’s just for receiving data compared to sending out, and SMB tanks way too much - which it didn’t do before.
Could be that the read ahead from Kernel mounts causes this? I have not tried with non Kernel mounts yet, given I had no serious problems before.
