So,

 

I have done quite a bit of digging around and have been unable to find a solution that actually works for me. Base of the problem is that while on a gigabit ethernet connection, I am only able to obtain speeds of around 14-20 MB/s when it is my understanding that one Gbit is equal to around 125 MByte. I am only receiving about 10% of that and I feel as though there is definitely something that I should be able to remedy.

 

First here is my unraid setup: http://puu.sh/nqyZM/ed82356ddb.png

Snapshots:

Here is a snapshot of a progress window that I took of a total transfer size of 910GB: http://puu.sh/nqmE5/cb7cfc5965.png

Here is a snapshot of what I believe to be the cache being eaten up before going back to its "normal speed":

To the NAS -> http://puu.sh/nqzlc/259ba1e7bf.png

From the NAS -> http://puu.sh/nqBx7/45db120a14.png

 

While these transfer came from a windows computer, I can reproduce all of these results from another computer that I will be posting the configs and logs to.

 

Using `iperf` over 2 computers on the network i can get these results: http://puu.sh/nqzVp/e2d38339a5.txt

All of the computers on the network are passing through the same devices. I have a 32 port switch that is connected directly to the router - then every computer on the network is connected to that switch.

This means I know that the network is at least capable of doing well above the shown speeds.

 

 

Information from the NAS:

System Log: http://puu.sh/nqznD/322daed4f0.txt

System Devices: http://puu.sh/nqzqB/45b462d654.txt

System Diagnostics: <See Attached>

`ethtool eth0` -> http://puu.sh/nqAee/1f2b84bc31.txt

`dd if=/dev/zero of=/mnt/disk1/test.dd count=8192000` -> http://puu.sh/nqAJ3/7dde8ef90f.txt

`dd of=/dev/zero if=/mnt/disk1/test.dd` -> http://puu.sh/nqALf/2f05b0b199.txt

`hdparm -tT /dev/mt_` -> http://puu.sh/nqB5v/467d61d46a.txt

 

Information from another linux computer:

`ethtool eth1` -> http://puu.sh/nqAq6/3565e051af.txt

`hdparm -tT /dev/sda/` -> http://puu.sh/nqBn3/41c04eaaa8.txt

 

Notes:

- Half way through writing this i noticed the MTU on the NAS was only 1500 so i moved that up to 9000 and same results.

 

I have spent quite a bit of time trying to debug this and am ready to ask for some assistance. I am aware that some of the hardware for the nas is not the best, but I still believe that I should be getting above 10MB/s. Especially with those fluctuations. I am open to suggestions for hardware upgrades.

 

Thanks!

-Cody

charmander-diagnostics-20160229-2105.zip

Hi, lets see if we can help you! You should certainly be experiencing better speeds than that. Not much time to scan your config BUT Ill give it a shot for 5 mins or so. Here we go:

 

For one I would look @ disk: ST3750640NS_5QD1XYNP (pdf)

 

The reallocated Sector count for this drive is "4".

 

5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       4

 

The Seek Error Rate for the Drive is Poor too IMHO (But others will probably disagree with me on this one):

 

7 Seek_Error_Rate         0x000f   070   060   030    Pre-fail  Always       -       150685101742

 

I don't "think" this is causing your speed issues (because I assume you are writing to the share that has Cache enabled and as such is not writing directly to the array but the SSD's first) BUT either way the general advice I would give for this device AFAIAC is "Replace ASAP" whatever you do with respect to the speed issue.

 

Back to the speed issue though, I can't tell for certain but I would ask you to make sure you're writing to a the share with Cache enabled and NOT a disk share. If You're writing to a disk Share you're writing straight to the Parity protected array and would expect the speeds to be slow.

 

Your other Mechanical Disks look fine. I am not really great at reading SSD SMART reports yet BUT AFAIK they are fine too.

 

Your network config looks ok to me. Perhaps someone else can pick something up that I have missed.

Have you installed the most recent drivers from the internet for your network card?  I too used to use the standard drivers that came with Windows and, while everything worked, I also experience slow speeds using unraid.  Then I installed the newest intel NIC drivers (my network card is an Intel chipset), and speed immediately trippled.  Worth looking into IMO.

Here is a snapshot of a progress window that I took of a total transfer size of 910GB:

 

This one looks strange, are you writing to the array or cache pool?

 

 

Here is a snapshot of what I believe to be the cache being eaten up before going back to its "normal speed":

