[mythtv] [mythtv-commits] Ticket #2708: patch: Allow remote FE/BE to prefer to use the myth protocol

[Ian Latter]

Hello Chris,


  I'd be interested in your findings on this (your buffering
experiments).  I recently (two weeks ago) put a Core 2 Duo 
backend together for my three DVB-T cards, and only use 
the native Myth (.20/RPM) protocol to provide connectivity.

  Interestingly while I've almost removed all of the stutter/skip/
pause from the live TV display, I've not had issues playing 
from recorded files, and I've consistently had bigger stutter/
skip/pause periods in the preview pane -- all cases using the 
native myth protocol for FE->BE comms.  All of my TV IO is
Standard Definition Digital, btw.

  The wiki is very focused on display drivers (which have
helped for the live TV full-screen display - I believe remaining
stutters come from occassional reception errors) .. but there 
is something else ..  the ring buffer size seems to affect the 
front end full-screen live TV display only (the stutters used to
happen further apart with bigger buffer sizes), that setting 
didn't (and doesn't) seem to affect the preview pane (which 
stutters much more often / shorter periods between stutters).
And as mentioned above, there haven't been issues with 
pre-recorded TV being played back.

  I also see the pauses that come through FF'ing per Bruce's
comments - though I considered this logical and reasonable (to
be expected - tho not friendly).


  I don't believe I have any hardware performance issues left 
to cause these problems, and the inconsistencies in the 
different types of displays suggest that this is true - it seems
more like there are differing buffer settings for the different 
display mechanisms. 

  Hardware for reference;

  Backend;
    Intel Core 2 Duo (E6600)
    2Gbytes RAM (don't recall the speed, fast)
    Root disk is SATAII EXT3 (running the DB)
    Storage is SATAII LVM Array EXT3 [3 disks]
    LAN is Gigabit Ethernet (r8169: RTL8168b/8111b)
    DVB-T is the WinFast DTV1000-T (card 35 of cx88) [3 of]
    OS is FC6 (updated per Wilson's)
    Kernel is custom 2.6.18-2 (patched for Asus P5B Mobo)
    Typical loads are
       - 0% idling
       - 0.2% recording
       - 2% recoding and streaming (all cards in use)

  Frontend;
    AMD Sempron 2400+
    512Mbytes RAM (don't recall the speed, slow)
    Root disk IDE EXT3 (DMA enabled)
    LAN is 100Mbit (forcedeth: nForce2)
    Video is AGP nVidia [GeForce4 MX - nForce GPU] (rev a3)
    OS is FC4 (updated per Wilson's)
    Kernel is 2.6.17-1.2142_FC4
    Typical loads are
       - 0% idling
       - 16-25% live TV

  I know there is general distaste for EXT3, but I've not seen 
data IO issues (and with the segregated backend neither the 
front nor the backends spend any real time on disk activity
any more).  
  The FrontEnd is the only 100Mbit LAN device on the network, 
but other than the HTTP proxy there are no local services (no 
file sharing whatsoever) thus all other devices are capped at 
the 1Mbit/s gateway, so I know its not local bandwidth causing 
choke points (all switches are Gigabit, but not managed - so no
SNMP or stats unfortunately).
  Additionally I use iptables on all of my Linux devices, and 
have used the logs on these two to resolve their filter configs. 
The multicast addresses and ports do seem to be running 
correctly.


  This is one of those slowly evolving background projects for 
me .. I'm still not sure what it should finally look like .. one day I'll
get it all up on the web site .. I still can't believe that I use 
smaller CPUs for servers than I do for my TV ;-))




----- Original Message -----
>From: "Chris Pinkham" <cpinkham at bc2va.org>
>To: "Development of mythtv" <mythtv-dev at mythtv.org>
>Subject:  Re: [mythtv] [mythtv-commits] Ticket #2708: patch: Allow	remote	FE/BE to 
prefer to use the myth protocol
>Date: Tue, 21 Nov 2006 16:57:20 -0500
>
> * On Tue Nov 21, 2006 at 04:35:47PM -0500, Daniel Kristjansson wrote:
> > This is almost certainly because we require a larger buffer when
> > streaming, and for some reason your network needs the larger buffer.
> > It would be easy to add a "Do Extra Buffering" checkbox and add
> > the needed change in the RingBuffer initialization parameters.
> 
> That's what I was thinking as well and figured that would have helped out
> the few times I've seen the issue with my NFS-mounted recording directories.
> 
> I don't mind adding something to force using the myth:// protocol even if the
> file might be accessible locally via a remotely mounted directory, but also
> want to try bumping up the buffer sizes on my end to see if it cures the
> issue I was seeing.
> 
> --
> Chris
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 


--
Ian Latter
Late night coder ..
http://midnightcode.org/