[Xenomai-help] i386 2.4 backport performing (too?) well

[Xenomai-help] i386 2.4 backport performing (too?) well

[Klaas Gadeyne]

With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
flawlessly, and moreover, I got excellent latency results:

I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
which is based on Takis Issaris' liveCD config.

This resulted in a maximal latency of 30 usec after a run of over 100
minutes under heavy load (tar and dd loops, compiling, keyboard
interrupts and ping flood) [2].

For comparison, on the same hardware platform: 
- the RTAI lxrt-latency on rtai 3.0r5 (adeos oldgen r18c1
   patch for 2.4.31 also) test reports 38 usec
- the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
   kernel resulted in a latency of 80 usec.

This seems too good to be true?  Can one simply compare the results of
the former RTAI lxrt-latency test with the xenomai latency test?

Klaas

[1] <https://mail.gna.org/public/adeos-main/2005-11/msg00010.html>
[2] HW: a via mini-itx board,
     HW config at <http://issaris.org/rtai/show_entry.php?ts=2004-12-01+18%3A02%3A08%2B01>

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Jan Kiszka]

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

Klaas Gadeyne wrote:
> With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
> decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
> flawlessly, and moreover, I got excellent latency results:
> 
> I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
> which is based on Takis Issaris' liveCD config.
> 
> This resulted in a maximal latency of 30 usec after a run of over 100
> minutes under heavy load (tar and dd loops, compiling, keyboard
> interrupts and ping flood) [2].
> 
> For comparison, on the same hardware platform: - the RTAI lxrt-latency
> on rtai 3.0r5 (adeos oldgen r18c1
>   patch for 2.4.31 also) test reports 38 usec
> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>   kernel resulted in a latency of 80 usec.
> 
> This seems too good to be true?  Can one simply compare the results of
> the former RTAI lxrt-latency test with the xenomai latency test?

Mmh, I tend to be sceptical as well, also remembering the results
Wolfgang posted about 2.6 vs. 2.4 on low-end PPC
(https://mail.gna.org/public/xenomai-core/2005-11/msg00131.html).

Well, such worst-case improvement may be real if and only if there is
less *kernel* code in hard-irq-off sections with 2.4. The complexity of
adeos/ipipe and xenomai isn't changed between both scenarios.

But I rather think that 2.4 just stresses the caches less than 2.6, thus
is may be more tricky to trigger the real worst-case path. So, what we
already saw with PPC: 2.4 and 2.6 may likely show similar RT
performances under Xenomai, but the overall system performance is much
better on low-end! However, I would be happy if this theory is too
pessimistic.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Philippe Gerum]

Klaas Gadeyne wrote:
> With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
> decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
> flawlessly, and moreover, I got excellent latency results:
> 
> I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
> which is based on Takis Issaris' liveCD config.
> 
> This resulted in a maximal latency of 30 usec after a run of over 100
> minutes under heavy load (tar and dd loops, compiling, keyboard
> interrupts and ping flood) [2].
> 
> For comparison, on the same hardware platform: - the RTAI lxrt-latency 
> on rtai 3.0r5 (adeos oldgen r18c1
>   patch for 2.4.31 also) test reports 38 usec
> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>   kernel resulted in a latency of 80 usec.

80 us on 2.6 is clearly pathological if 2.4 gives 30 us. All tests using 
2.6.14-1.0-10 on dual SMP 750Mhz and 2.8Ghz, Geode 266 Mhz, Celeron 
1Ghz, Centrino 1.6 Mhz and Pentium 90Mhz show a slight advantage for 2.4 
over 2.6 (1-3%), but still in the error margin, I think. Maybe some 
option is enabled in your 2.6 configuration that might trigger this very 
high value?

