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

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.

Reply to
ih8sp4m
Loading thread data ...

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

Do not think so - there has been quite some work to make it behave... (Now) when it has stabilized someone might backport 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...

(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.

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

For an example with a 1GHz Pentium III (under heavy load) see:

formatting link
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Ƅ
 Click to see the full signature
Reply to
Roger Larsson

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

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

Reply to
Michael Schnell

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.

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

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.

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.

Reply to
ih8sp4m

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

-Michael

Reply to
Michael Schnell

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.