[mythtv-users] Preventing a file transfer from saturating the network

[Gary Buhrmaster]

On Wed, Dec 24, 2014 at 6:49 AM, Neil Salstrom <salstrom at gmail.com> wrote:
....
> If theoretical speed on a gigablit lan is 125 MB/s what is real world?

Simple answer: It's complicated.

Less simple answer: In the real world, for likely home devices,
you need to be very careful if your sustained utilization exceeds
even a few percent due to microbursts and small buffers which
can drop packets (and even less with many dumb switches with
tiny buffers).  The problem is that you can easily get close to line
rate for a single point-to-point app with no other traffic, but when
you mix traffic, you can end up with drops due to the fact that at
any point, the packets (obviously) go out at line rate (usually in
a "burst" of packets), and if two sources send at the same time
(especially if one is near line rate), you can exceed the tiny
buffers in the typical home device, and something gets dropped
(and "the same time" is, of course, statistically likely in the long
run),  TCP handles losses with retry. UDP packets just get
dropped (in this usage).  If you have managed switches, you
can see the drops.  But with (most) managed switches, the
size of the buffers is a bit higher, so you might not see as many
drops.  And then, there are also buffers in the network adapter,
and the network stack in the OS.  Some tuning can sometimes
be applied (I typically set the sysctl net.core.rmem_default,
net.core.wmem_default, net.core.rmem_max, and
net.core.wmem_max values to be much higher than the default,
but even that cannot assure no losses).  QoS on managed
switches can also be used to mitigate against some impacts.
Dedicated networks/adapters are also a possible mitigation.
So is further separation of the BE from other services (the
more you throw on one system, the harder it is to tune it
well for all of the services).

A more complete answer: Will not fit in the margins of this
email :-)



Note that you can test any changes by using the
hdhomerun_config utility to save a stream to disk, run your
file transfer, and see if the hdhomerun_config utility shows
packet/segment losses.  I seem to recall that '.'s are good,
and 'n's show packet loss, and 's's show sequence errors.

Personally, I use QoS on my switches/routers, and
prioritize VoIP traffic, then my media traffic, and at the end,
the rest.  The hdhr sets a dscp of 32 as I recall (which I am
trusting at ingress), which (in my case) falls into queue 3,
and I see few (if any) drops for my VoIP (queue 4) and
media traffic (queue 3).  Without the QoS, I could easily
demonstrate loss of packets for the hdhr when sending
large files to my dedicated MBE.  Your mileage will vary.


Are you not glad you asked?