On 30/08/14 02:01, Fons Adriaensen wrote:
On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise wrote:
that's interesting, it seemed promising at first ... so this is for
being certain that particular and predictable sized tasks will get
scheduled in time for their own individual deadlines, and I guess
finding out immediately that something can't be guaranteed
Yes. On a single CPU machine, if the API accepts your parameters
(the condition involving the P_i and T_i is satisfied), then in
theory things should work up to 100% CPU. In practice a bit less,
due to implementation losses. The strange thing is that the same
algorithm can not provide the same guarantee on multi-CPU systems.
All it can do in that case is provide an upper bound on by how
much deadlines will be missed. There seems to be no solution for
this somewhat counter-intuitive result.
while on a single core machine there isn't a problem with dependencies in DSP
either ... audio is easier ... there is enough time to finish it all, or there
isn't.
Yes, it's those dependencies and the fact that the whole set of tasks
has a common deadline instead of each an individual one which doesn't
fit into the scheme. It's really meant for e.g. servers which should
use a well defined percentage of the time for each of a number of tasks.
Meeting the deadlines is in fact not the end, but the means by which
this is achieved by the new scheduler.
so multicore DSP scheduling is something like dependency based boot scheduling
... that has taken a lot of effort.
The most common case in our world is all tasks having the same period.
Then you schedule them on their dependencies, and nothing else. The
exception would be algorithms such as used in zita-convolver in which
part (or even most of) the work is done in larger periods, which are
all an exact multiple (even power of 2) of Jack's one. Rate-monotonic
scheduling (giving the tasks with larger periods lower priority) works
very well in that case, up to full CPU usage, provided all app use the
same mapping from period size to priority.
so a potential use for this scheduler in audio would be if we have a non-DSP
task which does not take a big part of the processing overall but that must keep
up to date, and should not be left to the last moment leaving it all in one
sample period potentially causing a DSP glitch.
Something like dealing with the control inputs or the feedback required to play
an instrument where responsiveness and lack of jitter are really important.
Then while the DSP threads are running with real-time priority we can still
guarantee an allocation of a steady but strictly limited amount of processing
time for the critical parts of perhaps midi or automation which is evenly spread
over the DSP periods. Maybe also making sure some particular aspects of the GUI
are always updated even when most of it slows down if the DSP load gets too high.
Simon
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