To the NAS ->

 

This one looks normal if you’re writing to the protected array.

 

Do you see a difference when writing to the cache pool or directly to a disk on the array?

Here is a snapshot of a progress window that I took of a total transfer size of 910GB:

 

This one looks strange, are you writing to the array or cache pool?

 

 

Here is a snapshot of what I believe to be the cache being eaten up before going back to its "normal speed":

To the NAS ->

 

This one looks normal if you’re writing to the protected array.

 

Do you see a difference when writing to the cache pool or directly to a disk on the array?

 

I think you have a bit of a consensus here pyro.699 => what we are asking here is are you SURE you're NOT writing straight to the Protected Array. If you ARE then the speeds you're experiencing are close to normal.

Thanks for the reply guys - This particular Array does not use the cache disk - Though I can enable it and try running tests again.

 

Share Image -> http://puu.sh/nr2HW/6135f5c846.png

 

EDIT - Even after enabling the cache disk on this share, i get similar speeds. http://puu.sh/nr2S2/c6f674acfa.png

Without a cache disk and with parity protection in place I would expect read speeds of the order of 100MB/sec and write speeds around 30-40MB per second.  With a cache disk added and shares enabled to use it then read speeds should be unaffected but write speeds are likely to be closer to 100MB/sec.

 

It seems that you are getting significantly less and it is not clear why.

Without a cache disk and with parity protection in place I would expect read speeds of the order of 100MB/sec and write speeds around 30-40MB per second.  With a cache disk added and shares enabled to use it then read speeds should be unaffected but write speeds are likely to be closer to 100MB/sec.

 

It seems that you are getting significantly less and it is not clear why.

Correct - and for my own knowledge, the 30-40MB/s is limited because I am not using SSDs right?

Without a cache disk and with parity protection in place I would expect read speeds of the order of 100MB/sec and write speeds around 30-40MB per second.  With a cache disk added and shares enabled to use it then read speeds should be unaffected but write speeds are likely to be closer to 100MB/sec.

 

It seems that you are getting significantly less and it is not clear why.

Correct - and for my own knowledge, the 30-40MB/s is limited because I am not using SSDs right?

 

No, because you're writing to a Parity protected disk. The fastest it will go.

 

If you had a cache that was mechanical you would get faster write speeds, not as fast as SSD in your cache but still faster than writing straight to a Parity protected disk.

No, because you're writing to a Parity protected disk. The fastest it will go.

 

If you had a cache that was mechanical you would get faster write speeds, not as fast as SSD in your cache but still faster than writing straight to a Parity protected disk.

 

Thank-you for the clarification.

 

Are there any other suggestions? I am not attached to my storage, I am fine with formatting/clearing/setting things up in a different way to test things out. Open to any suggestions - 10MB/s write speeds are not something I am a fan of.

No, because you're writing to a Parity protected disk. The fastest it will go.

 

If you had a cache that was mechanical you would get faster write speeds, not as fast as SSD in your cache but still faster than writing straight to a Parity protected disk.

 

Thank-you for the clarification.

 

Are there any other suggestions? I am not attached to my storage, I am fine with formatting/clearing/setting things up in a different way to test things out. Open to any suggestions - 10MB/s write speeds are not something I am a fan of.

A number of times figures around 10MB/s have turned out to be networking related issues where only 100Mbps LAN speed is being achieved.  It is well worth trying out some alternative LAN cables as you only need one pair in the cable to be bad and the connection will silently downgrade from 1Gbps to 100Mbps.  Since it is still apparently working many do not realise that it might be running in a degraded mode.

No, because you're writing to a Parity protected disk. The fastest it will go.

 

If you had a cache that was mechanical you would get faster write speeds, not as fast as SSD in your cache but still faster than writing straight to a Parity protected disk.

 

Thank-you for the clarification.

 

Are there any other suggestions? I am not attached to my storage, I am fine with formatting/clearing/setting things up in a different way to test things out. Open to any suggestions - 10MB/s write speeds are not something I am a fan of.

A number of times figures around 10MB/s have turned out to be networking related issues where only 100Mbps LAN speed is being achieved.  It is well worth trying out some alternative LAN cables as you only need one pair in the cable to be bad and the connection will silently downgrade from 1Gbps to 100Mbps.  Since it is still apparently working many do not realise that it might be running in a degraded mode.

 