> 
> This seems too good to be true?  Can one simply compare the results of
> the former RTAI lxrt-latency test with the xenomai latency test?
> 
> Klaas
> 
> [1] <https://mail.gna.org/public/adeos-main/2005-11/msg00010.html>
> [2] HW: a via mini-itx board,
>     HW config at 
> <http://issaris.org/rtai/show_entry.php?ts=2004-12-01+18%3A02%3A08%2B01>
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Klaas Gadeyne wrote:
> 
>>With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
>>decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
>>flawlessly, and moreover, I got excellent latency results:
>>
>>I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
>>which is based on Takis Issaris' liveCD config.
>>
>>This resulted in a maximal latency of 30 usec after a run of over 100
>>minutes under heavy load (tar and dd loops, compiling, keyboard
>>interrupts and ping flood) [2].
>>
>>For comparison, on the same hardware platform: - the RTAI lxrt-latency
>>on rtai 3.0r5 (adeos oldgen r18c1
>>  patch for 2.4.31 also) test reports 38 usec
>>- the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>  kernel resulted in a latency of 80 usec.
>>
>>This seems too good to be true?  Can one simply compare the results of
>>the former RTAI lxrt-latency test with the xenomai latency test?
> 
> 
> Mmh, I tend to be sceptical as well, also remembering the results
> Wolfgang posted about 2.6 vs. 2.4 on low-end PPC
> (https://mail.gna.org/public/xenomai-core/2005-11/msg00131.html).
> 
> Well, such worst-case improvement may be real if and only if there is
> less *kernel* code in hard-irq-off sections with 2.4. The complexity of
> adeos/ipipe and xenomai isn't changed between both scenarios.
> 
> But I rather think that 2.4 just stresses the caches less than 2.6, thus
> is may be more tricky to trigger the real worst-case path. So, what we
> already saw with PPC: 2.4 and 2.6 may likely show similar RT
> performances under Xenomai, but the overall system performance is much
> better on low-end! However, I would be happy if this theory is too
> pessimistic.

In the meantime I have measured latencies a few PowerPC systems with 
Xenomai 2.1 under Linux 2.4 and 2.6 and RTAI 3.0r5 (using RTHAL) under 
2.4. The latency figures for Xenomai compared with RTAI 3.0r5 are 
roughly a factor of two worse but I have not realized a significant 
difference between 2.4 and 2.6 (with Xenmomai, of course).

Wolfgang.

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Philippe Gerum]

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
> 
>> Klaas Gadeyne wrote:
>>
>>> With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
>>> decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
>>> flawlessly, and moreover, I got excellent latency results:
>>>
>>> I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
>>> which is based on Takis Issaris' liveCD config.
>>>
>>> This resulted in a maximal latency of 30 usec after a run of over 100
>>> minutes under heavy load (tar and dd loops, compiling, keyboard
>>> interrupts and ping flood) [2].
>>>
>>> For comparison, on the same hardware platform: - the RTAI lxrt-latency
>>> on rtai 3.0r5 (adeos oldgen r18c1
>>>  patch for 2.4.31 also) test reports 38 usec
>>> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>>  kernel resulted in a latency of 80 usec.
>>>
>>> This seems too good to be true?  Can one simply compare the results of
>>> the former RTAI lxrt-latency test with the xenomai latency test?
>>
>>
>>
>> Mmh, I tend to be sceptical as well, also remembering the results
>> Wolfgang posted about 2.6 vs. 2.4 on low-end PPC
>> (https://mail.gna.org/public/xenomai-core/2005-11/msg00131.html).
>>
>> Well, such worst-case improvement may be real if and only if there is
>> less *kernel* code in hard-irq-off sections with 2.4. The complexity of
>> adeos/ipipe and xenomai isn't changed between both scenarios.
>>
>> But I rather think that 2.4 just stresses the caches less than 2.6, thus
>> is may be more tricky to trigger the real worst-case path. So, what we
>> already saw with PPC: 2.4 and 2.6 may likely show similar RT
>> performances under Xenomai, but the overall system performance is much
>> better on low-end! However, I would be happy if this theory is too
>> pessimistic.
> 
> 
> In the meantime I have measured latencies a few PowerPC systems with 
> Xenomai 2.1 under Linux 2.4 and 2.6 and RTAI 3.0r5 (using RTHAL) under 
> 2.4. The latency figures for Xenomai compared with RTAI 3.0r5 are 
> roughly a factor of two worse but I have not realized a significant 
> difference between 2.4 and 2.6 (with Xenmomai, of course).

We still need to compare pure kernel-space executions since RTAI does 
not support user-space for PPC, but v2.1 does not provide the kernel 
space test yet, due to the build system refactoring. Still pondering how 
to introduce this back into the codebase.

> 
> Wolfgang.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Heikki Lindholm]

