[mythtv] [PATCH] Increase block size

[Bruce Markey]

Mark Frey wrote:
> As per the "Solving my performance problems" thread, here is the patch 
> that allows for block sizes greater than 64000 bytes. In this case I've 
> set the block size to 256000 bytes. I've tested this on a frontend == 
> backend machine, and thanks to Bruce this has also been tested for the 
> frontend != backend case.
>  
> My machine is limited by throughput and this patch helps me a great 
> deal, YMMV, but I don't believe it will hurt anyone's performance.

Mark, as you know, I did test that it does work for different
configurations and we hashed out some details off line. However,
I was focusing on the fact that it did work and didn't really
look at how it worked until today. A few questions come to mind.

I the existing code, there is the concept of requestedbytes that
sends REQUEST_BLOCKs ahead of time so the pipeline is always
moving. It appears that in RemoteFile::Read a request is sent,
it waits to read that data then the network is dormant until
the next Read. Is this correct? It may be okay but it seems
less efficient.

Part of av's QSocketDevice patch is that he needed to stay
below a limit of about 130k somewhere. However, I see you
are sending and receiving 256000 blocks. How is it that this
isn't a problem?

Before the QSocketDevice patch the block size was variable
based on estbitrate. On low bitrate data, waiting to complete
large blocks can add unnecessary latency. This may be easy to
fix by changing using the block size calculations from a few
versions back.

I guess what I expected to see was a separation of the reqsize
(fixed at 64000) and the readblocksize (variable from 64000 to
256000 or higher if needed in the future). safe_read(rf,...
would read 256000 per iteration but the underlying gunk would
use requested bytes and 64000 REQUEST_BLOCKs to suck in the
data. I think I'll this a shot and send a proposed patch if
it works out okay.

--  bjm