I/O issue causing video stutter

This is not so much an issue as much as curiosity as to the potential root cause...

I have an unRAID server and it is various versions, 4.x to 5.0RC16 at the moment.  I do not have a cache disk, so any activity is going to go right to my disk pool.  I have 2 GB of RAM and am running a sempron 140 CPU.

My question really is what would cause me stutter? My playback device is a PCH a-310 as well as 2 aging a-110's.  All exhibit the issue randomly during playback and sometimes never at all, so it is not a constant issue by any means, just something I deal with on a more random basis.

Kids could be watching a DVD iso and I go to my computer to open a share on a disk not spun up.  On the PC there is the usual delay like always as I wait, but in turn, this will result in the DVD iso to stutter and freeze momentarily.  If I stop spinning up disks or open what I need, playback usually returns to normal.

Another case would be running a linux VM on separate machine, sick beard and sabnzbd downloading something.  Stutter starts, I look at sab and see it is verifying or unpacking, so I attribute this to disk IO in 2 places.  Pause video, wait a few seconds and then things return to normal, but sometimes I need to repeat the pausing action while I wait for things to complete.  Other times, I stop the downloads completely.

Other such events to knowingly cause stutter is ripping a dvd or bluray.

In these cases, it is not always a guarantee for stutter, while all common the most troubling would be the one caused by spin-up.  My assumption is the other circumstances are most likely solved via a cache disk.  My concern is more that according to what I see, I should be able to stream movies to 2 places and while I rarely actually do, I would think that such an activity would generate similar levels of IO, therefore, making me believe I could not do it without stutter.

I know many user the 140 chip for the low power consumption, but I am still curious, could my issue relate in any way to CPU or memory being an issue?  Would an upgrade there do me any good or is the spin-up issue normal?  I assume a cache disk would resolve the issues I see when simultaneously writing, but I thought to get some opinions.

I am in the middle of re-doing my setup, new case to expand disk capacity and potentially moving to a virtual setup, reducing the number of systems I have around.  So I am just trying to figure out what my bottleneck might be, because I always read about the stories where people are streaming to more than one Tv and never an issue and I sometimes experience issues when going to one.  Sometimes I live with it as I get annoyed watching things by myself, but when it does it during a movie with me and the wife, it ruins it when i am stopping and starting things and looking for what could be causing the issue.  Thanks

unRAID freezes all disk transfers while a disk is spun up. This will cause stutter. Some have implemented plugins/scripts to spin up drives when a media client is started. Otherwise basic streaming is very lightweight to unRAID; I've just been benchmarking unRAID with different systems and video streaming in 10-20Mbps bitrates causes only 1-5% cpu usage.

Edit. Also even a single hard drive can easily sustain a bunch of such streams, data rates of modern > 1TB drives are normally more than 100MBps (=800Mbps). For the blu-ray rip part, are you using wired or wireless networks on some or all clients? If wireless which class, "n" / "g" or "ng-mixed"? What kind of data rate are you seeing for the ripping (eg. 12MBps / 96Mbps) to unRAID (usually limited by the BR-drive)? What is the file copy speed to unRAID (write speed) on wired connection?

Which MB? Any SATA cards?

Gigabyte mobo,  using 6 on board sata and an add-in sas/sata 8 port

Knowing unraid freezes the disks at a spin-up explains some of it.

Actually UnRAID doesn't freeze ALL the disks during a spin-up ... only those on the same set of controller channels.    That's the reason for "spin-up groups" ... it can take some experimentation to determine just which disks need to be in each group; but if you get them set correctly, you can eliminate the issue.    Whenever UnRAID spins up a disk in a specified group, it will spin them all up ... so any subsequent access to one of them won't require another spin-up (thus causing the stutters you've noticed).

Actually UnRAID doesn't freeze ALL the disks during a spin-up ... only those on the same set of controller channels.    That's the reason for "spin-up groups" ... it can take some experimentation to determine just which disks need to be in each group; but if you get them set correctly, you can eliminate the issue.    Whenever UnRAID spins up a disk in a specified group, it will spin them all up ... so any subsequent access to one of them won't require another spin-up (thus causing the stutters you've noticed).

