I remember changing this setting and sticking it in my GO file. I easily achieved 50MB/sec write speeds on the array. I have been away from the forum for a little bit, but this was popular when the Marvell Chipsets couldn't do parity checks, blah, blah. Anyway, maybe I should have left it at version 6.1.3. My write speeds now max out at 25MB/sec. I have not made any changes, except upgrading the unraid version itself and a few of the plugins I have. I see lots of new disk settings, but have left that all default. I currently use two Dell cards flashed in IT mode. Before I start running speed scripts, reviewing logs for a couple of hours has anything changed that would deteriorate write speeds? All drives come back good, reboot has been done. I wouldn't care if it was just a couple MB, but cutting the speed in half is a big deal.

 

Also, Happy Holidays!

 

 

Try updating to 6.1.6 before you do any speed tests. Somewhere in there, 6.1.x was a major change in the methodology for writes. I don't think it was in 6.1.3, but later versions.

 

There is a new setting that controls write queues depths. Read the announcement threads for details.

 

Try updating to 6.1.6 before you do any speed tests. Somewhere in there, 6.1.x was a major change in the methodology for writes. I don't think it was in 6.1.3, but later versions.

 

There is a new setting that controls write queues depths. Read the announcement threads for details.

 

I am at version 6.1.6. I was really liking the 50MB/sec write on a constant basis. I'll check things out a little more closer tonight.

 

http://lime-technology.com/forum/index.php?topic=44066.msg420657#msg420657

 

unRAID Server OS Change Log

Version 6.1.4 2015-11-15

 

unraid: introduce md_sync_thresh default set to md_sync_window/2 to improve parity sync/check

 

~~~~~~~

 

There is a tunable called 'md_sync_thresh' which you can set with a command such as:

 

mdcmd set md_sync_thresh <N>

 

The value <N> is a count of 'stripes' from 0..md_sync_window. 

 

The way it works is: when a parity sync/check starts, it queues up 'md_sync_window' number of 'stripes'.  Thus the maximum number of in-progress 'stripes' is md_sync_window.  As these 'stripes' complete the number in-progress obviously starts decreasing.  When it reaches 'md_sync_thresh' a thread awakens, queuing up more 'stripes' until md_sync_window number of 'stripes' are again in-progress. 

 

The default value for 'md_sync_thresh' is md_sync_window/2. 

 

In pre-6.1.4 it behaved as if md_sync_thresh was equal to md_sync_window-1 (that is immediately queued new 'stripe' each time in-progress 'stripe' completed).

 

In upcoming 6.2 this setting is configurable on Disk Settings page.

 

Emphasis added is mine.

 

So on 6.1.3 the value of md_sync_thresh was (md_sync_window - 1). On 6.1.4 and later, the default value of md_sync_thresh is (md_sync_window / 2). This might be why you're seeing slightly slower speeds.

 

Read through the rest of that thread to get an idea for some benchmarks done by other users with other controllers.

Thanks. Just as I get back to unraid I have a drive starting to fail on me. So any read/write tests are useless until I get it replaced. Arghhhh!