Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:
Good work. Looks like you're probably right about the accounting. It
may be as simple as the fact that it is on the timer tick that we're
getting rescheduled and this ends up being accounted as more since the
accounting happens only at the
Con Kolivas <[EMAIL PROTECTED]> writes:
> Good work. Looks like you're probably right about the accounting. It
> may be as simple as the fact that it is on the timer tick that we're
> getting rescheduled and this ends up being accounted as more since the
> accounting happens only at the scheduler
Jack O'Quin wrote:
The fact that the results did improve with the 90% setting suggests
that there may be a bug in your throttling or time accounting. The
DSP load for this test should hover around 50% when things are working
properly. It should never hit a 70% limit, not even momentarily. The
ba
> Jack O'Quin wrote:
>> The corrected version works noticeably better, but still nowhere near
>> as well as SCHED_FIFO. The first run had a cluster of really bad
>> xruns. The second and third were much better, but still with numerous
>> small xruns.
>>
>> http://www.joq.us/jack/benchmarks/sche
Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:
Sure enough I found the bug in less than 5 mins, and it would
definitely cause this terrible behaviour.
A silly bracket transposition error on my part :P
The corrected version works noticeably better, but still nowhere near
as well as SCH
Con Kolivas <[EMAIL PROTECTED]> writes:
> Sure enough I found the bug in less than 5 mins, and it would
> definitely cause this terrible behaviour.
>
> A silly bracket transposition error on my part :P
The corrected version works noticeably better, but still nowhere near
as well as SCHED_FIFO. T
Con Kolivas <[EMAIL PROTECTED]> writes:
> Jack O'Quin wrote:
>> Loading the realtime-lsm and then running with SCHED_FIFO *does* work
>> as expected on this kernel. I should retry the test with *exactly*
>> the expected patch sequence. What would that be?
>
> Sure enough I found the bug in less
Jack O'Quin wrote:
Loading the realtime-lsm and then running with SCHED_FIFO *does* work
as expected on this kernel. I should retry the test with *exactly*
the expected patch sequence. What would that be?
Sure enough I found the bug in less than 5 mins, and it would definitely
cause this terribl
Jack O'Quin wrote:
Con Kolivas <[EMAIL PROTECTED]> writes:
While it is not clear what form the final soft real time
implementation is, we should complete the partial implementation of
SCHED_ISO that is in 2.6.11-rc2-mm1.
I finally had a chance to try this today. I applied a slightly
different pa
Con Kolivas <[EMAIL PROTECTED]> writes:
> While it is not clear what form the final soft real time
> implementation is, we should complete the partial implementation of
> SCHED_ISO that is in 2.6.11-rc2-mm1.
I finally had a chance to try this today. I applied a slightly
different patch (2.6.11-r
While it is not clear what form the final soft real time implementation
is, we should complete the partial implementation of SCHED_ISO that is
in 2.6.11-rc2-mm1.
Thanks to Alex Nyberg and Zwane Mwaikambo for debugging help.
Cheers,
Con
This patch completes the implementation of the SCHED_ISO sch
11 matches
Mail list logo