Philippe Gerum kirjoitti:
> Wolfgang Grandegger wrote:
> 
>> Jan Kiszka wrote:
>>
>>> Klaas Gadeyne wrote:
>>>
>>>> With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
>>>> decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
>>>> flawlessly, and moreover, I got excellent latency results:
>>>>
>>>> I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
>>>> which is based on Takis Issaris' liveCD config.
>>>>
>>>> This resulted in a maximal latency of 30 usec after a run of over 100
>>>> minutes under heavy load (tar and dd loops, compiling, keyboard
>>>> interrupts and ping flood) [2].
>>>>
>>>> For comparison, on the same hardware platform: - the RTAI lxrt-latency
>>>> on rtai 3.0r5 (adeos oldgen r18c1
>>>>  patch for 2.4.31 also) test reports 38 usec
>>>> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>>>  kernel resulted in a latency of 80 usec.
>>>>
>>>> This seems too good to be true?  Can one simply compare the results of
>>>> the former RTAI lxrt-latency test with the xenomai latency test?
>>>
>>>
>>>
>>>
>>> Mmh, I tend to be sceptical as well, also remembering the results
>>> Wolfgang posted about 2.6 vs. 2.4 on low-end PPC
>>> (https://mail.gna.org/public/xenomai-core/2005-11/msg00131.html).
>>>
>>> Well, such worst-case improvement may be real if and only if there is
>>> less *kernel* code in hard-irq-off sections with 2.4. The complexity of
>>> adeos/ipipe and xenomai isn't changed between both scenarios.
>>>
>>> But I rather think that 2.4 just stresses the caches less than 2.6, thus
>>> is may be more tricky to trigger the real worst-case path. So, what we
>>> already saw with PPC: 2.4 and 2.6 may likely show similar RT
>>> performances under Xenomai, but the overall system performance is much
>>> better on low-end! However, I would be happy if this theory is too
>>> pessimistic.
>>
>>
>>
>> In the meantime I have measured latencies a few PowerPC systems with 
>> Xenomai 2.1 under Linux 2.4 and 2.6 and RTAI 3.0r5 (using RTHAL) under 
>> 2.4. The latency figures for Xenomai compared with RTAI 3.0r5 are 
>> roughly a factor of two worse but I have not realized a significant 
>> difference between 2.4 and 2.6 (with Xenmomai, of course).
> 
> 
> We still need to compare pure kernel-space executions since RTAI does 
> not support user-space for PPC, but v2.1 does not provide the kernel 
> space test yet, due to the build system refactoring. Still pondering how 
> to introduce this back into the codebase.

As a silly off-hand remark, it would be nice to get rid of the "making a 
module" for the kernel space tasks and be able to use the same .c for 
both kernel and user space. Maybe a module loader stub as init and some 
linker magic would do the trick. Don't know about main(), though..

-- Heikki Lindholm

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Wolfgang Grandegger]

Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
> 
>> Jan Kiszka wrote:
>>
>>> Klaas Gadeyne wrote:
>>>
>>>> With the arrival of the 2.4 i386 adeos ipipe patch for xenomai [1], I
>>>> decided to try to compile xenomai-trunk for a 2.4 kernel. This worked
>>>> flawlessly, and moreover, I got excellent latency results:
>>>>
>>>> I used the "same" kernel config as for our 2.4.31 rtai3.0r5 kernel,
>>>> which is based on Takis Issaris' liveCD config.
>>>>
>>>> This resulted in a maximal latency of 30 usec after a run of over 100
>>>> minutes under heavy load (tar and dd loops, compiling, keyboard
>>>> interrupts and ping flood) [2].
>>>>
>>>> For comparison, on the same hardware platform: - the RTAI lxrt-latency
>>>> on rtai 3.0r5 (adeos oldgen r18c1
>>>>  patch for 2.4.31 also) test reports 38 usec
>>>> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>>>  kernel resulted in a latency of 80 usec.
>>>>
>>>> This seems too good to be true?  Can one simply compare the results of
>>>> the former RTAI lxrt-latency test with the xenomai latency test?
>>>
>>>
>>>
>>>
>>> Mmh, I tend to be sceptical as well, also remembering the results
>>> Wolfgang posted about 2.6 vs. 2.4 on low-end PPC
>>> (https://mail.gna.org/public/xenomai-core/2005-11/msg00131.html).
>>>
>>> Well, such worst-case improvement may be real if and only if there is
>>> less *kernel* code in hard-irq-off sections with 2.4. The complexity of
>>> adeos/ipipe and xenomai isn't changed between both scenarios.
>>>
>>> But I rather think that 2.4 just stresses the caches less than 2.6, thus
>>> is may be more tricky to trigger the real worst-case path. So, what we
>>> already saw with PPC: 2.4 and 2.6 may likely show similar RT
>>> performances under Xenomai, but the overall system performance is much
>>> better on low-end! However, I would be happy if this theory is too
>>> pessimistic.
>>
>>
>>
>> In the meantime I have measured latencies a few PowerPC systems with 
>> Xenomai 2.1 under Linux 2.4 and 2.6 and RTAI 3.0r5 (using RTHAL) under 
>> 2.4. The latency figures for Xenomai compared with RTAI 3.0r5 are 
>> roughly a factor of two worse but I have not realized a significant 
>> difference between 2.4 and 2.6 (with Xenmomai, of course).
> 
> 
> We still need to compare pure kernel-space executions since RTAI does 
> not support user-space for PPC, but v2.1 does not provide the kernel 
> space test yet, due to the build system refactoring. Still pondering how 
> to introduce this back into the codebase.

Yes, I know. That's why I have said approximately and why I have not yet 
posted figures for the MPC 5200, for example. Nevertheless, Xenomai is
pointing into the right direction and support for PowerPC is already 
excellent (on the level with X86 :-). So far, building and running 
Xenomai worked fine without any real problems. Thanks a lot.

Wolfgang.

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Klaas Gadeyne]

