On Mon, 2006-10-30 at 15:15 +0100, M. Koehrer wrote: > 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. >
On such hw, you may want to enable the following: CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_AUTO=y > 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. > You could try running RTAI 3.3 over 2.6.17 with the very same config file too (Xenomai opts aside, of course), so you could rule out any configuration problem if the gap still exists. > 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 -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
