>> I have worked on a real-time system with periodic processing deadlines
>> in sub-2 ms range. We did not have any problems even though we used
>> regular Linux (no real-time flavors).
[ Snip, good explanation of "hard real-time". ]
Quote:> I did some tests with Kernel 2.4 and the available low latency patches
> (that I think are included in Kernel 2.6).
Indeed they are. Here are some (experimental) for 2.6 though:
Quote:> I found that the soft real-time behavior was increased greatly by the
> patches: much more low time limit deadlines were met. But the hard
> real-time behavior was not improved at all: there were still _some_
> >100msec deadlines that were missed.
That probably depends on general load (and for real-time it shouldn't...)
But some monitoring device most likely runs off of ramdisk, and doesn't
have APM / ACPI power management, or any other kernel-task that may keep
it busy (for instance "kswapd" can also be disabled).
Quote:> The test was done using a high priority process with real-time
> scheduling while heavy file copying on an IDE drive was done with a
> normal process.
I have read about some test like that on a lo spec machine. I think some
serial connection started dropping frames while under load. Hence a "ping"
flood over null-modem SLIP connection might be a good test too.
Quote:> AFAIK the bad boy is the IDE driver. AFAIK, same is completely rewritten
> for Kernel 2.6
Well, i haven't realy been following the kernel list. However i don't see
it mensioned in the haloween file:
Quote:> and thus the real-time behavior is supposed to be improved a lot.
Some article (on linuxdevices.com IIRC) sugested it is. But IIUC it's
the i/o scheduler that's much improved, rather then the device driver:
Quote:> Nonetheless there is no _guarantee_ that a deadline of > xx seconds is
> met, and thus Linux is not a hard real-time system.
But it can be patched with "rtirq" on intel.
Or run on top an executive like: RTLinux, RTAI