> How is this different from blowing a response deadline because
> another scheduled real-time task ate up so many system resources
> that the first one didn't get to execute by its deadline? As I
> understand it, if your CPU is too slow, it's too slow, and there's
> nothing you can do about it. I'm just proposing artifically `slowing
> down' the CPU.

The problem is that restricting a process from taking up more than 80%
of the CPU is not the same as slowing down the CPU.  If, say, you do
it over a one-second interval with a 100MHz CPU, then what an
application sees is a 100MHz CPU for 0.8 seconds and nothing for 0.2
seconds, not an 80MHz CPU.  If the aforementioned robot arm takes 0.1
seconds to punch through the wall and kill someone, then that's pretty
bad.

Now, if you prohibit a process from using more than 80% of the CPU
over a very short interval of time--1 microsecond, say--and your
real-time guarantees are only supposed to be accurate to 1 microsecond
anyway, then you're golden.  But that seems unlikely.