Re: [Xenomai-help] [RTnet-users] Xenomai/rtnet vs. 2.6.21 realtime preempt patch

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

M. Koehrer wrote:
> Hi Jan,
> 
>>> I have tried the latest 2.6.21 kernel + Ingo Molnar's realtime preempt
>> patch
>>> (see: http://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO)
>>>
>>> And I am really amazed about the results.
>>> On my Pentium 4D (dual core) system, 3.2 GHz, I ran the cyclictest
>>> application (which is something similar to the "latency" application of
>> Xenomai/RTAI)
>>> and I get values below 15 microseconds on my PC (for a single task running
>> with 200 microseconds).
> ....
>>> Currently, my application is working quite nice using Xenomai/rtnet
>> however there are some
>>> drawbacks like the issue with limited IRQs: Sharing of IRQs between
>> Ethernet-Drivers of rtnet
>>> and non-realtime drivers is not possible (at least I did not manage
>> that...).
>>> A smooth usage of real time features from a "standard" kernel could help
>> here!
>>
>> Nope, not really. As I think to have explained earlier, IRQ sharing
>> between drivers that are designed for real-time and others that are not
>> will never work deterministically. That has nothing to do with the
>> design of your RTOS underneath. Actually, the same issue once came up
>> for -rt over some ARM board that did poor IRQ line sharing as well.
>>
>> Jan
> I agree, the best is actually to have separate IRQs for real time and non real time drivers.
> However, reality shows me, that this is very hard to get with standard PCs.

MSI? -- Oh, damn... ;)

> I can plug in one or two PCI boards to have an unique IRQ for them. However, if I want
> to use more PCI boards IRQ sharing cannot be avoided.

Agreed. Theory is nice, but practice often rules.

> As with the preempt patch, the duration of non-realtime IRQ routines seems to be fairly short.

You got it: "seems". This approach might be fine for some applications,
but not for all.

> From this, I think it is at least an option to share IRQs between real time and non real time drivers
> even if the IRQ routine of the non real time driver may lead to a delay of the real time IRQ routine.
> It is a question of acceptable delays for the IRQs.

It is a question of acceptable delays in the actual (analysed and
measured) worst case vs. "probable" (more or less blindly measured)
worst case. If you know the driver that will sit on the same IRQ line
like eg. your RT NIC, you can decide on a case-by-case analysis for each
kernel release if its behaviour is acceptable for your scenario. But
then you could also go the clean way and establish a trampoline for that
non-RT driver (as I suggested a few years back).

I more and more think we should try to formalise the latter procedure
and help system developers to realise this by modified or additional
features of the API (RTDM, I-pipe). I just had a private thread with
some other guy from industry about a related issue. I will try to wrap
up my latest "shiny" ideas and come back with a proposal next week or so.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]