21 Feb
2006
21 Feb
'06
9:49 p.m.
On Tue, 2006-02-21 at 19:30 -0600, Jan Depner wrote:
On Tue, 2006-02-21 at 15:28 -0500, Lee Revell wrote:
Hard RT is not about what the response time is, it's about whether you
can guarantee to make some arbitrary deadline, which the -rt patch can
theoretically do (I say theoretically because you still would have to
audit a limited set of code paths for RT safeness).
On Tue, 2006-02-21 at 13:19 -0600, Jan Depner
wrote:
While I agree that it's very good it's not hard real-time. It can't
do guaranteed 15 microsecond interrupt response. It is a very good soft
real-time system.
There's a bunch of information on that on my
site (albeit outdated).
Tuning the disk drives is a must and it *will* help but there are
instances where the disk drive is busy and you can't get to it no
matter
how well tuned it is. I prefer to minimize any chance of that. You
have to remember that unless you're running RTLinux or VXWorks (or DOS
or VMS) you're not running a hard real time system. Shit happens.
The -rt kernel with fuill preemption actually is a hard real time system
(no one claims it is in the same league of reliability as QNX or
VXWorks, yet...) - it should be able to guarantee response times.
Of course the
best RTOS in the world won't save you from apps that do
disk or GUI stuff in a non RT safe way, or from buggy ACPI
implementations that disappear the CPU out from under the OS for
milliseconds...
Yup. I hate it when that happens ;-)