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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
