[mythtv] [mythtv-commits] Ticket #2708: patch: Allow remote FE/BE to prefer to use the myth protocol

[Daniel Kristjansson]

On Tue, 2006-11-21 at 15:38 -0800, Bruce Markey wrote:
> Chris Pinkham wrote:

> "FWIW: My in experience streaming works far better...
>   ...several posts in the dev & users lists that suggest to
>   use streaming rather than nfs mounts."
> 
> "I am one that finds streaming via protocol better than
>   nfs mount."
> 
> They are both saying that serving the files from the backend 
> seems to work better than NFS. This is what I'd expect as the
> backend method can be application aware of the read ahead and
> block size needs. If we can't out-perform NFS then we're doing
> something wrong because nothing in NFS was designed with the
> needs of mythfrontend specifically in mind =).

I theory Myth streaming should perform as almost as well or
in some cases better than NFS when the file storage is local
to the backend, but in practice I've found NFS to be much better
at the task. Perhaps it's because NFS is in the kernel and
so doesn't add as much latency as Myth streaming. Or it could
be because it doesn't use TCP by default and so can transmit
the data with much less overhead and the Nagling doesn't
stop us cold when there is a dropped packet. Maybe there is
a bug or there are some really large timeouts in the Myth
streaming implementation. Whatever the cause, most of the times
I've had performance problems with MythTV it was because Myth
streaming was getting in the way. I haven't felt the motivation
to make Myth streaming actually work, since the work around
is so simple, don't use it.

> The block size used to be adjusted based on an estimated bitrate
> but that didn't turn out to work so well. What I'm thinking
> right now is that maybe the block size should be adjustable
> based on the demand for the read ahead buffer. Start small then
> grow the block size until the read ahead buffer stays above
> some level without having to request too often. This could make
> it use small blocks right after seeking then build in size after
> a few iteration during continuous playback.

Wouldn't this cause HDTV streams to always stutter at startup?
Or are you considering something that preserves state across
streaming sessions?

-- Daniel