Re: [LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

On Tue, Jun 23, 2009 at 6:19 PM, Fernando Lopez-Lezcano&lt;nando(a)ccrma.stanford.edu&gt; wrote: that is hilarious :) this seems deeply odd. i am also in that same situation. it seems that something *must* be overriding it, but what? yeah, i note that in the second bug report there, peter z. makes some comments about RT scheduling that are not entirely accurate for our use case. we are aiming at deterministic behaviour by each client in a JACK graph, but we don't actually expect determinism across time (e.g. as clients are started and stopped). we're happy to eat 95% of the CPU time, even if we generally expect the typical figure to be more like 10%. this tends to force JACK towards a cgroup that has a perhaps unreasonably large allocation, and a misleading one. AFAICT, the Sum(all cgroup runtime) cannot exceed the rt sched period. So you cannot set things up to allow "JACK" to get 95% and <other RT stuff> to get 95% and just have stuff break if you try to do both. this is good and bad - its an accurate reflection of resource reservation policy, but it doesn't actually reflect what a regular user may want - running two RT subsystems at different times without reconfiguring their cgroups. of course, i have no idea what those two RT subsystems might be, so its a bit moot.