Subject: Re: Floating point in the kernel
To: Curt Sampson <email@example.com>
From: John F. Woods <firstname.lastname@example.org>
Date: 09/21/1998 21:23:21
> > 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.
> 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.