On Mon, 2006-09-11 at 14:18 +0200, Serge Noiraud wrote: > Hi evrybody, > > I send this message last week and I had no response. I don't see it in the > archives, so I repost it. > > jeudi 7 Septembre 2006 15:01, Jan Kiszka wrote/a écrit : > > Serge Noiraud wrote: > > > Hi, everybody > > > > > > I'm new to this list and I have several questions : > > > > > > I currently use linux 2.6.16 + rt from Ingo Molnar + LTTng on IA32 > > > architecture. > > > > > > I would like to know how difficult will be the job to add Xenomai over > > > this. > > > Perhaps this is already in your roadmap ? > > > > It is, see yesterday's thread on this: > > https://mail.gna.org/public/xenomai-help/2006-09/msg00029.html > > > > LTTng will likely be supported far earlier. The nucleus is prepared for > > it for quite a while, we are currently just lacking a recent LTT+Ipipe > > combo patch. But this task is scheduled to start soon. See also this > > list's archive or xenomai-core on related discussions. > > > > > Do we need to wait for a main line inclusion of the RT patch ? > > > > > > > Not necessarily, though this would simplify things. > > > > However, any helping hand or mind can accelerate the process. So, > > contributions are welcome. What application scenario do you have in mind? > I take my machines on the shelves for economic strategy ! So they are > certainly *NOT* realtime aware ! > I think my RT knowledges aren't sufficient to help you in development, but I > can be a tester if you want. Plus if I can. > > I would like Xenomai manage IRQs for some specific cards. > The others could be managed by linux-rt. > If I understand correctly how it works, I must rewrite my drivers. is it > correct ? > > I currently get 50-60us latencies. This is not sufficient for me. I would > like to down to 10-15us for these cards. > and I have one latency every three days about 9000us ( BIOS or hardware > problem ? ).
For the 9ms spot, this might be something already listed in our TROUBLESHOOTING file in the ia32 section, regarding the kernel config / SMI sources. Most of the hints found there are applicable to any x86-based hw, whether it runs a co-kernel or native preemption. > So I hope Xenomai could be the solution. > > Am I in the good way ? If you cannot get better than 50 us with native preemption on your hw, yes, it seems so. As part of the Xenomai 3 effort, we have already planned to port our real-time nucleus over PREEMPT_RT without Adeos; in this mode, it would fully rely on the level of predictability native preemption gives, which would not help you that much for the issue you are facing, if I understand correctly. Xenomai would of course still be able to run as a co-kernel, but not in a PREEMPT_RT environment, only over a vanilla kernel like today. What you would need is a PREEMPT_RT+Adeos combo, on top of which Xenomai would run, still using the Adeos layer for getting stringent real-time guarantees. The good news is that we already prototyped a port of this kind a year ago, and it worked (e.g. you can still find some checks for CONFIG_PREEMPT_RT in the Xenomai codebase, which dates back to this attempt). The bad news is that the native preemption patch we used was fairly ancient, and was not stepping that much on Adeos toes at that time. In contrast, recent PREEMPT_RT patches do step on Adeos's toes, in significant areas. This means that an hybridization between PREEMPT_RT and Adeos is needed anew, but using a different approach than a mere side-by-side integration which would not fly anymore. Whether this combo should exist before or after PREEMPT_RT has been merged into mainline is another issue to solve, and likely depends on how fast the dust settles over the native preemption code. -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
