Hi Philippe, I have rebuild my system using V2.2.4 of xenomai. Also, I had a look to reuse the kernel configuration from the 2.4.33 RTAI system. However, the results are more or less the same. The only kernel module I have loaded is the "tg3" network driver, the chipset of the PC (ICH6) is supported by the SMI detection and it is activated.
I have enclosed my kernel configuration, perhaps this can help to identify an issue. I do not have X11 running, it is a text-mode only system that is controlled via telnet from another PC. I'll try to do a stress test on the RTAI system as well. Regards Mathias > > 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. > > > > My question is now: Why can there be such a huge difference between the > two systems on the very same > > hardware?? > > Is there a way to improve this value? > > > > The RTAI system uses a 2.4.33 kernel, the XENOMAI uses the 2.6.17.7 > kernel. Could this > > be an issue? > > > > Several issues there: > > - are you 100% sure that your kernel config file for 2.4.33 is perfectly > recycled for 2.6.17, e.g. are all latency killer options as listed in > the TROUBLESHOOTING file really disabled? P4 configurations are > jitter-prone; some options are know to induce bad latencies. > > - worst-case figures do not depend on how fast you get them, the latter > information gives you nothing to interpret from. You may want to stress > test the box for a longer period of time, using things like e.g. a dd > loop, and a compilation in the background (dd if=/dev/zero of=/somefile > count=500 bs=1M). "ping" network test is not the worst latency raiser, > actually, under some circumstances, it could even hide some latency > issues, basically because it favours the code locality in i-cache. Also > make sure to measure without X-window interaction in both cases; some > graphic card drivers induce latencies, some don't. YMMV. > > This said, 40us on a P4 class machine is not an expected value for > Xenomai/x86. To give you some reference figures, I have a uniprocessor > 2.8Ghz Xeon box (no HT) performing at 15 us worst-case, and an older > dual 2.4Ghz Xeon SMP which honours 25 us worst-case in SMP mode. Fact is > that to get that, I need to disable a number of ACPI options (except > those which are needed to boot properly in SMP mode), and activate the > SMI work-around. > > And above all, a good starting point would be to send your kernel > configuration file, so that we could discuss about facts. Additionally, > you may want to upgrade to 2.2.4; 2.2.3 has a FPU issue on some hw. > -- Mathias Koehrer [EMAIL PROTECTED] Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 44,85 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2
config_linux_2.6.17.7.gz
Description: application/octetstream
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
