[mythtv] Solving my performance problems...

Mark Frey markfrey at fastmail.fm
Sun Dec 14 00:57:51 EST 2003


I've been trying to track down performance problems with my machine and
MythTV. After spending some time instrumenting the code , and figuring out
what RingBuffer, RemoteFile, etc. are doing, I determined the following:

1. I'm not CPU limited (<50% cpu used)
2. I'm not HD bandwidth limited (<30% bandwidth used)

After timing some things I found that the bandwidth at the raw read(...)
level is very high (straight from the drive, hitting the cache most of the
time), the effective bandwidth at the RingBuffer::safe_read(RemoteFile *...)
call is very low, ~1.5 to 2.0 MB/s (the drive transfer rate is ~30MB/s
reads). It seems like the Qt event loop processing etc. is the bottleneck. I
know this is no big suprise, I read a post from Isaac in July where he said
as much. What I have been trying to do is figure out if there is some way to
improve this. I could go get a new hard drive, use a kernel with both the
low latency and preempt patches and possibly get things running acceptably
for my current uses, but I wonder whether any amount of hardware would
provide enough performance for HDTV given the current overhead of the whole
socket-request-response stuff.

The obvious way to minimize the event loop overhead is to ask for more in a
single request, amortize the overhead cost over more bytes. The problem is,
that because of the socket buffer size, requests are currently limited to
64000 byte blocks. I've been hacking away trying to raise this limit to
determine how much performance I can gain. I've managed to test 128000 byte
blocks, and it looks like the bandwidth at the safe_read level scales by
block size (to some limit obviously). With 128000 byte blocks my bandwidth
increases to ~4MB/s. The problem is things aren't stable with the changes I
made (I essentially request the larger size on the frontend side, then pull
from the socket when the data becomes available, while on the backend
pushing bytes in buffer-sized chunks and waiting for the buffer to clear,
until I've sent the total requested). I believe I understand some of the
causes of the instability, but before I spend the time to figure it out I
wanted to make sure I'm not wasting my time.

So, my questions are:

1. Am I misunderstanding something in a big way here? Is there some
fundamental reason this won't work (I am not a sockets expert)?
2. Am I wrong that the socket request stuff is the bottleneck?
3. Requesting larger blocks might be great for frontend/backend on the same
machine, but stink for networked machines. The request size might have to be
configurable in some way. Would this be acceptable?

-Mark



More information about the mythtv-dev mailing list