Re: [Xenomai-help] Problems with rt_task_create and rt_task_join

[Michel Rinaldi <automation.03@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]


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

[-- Attachment #2: Type: text/html, Size: 1968 bytes --]