[mythtv] Re: Solving my performance problems...

[Mark Frey]

On Sunday 14 December 2003 04:52 pm, ijr at po.cwru.edu wrote:
>On Sunday 14 December 2003 04:52 pm, avalanche at beyondmonkey.com wrote:
>> I just tried out a quick hack to test something similar. I'm requesting a
>> big packet (256k) and splitting it up in 64k packets for transmission,
>> similar to what you are doing. I'm grabbing the underlying QSocketDevice
>> from the backend's QSocket, that way the trasmission of the smaller
packets
>>
>should be very fast, close to network limits. Right now it only works up
>> to 265k blocks (limited somewhere else) but even bigger blocks shouldn't
be
>> a problem if necessary. This patch is just a very quick hack but it seems
>> to work, should make it possible for you to do some benchmarks. I only
>> tested this with livetv, not sure if recordings on a remote frontend use
>> the same code path.
>
>The live-tv sending path is in libs/libmythtv/tv_rec.cpp,
>RequestRingBufferBlock, remote frontend transfers go through mythbackend/
>filetransfer.cpp. There's a 256k limit in tv_rec's copy as well.

>Isaac

Okay I've attached a patch based on a little of what I had done and a little
of what avalanche posted above.
Essentially this allows block requests of arbitrary size between the
remotefile code and the backend.

I've tested on my setup (frontend and backend on the same machine) and I get
a large performance increase (I couldn't manage RTJpeg, quality = 170,
480x480 on live tv before, now I can do quality = 255, 704x480
stutter-free).

A few things:

1. I need someone to test on a setup with frontend machine != backend
machine and let me know if they have any problems (worse performance,
segfaults, etc.) I've added a couple of VERBOSE, VB_GENERAL messages to note
where timeouts occur in the new scheme, so let me know if you see any of the
following messages:
 Frontend messages:
     "socket error in RemoteFile::Read()"
     "No response from control socket in RemoteFile::Read()"
     "RemoteFile::Read() failed in RingBuffer::safe_read()"
Backend messages:
     "..end WriteBlock with false, error = %1"
     "****Aborting WriteBlock"
I'll remove these messages (or change them to VB_NETWORK as appropriate)
when/if I submit this patch.

2. Can someone give me some good scenarios to test the filetransfer code?
What are the various ways to initiate file transfers through the UI?

3. I've removed some of the qApp->lock()/unlock() pairs in RemoteFile, and
bypassed some by using WriteBlock(QDeviceSocket...) rather than
WriteBlock(QSocket...). I traced through the code and cannot see that these
serve any purpose other than to serialize a bunch of unrelated stuff on the
backend. I am prepared to be *completely* wrong about this. Does anyone know
of any purpose to these locks?

4. Similarly, I have removed a sched_yield() call from the end of
RingBuffer::ReadAheadThread(). Again I looked pretty carefully to see what
purpose this served, but other than sabotaging the scheduler and starving
the read thread of timeslice, I can't see that it accomplishes anything.
Perhaps on a machine heavily CPU limited this would help. Does anyone know
why this was added? Without it performance is much better (on my machine of
course, YMMV).

Please let me know if this causes anyone any problems, if not I'll submit it
as a [PATCH].

-Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: packet.diff
Type: application/octet-stream
Size: 16752 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20031217/d0ec03bc/packet.obj