for i in /dev/[hs]d? ; do echo deadline > /sys/block/${i:5}/queue/scheduler ; done 2>null
for i in /dev/[hs]d? ; do echo 128 > /sys/block/${i:5}/queue/max_sectors_kb ; done 2>null 

 

This has improved the responsiveness of my server no end.

 

I can't comment on raw throughput and, largely, I don't really care.

 

Even when all the disks are thrashing reading and writing (with parity) I can continue on as normal with other array tasks.

 

Previously anything approaching a slightly intensive bought of writing would cause serious blocking issues for any other access.

 

Nice find.

 

Hallelujah!  We have the first independent testimonial.

 

I am glad it worked for you too.

 

You may want to make it permanent then:

1. Add  "elevator=deadline" (without the quotes) to the append line in your syslinux.cfg

2. Put the second line above in your "go" script.

 

Purko

 

 

"Or, you may try it out without chnging your syslinux.cfg and your go script: Just telnet to your unraid box and issue the following two commands:

 

Code:

for i in /dev/[hs]d? ; do echo deadline > /sys/block/${i:5}/queue/scheduler ; done 2>null

for i in /dev/[hs]d? ; do echo 128 > /sys/block/${i:5}/queue/max_sectors_kb ; done 2>null (If your telnet client allows you to paste stuff from the clipboard, then just copy the lines from here and paste them there to avoid any typing mistakes)

 

So try it out, copy some big number of large files to your unRaid box, and tell us what happens. I'd love to hear your report."

 

I tried these two commands via telnet and lost connection to my unRAID server. I had to reboot my Win 7 computer to regain connection to the unRAID server. Have no idea what happened.

I tried these two commands via telnet and lost connection to my unRAID server. I had to reboot my Win 7 computer to regain connection to the unRAID server. Have no idea what happened.

 

I too have no idea what happened. These two tweaks are really minor, and they have little to no effect on mmost systems. They can not possibly cause anything catastrophic like you losing your connection to the unraid box.

 

What most likely happened is that your windows7 crapped out independently of what you were doing in your telnet session.

 

 

I tried these two commands via telnet and lost connection to my unRAID server. I had to reboot my Win 7 computer to regain connection to the unRAID server. Have no idea what happened.

 

I too have no idea what happened. These two tweaks are really minor, and they have little to no effect on mmost systems. They can not possibly cause anything catastrophic like you losing your connection to the unraid box.

 

What most likely happened is that your windows7 crapped out independently of what you were doing in your telnet session.

 

 

Maybe but I've been using Win 7 for months now without issue. I'll give it another go as it was more of an inconvience than anything else.

Finally able to see where ncq option makes a difference. If foce ncq disabled=no, I can copy mutiple files to unraid(13MB/s two files, 25MB/s single).

 

With force ncq disabled=yes, copying a second file drops network throughput to 3MB/s from 25MB/s.

 

 

 

 

 

Wow!!!! I just got done with some preliminary testing with these settings and my writes went up from an average of 18.2 MB/s to 25.3 MB/s and yes I remembered to clear the cache and ran the test many times with a 4GB file.  Writing across the network I got around 25 MB/s as well to the disk share and around 16 MB/s with the user share.  This is a gigantic performance increase for me!  It wasn't the scheduler change that made any difference in fact that slowed things down just a hair.  It was the max_sectors_kb being changed to 128.  This test was actually done with the scheduler running at deadline so the numbers should be a tad bit higher even when/if I decide to change it back.  I still need to test now if I can do large copy jobs without causing network interruptions.  If the scheduler change fixes that I'll be really happy.

 

If this doesn't slow anyone down but helps for some maybe Tom should make this a default.

Wow!!!! I just got done with some preliminary testing with these settings and my writes went up from an average of 18.2 MB/s to 25.3 MB/s and yes I remembered to clear the cache and ran the test many times with a 4GB file.  Writing across the network I got around 25 MB/s as well to the disk share and around 16 MB/s with the user share.  This is a gigantic performance increase for me!  It wasn't the scheduler change that made any difference in fact that slowed things down just a hair.  It was the max_sectors_kb being changed to 128.  This test was actually done with the scheduler running at deadline so the numbers should be a tad bit higher even when/if I decide to change it back.  I still need to test now if I can do large copy jobs without causing network interruptions.  If the scheduler change fixes that I'll be really happy.

 

I am so glad to hear this! 

 

If this doesn't slow anyone down but helps for some maybe Tom should make this a default.

 

