O(1) scheduler and premption patches versus realtime performance question.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi.

I am starting to develop with a Xscale PXA255 and doing some
prospection on alternatives for realtime with Linux.

I have read about montavista's rtpatch and learned they stopped
releasing new versions of its funcionality has become standard with
linux's own O(1) scheduler. From my understanding, this scheduler plus
the preemption patch makes linux rather deterministic at tens/hundreds
of microseconds.

One issue I have is I couldn't find recent patches for O(1) scheduler
for kernel 2.4 (I think they are maintained by Ingo Molnar). So the
first question is: has this scheduler been included into recent 2.4
kernels? Also does it work with ARMs as well as preemption one? (I
have got the impression this kind of stuff is aimed at x86
architecture.)

Also I would appreciate comments about using this approach versus RTAI
(and their LXRT/NEWLXRT derivatives). My application is not very
demanding regarding fast response (tens of microseconds are fine) and
I intend implement the few parts that need fast response as short
interrupt service routines.

Other comments and alternative approaches are welcome as well.

Thank you all for your help.

Elder.

Re: O(1) scheduler and premption patches versus realtime performance question.

Quoted text here. Click to load it

Montavista claims 2.5 microseconds average...
They have probably applied the lock break patch as well.

Quoted text here. Click to load it

Do not think so - there has been quite some work to make it behave...
(Now) when it has stabilized someone might backport it.

Quoted text here. Click to load it

Should work. It redefines the SMP spin locks to turn off/on preemtion.
But it is rather simple - inc and dec on a counter...

Quoted text here. Click to load it

(And RTLinux)

They put their RT handling between the hardware and Linux kernel.
+: Better than Linux interrupt latency!
-: The application is no longer a ordinary Linux process and can not
   use Linux services (filesystem, drivers), but you should avoid them
   anyway if you really care about RTed ness.

Quoted text here. Click to load it

Tens of microseconds (10E-6 s = 10us) are quite demanding!

For an example with a 1GHz Pentium III (under heavy load) see:
        http://www.linuxdevices.com/articles/AT7751365763.html
Average is _14 us interrupt response_, 132 us task response
Max is 181 us, 4508 us (4.5 ms) task response
This with a 2.6 based kernel. 2.4 based kernels are slower. Slower
hardware usually gives longer latencies (but some of the latency comes from
walking the pagetables, less memory might help... more might hurt...)

Why do your application require that? What will the rate of events be?
Can you buffer to get less demanding requirements?

/RogerL

--
Roger Larsson
Skellefteċ
We've slightly trimmed the long signature. Click to see the full one.
Re: O(1) scheduler and premption patches versus realtime performance question.
Quoted text here. Click to load it

Good to know that. Maybe it's worth looking more deeply at newlxrt ARM
port after all as we already have worked with RTAI/LXRT.

Quoted text here. Click to load it

OK. :-) Actualy some hundreds are still fine in our particular case.

Quoted text here. Click to load it

Not much. Acquisition rates up to 500Hz. Maybe I over(under)stated my
interrupt latency needs (up to 500us still quite acceptable). RTAI
people states (sub)us latencies depending on processor. From your
figures above I see it's due to HAL as Linux may keep interrupt
disabled waaaaay long.

Quoted text here. Click to load it

Actualy we are doing it as a microcontroller performs the real
acquisition and send it serially to the host. That's why hundreds us
is still acceptable and not affected by jitter due to interrupt
latency.

Thanks for the hints.

Elder.

Re: O(1) scheduler and premption patches versus realtime performance question.
Quoted text here. Click to load it

If its async, you might use a modern UART with 64 byte FIFO to allow for
a more relaxed timing.

-Michael

Re: O(1) scheduler and premption patches versus realtime performance question.
Quoted text here. Click to load it

"rather deterministic" is a very funny term, like "a little bit
pregnant" <g>.

Linux is not (and supposedly will never be) deterministic. If you want
this you need to add RTAI or something like that. So for hard realtime
(if something disastrous happens when a latency limit is not met), pure
Linux can't be used.

But Kernel 2.6 has been tested to reduce the measured (not the proven!)
maximum latency by a factor of some 30 (see some recent thread in this
forum). So for _soft_ realtime stuff (something undesired happens when a
latency limit is not met and this happening e.g. once a year is
acceptable), Linux with Kernel 2.6 seems to be a _very_ suitable OS.

This was achieved by improving the Kernel preemptibility greatly,
rewriting some nasty behaving stuff (like the IDE driver), the new
scheduler and some less obvious improvements.

-Michael

Site Timeline