From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4C234679.10209@domain.hid> References: <4C1B7EB1.2040006@domain.hid> <4C1B8C04.3010900@domain.hid> <4C1BCCBF.7010400@domain.hid> <1277330401.2453.145.camel@domain.hid> <4C234679.10209@domain.hid> Date: Thu, 24 Jun 2010 18:51:52 +0530 Message-ID: From: Nero Fernandez Content-Type: multipart/alternative; boundary=0016e64dbd929fb9410489c68905 Subject: Re: [Xenomai-core] Fwd: problem in pthread_mutex_lock/unlock List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org --0016e64dbd929fb9410489c68905 Content-Type: text/plain; charset=ISO-8859-1 Yes, the measurements are on no-load scenarios. I will try to repeat my measurements with system-loads as you suggest. Following is the cpu-info of my board: ---------------------------------------------------------- Processor : ARM926EJ-S rev 5 (v5l) BogoMIPS : 131.48 Features : swp half fastmult edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 5 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format : Harvard I size : 16384 I assoc : 4 I line length : 32 I sets : 128 D size : 16384 D assoc : 4 D line length : 32 D sets : 128 ---------------------------------------------------------- On Thu, Jun 24, 2010 at 5:20 PM, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org> wrote: > Nero Fernandez wrote: > > Thanks for your response, Philippe. > > > > The concerns while the carrying out my experiments were to: > > > > - compare xenomai co-kernel overheads (timer and context switch > latencies) > > in xenomai-space vs similar native-linux overheads. These are > > presented in > > the first two sheets. > > On what ARM system do you get these latency figures? I really doubt the > linux kernel has a bounded latency under 35us. Because: > - the preempt_rt people, which work on getting a bounded latency get > something around 200us on AT91, an ARM9; > - there would be no reason of the preempt_rt effort if the linux kernel > interrupt latency was already bounded. > > So, I take it that you do your measurement without generating a load. We > do our measurements using the latency test, while generating a load for > several hours. And on the average ARM, we usually get an interrupt > latency around 50us. > > Please add some load on the system, and do the measurments again. The > best source of load we have found so far is to load the LTP testsuite > while running the latency test. > > If you tell me what ARM SOC, or at least what ARM architecture revision > you use (the ARM920T core is an armv4, and the ARM926EJS is an armv5, so > ARM 9 does not tell us much), I can provide you with the root filesystem > we use for our tests. > > -- > Gilles. > --0016e64dbd929fb9410489c68905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, the measurements are on no-load scenarios.
I will try to repeat= my measurements with system-loads as you suggest.

Following is the = cpu-info of my board:
Processor=A0=A0=A0=A0= =A0=A0 : ARM926EJ-S rev 5 (v5l)
BogoMIPS= =A0=A0=A0=A0=A0=A0=A0 : 131.48
Features=A0=A0=A0=A0=A0= =A0=A0 : swp half fastmult edsp java
CPU = implementer : 0x41
CPU architecture: 5TEJ<= /span>
CPU variant=A0=A0=A0=A0 : 0x0
CPU part=A0=A0=A0=A0=A0= =A0=A0 : 0x926
CPU revision=A0=A0=A0 : 5
Cache type=A0=A0=A0=A0= =A0 : write-back
Cache clean=A0=A0=A0=A0 := cp15 c7 ops
Cache lockdown=A0 : for= mat C
Cache format=A0=A0=A0 : Harvard
I size=A0=A0=A0=A0=A0= =A0=A0=A0=A0 : 16384
I assoc=A0=A0=A0=A0= =A0=A0=A0=A0 : 4
I line length=A0=A0 : 3= 2
I sets=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 128<= /span>
D size=A0=A0=A0=A0=A0= =A0=A0=A0=A0 : 16384
D assoc=A0=A0=A0=A0= =A0=A0=A0=A0 : 4
D line length=A0=A0 : 3= 2
D sets=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 128<= /span>
-----------------------= -----------------------------------

On Thu, Jun 24, 2010 at 5:20 PM, Gilles Chanteperdrix &= lt;gilles.chanteperdrix= @xenomai.org> wrote:
Nero Fernandez wrote:
> Thanks for your response, Philippe.
>
> The concerns while the carrying out my experiments were to:
>
> =A0- compare xenomai co-kernel overheads (timer and context switch lat= encies)
> =A0 =A0in xenomai-space vs similar native-linux overheads. These are > presented in
> =A0 =A0the first two sheets.

On what ARM system do you get these latency figures? I really doubt t= he
linux kernel has a bounded latency under 35us. Because:
- the preempt_rt people, which work on getting a bounded latency get
something around 200us on AT91, an ARM9;
- there would be no reason of the preempt_rt effort if the linux kernel
interrupt latency was already bounded.

So, I take it that you do your measurement without generating a load. We do our measurements using the latency test, while generating a load for
several hours. And on the average ARM, we usually get an interrupt
latency around 50us.

Please add some load on the system, and do the measurments again. The
best source of load we have found so far is to load the LTP testsuite
while running the latency test.

If you tell me what ARM SOC, or at least what ARM architecture revision
you use (the ARM920T core is an armv4, and the ARM926EJS is an armv5, so ARM 9 does not tell us much), I can provide you with the root filesystem we use for our tests.

--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gilles.

--0016e64dbd929fb9410489c68905--