I use unRaid as a media server for Xboxes around my house.  On them I run XBMC media center software.  If I'm watching a DVD rip and start a parity check the video playback begins to stutter.  I've noticed this for quite some time (across different unRaid versions), but I always forgot to post about it.  Also, if I navigate the movie directories or delete a movie folder via my Windows desktop, video playback wil stop for a couple seconds and then continue.

 

Does anybody else experience this either on XBMC or any other media player?

After all the tough problems lately, this one is easy, but you won't like the answer:  don't run parity checks at the same time as anything else.  Parity checks and parity builds and drive rebuilds all cause maximum disk I/O, and are certainly going to interfere with any other I/O.  Normally, a maintenance task like parity checks should only be run in off hours, or as needed in a troubleshooting event, when there would be no competition for the server's attention.

 

Trying to run a parity check at the same time as you are trying to stream a movie means the disk heads are going to have to rapidly swing back and forth between the movie blocks and the blocks being parity checked.  In addition, I suspect that all of the disk I/O for the parity check will be constantly flushing the disk buffers and caches, possibly causing multiple disk reads for the streaming.  And I suspect all of the head movement is going to significantly increase the drive temp.

 

Perhaps in the future, Tom could add an option to run the parity check in idle time, that is, monitor for other disk I/O and pause the parity check for a minute after detecting any other source of disk I/O.  Which means of course, it won't finish running until after the movie finishes, which begs the question "why not run it later in off hours any way".

 

I don't know why navigating through movie folders should have any noticeable effect, unless the disk they are on needs to be spun up.  Deleting a file or folder causes writes to the unRAID server, which involves spinning up the parity drive and I/O's to the movie and parity drives.  I've noticed that deletions seem to be an intensive disk I/O operation in the Reiser file system, seem to take a lot longer than deletions to standard Windows file systems.

RobJ hit the nail write on the head with this one.

 

It is the reason that some of the members here have set up cron jobs to run parity checks during the wee hours of the morning.  I run mine on Sunday mornings at 1am.  This time works pretty good for me (but i might be changing it to Monday mornings instead).

 

Do some searching on the forum for a cron script that can get this job done for you.

Maybe it's just my setup but parity checks take about a day to complete in total for an 8TB system with 14 drives.  So there isn't ever a good time to run it unless I leave town for the weekend.  I have been known to shutdown from the console without thinking and creating the need for parity to be rechecked.  I would love to see a throttle built in for parity checks.  If I'm doing a parity check and I really need to watch something I usually copy the file locally and play it.  Another thing that should help is using something like the "Matroska Splitter" for your renderer.  You can adjust the buffer times within the config to help with the stuttering.  I used to do this when I ran my media over my wireless network.

Hmm... I could've sworn that way back this was never a problem, but I'm probably wrong.  I do have parity checks scheduled to run once a month via a scrip Joe L. posted.  In fact that's how I remembered to post this.  Saturday night my wife and I were in the middle of watching a movie and all of the sudden it started stuttering like crazy and I was like what the...?  Then it dawned on me that it just turned March 1 and my server was performing a parity check.  To be able to finish the movie I had to cancel the parity check. 

 

I agree with havix that it would be hard to have a set time where there would never be anyone watching considering how long parity checks can take.  It would be cool if you could assign a priority level in the settings or something so that it would throttle back or pause when a certain amount of disk activity was detected and then resume or pick back up when the activity ceased.  It's annoying not being able to use the system while a parity check is being done.

 

Also, something I really don't like that has been mentioned before is that when you cancel a parity check the gui show a check run with the date and time that you stopped it.  There's nothing to indicate that the check was canceled.  It acts like it ran to it's conclusion and everything is fine.  Definitely not a good thing.

 

 

 

Although this is not a problem for most users right now, as drives get bigger this problem will get worse and worse.  Imagine an array of 4T drives.  It is going to take 4 times longer than your current parity check.  For me that would be close to 40 hours!  Sooner or later Tom will have to address this issue. 

 

I'd like to be able to schedule a parity check on only a certain portion of the drive (say from start to 25%).  Then the next night I could schedule from 25% to 50%, etc, etc.  With this a user could schedule the complete parity check over a series of days during off hours.  It would also be a way of resuming a parity check that you needed to cancel so that you could watch a movie!

