----- Messaggio originale ----- Da: "Gilles Chanteperdrix" <[email protected]> A: "Michel Rinaldi" <[email protected]> Cc: [email protected] Inviato: Lunedì, 24 gennaio 2011 17:54:51 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna Oggetto: Re: [Xenomai-help] Problems with rt_task_create and rt_task_join
>Ok. Sorry, the rt_sem_p is actually waiting for the semaphore. So, for >it to take a long time, the kernel module would have to post it all the >time. In the kernel module, you should check rtdm_task_wait_period >return value. > >Anyway, what I said still stands: if we suspect the application of being >the culprit, we should try and run a system without this application >first. That is, only latency and some non real-time load. I run a latency test for about 2 hours, in concomitance with two dd if=/dev/zero of=/dev/null commands and some sporadic ssh big file transfers. Last row in test output was: RTD| 6.546| 7.191| 10.346| 0| 0| 1.101| 29.508 Maximum latencies was obtained during file transfers. With this result I think that I could assert that Xenomai works properly on my system, is right? In facts, same test (only without file transfer) under another system with 1GHz Intel Atom on a SCH (Poulsbo) chipset (not supported by Xenomai to disable SMIs) reports these results: RTD| 11.353| 13.808| 31.264| 3| 0| 2.934| 231.539 I think high latencies are due to SMIs. By the way, is there a reason why Xenomai does not disable SMIs on SCH chipsets? In past I tried to "patch" smi.c file with SCH identifier, but latency test results make worse instead improve. Thank you again Mauro
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
