----- Messaggio originale -----
Da: "Gilles Chanteperdrix" <gilles.chanteperdrix@domain.hid>
A: "Michel Rinaldi" <automation.03@domain.hidmigroup.it>
Cc: xenomai@xenomai.org
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