Maybe it's just my setup but parity checks take about a day to complete in total for an 8TB system with 14 drives.  So there isn't ever a good time to run it unless I leave town for the weekend.   I have been known to shutdown from the console without thinking and creating the need for parity to be rechecked.  I would love to see a throttle built in for parity checks.  If I'm doing a parity check and I really need to watch something I usually copy the file locally and play it.  Another thing that should help is using something like the "Matroska Splitter" for your renderer.  You can adjust the buffer times within the config to help with the stuttering.  I used to do this when I ran my media over my wireless network.

 

A run on my system with 5TB of storage (2x750GB, 2x500GB, 1x1TB, 1x1.5GB) runs in about 7 hours.  I start it at 1 am and it finishes around 8 in the morning.

I've thought about trying to use ionice, but have been too busy with some other projects.  I have used it in other situations to set Apache ionice to realtime, to make sure it had priority for streaming high bitrates.  It is also used in some video-capture situations.

This sounds related to the other issue posted (currently no resolution) regarding directory listings hanging transfers or causing stutters on video playback.

 

I hope Tom looks at this issue soon, as an increasing number of users are now reporting it.

This is not necessarily an "issue" for Tom.

 

A computer has default settings that are compromises -- they work reasonably well in the vast majority of situations.  Sort of like the camshaft and timings for a car... they are a compromise that gives you the best overall gas mileage because there is no way for the manufacturer to know what speed you do most of your traveling at.

 

If you change the camshaft to increase mileage on the highway, because you drive 99% highway, then city-mileage will suck.  And vice-versa.

 

You are trying to do two things at once, so the computer has to divide its attention between the two activities.  In addition, dozens of other activities are running in the background, including the unRAID processes of dealing with disks and parity.  They all need some amount of I/O and CPU, and when the amount they need exceeds the amount the server has to give, then you get bottlenecks, contention, and the server has to ration the I/O and CPU among the processes via the scheduler.

 

If a change was made to stock-unRAID that addressed the "issue" you raised, it could very well hurt write performance when copying files to unRAID.  It would likely cause other unforeseen performance changes.

 

Tom has to build the car with a generic camshaft that works well in the most situations. 

 

Now Linux has a number of utilities that you can use to "tune" your server.  You should google tune linux and read up on them.  Samba and NFS also have tuning parameters.

 

But remember -- you can't have everything.  If you increase performance of one program, you will be likely decreasing performance of another.

 

I have been thinking about a "performance" control panel for unMENU or unRAID_Web, where you could select from some pre-defined profiles such as:

 

- optimize for streaming media playback

- optimize for maximum write speed

- optimize for maximum read speed

 

There could be more... but you get the idea.

 

 

 

Attached is a set of "User-Scripts" for unmenu that will allow you to "tune" the disk I/O scheduler. 

 

There are several sets of buttons. 

One button will give you the ability to see the current read-ahead setting, another to see the current disk I/O schedule method.

 

One button will let you perform a hard-disk speed test on all your disks.  This button will perform a hdparm -tT on all your disks.  It takes a few seconds per disk to run, so it you have a lot of disks it will take a while before your browser will return with the result.  Just be patient.  It will let you see the disk speeds diring a parity check in each of the settings as you experiement.

 

The other two sets of buttons will let you set the disk read-ahead values and disk I/O schedule method.

 

I can tell you first-hand that the "cfq" (Completely Fair Queuing) is probably NOT what you want.  A movie will stutter badly if played during a parity check on my server when in that mode.  (Click the button, and within a minute the stutters will start if a parity check is in progress.  It takes a bit of time to clear out the existing buffered data and show the effects of any newly selected mode)

 

As shipped by Tom, The disk I/O on the server is in Simple FIFO mode and has a read-ahead of 1024.

 

I honestly do not know which mode is best for watching movies over the LAN.  It may even differ based on your hardware and built in buffer-memory.  Perhaps others can report their findings.

 

The disk I/O buttons will probably have no effect on earlier versions of unRAID.  (I am not sure on which linux version the I/O tuning became available) I'm running 4.4.2 version of unRAID.

 

