Hi Jan, On Tue, 2004-07-27 at 16:11, Jan Kiszka > Is there anything in xenomai which depends more on or interfers with the > linux kernel than the lxrt scheduler does?
I don't think so, but I suspect that some portions of the nucleus (basically the timer handler and the rescheduler) are more sensitive to bus contention (maybe more data moved, more code to be fetched, more cache-unaligned stuff, I don't know yet). Add to this that the nucleus is a pure Adeos implementation, the hw interrupts are almost never masked out, but only the Xenomai domain is stalled, which leaves room for performance degradation if the primary IRQ handlers preempt otherwise interrupt-free sections and need to fiddle with the x86 sluggish PIC in such situation, especially when we are talking about 50us latencies, and not ms level ones. LXRT happens to mask the IRQs at hw level sometimes for internal reasons thus bypassing the pipeline for a limited time. Maybe instrumenting the nucleus will prove that we must prevent hw preemption in some rare but useful cases too. Btw, unless I'm mistaken, Marc initially compared the LXRT-based user/latency running with a 10Khz period with a fusion based one running at 1Khz. This is not really fair: the more you allow Linux to trash the cache with a higher sleep delay, the more latency you will get to reinstate the test context. What would have been more appropriate is to run the POSIX test at 10Khz too (if it does not break, I mean :o), or downgrade the LXRT period to 1Khz. > What puzzles us is that the > hal (adeos), thus the interrupt shield, is identical... > Which is basically good news, isn't it? I mean: there is hope :o) More seriously, once the nucleus is stable with its new user-space support (and it seems it is reaching this state now, since you did not experiment any unbounded jitter), Gilles and I will focus on improving the inherent latency. I just want to clear all the stability issues first. I'll try to reproduce higher jitters on other machines I can put my hands on. > Jan > > > _______________________________________________ > Rtai-dev mailing list > [EMAIL PROTECTED] > https://mail.gna.org/listinfo/rtai-dev -- Philippe.
