From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 25 Jan 2011 14:17:40 +0100 (CET) From: Michel Rinaldi Message-ID: <14122707.101295961457625.JavaMail.SYSTEM@PC-MRINALDI> In-Reply-To: <20964580.81295961364859.JavaMail.SYSTEM@PC-MRINALDI> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5_8621536.1295961457609" Subject: Re: [Xenomai-help] Problems with rt_task_create and rt_task_join List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org ------=_Part_5_8621536.1295961457609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Messaggio originale -----=20 Da: "Gilles Chanteperdrix" =20 A: "Michel Rinaldi" =20 Cc: xenomai@xenomai.org Inviato: Luned=C3=AC, 24 gennaio 2011 17:54:51 GMT +01:00 Amsterdam/Berlino= /Berna/Roma/Stoccolma/Vienna=20 Oggetto: Re: [Xenomai-help] Problems with rt_task_create and rt_task_join= =20 >Ok. Sorry, the rt_sem_p is actually waiting for the semaphore. So, for=20 >it to take a long time, the kernel module would have to post it all the=20 >time. In the kernel module, you should check rtdm_task_wait_period=20 >return value.=20 >=20 >Anyway, what I said still stands: if we suspect the application of being= =20 >the culprit, we should try and run a system without this application=20 >first. That is, only latency and some non real-time load.=20 I run a latency test for about 2 hours, in concomitance with two=20 dd if=3D/dev/zero of=3D/dev/null=20 commands and some sporadic ssh big file transfers. Last row in test output = was:=20 RTD| 6.546| 7.191| 10.346| 0| 0| 1.101| 29.508=20 Maximum latencies was obtained during file transfers.=20 With this result I think that I could assert that Xenomai works properly on= my system, is right?=20 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 dis= able SMIs) reports these results:=20 RTD| 11.353| 13.808| 31.264| 3| 0| 2.934| 231.539=20 I think high latencies are due to SMIs.=20 By the way, is there a reason why Xenomai does not disable SMIs on SCH chip= sets?=20 In past I tried to "patch" smi.c file with SCH identifier, but latency test= results make worse instead improve.=20 Thank you again=20 Mauro=20 ------=_Part_5_8621536.1295961457609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >
----- Messaggio originale -----
Da: "Gilles Chanteperdrix" <gill= es.chanteperdrix@domain.hid>
A: "Michel Rinaldi" <automation.03@domain.hid= migroup.it>
Cc: xenomai@xenomai.org
Inviato: Luned=C3=AC, 24 genn= aio 2011 17:54:51 GMT +01:00 Amsterdam/Berlino/Berna/Roma/Stoccolma/Vienna<= br>Oggetto: Re: [Xenomai-help] Problems with rt_task_create and rt_task_joi= n


>Ok. Sorry, the rt_sem_p is actually waiting for the semaph= ore. 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_t= ask_wait_period
>return value.
>
>Anyway, what I said sti= ll stands: if we suspect the application of being
>the culprit, we sh= ould try and run a system without this application
>first. That is, o= nly latency and some non real-time load.

I run a latency test for ab= out 2 hours, in concomitance with two
dd if=3D/dev/zero of=3D/dev/null<= br>commands and some sporadic ssh big file transfers. Last row in test outp= ut was:

RTD| 6.546| 7.191| 10.346| 0| 0| 1.101| 29.508

Maxim= um latencies was obtained during file transfers.
With this result I thin= k 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 chipset= s?
In past I tried to "patch" smi.c file with SCH identifier, but latenc= y test results make worse instead improve.

Thank you again
Mauro<= br> ------=_Part_5_8621536.1295961457609--