[mythtv-users] HDHR prob with new wallwarts

[Stephen Worthington]

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.

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.