NFS export it set to async. I also tried Samba protocol and got same speeds.
I have compression: off & Extra Mount Options: noatime set.
EDIT: Added the following:
The USB itās installed on is not a 3.0 USB and the install took HOURS. Could it possibly be related to something with a BIOS setting or USB legacy issue? From what I read the USB should be 99% read only for the OS and shouldnāt impact share write/read performance, but I could be wrong?
Memory Usage (8GB total) is also - Used: 9%, Cached: 69%, Free: 22% ā It was Free: 0% as Cached was taking of all that used wasnāt.
it will create a file of 4GB consisting of zeros on the share, the command blocks till its completed, so dont worry if nothing happens. after it completed the overall speed is displayed. note that this only works if compression is disabled, but this should not be a problem for you if your share is mounted with compression off, too.
this is to check if its something with the networking or the share itself as the command writes directly to the share/disks.
Indeed, so while it happens in smb too, i assume its nothing related to those daemons. Can you try client with some different Server? (Or assume its not the client when it worked before with another Server)
Its unlikely but maybe something with the network cards drivers? Did you have another system up and running without the Problem with the same Hardware?
Thinking it may be related to my NICās. My mobo is a AM1B-M which has a Realtek RTL8111GR onBoard NIC and I have a PCI card as well - an Airlink AG32PCI which has either a RTL8110 or RTL8169, cant confirm exactlyā¦
I did a fresh install last night on a new USB 3.0 stick on a USB 3 port, had to turn USB 3.0 support in BIOS from āAutoā to "Enabledā to successfully boot and it took about 30mins whereas the previous install took hoursā¦ Took me forever to get network connectivity to work after the install unlike prev. both NICās obtained IPās. I was able to get one card with an IP but unable to connect via web-ui but I can successfully ping both machines. Looking at ordering an Intel NIC this AM.
Do you know of any problems with the Realtek RTL811* Series NICās & CentOS? Iām an Ubuntu user mainly and not used to this yum stuff lol
So I reinstalled last night (I think my previous install didnāt install properly, might have had some issues with method used to write the ISO to the USB) network issues have all been resolved, still having same issue with write speed however.
Tried to install epel-release & iperf but Iām getting a URL cant be resolved, trying another mirror error, looks like I might get success when I cancel with CTRL+C but it ends up failing. Looked into adding another repository but I honestly have no idea what Iām doing in CentOS, itās so much different than Debian.
BTW- I GREATLY appreciate all your assistance and guidance @felixbrucker , Iām dead set on getting this to work and documenting everything I try. Iāve decided that Iāll be moving to Rockstor for my primary homelab NAS solution, Itās everything Iām looking for with btrfs I just need to figure out what Iām doing wrong to fix this 15MB/s write speed issue lol.
Everything is connected via GB LAN, the origin content drive is a 3TB Seagate 72k drive and has no issues writing to a local SSD. I do have the Rockstor box connected via a Airlink 5-Port 10/100/1000Mbps Green Switch temporarily as I rebuild my homelab. My laptop Win10 doesnāt seem to have the option in windows features to turn on NFS and havenāt tried any other machine but I didnāt have any issues writing at around 90MB/s when I was using DriveBender.
@ScottyEdmonds Hello. The epel-release package is just a CentOS package that adds an additional rpm/yum repository (the epel one); required in this case as iperf is not included in the default CentOS repositories.
You can configure repos using the files in /etc/yum.repos.d . So in Ubuntu terms its like a really common ppa that can be added by a build in package.
I would say you may have network issues if the rather excellent instructions from @felixbrucker for installing iperf are returning āURL cant be resolvedā ie it canāt find / resolve the network name it has on record for epel or whatever else it needs.
Hope that helps.
Also I have often seen asynchronous speeds on network cards, ie sometimes they work great in one direction and less well in the other.
as @phillxnet pointed out your network configuration seems a bit off, is your dhcp/static config working?
check if your dns and internet routing is working by pinging google.com which first resolves google.com to an ip and then pings it, with your current configuration this should fail at some point, try to get to ping google (or any other reliable internet host by hostname) and then retry the yum lines.
the most likely problem is the dns here (you can check by pinging some address instead, like 8.8.8.8), check if you specified one when using static ip addresses.
@phillxnet async speeds for network cards, strange, havent seen such a thing till now, but you know, nothing is impossible
seems normal to me, you were definitely able to push gbit speed with the same client before with some different server os?
if so it seems like the nic driver in centos has a bug somewhere which prevents it from getting gbit speeds
you can try to install some ubuntu server on some usb stick and try to reproduce the iperf test from there, but regarding nic driver issues and how to fix them my knowledge is limited
So I decided to go back and try an earlier version as I usually have success with that. And of course, getting full expected write speeds. Now letās just see if an upgrade ruins my success.
@felixbrucker yes the upgrade to the 4.02 kernel killed it. Installed 3.8-0 and success until it asked me to upgrade the kernel.
EDIT: After some testing, I upgraded to latest version from 3.8-0 and rebooted and all seems to be working as it should!!! CELEBRATION TIME
EDIT: Actually no, Iām getting this which will cause the issue - You are running an unsupported kernel(4.0.2-1.el7.elrepo.x86_64). Some features may not work properly. Please reboot and the system will automatically boot using the supported kernel(4.1.0-1.el7.elrepo.x86_64) - 4.1.0-1 will kill my NICās download.
Sorry for joining the party late, but is there a simple script/list of steps that demonstrates the performance difference between 4.0.2 and 4.1.0 kernels? I am planning to make 4.2 default soon and would like to run the test on the kernel.
@ScottyEdmonds, btw, you can ignore the unsupported kernel warning as there is not much difference between 4.0.2 and 4.1, but I do hope you can use the 4.2 kernel coming soon.