I stand corrected. I did not know that, I always assumed that everything was frozen since that how it seemed. Actually this is a great piece of info. What does "same set of controller channels" mean? Is it the whole controller / mb or eg. a specific SAS-channel (four ports) or is it something controller specific?

Is there any logic to the experimentation as noted,  mobo sata,  sas port etc?

Is there any logic to the experimentation as noted,  mobo sata,  sas port etc?

IDK, could be by controller or SAS port. Try a cache disk first; although, this could be worse with multiple accesses to cached content; unless a SSD is used.

Is there any logic to the experimentation as noted,  mobo sata,  sas port etc?

Well ... obviously a group won't include ports from different controllers (i.e. motherboard and an add-in card)

My experience is that they're usually in groups of either 2 or 4, depending on the underlying controller chips.  Most of mine are in groups of 4 ... but I never did figure out a simple way to isolate them -- I just did determined it the "brute force" way 

What I did to isolate my spin-up groups ...

=> I spun all the drives down; then started a movie streaming from one drive [e.g. disk1] ... which, of course spun that drive back up.

=>  I then, one-at-a-time, started accessing other disks to force them to spin up ... noting whether or not this caused a "freeze" or "stutter" on the movie.    Say, for example, that disk2 did not, but disk3 did.  I'd then make a note that disk1 and disk3 needed to be grouped;  then I spun down all drives again; restarted the movie from disk1; and continued the process, until I knew which disks interacted with disk1. 

This doesn't take as long as it might seem.  Once you've isolated a particular spin-up group; those disks no longer need to be part of the next test.    So the number of disks to test keeps getting smaller as you proceed through the process.

... and once you've got the groups isolated, stutters will be a thing of the past 

The downside, of course, is that you'll be spinning up disks you may not need whenever you watch a movie.    If you never use your server for anything else while watching media, then you may not want to do that.

Ok,  makes sense.  I guess I will plan to start with a cache disk.  My new case only has 15 drive bays,  so maybe what I will do is put all data drives onto the sas cards and put the cache disk on the motherboard.  At least that's the current thought process.

another corner case to consider which was affecting me... i have jumbo frames setup, but somehow one of my computers NIC drivers got updated during a windows update. It reset all the jumbo frame settings, and I suddenly experienced video stutter streaming from unRaid. File copy transfers were still very fast...

I eventually figured this out and set the proper jumbo frame values in the NIC drivers, and 1080p HD vid streaming is back to normal now...

I use a popcorn hour A-300 and was experiencing stutter/freezing on 1080p movies streamed from my unRAID server.  I fixed the stuttering/freezing by changing the unRAID NFS share on the A-300 from NFS to NFS-TCP.

Good luck!

Not using jumbo frames

And I stopped using NFS because of the stake file handle.  Gonna have to try going back.

I ran into "Stale File Handle" problems.  I get around it by mounting and umounting the PCH share inside the YAMJ shell script.

Gonna try with 5.0 now that stale files are supposed to be fixed

Ok,  I wanted to revisit this after my experience this weekend.

It all started with of alk things bubble guppies mkv files.  On my a-110 the files would start and immediately get jittery.  The picture freezing up and the file was essentially unplayable.

Later that day,  I went to my a-210 and can't recall if I tried smb or went straight to NFS,  but regardless,  the file played fine.

That night,  I watched Public Enemies Blu-ray (ts) rip,  it is dts-hd,  the movie played but randomly the audio froze and the picture skipped.  It would recover after a few seconds,  but it was ultra annoying.

Eventually,  I remembered and switched to NFS.  After this the movie seemed to play flawlessly.  So yesterday morning I decided to try NFS on the a-110 with bubble guppies and needless to say the kids have been enjoying it ever since.

So,  NFS definitely makes a big difference as it turned unplayable into playable.

I even tried switching to smb just to verify and it still stuttered,  back to NFS and it was OK.  So it is not like unraid,  my home network or my pch were suddenly working better,  it was definitely NFS vs smb.

The only thing I did notice about NFS is that it is more sensitive while waiting for the disks to spin up, my pch reports no media and I need to go back and forth till things are finally spun up.  However,  that's a small price to pay for working video files.