FYI, my turbo write speeds range from 70MB/s to 110MB/s depending on number of files being written, size of files, and what else the server is doing.  Line speeds (110MB/s+) have only been feasible for me with very large files and an essentially idle server.  Copying a BD Rip definitely qualifies as a very large file, but based on your htop I would say your server appears somewhat busy doing a number of things.  Bottomline - based on my experience I agree with Frank1940's assessment that 80MB/s is within normal operating expectations for turbo write.

 

I still love turbo write, though :).

I've wondered if a faster CPU might alleviate some of these issues, not sure if it's worth it, as i don't think CPU speed affects unRAID too much??

Thanks for the responses all.  Much appreciated.

 

I also just did a test with Plex off and the results are basically the same.  I didn't get the long periods with 0k but it dipped down to 12MB for periods here and there.  I would be completely fine with an 80MB/s standard.  It seems reasonable considering the setup.  12MB and lower are not normal.  I have been using Unraid for a very long time and this isn't typical from my experience.

 

I will try a few of the other suggestions to see if that affects things.

You also have to remember that the ultimate limit is the slowest piece of hardware in the chain.  That is often one of the hard disks involved.  Most folks tend to think that the network speed (Gb for instance) is that but is can be be any number of other pieces of the equation.  With my sempron 140 hardware, it was the CPU when using dual parity and that was still the case when I move the Test Bed to an Athlon II with dual parity. 

 

There were even some tests run where the array was configured with SSD's.  The point being is that no matter what upgrades you do, there is will always be some item which establishes THE limit.  A lot of folks consider the Gb network as being the speed at which the data should be transferred/written to the array BUT there are already folks playing around with 10Gb network cards...

 

Edited April 7, 20179 yr by Frank1940

1 hour ago, sdamaged said:

I've wondered if a faster CPU might alleviate some of these issues, not sure if it's worth it, as i don't think CPU speed affects unRAID too much??

 

Taking a quick look at my System Profiler, I believe that you would be looking for a processor that has the avx2x4 instruction extension in the CPU for any system that you want to use dual parity on.  While you can probably get a high end CPU that would not be limiting factor (simply having the brute horsepower to do the calculation fast enough), you can probably locate a much cheaper processor with the avx2x4 instruction that can do the same job.

28 minutes ago, Frank1940 said:

You also have to remember that the ultimate limit is the slowest piece of hardware in the chain.  That is often one of the hard disks involved.  Most folks tend to think that the network speed (Gb for instance) is that but is can be be any number of other pieces of the equation.  With my sempron 140 hardware, it was the CPU when using dual parity and that was still the case when I move the Test Bed to an Athlon II with dual parity. 

 

There were even some tests run where the array was configured with SSD's.  The point being is that no matter what upgrades you do, there is will always be some item which establishes THE limit.  A lot of folks consider the Gb network as being the speed at which the data should be transferred/written to the array BUT there are already folks playing around with 10Gb network cards...

 

 

I agree with this and point taken.  My main concern is that I have had better performance in the past with the same hardware.  If it's a hardware failure somewhere in the stack I am hoping to find that out. 

 

The dual parity comments are interesting.  I run dual but don't think this is a change brought on by that transition.  I made that jump 6-8 months ago.  I will run a parity check this weekend to see how that responds.  In the past I have gotten speeds of 80-110 pretty consistently.

16 minutes ago, clearzero said:

I agree with this and point taken.  My main concern is that I have had better performance in the past with the same hardware.  If it's a hardware failure somewhere in the stack I am hoping to find that out. 

You should probably take a look at your Smart data.  You can do this by going to the Main tab, clicking on the disk number under the 'Device' column and selecting the Attributes tab.  You can then move from disk-to-disk with the 'arrow' icons on that page.  (The 'Disk # Settings' tab will give you the smart parameters you want to look at.)

My parity check speeds are fairly consistent, it takes a while but it's usually around about the same speed each time

 

Using dual Seagate Archive 8TB drives for parity, no idea if they affect the speed

 

 

Edited April 7, 20179 yr by sdamaged

8 minutes ago, sdamaged said:

My parity check speeds are fairly consistent

 

Not really, unless something changed, especially on the last one, there's over 5 hours difference, I consider consistent when they within 15 minutes of each other.

Well yeah, the one on 5th April was very slow - i've no idea why, unless the Plex docker was hammering the CPU and doing disk / library scans

You can run this to see if there's a disk with slow sectors, although not always visible if it's mild in the standard test as it only scans a very small percentage of the disk's surface:

 

 

Thanks Johnnie

 

This is my result

 

 

Deleted

Edited April 8, 20179 yr by Benson

7 minutes ago, Benson said:

You using dual Seagate Archive 8TB drives, why haven't show in the diagnostics file ?

So,problem should be cause by those SMR drive, disk were internal busy during wrire (even read).

 

The chart shows the ST8s as the fastest, but curve for parity isn't very smooth. Don't know whether it means anything.

10 minutes ago, trurl said:

The chart shows the ST8s as the fastest, but curve for parity isn't very smooth. Don't know whether it means anything.

 

Yes, could be something, could be nothing, you should test your parity only with more sample points, e.g.:

 

diskspeed.sh -s 51 -n sdX

 

Replace X with parity letter.

OK results below

Not very smooth, but no long dips either, so doubt that is the problem.

3 hours ago, trurl said:

The chart shows the ST8s as the fastest, but curve for parity isn't very smooth. Don't know whether it means anything.

Detete post due to SMR disk not OP's own.

 

For SMR disk, I always think it may quite slow during write opertion due to SMR nauture.

Edited April 8, 20179 yr by Benson