[mythtv-users] HDHR prob with new wallwarts

[Jan Ceuleers]

On 08/12/2019 10:39, Stephen Worthington wrote:
> 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

Fair enough, the disks are now faster.

> For quite a while now, Linux systems have by default set up traffic
> control on the transmit side of Ethernet ports.

Well aware of this - I'm on the bufferbloat mailing list.

But the point I was raising is about packet drops within the home
/network/, i.e. not at the endpoints where you can indeed assume that
queuing and differentiated dropping are available. It's the network
elements (i.e. ethernet switches, WiFi routers) that packet marking is
aimed at. Consumer-level devices typically do not support differentiated
treatment of traffic. Not even if they run Linux because the forwarding
is delegated to a hardware packet accelerator which doesn't support many
of the features present in the Linux kernel which apply only to software
forwarding.

> 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.

Right.

Since we are talking about HDHRs we can safely say that the dropping
does not happen at the transmit side, since this would point to a design
flaw on the part of SD (namely an underdimensioning of the Ethernet
port). My 4-port HDHR has a 100Mbit/s Ethernet interface which is still
dramatically under-utilised when 4 HD DVB-C recordings are in progress.

So this is about the network in between the tuners and the backend. And
you go on to hope that the silicon used in today's consumer-level
switches supports DSCP these days, and I'm afraid that this is simply
not the case. That was my point.

In practice users will need to design their networks such that there is
no overload on the network path between network tuners on the one hand
and the mythtv backend on the other. The easiest way of doing that is to
connect the network tuner to a separate network interface on the
backend, i.e. not to put the network tuner on the LAN at all. The
second-best approach is to apply ingress traffic shaping to the network
port on the backend such that aggregate ingress traffic from senders
other than the network tuners is capped. This provides backpressure to
incoming TCP flows. Doesn't help against UDP overload. Make sure
therefore that NFS is configured to use TCP rather than UDP, and the
same applies to other protocols that offer a choice of transport.

I don't do any of this because in practice I don't see packet loss on my
machinery. Not even during my weekly backup runs (a couple of which
involve backing up from NVMe SSDs in client devices to a SATA3-connected
spinning rust disk in the server. It could happen if a large file needs
to be transported, but this is mitigated by the amount of RAM the server
uses as a disk buffer.

BR, Jan