[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga

[Denis Oliver Kropp <dok@directfb.org>]

Quoting Antonino Daplas (adaplas@pol.net):
> > You mean the interrupt?  The signal will always arrive at the right
> > time.  The kernel may not deliver the interrupt for some time after
> > the signal arrives however.
> > 
> Yes, the time interval from the arrival of the interrupt signal, waking
> up the process, returning from the ioctl call, to processing the
> registers.  That was what I meant.
> 
> Sleeping while waiting for an interrupt to arrive is very nice because
> it gives the CPU to another process.  Very good for systems where CPU
> power and thoroughput is important.  But this is not appropriate if the
> process needs to get the signal immediately, or at least timely, manner.
> The problem with this is during the wake_up().  Whether the process
> wakes up now or a few hundred milliseconds later depends on so many
> factors which the process nor the kernel can control. IE.  If at the
> time of waking up, the current process using the CPU was not a nice
> player and it won't give back the cpu to the kernel, you get delayed. 
> If there are a lot of tasks waiting to wake up ahead of you, you get
> delayed more.  And if each of these tasks waiting ahead of you awakes,
> each will take a few more precious CPU cycles to process what it was
> sleeping for, and you get delayed more and more.  And there is nothing
> the kernel can do, because it cannot preempt. 
> 
> The worst part is that that each time you sleep, the time you actually
> wake up will not be constant. It's actually better to have high, but
> regularly timed latency, than relatively small but irregularly timed
> latency. It's easy to compensate when latency is a known constant.
> 
> A lot of the latency problems are being solved in linux-2.5 (O(1)
> scheduler, preemption, workqueues, CPU affinity, punishing CPU hoggers,
> rewarding nice players, etc)
> 
> So, for things that are sensitive to latencies, you're better of polling
> the registers directly, even just for testing purposes.  Athough it
> increases CPU usage a lot, it will factor out the latency part.

Did you try sched_setscheduler (SCHED_RR) and
setpriority (sched_get_priority_max()) ?

I'm not sure if the process running during the interrupt occurs continues
after the handler, but I think our process is the next to run after waking
up.

-- 
Best regards,
  Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

                            Convergence GmbH


-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.