As far as I know, Limetech will be changing the default scheduler from noop to cfq in the next build (due out any time now)

As for setting max_sectors_kb to 128, you can keep that in your "go" script.

 

Purko

 

 

 

 

 

 

Well I had worse performance with all the other schedulers and after lots of testing I still get stuttering with every one of them too.  I tried with NCQ on and off and this also didn't help.  Oh well at least my write speeds have improved.

Well I had worse performance with all the other schedulers and after lots of testing I still get stuttering with every one of them too.  I tried with NCQ on and off and this also didn't help.  Oh well at least my write speeds have improved.

 

And how about the large copy jobs with files over GB?

They are not getting stuck/aborting anymore, are they?

 

Well I had worse performance with all the other schedulers and after lots of testing I still get stuttering with every one of them too.  I tried with NCQ on and off and this also didn't help.  Oh well at least my write speeds have improved.

 

And how about the large copy jobs with files over GB?

They are not getting stuck/aborting anymore, are they?

 

 

I should clarify, I still get stuttering while I copy.  I don't have issues with copies getting stuck or aborting.  I just was hoping to find a way to copy to my server without causing noticeable issues with video playback.  Although with the proper player/codecs I can eliminate that as well.  I currently use XBMC which I have a large cache set for playback.  The issue is when the wife plays back something on her desktop inside Windows Media Player and I get a cold stare every time I'm copying over something. I  cringe everytime I hear her video start to stutter

I copied some 4gb files over my gig network and most of the results where the same.  However CFQ with 128 was about 1 MB/sec faster on average.

 

I usually get around 19-20MB/sec with the above set I saw 21-22.  Deadline has similar results but not as consistant as cfq.

 

I tried this with both NCQ on and off and didn't see a difference but with NCQ off my parity check is about 78MB/s and with it on is around 62MB/s

CFQ with 128 was about 1 MB/sec faster on average.

Same here.  That's what I'm using in my server. 

 

And, I'm eagerly waiting for kernel 2.6.32, which is supposed to bring some notable improvements in CFQ.

 

As am I. The 2.6.32 kernel series includes multiple performance improvements, especially in the area of flushing buffers. I'll upgrade to that kernel around January 16th, roughly a month after it's second patch (2.6.32.2). Hopefully they'll have 2.6.32.3 out if needed.

I am hoping that Tom will make a 4.5.1 build with the 2.6.32 kernel.

I added those lines of code to the config file and I didn't get any increase at all. I just upgrade to 4.5 final a few days ago and I get worse speeds all across the board then I did with 4.3.3. Right now I'm getting about 11MB/sec from my Win7 box to unRaid.

I added those lines of code to the config file and I didn't get any increase at all. I just upgrade to 4.5 final a few days ago and I get worse speeds all across the board then I did with 4.3.3. Right now I'm getting about 11MB/sec from my Win7 box to unRaid.

 

You didn't mention what CPU you have in your server. The tweaks mentioned in this thread make a noticeable difference on low-powered machines, like 1GHz CPU or so.

 

Also, you are referring to transfers between your server and Win7 (samba?) which is a whole different discussion. Search the boards for Win7 problems.

 

Purko

 

 

I recently upgraded to unRAID 4.5 final from beta 7.

 

The write performance to the array is so much faster than before - I used to get 12-13 MB/sec, I am now getting about 30.

 

However, I am noticing that writes to the cache drive are slower.  Imgburn used to consistantly report 42-44 MB/sec, now I am getting about 36-38.

 

Anyway, hoping purko or someone wold summarize the currently recommended tweaks for the 4.5 release.  It's unclear what has already been built in.

 

Thanks!

You didn't mention what CPU you have in your server. The tweaks mentioned in this thread make a noticeable difference on low-powered machines, like 1Hz CPU or so.

 

For those of you playing along at home, he meant 1 GHz.

For those of you playing along at home, he meant 1 GHz.

 

Right!

 

Thanks Wholly!    

 

(I changed it up there)

 

Anyway, hoping purko or someone wold summarize the currently recommended tweaks for the 4.5 release.  It's unclear what has already been built in.

 

4.5.0-final brought a bunch of nice speed improvements, but it did not change the scheduler (noop), or the value of max_sectors_kb (512).

So, on my server I still see improvements when I change those to cfq and 128 respectively.

 

Of course, your mileage may vary. You may not see much improvement if you have a fast CPU.

 

Purko