[mythtv-users] HDHR prob with new wallwarts

[Daryl McDonald]

On Sun, Dec 8, 2019 at 4:39 AM Stephen Worthington <stephen_agent at jsw.gen.nz>
wrote:

> On Sun, 8 Dec 2019 08:46:20 +0100, you wrote:
>
> >On 08/12/2019 07:40, Stephen Worthington wrote:
> >> As for CS3 versus CS5, there are two different ways an HDHR gets used.
> >> One is where it is being recorded, and the other is where it is being
> >> watched directly by a human.  For a recording, it would actually be
> >> better to use a TCP connection with error correction and
> >> retransmission, so you could under most circumstances ensure that
> >> there were zero lost or damaged packets.  It does not matter to a
> >> recording device if the packets arrive a little late and with variable
> >> timing.  So if a TCP connection is used, in theory it would not be
> >> necessary to use a DSCP priority tag at all.  Where a human is
> >> watching though, the error correction involved in a TCP connection is
> >> usually unacceptable as it causes "buffering" moments where the
> >> playback stops.  So for a human, a high priority for the traffic is
> >> necessary to allow the packets to not be dropped and to travel with
> >> low jitter.  So that might well justify using CS5 instead of the CS3
> >> recommended by RFC4594.  For recording using UDP packets, CS3 should
> >> be all that is necessary.
> >
> >Stephen, I am wondering about circumstances under which packet drops
> >would occur in a home network at all. Furthermore I am wondering whether
> >you'd have an intelligent device in a home network making decisions
> >about which packets to drop, or whether any such packet dropping would
> >be done by consumer-class boxes that lack the smarts to look at packet
> >classification.
> >
> >The topic you describe is relevant in an enterprise network, but in a
> >home network?
> >
> >The only in-home scenario I can think of is WiFi APs, given that WMM has
> >been a mandatory feature of the standards for some time now. Still, it
> >seems that the mapping of DSCP values to WMM access categories is
> >inconsistent across WiFi vendor implementations, so not very useful in
> >practice.
>
> There did not used to be any common situations where a 1 gigabit
> Ethernet connection in a home network could be flooded and cause
> packet drops.  But that changed when hard drives became available that
> could read and write faster than 1 gigabit/s, and it got worse when
> SSDs came along as they are all much faster than that.  So now a
> simple file copy across a network connection can use up the entire 1
> gigabit/s easily.  That does not cause problems with TCP traffic - a
> packet drop with TCP simply causes a resend and usually will also slow
> down the TCP traffic, preventing further packet drops for a while. But
> with UDP you can get packet drops that cause problems, especially with
> multimedia streams.  And it is dead easy for someone (or the system)
> to start heavy traffic like that at any time.
>

I'm using a SSD for my OS and three HDDs for recordings.

>
> For quite a while now, Linux systems have by default set up traffic
> control on the transmit side of Ethernet ports.  If you do a command
> like this:
>
> root at mypvr:~# ip link show eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
> master br0 state UP mode DEFAULT group default qlen 1000
>     link/ether c8:60:00:15:81:76 brd ff:ff:ff:ff:ff:ff
>
> you will see "qdisc fq_codel" which tells you that the "Queuing
> Discipline" is set to "Fair Queuing with Controlled Delay".  The "qlen
> 1000" is the size of the transmit queue.  So packets being sent via
> eth0 will be queued and then sent in the order decided by the fq_codel
> algorithm, or dropped as necessary.  The command "tc" (Traffic
> Control) allows you to set up all the parameters for this, but the
> default setup is usually all that is needed for a home network.
>
> A command like this:
>
> root at mypvr:~# tc -s qdisc show dev eth0
> qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514
> target 5.0ms interval 100.0ms memory_limit 32Mb ecn
>  Sent 15430762721 bytes 14388768 pkt (dropped 0, overlimits 0 requeues
> 14)
>  backlog 0b 0p requeues 14
>   maxpacket 65102 drop_overlimit 0 new_flow_count 11282 ecn_mark 0
>   new_flows_len 0 old_flows_len 0
>
> can show you what the traffic control has been doing.  I have no idea
> what "requeues 14" means, but "dropped 0" looks good to me.
>
> The problem with network tuners unfortunately is on the receive side
> for a MythTV box - where the MythTV box does not have any control. All
> the receiving Ethernet port can do is receive the packets sent to it.
> Packet dropping happens at the transmit end, or in between.  In the
> case of network tuners connected via an Ethernet switch, it will
> normally be the switch that has to drop excess packets, as the
> connection from the tuner to the switch is full speed without any
> contention from other traffic, there being only one device on the
> switch's Ethernet port.  And home user type switches rarely have any
> control on how contention is handled, although they may use a sensible
> algorithm.  It just depends on how they are designed and what their
> silicon is capable of.  You would hope that by now the silicon would
> be able to check the DSCP bits and drop lower priority packets when Tx
> port queue on the switch overflows, but I have never seen any
> datasheet or manual for a home type switch that told you anything
> about that.  On cheap switches, it may simply work by FIFO and any
> packet that gets queued for transmission on a switch port when that
> queue is full will simply be dropped.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20191209/b79041d8/attachment.htm>