[mythtv-commits] Re: Ticket #551: blocking in ThreadedFileWriter
MythTV
mythtv at cvs.mythtv.org
Tue Nov 8 17:56:30 EST 2005
#551: blocking in ThreadedFileWriter
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner: danielk
Type: defect | Status: assigned
Priority: major | Milestone: 0.19
Component: mythtv | Version: head
Severity: medium | Resolution:
-----------------------+----------------------------------------------------
Comment (by danielk):
Hmm, I don't believe my glitches are coming from the threadedfilewriter.
I added some instrumentation on DVBRecorder::ReadFromDMX(), so that it
prints out anytime this takes longer than 2 ms. What I got was mostly
boring.
{{{
2005-11-08 17:47:45.489 ReadFromDMX took 3 ms
2005-11-08 17:47:45.500 ReadFromDMX took 4 ms
2005-11-08 17:47:45.509 ReadFromDMX took 3 ms
2005-11-08 17:47:45.519 ReadFromDMX took 3 ms
2005-11-08 17:47:45.528 HandleKeyframe()
2005-11-08 17:47:45.528 SavePositionMap()
2005-11-08 17:47:45.529 ReadFromDMX took 3 ms
2005-11-08 17:47:45.539 ReadFromDMX took 4 ms
}}}
All this would indicate that we should probably double the default buffer
sizes.
But once in a while you get something like this:
{{{
2005-11-08 17:47:46.045 ReadFromDMX took 3 ms
2005-11-08 17:47:46.052 HandleKeyframe()
2005-11-08 17:47:46.052 SavePositionMap()
2005-11-08 17:47:46.081 find keyframes took 29 ms
2005-11-08 17:47:46.099 ReadFromDMX took 47 ms
2005-11-08 17:47:46.105 ReadFromDMX took 4 ms
2005-11-08 17:47:46.114 ReadFromDMX took 4 ms
}}
So it looks like we are blocking on database saves, not disk writes..
And this is way bigger than the DVBRecorder 8KB buffers, which allow
ReadFromDMX() to take up to 3.4 ms without the chance of an overflow..
The HDTVRecorder is not affected by this because it grows it's buffer
when something like this happens.
--
Ticket URL: <http://svn.mythtv.org/trac/ticket/551>
MythTV <http://www.mythtv.org/>
MythTV
More information about the mythtv-commits
mailing list