I ran Freenas for well over a year with minimal issues but was always looking to migrate to Unraid. My speeds spontaneously combusted so i decided to take this opportunity to jump ship to Unraid. Much to my chagrin, this did not fix the slow file transfer issues. No matter what I do, no matter how hard i try, I cannot seem to break ~35MB/s.

 

Transferred some files though my laptop (wifi) and pretty much same 30-35MB/s speeds. I have verified that my server is running at full 1000Mbps gigabit and so is my PC. Was initially on a pentium g3258 system w/ 12GB's of RAM but switched to an i5 6400 w/ a mere 4GB's of RAM (I plan to upgrade this in the future; don't hurt me). The disks speeds are fine its just through network that is giving me issues. Data is being written to the SSD cache drive upon arrival and is being read, usually, from my local SSD. Would really appreciate any help (don't want to go back to Freenas (although i don't think that'll change anything)).

nasferatu-diagnostics-20190830-1601.zip

iperf show it should be network issue in first sight and you use WiFi.

 

What have change for last pic. show 109MB/s which ref. 1st pic show 32.8MB/s, you haven't mention this.

Edited August 30, 20196 yr by Benson

Just now, Benson said:

iperf show it should be network issue in first sight and you use WiFi.

 

What have change for last pic. show 109MB/s which ref. 1st pic show 32.8MB/s, you haven't mention this.

Looking back I really didn't make this clear - sorry. The 109MB/s is a screenshot from quite a while back while running Freenas. It's the same hardware so it's just there to show it did work; not a NIC issue or anything. 

I was testing all day today and yesterday from my main PC (gigabit ethernet connection) and was using the laptop on wifi to make sure it wasn't an issue on my PC's end.

OK, does iperf test with Unraid also reach 1Gbps (gigabit ethernet connection)?

 

I am using handset, so I can't read the diagnostic. But simple ask, does reconstruct write is enable ?

Edited August 30, 20196 yr by Benson

Just now, Benson said:

OK, does iperf test with Unraid also reach 1Gbps ?

 

I am using handset, so I can't read the diagnostic. But simple ask, does reconstruct write is enable ?

I'm not entirely sure what you mean in regards to the first sentence - the iperf screenshot is from unraid - all the screenshots are from unraid (today) other than the 109MB/s transfer. 

I've tried both reconstruct write and auto to no avail.

1 minute ago, Tom21 said:

I'm not entirely sure what you mean in regards to the first sentence - the iperf screenshot is from unraid - all the screenshots are from unraid (today) other than the 109MB/s transfer. 

I've tried both reconstruct write and auto to no avail.

Youe screen capture show iperf just 200Mbps  ~26MB/s.

Just now, Benson said:

Youe screen capture show iperf just 200Mbps  ~26MB/s.

never hit more than ~240Mbps on an iperf test on the current unraid setup.

2 minutes ago, Tom21 said:

never hit more than ~240Mbps on an iperf test on the current unraid setup.

So that's why I say it is network issue rather then storage issue, if both end in ethernet not WiFi.

Edited August 30, 20196 yr by Benson

Just now, Benson said:

So that's why I say it is network issue rather then storage issue, if both end in ethernet not WiFi.

so the question is: how do we fix it?

May be i need check the diagnostic fist to answer.