I am able to get 980MBit/s when not writing to the disks. http://puu.sh/nqzVp/e2d38339a5.txt

The cables are new, cat6 cables - they are in wall and unbent. I have also recently replaced them

- Half way through writing this i noticed the MTU on the NAS was only 1500 so i moved that up to 9000 and same results.

An MTU of 1500 is the default for some very good reasons.

 

I abandoned Jumbo frames some time ago because using them in usually more trouble than it's worth. The problem is that they are not backwards compatible and you can't mix MTUs on the same physical segment. Setting the MTU of everything to 1500 is much safer and it still works if some host fails to negotiate a gigabit link and falls back to 100 Mb/s.

`hdparm -tT /dev/mt_` -> http://puu.sh/nqB5v/467d61d46a.txt

 

/dev/md1:

Timing cached reads:  7104 MB in  2.00 seconds = 3554.68 MB/sec

Timing buffered disk reads: 258 MB in  3.02 seconds =  85.35 MB/sec

 

/dev/md2:

Timing cached reads:  7266 MB in  2.00 seconds = 3635.87 MB/sec

Timing buffered disk reads: 170 MB in  3.02 seconds =  56.26 MB/sec

 

/dev/md3:

Timing cached reads:  7210 MB in  2.00 seconds = 3608.04 MB/sec

Timing buffered disk reads: 238 MB in  3.02 seconds =  78.81 MB/sec

 

 

You have somewhat older disks and these tests explain the less than optimal read speeds, still doesn’t explain 10MB/s write speeds.

 

You can try and copy the same big file (at least 8GB) from your desktop directly to each disk share (\\tower\diskx) , report back your results.

 

 

 

 

You have somewhat older disks and these tests explain the less than optimal read speeds, still doesn’t explain 10MB/s write speeds.

 

You can try and copy the same big file (at least 8GB) from your desktop directly to each disk share (\\tower\diskx) , report back your results.

 

I am at work right now, so all i can do is SSH in. But they all seemed to follow this pattern:

Peaked to 85 until 18%
$ scp jupiter-ascending.mkv [email protected]:/mnt/disk1/
jupiter-ascending.mkv   			100% 8945MB  35.9MB/s   04:09

Peaked to 90 until 20%
$ scp jupiter-ascending.mkv [email protected]:/mnt/disk2/
jupiter-ascending.mkv   			100% 8945MB  27.0MB/s   05:31

Peaked to 88 until 21%
$ scp jupiter-ascending.mkv [email protected]:/mnt/disk3/
jupiter-ascending.mkv   			100% 8945MB  34.4MB/s   04:20

 

Those speeds look normal to me when writing to the protected array, you will have close to gigabit speed until RAM cache is filled (default is 20% of free memory), then and with those disks I would expect speeds between 25 and 35MB/s.

 

With more modern disks normal writing speed to the protected array is between 45 and 60MB/s.

 

Those speeds look normal to me when writing to the protected array, you will have close to gigabit speed until RAM cache is filled (default is 20% of free memory), then and with those disks I would expect speeds between 25 and 35MB/s.

 

With more modern disks normal writing speed to the protected array is between 45 and 60MB/s.

What do you mean by more modern disks? I know that 2 of the disks are quite old and I am looking at replacing them, however there are new disks in there. The 2TB drive was purchased here: http://www.newegg.ca/Product/Product.aspx?Item=9SIAA403RK0501

 

What do you mean by more modern disks? I know that 2 of the disks are quite old and I am looking at replacing them, however there are new disks in there. The 2TB drive was purchased here: http://www.newegg.ca/Product/Product.aspx?Item=9SIAA403RK0501

 

That’s your parity disk, when writing to the array it will write at the same time your parity disk and the actual disk you’re writing to, speed will be limited by the slower of the two, in this case your array disks.

Let me add that there’s also turbo write, a considerably faster writing mode if you don’t mind all disks spining up for writes, using it you should get between 50 and 70MB/s.

 

See here, there’s also a good explanation of how normal write works and why it’s slower.

 

Check the dashboard or the info button and tell us how is the ethernet connection speed reported.

I have a switch that sometimes doesn't negotiate for the GBit speed --> 10MB/s.

After resetting, it will go full speed --> ~100MB/s direct copy to the cache drive.

 

You also might want to try diskspeed to get an idea how your drives perform.

http://lime-technology.com/forum/index.php?topic=31073.0