I also included a newer version of the User-Script plug-in.  It properly handles buttons with embedded single quote marks.

 

The buttons will look like this:

 

To install, just unzip the attachment to the folder with your other unMENU files.  Then click on the User-Scripts link in unMENU.

 

Please, report back on your findings.  Tom might have chosen the best I/O queuing  method, or perhaps not, and it might vary based on your usage of the server.

 

Oh yes, the "button" scripts are just shell scripts.  They can be run individually from the Linux command line even if you do not have unmenu installed.

 

Joe L.

 

Here is an interesting link to a page describing the various disk I/O modes. 

http://www.gelato.unsw.edu.au/IA64wiki/LinuxIOSchedulers

 

Here is the wiki entry describing the "noop" mode Tom has enabled in the current 4.4.2 unRAID.

http://en.wikipedia.org/wiki/Noop_scheduler

And here are links to the others:

http://en.wikipedia.org/wiki/CFQ

http://en.wikipedia.org/wiki/Anticipatory_scheduling

http://en.wikipedia.org/wiki/Deadline_scheduler

 

There are tunable values affiliated with most.  You might be able to experiment a bit with these too once you have chosen a I/O mode

 

Joe L.

I can understand why a transfer of video/music/anything may stutter during a parity check.. I can live with that.

 

However why would all of these be affected by a simple directory listing?

I can understand why a transfer of video/music/anything may stutter during a parity check.. I can live with that.

 

However why would all of these be affected by a simple directory listing?

My best guess is: the network I/O and the part of the kernel that is involved in the spin-up share a common "lock" on some resource.

Normally, this "lock" is not an issue and normal buffering makes it go unnoticed.  The duration of the spin-up causes the "locked" I/O to be noticed.

 

It is not the directory listing itself, but the spin up of a drive to read its contents that are not in the buffer cache that is the issue.

 

In this post a user indicated that they learned in an e-mail from Tom that he has been able to duplicate the spin-up I/O freeze issue and is working on a fix.

 

There is hope...   I'm hoping the same lock (and eventual fix) might also be the cause when "writes" to the array to "stutter" (stop for seconds at a time) as the I/O buffers are being flushed to the physical disks by the "pdflush" process.

 

Joe L.

As I read about these stuttering issues and realize that I don't have them, I begin to wonder if the issue might have to do with user shares.  I think that read performance is reduced with them, and also the time to spin up a bunch of disks can be significant.  With my individual disk setup, maybe the buffering is sufficient to keep up.  I have noticed, while coding myMain, that I had a hard time getting spinups to run in parallel.  Hopefully Tom can get to the root of it.

It's not user-shares.  I don't use them yet have both problems.

 

Yup, I noticed the same thing recently. I finally hit the spin up all drives button, then it did not affect my performance.

Has anyone done any tests as to which raid cards give the best jbod for unraid performance?

We should hold a competition and have everyone post their results based on a specific set of test with logs.

It would give all of us an idea as to how to improve performance. I need to get off my pci Promise cards, and I have both PCI-X and PCI-E slots, I just do not know which is best performance wise, and which (if I build a dev unraid system) might be able to support raid 5 cache drive or parity drive.

i can't say that i have the same problem.

i have started a parity check and ran 2 DVD streams at the same time. 1 through a Gigabit lan and 1 through a 802.11g connection. No stutter on either.  i also started two dvd streams and then started a parity check. both streams were never interupted, zero stutter.

running version 4.4 on recomended Asus mobo. all SATA are connected to the motherboard ports. No additional Mods or services running.

 

It sounds like there may be a bit more to this .  I'll have to test if spinning up all the drives fixes it for me or not.  I wonder what that would have to do with anything. Could someone else verify if this stops the stuttering for you too?

There was a similar thread in the 4.3 forum, and I think the mystery may be solved.

 

If your user share's split level is set too high, files for a given movie may be split across multiple disks.  This will cause stuttering if some of those disks are spun down.

 

Look here for more details and discussion.

 

This seemed to be the problem over in that thread.  Please check same here.  If people are still having a problem please post back with specifics.