[linux-dvb] Re: refactoring

[John Dalgliesh <johnd@defyne.org>]

On Mon, 18 Oct 2004, Gerd Knorr wrote:
>
> > > How do you check whether new data is available? Are you doing
> > > busy-polling on the write position? I wanted to wake up a
> > > poll()-waitqueue in the data-available irq, but maybe there are better
> > > ways...
> >
> > Well the thing is that there is almost always new data waiting (at least
> > on full-TS devices) so it's not really busy waiting. The user program just
> > gets a chunk of new packets, then does whatever it wants to them: writes
> > them to disk, sends them over the network, demultiplexes the PES for
> > decoding, etc.
>
> I doubt that this is true.  For example an application which does a
> channel scan wants to read just a few tables.  For 99% of the TS packets
> the "processing" is looking at the PID, noticing "oh, that one is not
> for me" and throw it away.  That will be fast enougth that the app has
> to wait for data.

Sure, that kind of app would likely wait for data. But it's not
particularly latency sensitive so it doesn't care...

> Even when decoding video that will be true, it takes around 10% CPU only
> on a modern desktop machine, so the app _has_ to wait at some point.  If
> it's not waiting for TS data then just because it's waiting somewhere
> else (before blitting the video frame to the screen to get the timing
> and a/v sync correct for example), not because the TS data is coming in
> fast enougth.

Hmm, yes, you are completely correct. If the processing is fast enough to
run on your machine then you will always catch up on the buffer until
either you reach some equilibrium if your overhead is greater than one
packet's time (chewing tons of CPU but with mega low latency), or if it is
less than one packet's time you will hit the sleep.

Yep, looks like I need to rethink this approach and maybe always wait
until some time/non-zero buffer size constraint is reached. Or at least
make it clear that it might be a good idea for apps to do so via some
artificial overhead if real processing time is too small. Thanks for
pointing out that very wrong reasoning! :)

>   Gerd
>
> --
> return -ENOSIG;

{P^/

btw 10% CPU? Much of the TV I watch takes ~140% CPU (on my dual G4) since
it is HD :D (but that doesn't change your point).