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

[Bruce Markey]

Mark Frey wrote:
> 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:
...
> 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.) ...

Will do.

> 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?

Take a look at the channel icons. I think remote frontends
use this to copy missing station logos from the master.

> 4. Similarly, I have removed a sched_yield() call from the end of

Bummer.

> RingBuffer::ReadAheadThread(). Again I looked pretty carefully to see what
> purpose this served,

It's kind of invisible ;-)

> but other than sabotaging the scheduler and starving
> the read thread of timeslice, I can't see that it accomplishes anything.

Whoo-hoo! Cool! 

Seriously, the only thing that is truly time critical in the
frontend during playback is when Show() is called during the
video output loop. If this is late and the frame timing is
uneven, there will be jitter. The jitter problem isn't just
figuring out when the next frame should be drawn but how to
have the best chance of acquiring the CPU at the time when the
frame needs to be drawn.

The reason I put this sched_yield() here is because it is at
a point where the work has been done for now and there is nothing
time critical at this point so there is no reason it should hold
the CPU. So in a way, this is kind of like "nice"ing this thread
to give the video output loop a better chance or if there is a
backend doing software encoding, give it a better chance of
grabbing new frames on time.

If the CPU isn't pegged, everything will run and keep up with
it's work. It's just the things that have critical timing that
need a little extra advantage.

So yes, this is here to sabotage the scheduler and starve the
read thread of timeslice. Well put ;-).

> 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).

Not sure how you are gaging performance. For me it didn't
increase CPU load or anything like that but it did reduce
jitter. If you have some metric where there is clearly a
negative impact I'd certainly like to look into it.

--  bjm