Subject: Re: [linux-audio-dev] SCHED_FIFO versus SCHED_RR
From: dave willis (dubson_AT_dhammanet.net)
Date: Tue Nov 27 2001 - 12:28:44 EET
On Mon, 26 Nov 2001, Phil Burk wrote:
> It sounds like SCHED_RR is a bit more polite. I wouldn't want a monster
> synthesis thread to hog the CPU and lock out everything else. I guess with
> Round Robin that equal priority threads at least get a chance to run. I want
> equal priority threads to timeslice with my task.
what are you doing? i *would* (probably) want a monster synthesis thread
to lock out everything else if it happened to hog my cpu during the
operation (and not get stuck)- otherwise i'd be getting overruns. i did
some testing running latencytest and aplay (i added SCHED_FIFO and
SCHED_RR to aplay):
latencytest started with same or greater sched will cause aprox 100 ms
xrun on aplay. cpu_load does not matter, unless it's maxed then aplay
and latencytest will have huge xruns and both will be silent.
latencytest started w/ lower sched will not affect aplay. if cpu_load is
maxed aplay will be fine, but latencytest will have huge xruns and be
silent.
aplay started with same or greater sched will cause aprox 100 ms xrun on
latencytest.
aplay started with lower sched will not affect latencytest.
latencytest started with a high cpu load will cause standard aplay to
have frequent long xruns.
using SCHED_RR instead of SCHED_FIFO with same sched on both programs
can cause xruns on *both* programs.
so, with something like aplay, if i'm just playing something in the
background, an occasional short (but noticable) xrun is fine. but with
something like what latencytest is for (pd/jmax, other real-time synths,
etc), i don't want any other process messing it up (like aplay, network
traffic, cron scripts, etc). of course, i also don't want the program to
get stuck (but it will still freeze up everything if it's run at sched 1,
except for the higher scheduled tasks). SCHED_RR does not help at all if
a program is hogging the cpu. at best, it only seems to compromise the
performance of programs equally if they all have the same sched. i added
an exit for latencytest if the number of overruns gets too high (so i
don't lock up my system eternally). something like this could be done for
other programs as well. i think that's it. ;) i at least learned a lot
while testing, and added some nice options to aplay and latencytest in the
process.
-dave
--
perl -e'@email=split(//,".tenmhd\@nosbud");foreach$letter(@email){$
email=$letter.$email;}$email=~s/(m|net\.)/a\1\1/g;print"$email\n";'
This archive was generated by hypermail 2b28 : Tue Nov 27 2001 - 12:26:56 EET