--sched uses the SCHED_RR scheduling policy which allows Csound to
use up to 100% of CPU time, regardless of any other applications
running. Setting a nice level only changes the weighting of CPU time
between applications running at the same time, while a process
running with a real-time scheduling policy (SCHED_RR or SCHED_FIFO)
can take away the CPU from other "normal" processes (i.e. those with
a SCHED_OTHER policy) at any time, even locking up the system and
making it not respond to user input. Thus, --sched is more powerful
than renice, but is also dangerous and normally requires root
privileges.

The --sched option also has some parameters:

  --sched=N

    if N is positive, uses SCHED_RR with a priority of N (1 to 99).
    If N is zero or negative, uses SCHED_OTHER with a nice level of
    N (-20 to 0), but still locks memory.

  --sched=N,MAXCPU,TIME

    same as above, but also enables the use of an experimental
    "watchdog" thread that will terminate Csound if the CPU usage
    exceeds MAXCPU percents over a period of TIME seconds.
    This can save some reboots or uses of Alt+SysRq key combinations
    that may otherwise be needed when the CPU is maxed out.
    Example: --sched=95,97,10

On Wednesday 25 January 2006 19:11, David Akbari wrote:

> Since I know some people who lurk the list are savvy with computer 
> science I figured I'd ask the following question:
> 
> What is the difference between using the --sched flag on the 
> commandline vs. not using --sched and instead using renice for the 
> running Csound process ? (Other than the fact that --sched locks 
> memory)
> 
> something like
> 
> % sudo renice -20 -p <csound pid here>
> 
> I'm asking this in the abstract, I do not mean to pose questions that 
> would result in benchmarks - I am merely curious.