> > A hard real-time can't say that because real-time isn't about
> > performance.  Real-time is about *predictable response time*, and
> > refusing to schedule a real-time task for some period of time just
> > because it has been busy means it will blow its response deadline.
> 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.

To emphasize Greg Hudson's point, to refuse to schedule a real-time process
for some time T because it has used up N consecutive scheduling slots means
that your real-time response is at best T; for typical times used in
schedulers, that's likely to be tenths of a second, which is useless in
nearly any actual real-time application.  As to the question of "too slow",
real-time programmers frequently do count instruction and clock cycles
so that they *know* what kind of budget they have.

And lastly,

> 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 said before, anyone who naively thinks they can put two uncoordinated
"real time" tasks on the same processor just doesn't understand real-time
systems.  If you have two real time tasks each of which needs a particular
guarantee of responsiveness, then you design them together to ensure that
both of their guarantees can be met.