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

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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Aug 30 08:15:01 2014