ok so we have a development; seems to be dropped packets and high ping.

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.19  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::d217:c2ff:fe99:4a11  prefixlen 64  scopeid 0x20<link>
        ether d0:17:c2:99:4a:11  txqueuelen 1000  (Ethernet)
        RX packets 18326097  bytes 26673856993 (24.8 GiB)
        RX errors 0  dropped 1521  overruns 0  frame 0
        TX packets 8991972  bytes 6856561513 (6.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=103 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=61.3 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=3.06 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=4.52 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=5.01 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=3.44 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=4.41 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=3.49 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=2.96 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=5.99 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=2.91 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=2.97 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=3.00 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=2.96 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=2.95 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=3.01 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=3.90 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=4.97 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=2.92 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=3.02 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=64 time=2.94 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=64 time=3.74 ms
64 bytes from 192.168.0.1: icmp_seq=23 ttl=64 time=3.36 ms
64 bytes from 192.168.0.1: icmp_seq=24 ttl=64 time=3.04 ms
64 bytes from 192.168.0.1: icmp_seq=25 ttl=64 time=5.56 ms
^C
--- 192.168.0.1 ping statistics ---
25 packets transmitted, 25 received, 0% packet loss, time 24032ms
rtt min/avg/max/mdev = 2.908/9.926/102.729/22.068 ms

 

Edited August 30, 20196 yr by Tom21

The drop frame seems not the cause, because it just 1521.

 

Does both end in same network segment ? Also 192.168.0.X

Edited August 30, 20196 yr by Benson

Just now, Benson said:

The drop frame seems not the cause, because it just 1521.

 

Does both end in same network segment ? Pls provide both end IP and subnet mask.

alright so the server and my PC are running off of powerline adapters (two different ones). I relocated the server earlier with a direct cat6 connection to the router - this did not help.

Everything on my network is some variation of 192.168.0.0 - so 192.168.0.58(my PC), 192.168.0.19(server) etc
both subnet masks are 255.255.255.0

Edited August 30, 20196 yr by Tom21

You mean currently have powerline in between and if running Freenas then got 100MB/s transfer but just Unraid can't ?

 

Pls understand case still be network relate.

Edited August 31, 20196 yr by Benson

Just now, Benson said:

You mean currently have powerline in between and if running freenaas then got 100MB/s transfer but just Unraid can't ?

 

Pls understand case still be network relate.

It was working (100MB/s) on Freenas until it suddenly didn't(30MB/s). Ive since switched to Unraid where it also does not work. The powerline adapters must be irrelevant because ive tested with a direct ethernet cable to the router - still got 30MB/s max.

Even with Powerline 1300, actual max bandwidth will be 550Mbps.

 

I am sure if you direct connect them by ethernet wire, you will got different result.

 

https://en.m.wikipedia.org/wiki/HomePlug

Edited August 31, 20196 yr by Benson

Just now, Benson said:

Even with Powerline 1300, actual max bandwidth will be 550Mbps.

 

I am sure if you direct connect them by ethernet wire, you will got different result.

 

https://en.m.wikipedia.org/wiki/HomePlug

but then how did i get 109MB/s through powerline? 550Mbps is also 250 above what im currently getting so even with overhead, im not hitting that supposed limit.

@Tom21

I see that you are using a realtek 8xxx chipset based network card.

These devices, and their open source r8189 driver do not perform well, I'm not sure - but I believe @limetech was shipping the closed source r8168 driver at one point - perhaps they can comment as to whether or not this is the case. 

TL;DR:
The 8168 driver performs as expected, on par with Windows.
The 8169 driver performs at anywhere between 20 and 50% of the performance of the 8168 driver and Windows.

 

Edited August 31, 20196 yr by Xaero

Just now, Xaero said:

@Tom21

I see that you are using a realtek 8xxx chipset based network card.

These devices, and their open source r8189 driver do not perform well, I'm not sure - but I believe @limetech was shipping the closed source r8168 driver at one point - perhaps they can comment as to whether or not this is the case. 

TL;DR:
The 8168 driver performs as expected, on par with Windows.
The 8169 driver performs at anywhere between 20 and 50% of the performance of the 8168 driver and Windows.

 

thank you for commenting(?). I will look into this. One thing i can say is that I did try another board which upon looking is also a realtek 8xxx chipset - rip.

I actually did a little bit of searching, in the Unraid 5.xx days, Limetech was shipping with the r8168 driver included, but they had to "pick" a default driver to configure. Since one driver or the other will work better depending on which exact realtek chip you have, eventually they decided to ship only the Linux kernel team's r8189 driver. 

Also in your diagnostics zip, lsmod shows that the current driver in use is r8189 - which suggests this is the case. If you have an intel nic laying around, it may be worth a shot to see if it resolves the speed issues. I would like to see both drivers included - but that requires manual intervention of the user if they have one of these (very common) chips.

You may be able to install the slackware package for this module on unraid; you would then need to blacklist the r8169 module so that the r8168 module could load instead. I'll need to research a bit. My other server, which runs Arch had a similar network speed problem, and it currently uses the r8168 module to resolve that problem. Also know that this would come with the giant "YMMV" and "Not supported by LimeTech" badges of honor.

Edited August 31, 20196 yr by Xaero

Just now, Xaero said:

I actually did a little bit of searching, in the Unraid 5.xx days, Limetech was shipping with the r8168 driver included, but they had to "pick" a default driver to configure. Since one driver or the other will work better depending on which exact realtek chip you have, eventually they decided to ship only the Linux kernel team's r8189 driver. 

Also in your diagnostics zip, lsmod shows that the current driver in use is r8189 - which suggests this is the case. If you have an intel nic laying around, it may be worth a shot to see if it resolves the speed issues. I would like to see both drivers included - but that requires manual intervention of the user if they have one of these (very common) chips.

You may be able to install the slackware package for this module on unraid; you would then need to blacklist the r8169 module so that the r8168 module could load instead. I'll need to research a bit. My other server, which runs Arch had a similar network speed problem, and it currently uses the r8168 module to resolve that problem. Also know that this would come with the giant "YMMV" and "Not supported by LimeTech" badges of honor.

just been running off of this (

) which has presented some issues thus far but its from 2012 so ill have to work around it

@idkhowto@you im going off of this: 

cd /lib/modules/3.9.3-unRAID/kernel/drivers/net/ethernet/realtek
rmmod r8169
mv r8169.ko r8169.ko.bak
cp /boot/r8168.ko .
depmod -a
insmod r8168.ko

(with edited path) but r8169.ko and r8168.ko.bak do not exist - there is only r8169.ko.xz

i have obtained a pre-compiled copy of r1868.ko but im reckoning im going to have to compile it myself because this copy is from 2012. Honestly idk but you have gifted me with an extremely good lead here.

Edited August 31, 20196 yr by Tom21

You will likely have to build the module from scratch. However you may be able to steal the r8168.ko.xz from this package:
https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/r8168-lts-8.047.02-3-x86_64.pkg.tar.xz.html
As it was compiled for Linux 4.19.x and that is the current kernel for Unraid. I would highly recommend against this, as you cannot guarantee stability with mismatch kernel version modules. But it would be okay for testing to see if it is the cause of the problem before proceeding to build a custom module for unraid.

Edited August 31, 20196 yr by Xaero

Just now, Xaero said:

You will likely have to build the module from scratch. However you may be able to steal the r8168.ko.xz from this package:
https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/r8168-lts-8.047.02-3-x86_64.pkg.tar.xz.html
As it was compiled for Linux 4.19.x and that is the current kernel for Unraid. I would highly recommend against this, as you cannot guarantee stability with mismatch kernel version modules. But it would be okay for testing to see if it is the cause of the problem before proceeding to build a custom module for unraid.

i dont know if im being really stupid now; when i cd into /lib/modules/4.x.x.x.x.x-unRAID/kernel/drivers/net/ethernet/realtek and perform the 'mv' (with slight variation) or 'cp' commands it says, and i quote, 

cp: cannot create regular file './r8168.ko.xz': Read-only file system

 

 

 

41 minutes ago, Tom21 said:

i dont know if im being really stupid now; when i cd into /lib/modules/4.x.x.x.x.x-unRAID/kernel/drivers/net/ethernet/realtek and perform the 'mv' (with slight variation) or 'cp' commands it says, and i quote, 

cp: cannot create regular file './r8168.ko.xz': Read-only file system

 

 

 

From /etc/fstab:
/boot/bzmodules            /lib/modules  squashfs  ro,defaults  0  2

The /lib/modules directory is actually a mounted squashfs filesystem, you'd (in the end) need to rebuild that squashfs image with the new file.

You may be able to get away with just using:
insmod /path/to/r8168.ko.xz

insmod accepts paths, but does no dependency resolution.
modprobe looks inside /lib/modules/... for the module, and automatically probes any needed modules.
rmmod r8169 && insmod/path/to/r8168.ko.xz
May work.

If not you can get really convoluted for testing:

mkdir /tmp/testing

mkdir /tmp/testing/work

mkdir /tmp/testing/upper

mount -t overlay overlay -o lowerdir=/lib/modules,upperdir=/tmp/testing/upper,workdir=/tmp/testing/work /lib/modules

You can then copy that module into the directory, and Linux should be none the wiser of it's actual location.

Also know that doing this wouldn't immediately result in modprobe knowing how to use the new module, you'd also need to run depmod -a to generate the module dependencies. At that point modprobe would almost certainly work. I know, it's a giant pain to troubleshoot this way. Normally it would be as simple as "yaourt -S r8168-dkms" or something similar and moving on with life.

This sort of thing is the reason I wish unraid would embrace package management; but I understand their reasons for not doing so.

Edited August 31, 20196 yr by Xaero