M. Koehrer wrote: > Hi Jan, > > thanks for your reply. > >>> I am currently checking XENOMAI (V2.2.3 on a 2.6.17.7 kernel P4) to see if >> I can use it >>> as replacement for a RTAI 3.3-cv application. >>> The first thing I did was to run the latency test in the the xenomai's >> testsuite directory. >>> The results of the worst time latency are really ugly - about 40µs! >>> On the very same PC I got a value of about 5µs using RTAI 3.3-cv running >> the RTAI's >>> user/latency test. >> I'm _very_ sceptical about your 5 us. Could you elaborate on how you >> load your box and how long those tests ran? See also TROUBLESHOOTING in >> the Xenomai source tree on appropriate load for triggering the worst case. > > My test setup was the same in both cases. > I connect to the RTAI/Xenomai PC via telnet and let the latency test run for > about 5 minutes.
5 min. are far too short. It takes a while to "arrange" the worst case, i.e. a dirty cache, one unrelated IRQ or atomic section running while the timer (or any other event of interest) occurs, and then one or more further IRQs right after the woken-up task re-enabled interrupts. If you hit such scenario can be observed via the latency tracer (which has some impact on the numbers, but not on the structuring). > No other activity happens (well, there are a couple of services running like > apache, ... - but they should not cause any load). > The strange thing, is that in Xenomai even after a few seconds a latency in > the range of the > maximum latency is shown. Such a test on an unloaded system says almost nothing about a hard real-time system. > > I can retry the tests using a background stress situation. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