On Fri, 2 Dec 2005, Philippe Gerum wrote:
> Klaas Gadeyne wrote:
[...]
>> For comparison, on the same hardware platform: - the RTAI lxrt-latency on 
>> rtai 3.0r5 (adeos oldgen r18c1
>>   patch for 2.4.31 also) test reports 38 usec
>> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>   kernel resulted in a latency of 80 usec.
>
> 80 us on 2.6 is clearly pathological if 2.4 gives 30 us. All tests using 
> 2.6.14-1.0-10 on dual SMP 750Mhz and 2.8Ghz, Geode 266 Mhz, Celeron 1Ghz, 
> Centrino 1.6 Mhz and Pentium 90Mhz show a slight advantage for 2.4 over 2.6 
> (1-3%), but still in the error margin, I think. Maybe some option is enabled 
> in your 2.6 configuration that might trigger this very high value?

I rechecked the 2.6 config.  Apart from the lapic option, which I
couldn't enable with xenomai [*], I can't see something obvious that I
would have missed.  I'm sending you the config file in private.

Note that I haven't tested the 2.6 kernel with xenomai-trunk yet though...

thx,

Klaas

[*] When enabling local apic in the kernel configuration and booting
with the lapic option, I get

Disable APIC support or pass "lapic" as boot param.

while loading xeno_hal.

Re: [Xenomai-help] i386 2.4 backport performing (too?) well

[Philippe Gerum]

Klaas Gadeyne wrote:
> On Fri, 2 Dec 2005, Philippe Gerum wrote:
> 
>> Klaas Gadeyne wrote:
> 
> [...]
> 
>>> For comparison, on the same hardware platform: - the RTAI 
>>> lxrt-latency on rtai 3.0r5 (adeos oldgen r18c1
>>>   patch for 2.4.31 also) test reports 38 usec
>>> - the latency test of xenomai 2.01 running on a 2.6.14-ipipe-1.0-10
>>>   kernel resulted in a latency of 80 usec.
>>
>>
>> 80 us on 2.6 is clearly pathological if 2.4 gives 30 us. All tests 
>> using 2.6.14-1.0-10 on dual SMP 750Mhz and 2.8Ghz, Geode 266 Mhz, 
>> Celeron 1Ghz, Centrino 1.6 Mhz and Pentium 90Mhz show a slight 
>> advantage for 2.4 over 2.6 (1-3%), but still in the error margin, I 
>> think. Maybe some option is enabled in your 2.6 configuration that 
>> might trigger this very high value?
> 
> 
> I rechecked the 2.6 config.  Apart from the lapic option, which I
> couldn't enable with xenomai [*], I can't see something obvious that I
> would have missed.  I'm sending you the config file in private.
> 
> Note that I haven't tested the 2.6 kernel with xenomai-trunk yet though...
> 
> thx,
> 
> Klaas
> 
> [*] When enabling local apic in the kernel configuration and booting
> with the lapic option, I get
> 

> Disable APIC support or pass "lapic" as boot param.
> 

lapic=1 on your boot line. This is not a Xeno issue, but a Linux kernel 
requirement. Using the local APIC is even recommended when available on 
your hw with Xeno.

> while loading xeno_hal.
> 
> 
> 


-- 

Philippe.