Mailing List Archive

On Friday 15 November 2002 10:53 am, rob wrote:
> Here's a patch to fix the block of code in NuppelVideoRecorder.cpp that
> has the comment "count free buffers -- FIXME this can be done with less
> CPU time!!" It just adds a member variable to the class that keeps
> track of the free buffers, instead of counting them in the loop every
> time in the function.

Unfortunately, this won't work as you'd think -- the two modifications to the
counter you added happen in different threads. And, especially the
modification to the counter in BufferIt() has the possibility of swapping to
the thread that's doing the doWriteThread() in between the two changes. So,
to do this properly, you'd have to lock down all access to that variable, and
that'd probably take more time than the current iteration through all
available buffers to count which are in use or not.

> Also, in what case(s) is it necessary to have the thread for writing
> data to the disk (ThreadedFileWriter)? The implementation is a ring
> buffer that has data added when Write() is called, then sending that
> data to the disk in another thread. Doesn't the write() system call
> just dump the data to kernel buffers, where it is written when it can
> be? The extra thread and memcpy's to implement the ring buffer stuff
> may not be necessary. I didn't notice any difference in performance
> when I removed all of the ThreadedFileWriter code and just had system
> write() calls.

It's useful for when you've got a slower disk and are using the rtjpeg codec.
If for some reason, there's a period of heavier disk usage caused by
something else on the system, and the recorded starts running out of free
video buffers, it used to just assume that that was because of a temporary
lack of CPU, and decide not to compress a frame in order to save a little CPU
time. If it _was_ due to a lack of disk transfer capacity instead, that'd
just make the problem worse. With the ThreadedFileWriter class, it can know
how full the buffers to write to disk are, and force compression of a frame
in that case.

Isaac

On Fri, 15 Nov 2002, Isaac Richards wrote:

> Unfortunately, this won't work as you'd think -- the two modifications to the
> counter you added happen in different threads. And, especially the
> modification to the counter in BufferIt() has the possibility of swapping to
> the thread that's doing the doWriteThread() in between the two changes. So,
> to do this properly, you'd have to lock down all access to that variable, and
> that'd probably take more time than the current iteration through all
> available buffers to count which are in use or not.

Rats! It would probably be quicker to just iterate through the buffers
each time than start locking with ever access.

>
> > Also, in what case(s) is it necessary to have the thread for writing
> > data to the disk (ThreadedFileWriter)? The implementation is a ring
> > buffer that has data added when Write() is called, then sending that
> > data to the disk in another thread. Doesn't the write() system call
> > just dump the data to kernel buffers, where it is written when it can
> > be? The extra thread and memcpy's to implement the ring buffer stuff
> > may not be necessary. I didn't notice any difference in performance
> > when I removed all of the ThreadedFileWriter code and just had system
> > write() calls.
>
> It's useful for when you've got a slower disk and are using the rtjpeg codec.
> If for some reason, there's a period of heavier disk usage caused by
> something else on the system, and the recorded starts running out of free
> video buffers, it used to just assume that that was because of a temporary
> lack of CPU, and decide not to compress a frame in order to save a little CPU
> time. If it _was_ due to a lack of disk transfer capacity instead, that'd
> just make the problem worse. With the ThreadedFileWriter class, it can know
> how full the buffers to write to disk are, and force compression of a frame
> in that case.

Hmmm.. So if someone has a system with a fast hard drive, lots of memory,
and it's dedicated to this task, they wouldn't need the extra thread.
But those people are the ones that wouldn't notice any slowdown anyway,
from the overhead of the extra thread.