[mythtv] Reducing frontend startup time

[f-myth-users at media.mit.edu]

    > Date: Mon, 11 Jan 2016 09:43:03 -0500
    > From: Dan Wilga <mythtv-dev2 at dwilga-linux1.amherst.edu>

    > It's something to do with the TCP connection between the frontend and 
    > the backend getting dropped if the frontend machine is in S3 idle for 
    > too long. (Note that I said UDP in my original post; I just verified 
    > that it is TCP.)

That seems reasonable.  There are several ways this might happen,
and you may be able to configure them.  You may also be able to use
wireshark on the non-sleeping end, or a hub (or a smart switch that
can clone ports, but not a dumb switch) between them, to see what
the actual traffic looks like.

First, one end or both ends may be using TCP keepalives.  (ssh will
do this by default, for example, but you can turn it off.)  This will
typically cause your connection to die in about two hours, plus some
extra fuzz.

Also, assuming you turn that off, there are a couple different
timeouts that affect how long it takes a connection to die if you've
tried to send a packet to the other end and it hasn't been acknowledged.
You can configure how many retries it takes before the conn fails.
I have no idea if you might have even a single outstanding unacked
packet in either direction when your host sleeps, but it's possible.

(In other words, keepalives send traffic when there hasn't been any
traffic in a long time, and kill the connection if the keepalive
doesn't get acknowledged.  TCP timeouts notice if there -is- traffic
but the other end doesn't seem to be answering it.)

This assumes that taking the frontend out of sleep doesn't cause the
network stack to reset its network in some way, of course, which will
kill connections at its end regardless.  And that things like arp
don't forget mappings from Ethernet MAC addresses to IP addresses.

If you'd like some pointers as to which values you might try frobbing
with, say so, though I'm unclear whether either end can be configured
to not use keepalives if it is, because I don't know what software is
actually at either end of the TCP connection.  It might be a better
idea to explicitly reinitialize the TCP connection at both ends when
coming out of sleep, if you can arrange that.