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

Mark Frey markfrey at fastmail.fm
Thu Dec 18 01:46:10 EST 2003


Okay, the patch I posted had a small yet apocalyptic bug in it. I'm testing
the fix, and the file transfer stuff, and will post a new patch when I'm
more sure it won't blow up in my face again. Until then, don't use the
previously posted patch. Sorry.

-Mark

Mark Frey wrote:
>Okay I've attached a patch based on a little of what I had done and a
little
>of what avalanche posted earlier.
>Essentially this allows block requests of arbitrary size between the
>remotefile code and the backend.
>
> Bruce Markey wrote:
> >> 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.
>
> My hardware is hard-drive-throughput limited, so starving the read thread
> hurts performance for me. I measure net hard drive throughput (bytes read
by
> the read ahead thread over time) and I lose about 15% with the
sched_yield()
> in there.
>
> >On the very first attempt, it paused several times and failed
> >within 20sec.
> >
> >Frontend:
> >
> >2003-12-17 18:05:39 Connecting to backend server: 192.168.0.35:6543 (try
1
> of 1)
> >2003-12-17 18:05:44 Opening OSS audio device '/dev/dsp'.
> >2003-12-17 18:05:44 Using XV port 111
> >2003-12-17 18:05:44 Changing from None to WatchingPreRecorded
> >2003-12-17 18:05:50 prebuffering pause
> >2003-12-17 18:05:53 prebuffering pause
> >2003-12-17 18:05:54 prebuffering pause
> >2003-12-17 18:05:56 prebuffering pause
> >2003-12-17 18:05:57 prebuffering pause
> >2003-12-17 18:05:59 prebuffering pause
> >2003-12-17 18:06:00 prebuffering pause
> >2003-12-17 18:06:03 prebuffering pause
> >2003-12-17 18:06:03 RemoteFile::Read() failed in RingBuffer::safe_read()
> >2003-12-17 18:06:04 Changing from WatchingPreRecorded to None
> >2003-12-17 18:06:04 Changing from None to None
> >
> >Backend:
> >
> >2003-12-17 18:05:43 MainServer::HandleAnnounce Playback
> >2003-12-17 18:05:43 adding: nordtv as a client (events: 0)
> >2003-12-17 18:05:43 MainServer::HandleAnnounce FileTransfer
> >2003-12-17 18:05:43 adding: nordtv as a remote file transfer
> >2003-12-17 18:06:03 ****Aborting WriteBlock
> >
> >Other attempts did better but I haven't been able to run for
> >more than a couple minutes without playback exiting on a false
> >EOF.
> >
> >I also noticed that seeks are considerably slower so I did
> >a test to see how long it takes to skip forward in a one hour
> >remote file. The fast forward amount was set to 30 so there
> >would be about 120 seek to get through the file. However, on
> >four attempts I never got all the way through without a Read()
> >failed in RingBuffer::safe_read(). The closest I got was 54min
> >in 1:46. Without the patch it took 49 seconds to make it to
> >the end of the file so seeks with the patch take more than
> >twice as long.
>
> To quote your earlier post: Bummer.
>
> This may be a problem with the file transfer stuff, which as I indicated
in
> my message I wasn't sure how to test. Isaac gave me a pointer for that, so
> let me look at it and hopefully that is the root of the problem when
> frontend machine != backend machine.
>
> Out of curiosity, did you try watching live tv? That code path is tested
> better, I would be curious if you see the same issues.
>
> Thanks alot for testing this for me.
>
> -Mark
>



More information about the mythtv-dev mailing list