Re: [LAU] i5 Hyper-Threading, BIOS settings and Arch n00b pointers

On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise wrote:

> Seems that 3.14 has also added a deadline-based scheduler that is
> closer to what audio needs from realtime than the extremely low
> latency preemption based on priorities that the two older realtime
> schedulers offer.
>
> http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-scheduling-314

Not really.

I went to a workshop on this some weeks ago, with presentations
by the author(s) of this deadline scheduler.

I presented a short intro to Jack, what it does and how and why,
with the aim to enable a discussion on if the deadline scheduler
would be a good solution for running a dynamic set of audio apps.
The conclusion was that (apart from some specific uses in e.g.
drivers) it was not designed to solve this type of problem, and
it would quite difficult to use it in such a context.

The new scheduler is designed to run a set of periodic tasks,
with arbitrary periods and having few or no dependencies between
them, at up to 100% CPU usage, while meeting their deadlines.

Rate-proportional scheduling (shorter period -> higher priority)
can only do this up to 69% CPU use, except in some special cases
such as all periods being equal or having simple integer ratios
between them.

The situation with a set of audio apps running under Jack (or
something similar) is very different: the order in which they
have to run depends on their connections.

Another problem with the deadline scheduler as implemented is
that you can not overcommit CPU use. If P_i is the period of
task 'i' and T_i its running time, then Sum_i { T_i / P_i }
must be smaller than the number of CPUs available to the
scheduler. This is enforced by the API, where T_i, P_i and
D_i (the relative deadline) are parameters. If a task ever
tries to take more than its T_i, it will be interrupted and
have to wait until its CPU budget is updated, which will be
after a time P_i.

In fact, having tasks pre-empted like this is a very normal
way to use the scheduler. The idea is that each task should
get a defined share T_i of time in each period P_i, and meet
its deadline which is relative to the instant it becomes
runnable.

If on the other hand a task has to finish a defined amount
of work in each period (e.g process a period of audio because
others depend on the output), then its configured T_i must be
the absolute worst case time it could ever take to do that.
So to make this work with audio processes you need to *know*
their running time, and if these times are variable you must
use the worst case one. Which means that CPU use will be well
below 100%.

Ciao,

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user