<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Dec 8, 2019 at 4:39 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 8 Dec 2019 08:46:20 +0100, you wrote:<br>
<br>
>On 08/12/2019 07:40, Stephen Worthington wrote:<br>
>> As for CS3 versus CS5, there are two different ways an HDHR gets used.<br>
>> One is where it is being recorded, and the other is where it is being<br>
>> watched directly by a human.  For a recording, it would actually be<br>
>> better to use a TCP connection with error correction and<br>
>> retransmission, so you could under most circumstances ensure that<br>
>> there were zero lost or damaged packets.  It does not matter to a<br>
>> recording device if the packets arrive a little late and with variable<br>
>> timing.  So if a TCP connection is used, in theory it would not be<br>
>> necessary to use a DSCP priority tag at all.  Where a human is<br>
>> watching though, the error correction involved in a TCP connection is<br>
>> usually unacceptable as it causes "buffering" moments where the<br>
>> playback stops.  So for a human, a high priority for the traffic is<br>
>> necessary to allow the packets to not be dropped and to travel with<br>
>> low jitter.  So that might well justify using CS5 instead of the CS3<br>
>> recommended by RFC4594.  For recording using UDP packets, CS3 should<br>
>> be all that is necessary.<br>
><br>
>Stephen, I am wondering about circumstances under which packet drops<br>
>would occur in a home network at all. Furthermore I am wondering whether<br>
>you'd have an intelligent device in a home network making decisions<br>
>about which packets to drop, or whether any such packet dropping would<br>
>be done by consumer-class boxes that lack the smarts to look at packet<br>
>classification.<br>
><br>
>The topic you describe is relevant in an enterprise network, but in a<br>
>home network?<br>
><br>
>The only in-home scenario I can think of is WiFi APs, given that WMM has<br>
>been a mandatory feature of the standards for some time now. Still, it<br>
>seems that the mapping of DSCP values to WMM access categories is<br>
>inconsistent across WiFi vendor implementations, so not very useful in<br>
>practice.<br>
<br>
There did not used to be any common situations where a 1 gigabit<br>
Ethernet connection in a home network could be flooded and cause<br>
packet drops.  But that changed when hard drives became available that<br>
could read and write faster than 1 gigabit/s, and it got worse when<br>
SSDs came along as they are all much faster than that.  So now a<br>
simple file copy across a network connection can use up the entire 1<br>
gigabit/s easily.  That does not cause problems with TCP traffic - a<br>
packet drop with TCP simply causes a resend and usually will also slow<br>
down the TCP traffic, preventing further packet drops for a while. But<br>
with UDP you can get packet drops that cause problems, especially with<br>
multimedia streams.  And it is dead easy for someone (or the system)<br>
to start heavy traffic like that at any time.<br></blockquote><div><br></div><div>I'm using a SSD for my OS and three HDDs for recordings. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
For quite a while now, Linux systems have by default set up traffic<br>
control on the transmit side of Ethernet ports.  If you do a command<br>
like this:<br>
<br>
root@mypvr:~# ip link show eth0<br>
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel<br>
master br0 state UP mode DEFAULT group default qlen 1000<br>
    link/ether c8:60:00:15:81:76 brd ff:ff:ff:ff:ff:ff<br>
<br>
you will see "qdisc fq_codel" which tells you that the "Queuing<br>
Discipline" is set to "Fair Queuing with Controlled Delay".  The "qlen<br>
1000" is the size of the transmit queue.  So packets being sent via<br>
eth0 will be queued and then sent in the order decided by the fq_codel<br>
algorithm, or dropped as necessary.  The command "tc" (Traffic<br>
Control) allows you to set up all the parameters for this, but the<br>
default setup is usually all that is needed for a home network.<br>
<br>
A command like this:<br>
<br>
root@mypvr:~# tc -s qdisc show dev eth0<br>
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514<br>
target 5.0ms interval 100.0ms memory_limit 32Mb ecn<br>
 Sent 15430762721 bytes 14388768 pkt (dropped 0, overlimits 0 requeues<br>
14)<br>
 backlog 0b 0p requeues 14<br>
  maxpacket 65102 drop_overlimit 0 new_flow_count 11282 ecn_mark 0<br>
  new_flows_len 0 old_flows_len 0<br>
<br>
can show you what the traffic control has been doing.  I have no idea<br>
what "requeues 14" means, but "dropped 0" looks good to me.<br>
<br>
The problem with network tuners unfortunately is on the receive side<br>
for a MythTV box - where the MythTV box does not have any control. All<br>
the receiving Ethernet port can do is receive the packets sent to it.<br>
Packet dropping happens at the transmit end, or in between.  In the<br>
case of network tuners connected via an Ethernet switch, it will<br>
normally be the switch that has to drop excess packets, as the<br>
connection from the tuner to the switch is full speed without any<br>
contention from other traffic, there being only one device on the<br>
switch's Ethernet port.  And home user type switches rarely have any<br>
control on how contention is handled, although they may use a sensible<br>
algorithm.  It just depends on how they are designed and what their<br>
silicon is capable of.  You would hope that by now the silicon would<br>
be able to check the DSCP bits and drop lower priority packets when Tx<br>
port queue on the switch overflows, but I have never seen any<br>
datasheet or manual for a home type switch that told you anything<br>
about that.  On cheap switches, it may simply work by FIFO and any<br>
packet that gets queued for transmission on a switch port when that<br>
queue is full will simply be dropped.<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
</blockquote></div></div>