At this point we are speculating about the past.

 

Stop blue iris, set share to cache-yes, run mover, see if they get moved. Set share to cache-no, start blue iris, see if any new ones get created on cache.

Okay, I collected some interesting data last night.  I am still able to re-create the stuttering playback issue, but this time I was looking at the activity within the array and captured the image below.  The array is ingesting a burst of data (a single file write operation, typically between 10 and 80 MB, sourced from the security camera app), and approximately one minute later, there's a huge amount of HDD activity and the movie playback stutters.  This phenomenon is repeated very reliably each time such a write to the array takes place.

 

So...  a workaround to this is to simply not have BlueIris write to the array, but I'm wondering if there is anything that can be tweaked in unRAID to solve this problem more elegantly.  

 

My 2nd main question now is:  Did something change from 5.x to 6.x to cause unRAID to be more sensitive to this inbound stream of data during movie playback?  As I stated in my initial post, this problem only started happening after my upgrade to 6.3.5 from 5.0.6.

 

Bryan

 

Edited October 18, 20178 yr by cowger

Make sure that your MB is setup to use ACHI mode for disk access and not one of the legacy IDE modes. 

5 minutes ago, Frank1940 said:

Make sure that your MB is setup to use ACHI mode for disk access and not one of the legacy IDE modes. 

 

Okay... but unfortunately this is where I get in over my head.  Can you provide me an idiot's guide on how to check / affect this?

 

If it helps, attached is some information about my BIOS settings, but I don't see anything in there about ACHI...

35 minutes ago, cowger said:

If it helps, attached is some information about my BIOS settings, but I don't see anything in there about ACHI..

 

AHCI is already enable.

 

Reiserfs is known to have terrible performance with full disks, disk6 is almost empty, move any data from there, format it xfs and create a new share that includes only disk6, try recording to that new share and see if it's any better.

Check out the Tips and Tweaks plugin and see what your cpu scaling governor is set to. If it's set to power save, try switching it to performance to see if your transfer speeds go up, and if the stuttering goes away...

 

On my server, with my older slower cpu, and even to a lesser degree with my current behemoth, file transfers over the network and between disks is always faster on the "performance" setting.

 

 

1 hour ago, DoeBoye said:

Check out the Tips and Tweaks plugin and see what your cpu scaling governor is set to. If it's set to power save, try switching it to performance to see if your transfer speeds go up, and if the stuttering goes away...

 

On my server, with my older slower cpu, and even to a lesser degree with my current behemoth, file transfers over the network and between disks is always faster on the "performance" setting.

 

 

 

Thanks, good tip!  Mine was indeed set to power save.  

 

I think my plan at this point is:

1) Disable BlueIris writes to this array (for now)

2) Systematically update each disk (one at a time) to XFS

3) Re-balance the allocation of each disk at the end of that process

4) Re-enable BlueIris writes to the array

5) Play around with CPU scaling at that time, too

 

Thanks, all, for the help to this point.  I certainly never would have gotten anywhere this quickly without your help.

 

Bryan

 

42 minutes ago, cowger said:

Thanks, good tip!  Mine was indeed set to power save.

Keep in mind your server will use slightly more electricity because it is keeping the CPU at the maximum frequency (maximum non-turbo frequency I believe.. if your cpu supports turbo). Also, you may have "onDemand" available, which is the best of both worlds, but is not always available, and may still cause stutters until the CPU speeds up... This of course, is assuming that CPU frequency is causing the issue.

 

Make sure to report back and let us know the outcome of your tests!

 

It strikes me that the two problems could still be related.  Writing to the array can cause a utilization spike because parity needs to be calculated and written.  There shouldn't be as much of a utilization spike while writing to the cache drive (where the files are mysteriously being written). 

 

Well, get yourself off of ReiserFS as the priority.  If the problem still exists after then at least there will be one less potential cause.

I'm starting through the long process of moving data around and converting to XFS. 

 

After moving everything off disk 6, I went to stop the array and it seemed to hang on "sync filesystems".  I gave it about 45 minutes and then gave up, resetting the array, and am now paying the price for that with a 38 hour parity check.  

 

I tried to google why "sync filesystems" might have hung, but didn't find anything that seemed to apply.  For my future "stop array" commands, should I do something before I hit "stop", or just give it more time?  

 

I guess my question is:  Did "sync filesystems" likely hang, or can it take that long?

 

One final post to close this thread out.  In summary, everything appears to be fixed and now working as expected.  I've converted all disks over to XFS and enabled cache for writes to my Movies and Archives shares.  As a final test, I ripped a DVD to the array (to generate inbound traffic) while streaming out a movie last night and it worked just fine with no stutter events.  You can see the writes to the array as the 30-odd spikes in the Storage window below, while the movie streaming progresses without interruption.

 

I want to thank everyone who took the time to walk me through this.  I now have a much better understanding of my unRAID system, where before it was unfortunately just kind of a black box to me. 

 

Cheers!

Bryan

Glad to hear it.