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

Simon Wise simonzwise at gmail.com
Sat Aug 30 02:39:46 UTC 2014


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


More information about the Linux-audio-user mailing list