[mythtv-users] ringbuffer errors?

Rich West Rich.West at wesmo.com
Thu Jan 2 18:45:16 UTC 2014


On 01/02/2014 10:29 AM, Jeff Breitner wrote:
>
>
>
> On Wed, Jan 1, 2014 at 11:58 AM, Rich West <Rich.West at wesmo.com
> <mailto:Rich.West at wesmo.com>> wrote:
>
>     Of course, MythTV decides to act up last night.. to the point
>     where watching
>     a recording of the ball dropping was just not possible (I heard a
>     LOT of "I
>     think this is the year we move away from mythtv!" from my other half).
>
> ... 
>
>
>     CPU usage & network usage on both the frontend and backend systems
>     were
>     extremely low.  From that standpoint, they were basically bored.
>      Disk I/O
>     seemed fine (of course sysstat wasn't installed, and there was
>     essentially a
>     revolt, so I couldn't dig too deep with the debugging), no disk errors
>     reported, and generally the backend appeared healthy (I graph
>     everything via
>     cacti, including tuner usage, jobs, errors, etc).  I've never had
>     issues
>     like this in the past, and we essentially did the same thing around
>     Thanksgiving (family over likes the football games) with great
>     success.
>     Needless to say, it was very frustrating, and I'm not sure where
>     to even
>     begin looking..
>
>
>
> Have you looked at what you are using for a kernel IO scheduler? 
>
> I think there may be some unpleasant interaction with the backend
> thread writer and kernel IO scheduling in deadline or cfq.  Noop seems
> to be the only way I can avoid having those kinds of messages along
> with complaints about waiting 100ms (or more) for video.
>
> Even though XFS does a good job preventing fragmentation, once the
> file system gets north of 85% capacity, the performance starts to drop
> off.  Does your LiveTV storage fit within 85% capacity?

Each volume in the storage group is running at near total capacity.  I
wonder if it is worth dedicating a different drive to livetv only.

>
> Finally, has your bios done something stupid and moved your sata
> drives to legacy ata?  I found that a bios flash to fix a different
> flaw changed it, and only when I was chasing a red herring on this
> issue did I notice that ncq was turned off (cat
> /sys/block/sda/device/queue_depth == 1 ... which is disabled).

Good point.  I just checked each disk, and the queue_depth is set to 1
for each (disabled) (re: https://ata.wiki.kernel.org/index.php/Libata_FAQ)

dmesg | grep -i ncq
[    1.240156] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[    1.773447] ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)

>
> These three things, once resolved, greatly improved things.

I'll check the BIOS this evening.  I'm getting "permission denied" when
trying to adjust via "echo 31 > /sys/block/sdX/device/queue_depth", and
http://forums.fedoraforum.org/showpost.php?p=1029722&postcount=2 seems
to indicate that you've pointed me down the right path.

Thanks, Jeff!
-Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140102/9ad48ae7/attachment.html>


More information about the mythtv-users mailing list