RE: [Xenomai-core] PATCH: fix ppc64 calibration

RE: [Xenomai-core] PATCH: fix ppc64 calibration

[Fillod Stephane]

Heikki Lindholm wrote:
[..]
> Probably, but there are less than awesome 4xx boards around and I'd 
> guess they might even be more likely targets than G4 based machines,
for 
> example. Some tuning might be needed.

How many people are using Xenomai (or Fusion) on 4xx ?
What are their typical sched latency ?

-- 
Stephane

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Heikki Lindholm]

Fillod Stephane kirjoitti:
> Heikki Lindholm wrote:
> [..]
> 
>>Probably, but there are less than awesome 4xx boards around and I'd 
>>guess they might even be more likely targets than G4 based machines,
> 
> for 
> 
>>example. Some tuning might be needed.
> 
> 
> How many people are using Xenomai (or Fusion) on 4xx ?

No idea here, but my understanding is that these are popular embedded 
processors.

> What are their typical sched latency ?

This one I could check for a 405 box.

-- Heikki Lindholm

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Wolfgang Grandegger]

On 10/11/2005 05:11 PM Fillod Stephane wrote:
> Heikki Lindholm wrote:
> [..]
>> Probably, but there are less than awesome 4xx boards around and I'd 
>> guess they might even be more likely targets than G4 based machines,
> for 
>> example. Some tuning might be needed.
> 
> How many people are using Xenomai (or Fusion) on 4xx ?
> What are their typical sched latency ?

RTAI is used on 4xx and other embedded PowerPC processors, like 8xx,
8xxx and 52xx and Xenomai/Fusion might be an option in the future.
Today, there are only a few people running and testing Xenomai/Fusion on
these PowerPC processors, I guess. The problem is the availability of
the Linux 2.6 together with the ADEOS/iPipe-Patch. A lot of embedded
PowerPC boards do still not run or even compile Linux 2.6.

Depending on the CPU power and cache size, latencies can go up to 200 us
(or more), e.g. on a MPC 850 with 50 MHz and 1K cache. I'm going to
measure the latency on a Ocotea (440GP) and Ebony (405) board this week
(with adeos-linux-2.6.10-ppc-r8c4.patch and Fusion 0.9.1).

Wolfgang.

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Wolfgang Grandegger]

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

On 10/11/2005 05:11 PM Fillod Stephane wrote:
> Heikki Lindholm wrote:
> [..]
>> Probably, but there are less than awesome 4xx boards around and I'd 
>> guess they might even be more likely targets than G4 based machines,
> for 
>> example. Some tuning might be needed.
> 
> How many people are using Xenomai (or Fusion) on 4xx ?
> What are their typical sched latency ?

Attached is the result of some latency measurements on the Ocotea eval
board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately,
the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless,
it's difficult to provide a resonable default value. Why not simply
using 0 and it's then up to the user to provide an appropriate value
at configuration time?

Wolfgang.



[-- Attachment #2: fusion-latencies-ocotea.log --]
[-- Type: text/plain, Size: 1613 bytes --]

_______________________________________________________________________________

AMCC PowerPC 440GX Rev. C
Board: Ocotea - AMCC PPC440GX Evaluation Board
        VCO: 1066 MHz
        CPU: 533 MHz
        PLB: 152 MHz
        OPB: 76 MHz
        EPB: 76 MHz
I2C:   ready
DRAM:  256 MB
FLASH:  5 MB
PCI:   Bus Dev VenId DevId Class Int
In:    serial
Out:   serial
Err:   serial
Net:   ppc_4xx_eth0, ppc_4xx_eth1, ppc_4xx_eth2, ppc_4xx_eth3

Linux: linuxppc-2.6.10rc3

Adeos 2.6r8c4/ppc -- Pipelining: permanent

   Linux: priority=100, id=0x00000000, ptdkeys=0/4
        irq0-95: accepted
        irq96: accepted, virtual
        irq97: grabbed, virtual
_______________________________________________________________________________


*** SWITCH Without load ***

== Sampling period: 100 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|        5310|        7168|       17493|           0


*** CRUNCHER without load ***

Calibrating cruncher...301237,  8663, done -- ideal computation time = 9622 us.
1000 samples, 1000 hz freq (pid=24806, policy=SCHED_FIFO, prio=99)
--------
Nanosleep jitter: min = -8 us, max = 27 us, avg = -8 us
Execution jitter: min = -30 us (0%), max = 77 us (0%), avg = 7 us (0%)
--------


*** KLATENCY with load ("ping -f" and "while ls; do ls; done" in telnet window) ***

RTS|      -12510|       -9546|        3731|       0|    00:06:26/00:06:26


*** LATENCY with load ("ping -f" and "while ls; do ls; done" in telnet window) ***

== Sampling period: 100 us
...
RTS|      -11940|       -8885|        7143|       0|    00:06:55/00:06:55

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Heikki Lindholm]

Wolfgang Grandegger kirjoitti:
> On 10/11/2005 05:11 PM Fillod Stephane wrote:
> 
>>Heikki Lindholm wrote:
>>[..]
>>
>>>Probably, but there are less than awesome 4xx boards around and I'd 
>>>guess they might even be more likely targets than G4 based machines,
>>
>>for 
>>
>>>example. Some tuning might be needed.
>>
>>How many people are using Xenomai (or Fusion) on 4xx ?
>>What are their typical sched latency ?
> 
> 
> Attached is the result of some latency measurements on the Ocotea eval
> board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately,
> the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless,
> it's difficult to provide a resonable default value. Why not simply
> using 0 and it's then up to the user to provide an appropriate value
> at configuration time?

0? No machine is that fast. For the 32-bit ppc it might be harder to 
provide a reasonable default, because of the broader scale of hardware, 
but I'd guess that < 100MHz targets prefer to use a dedicated RTOS 
instead of Xenomai. For the 64-bit targets, I didn't find slower than 
400 MHz machines and they were iSeries, which, I suppose, also aren't 
prime target for Xenomai. Regardless of what default value is used, 
there could be some examples provided by the config help to direct user 
to the right direction.

What's the problem with Ebonys? I remember running at least 2.6.9 on 
Ebonys (440GP) and Walnuts (405).

-- Heikki Lindholm

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Wolfgang Grandegger]

On 10/12/2005 02:51 PM Heikki Lindholm wrote:
> Wolfgang Grandegger kirjoitti:
>> On 10/11/2005 05:11 PM Fillod Stephane wrote:
>> 
>>>Heikki Lindholm wrote:
>>>[..]
>>>
>>>>Probably, but there are less than awesome 4xx boards around and I'd 
>>>>guess they might even be more likely targets than G4 based machines,
>>>
>>>for 
>>>
>>>>example. Some tuning might be needed.
>>>
>>>How many people are using Xenomai (or Fusion) on 4xx ?
>>>What are their typical sched latency ?
>> 
>> 
>> Attached is the result of some latency measurements on the Ocotea eval
>> board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately,
>> the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless,
>> it's difficult to provide a resonable default value. Why not simply
>> using 0 and it's then up to the user to provide an appropriate value
>> at configuration time?
> 
> 0? No machine is that fast. For the 32-bit ppc it might be harder to 
> provide a reasonable default, because of the broader scale of hardware, 
> but I'd guess that < 100MHz targets prefer to use a dedicated RTOS 
> instead of Xenomai. For the 64-bit targets, I didn't find slower than 

There are a lot of 32 bit CPUs < 100 MHz running Linux and sometimes
they even need a realtime extension.

> 400 MHz machines and they were iSeries, which, I suppose, also aren't 
> prime target for Xenomai. Regardless of what default value is used, 
> there could be some examples provided by the config help to direct user 
> to the right direction.

I fully agree.

> What's the problem with Ebonys? I remember running at least 2.6.9 on 
> Ebonys (440GP) and Walnuts (405).

We have linux-2.4.14-rc3 running on all AMCC eval boards (see
http://www.denx.de). But the kernel supported by RTAI/Fusion,
linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
missing support for U-Boot but there might be others. And it's simply
not worth the effort to port it, I think.

Wolfgang.

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Heikki Lindholm]

Wolfgang Grandegger kirjoitti:
> 
>>What's the problem with Ebonys? I remember running at least 2.6.9 on 
>>Ebonys (440GP) and Walnuts (405).
> 
> 
> We have linux-2.4.14-rc3 running on all AMCC eval boards (see
> http://www.denx.de). But the kernel supported by RTAI/Fusion,
> linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
> missing support for U-Boot but there might be others. And it's simply
> not worth the effort to port it, I think.

Now that you mention it, I remember I had to hack u-boot support in 
there back when I used the Ebonys. Maybe I'll see if I can get some 
numbers out of them later this week.

-- Heikki Lindholm

[Xenomai-core] 2.4 vs 2.6 in embedded space

[Philippe Gerum]

Wolfgang Grandegger wrote:
> We have linux-2.4.14-rc3 running on all AMCC eval boards (see
> http://www.denx.de). But the kernel supported by RTAI/Fusion,
> linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
> missing support for U-Boot but there might be others. And it's simply
> not worth the effort to port it, I think.

Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 
and why, or do you think that part of the reluctance to move to 2.6 is mostly 
explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
fix if it ain't broken" perception?

-- 

Philippe.

Re: [Xenomai-core] 2.4 vs 2.6 in embedded space

[Wolfgang Denk]

Dear Philippe,

in message <434D2006.1060908@domain.hid> you wrote:
>
> Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 

Something like that.

> and why, or do you think that part of the reluctance to move to 2.6 is mostly 
> explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
> fix if it ain't broken" perception?

Please see
http://www.denx.de/twiki/bin/view/Know/Linux24vs26
and
http://www.denx.de/twiki/bin/view/Know/Clock100vs1000Hz

The major causes of the serious performance degradation under 2.6 are
(1) the increased code size (especially the code that is running in
    interrupt context and for test switching - check for example just
    the code size of the scheduler and compar ewith it's size under 2.4),
    and
(2) the increased clock frequency.

OK, (2) has been partially fixed in the mean time by making the clock
frequency adjustable, so you can go back to the old value of  100  Hz
on  low  end  systems. The other factor remains. And yes, this is "by
design" - Linux is more and more designed for high end machines  like
fat  servers  running  thousands  of  tasks  or  other multiprocessor
systems with N GHz clocks. A MPC860 at 50 Mhz is just another world.

<joke>
I see a business opportunity to revive the 2.2 or even the 2.0 kernel
tree  development  especially  for  small   systems   wth   real-time
requirements.
</joke>

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@domain.hid
If there was anything that depressed him more than his own  cynicism,
it was that quite often it still wasn't as cynical as real life.
                                 - Terry Pratchett, _Guards! Guards!_

[Xenomai-core] Re: 2.4 vs 2.6 in embedded space

[Wolfgang Grandegger]

On 10/12/2005 04:39 PM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> We have linux-2.4.14-rc3 running on all AMCC eval boards (see
>> http://www.denx.de). But the kernel supported by RTAI/Fusion,
>> linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
>> missing support for U-Boot but there might be others. And it's simply
>> not worth the effort to port it, I think.
> 
> Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 
> and why, or do you think that part of the reluctance to move to 2.6 is mostly 
> explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
> fix if it ain't broken" perception?

As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low
end systems, because it's bigger, slower, ... This is also true for
Xenomai (RTAI/fusion). It's difficult to beat the latency value of the
old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's
how thing are going. Nevertheless, compared to the realtime preemption
patch, Xenomai is _lightweight_ :-).

Furthermore I think, that part of the reluctance is also due to
"development in progress" including features like the realtime
preemption patch, especially on embedded PowerPC systems. People are
waiting that things get available and stable.

Wolfgang.

[Xenomai-core] Re: 2.4 vs 2.6 in embedded space

[Philippe Gerum]

Wolfgang Grandegger wrote:
> On 10/12/2005 04:39 PM Philippe Gerum wrote:
> 
>>Wolfgang Grandegger wrote:
>>
>>>We have linux-2.4.14-rc3 running on all AMCC eval boards (see
>>>http://www.denx.de). But the kernel supported by RTAI/Fusion,
>>>linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
>>>missing support for U-Boot but there might be others. And it's simply
>>>not worth the effort to port it, I think.
>>
>>Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 
>>and why, or do you think that part of the reluctance to move to 2.6 is mostly 
>>explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
>>fix if it ain't broken" perception?
> 
> 
> As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low
> end systems, because it's bigger, slower, ... This is also true for
> Xenomai (RTAI/fusion). It's difficult to beat the latency value of the
> old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's
> how thing are going. Nevertheless, compared to the realtime preemption
> patch, Xenomai is _lightweight_ :-).

I think so too; that's the problem with strictly native real-time support in the 
kernel: you must end up with some kind of SMPish structure which virtually 
exhibits an infinite number of processors (one per task basically), so it's not 
going to help reducing the cpu footprints and the various noisy artefacts 
implied by the generalized mutex approach (which is otherwise sound, that's no 
the issue). This is also why there is still space for real-time extensions, 
provided - I think - they run as symbiotically as possible with Linux, so that 
we don't end up telling people to ignore they have Linux while running their 
apps over it.

As far as Xeno is concerned, we should be able to continue to reduce those 
footprints. From my window, I see two aspects we need to work on:
- impact of the Adeos pipelining on cache especially for hw with sluggish
memory bandwidth
- a better placement of the hot data that are accessed inside the fast interrupt 
path (mainly those of the scheduler).

Looking at the ppc figures since early 2005 or so, the raw latency has 
continuously been reduced, i.e. we went from ~120 us on a Freescale's Icecube 
running the user-space test, to 53 us as measured recently with 0.9.1+r8c4. I 
did not manage to check again on the Sandpoint (connection problem to the Vlab) 
which is very representative of the low-end hw issues we could face [and 
basically made me cry when I first looked at the latency reports], but I suspect 
that thing might have progressed there too. I've recently ported 0.9.1 over a 
Mvista kernel (experimental PREEMPT_RT-like stuff + other patches) on a mpc8541, 
and the figures for user-space are ~22 us worst-cast lat.
Of course, this is not what one would call a sluggish low-end hw and I agree 
that a more structured design like Xeno can't beat a flat ISR-based design, but 
still, in any case, I'm optimistic enough to think that we likely have a margin 
of improvement there.

> 
> Furthermore I think, that part of the reluctance is also due to
> "development in progress" including features like the realtime
> preemption patch, especially on embedded PowerPC systems. People are
> waiting that things get available and stable.
> 

Well, we might all have the same problem here...

-- 

Philippe.

[Xenomai-core] Re: 2.4 vs 2.6 in embedded space

[Wolfgang Grandegger]

On 10/13/2005 11:11 AM Philippe Gerum wrote:
> Wolfgang Grandegger wrote:
>> On 10/12/2005 04:39 PM Philippe Gerum wrote:
>> 
>>>Wolfgang Grandegger wrote:
>>>
>>>>We have linux-2.4.14-rc3 running on all AMCC eval boards (see
>>>>http://www.denx.de). But the kernel supported by RTAI/Fusion,
>>>>linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
>>>>missing support for U-Boot but there might be others. And it's simply
>>>>not worth the effort to port it, I think.
>>>
>>>Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 
>>>and why, or do you think that part of the reluctance to move to 2.6 is mostly 
>>>explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
>>>fix if it ain't broken" perception?
>> 
>> 
>> As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low
>> end systems, because it's bigger, slower, ... This is also true for
>> Xenomai (RTAI/fusion). It's difficult to beat the latency value of the
>> old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's
>> how thing are going. Nevertheless, compared to the realtime preemption
>> patch, Xenomai is _lightweight_ :-).
> 
> I think so too; that's the problem with strictly native real-time support in the 
> kernel: you must end up with some kind of SMPish structure which virtually 
> exhibits an infinite number of processors (one per task basically), so it's not 
> going to help reducing the cpu footprints and the various noisy artefacts 
> implied by the generalized mutex approach (which is otherwise sound, that's no 
> the issue). This is also why there is still space for real-time extensions, 
> provided - I think - they run as symbiotically as possible with Linux, so that 
> we don't end up telling people to ignore they have Linux while running their 
> apps over it.

I agree and I'm really interested to get the benchmark comparison tests
http://www.opersys.com/lrtbf/index.html running on a low-end PowerPC system.

> 
> As far as Xeno is concerned, we should be able to continue to reduce those 
> footprints. From my window, I see two aspects we need to work on:
> - impact of the Adeos pipelining on cache especially for hw with sluggish
> memory bandwidth
> - a better placement of the hot data that are accessed inside the fast interrupt 
> path (mainly those of the scheduler).

That would be nice, indeed. I also understood, that iPIPE is already
lighter than ADEOS.

> Looking at the ppc figures since early 2005 or so, the raw latency has 
> continuously been reduced, i.e. we went from ~120 us on a Freescale's Icecube 
> running the user-space test, to 53 us as measured recently with 0.9.1+r8c4. I 
> did not manage to check again on the Sandpoint (connection problem to the Vlab) 
> which is very representative of the low-end hw issues we could face [and 
> basically made me cry when I first looked at the latency reports], but I suspect 
> that thing might have progressed there too. I've recently ported 0.9.1 over a 
> Mvista kernel (experimental PREEMPT_RT-like stuff + other patches) on a mpc8541, 
> and the figures for user-space are ~22 us worst-cast lat.
> Of course, this is not what one would call a sluggish low-end hw and I agree 
> that a more structured design like Xeno can't beat a flat ISR-based design, but 
> still, in any case, I'm optimistic enough to think that we likely have a margin 
> of improvement there.

When the iPIPE-Patch for PowerPC is available for a recent 2.6 kernel
version, I could run benchmark tests on various PowerPC systems, e.g. on
4xx processors from AMCC, including a rather low-end 405 at 200 MHz.

>> Furthermore I think, that part of the reluctance is also due to
>> "development in progress" including features like the realtime
>> preemption patch, especially on embedded PowerPC systems. People are
>> waiting that things get available and stable.
>> 
> 
> Well, we might all have the same problem here...

Wolfgang.

[Xenomai-core] Re: 2.4 vs 2.6 in embedded space

[Philippe Gerum]

Wolfgang Grandegger wrote:
> On 10/13/2005 11:11 AM Philippe Gerum wrote:
> 
>>Wolfgang Grandegger wrote:
>>
>>>On 10/12/2005 04:39 PM Philippe Gerum wrote:
>>>
>>>
>>>>Wolfgang Grandegger wrote:
>>>>
>>>>
>>>>>We have linux-2.4.14-rc3 running on all AMCC eval boards (see
>>>>>http://www.denx.de). But the kernel supported by RTAI/Fusion,
>>>>>linuxppc-2.6.10rc3, does not boot on Ebony. The main problem is the
>>>>>missing support for U-Boot but there might be others. And it's simply
>>>>>not worth the effort to port it, I think.
>>>>
>>>>Open question: to your opinion, is 2.6 on low-end embedded hw doomed "by design" 
>>>>and why, or do you think that part of the reluctance to move to 2.6 is mostly 
>>>>explained because 2.4 is just fine and up to the task, IOW it's kind of a "don't 
>>>>fix if it ain't broken" perception?
>>>
>>>
>>>As Wolfgang (Denk) already pointed out, 2.6 is less attractive on low
>>>end systems, because it's bigger, slower, ... This is also true for
>>>Xenomai (RTAI/fusion). It's difficult to beat the latency value of the
>>>old RTAI/RTHAL under 2.4. You need more CPU power and resources, that's
>>>how thing are going. Nevertheless, compared to the realtime preemption
>>>patch, Xenomai is _lightweight_ :-).
>>
>>I think so too; that's the problem with strictly native real-time support in the 
>>kernel: you must end up with some kind of SMPish structure which virtually 
>>exhibits an infinite number of processors (one per task basically), so it's not 
>>going to help reducing the cpu footprints and the various noisy artefacts 
>>implied by the generalized mutex approach (which is otherwise sound, that's no 
>>the issue). This is also why there is still space for real-time extensions, 
>>provided - I think - they run as symbiotically as possible with Linux, so that 
>>we don't end up telling people to ignore they have Linux while running their 
>>apps over it.
> 
> 
> I agree and I'm really interested to get the benchmark comparison tests
> http://www.opersys.com/lrtbf/index.html running on a low-end PowerPC system.
> 

Actually, those results are pretty bad compared to what we have now x86-wise: a 
dual 750 Mhz exhibits a worst-case latency of 42 us, and a dual 2.4 Ghz is under 
the 20 us thereshold, which includes a complete tasking in user-space, which was 
not accounted for in these tests.

It's one reason more to have this benchmarking infrastructure, so that the 
numbers keep being updated regularly, whichever way they are progressing/regressing.

> 
>>As far as Xeno is concerned, we should be able to continue to reduce those 
>>footprints. From my window, I see two aspects we need to work on:
>>- impact of the Adeos pipelining on cache especially for hw with sluggish
>>memory bandwidth
>>- a better placement of the hot data that are accessed inside the fast interrupt 
>>path (mainly those of the scheduler).
> 
> 
> That would be nice, indeed. I also understood, that iPIPE is already
> lighter than ADEOS.
> 

It is, yes. It has been alleviated from all the cruft needed to have it as a 
module on option, which was a genuinely BAD IDEA (tm, (C) 2002 rpm, ludicrous 
patent pending <hey, guys, I'm _kidding_>). The arch that would benefit the most 
of the implied simplifications is x86 since this also solves a design issue 
there, but at least we now have a saner ground to build over and optimize it for 
other archs.

> 
>>Looking at the ppc figures since early 2005 or so, the raw latency has 
>>continuously been reduced, i.e. we went from ~120 us on a Freescale's Icecube 
>>running the user-space test, to 53 us as measured recently with 0.9.1+r8c4. I 
>>did not manage to check again on the Sandpoint (connection problem to the Vlab) 
>>which is very representative of the low-end hw issues we could face [and 
>>basically made me cry when I first looked at the latency reports], but I suspect 
>>that thing might have progressed there too. I've recently ported 0.9.1 over a 
>>Mvista kernel (experimental PREEMPT_RT-like stuff + other patches) on a mpc8541, 
>>and the figures for user-space are ~22 us worst-cast lat.
>>Of course, this is not what one would call a sluggish low-end hw and I agree 
>>that a more structured design like Xeno can't beat a flat ISR-based design, but 
>>still, in any case, I'm optimistic enough to think that we likely have a margin 
>>of improvement there.
> 
> 
> When the iPIPE-Patch for PowerPC is available for a recent 2.6 kernel
> version, I could run benchmark tests on various PowerPC systems, e.g. on
> 4xx processors from AMCC, including a rather low-end 405 at 200 MHz.
> 

It mostly runs already, I just need to figure out why Xenomai's klatency test 
breaks my IceCube instead of quietly running like the latency one does...

> 
>>>Furthermore I think, that part of the reluctance is also due to
>>>"development in progress" including features like the realtime
>>>preemption patch, especially on embedded PowerPC systems. People are
>>>waiting that things get available and stable.
>>>
>>
>>Well, we might all have the same problem here...
> 
> 
> Wolfgang.
> 
> 
> 


-- 

Philippe.

RE: [Xenomai-core] PATCH: fix ppc64 calibration

[Fillod Stephane]

Wolfgang Grandegger wrote:
>On 10/11/2005 05:11 PM Fillod Stephane wrote:
>> Heikki Lindholm wrote:
>> [..]
>>> Probably, but there are less than awesome 4xx boards around and I'd 
>>> guess they might even be more likely targets than G4 based machines,
>> for 
>>> example. Some tuning might be needed.
>> 
>> How many people are using Xenomai (or Fusion) on 4xx ?
>> What are their typical sched latency ?
>
>Attached is the result of some latency measurements on the Ocotea eval
>board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately,
>the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless,
>it's difficult to provide a resonable default value. Why not simply
>using 0 and it's then up to the user to provide an appropriate value
>at configuration time?

If it helps, know there's 2.6.10 and 2.6.11 (CONFIG_PREEMPT disabled 
though) ADEOS patches available for ppc.

My latency measurements for Freescale e500 are here:
 https://mail.gna.org/public/rtai-dev/2005-02/msg00045.html

It looks like an ADEOS/I-Pipe patch for current Linux kernels is much 
expected.

The default calibration value may be set according to L1_CACHE_BYTES.
Of course I'm fine with a default value set to 0, which is closer to my 
end of the spectrum :-)

-- 
Stephane

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Wolfgang Grandegger]

On 10/12/2005 03:16 PM Fillod Stephane wrote:
> Wolfgang Grandegger wrote:
>>On 10/11/2005 05:11 PM Fillod Stephane wrote:
>>> Heikki Lindholm wrote:
>>> [..]
>>>> Probably, but there are less than awesome 4xx boards around and I'd 
>>>> guess they might even be more likely targets than G4 based machines,
>>> for 
>>>> example. Some tuning might be needed.
>>> 
>>> How many people are using Xenomai (or Fusion) on 4xx ?
>>> What are their typical sched latency ?
>>
>>Attached is the result of some latency measurements on the Ocotea eval
>>board. The AMCC 440 GX is already a fast 4xx processor. Unfortunately,
>>the linuxppc-2.6.10rc3 does not run on our Ebony board. Nevertheless,
>>it's difficult to provide a resonable default value. Why not simply
>>using 0 and it's then up to the user to provide an appropriate value
>>at configuration time?
> 
> If it helps, know there's 2.6.10 and 2.6.11 (CONFIG_PREEMPT disabled 
> though) ADEOS patches available for ppc.

I'm using adeos-linux-2.6.10-ppc-r8c4.patch with linuxppc-2.6.10rc3,
which works fine, at least on the Ocotea board.

> 
> My latency measurements for Freescale e500 are here:
>  https://mail.gna.org/public/rtai-dev/2005-02/msg00045.html
> 
> It looks like an ADEOS/I-Pipe patch for current Linux kernels is much 
> expected.

Of course. But Phillips is already heavily loaded with the project, I
assume.

> 
> The default calibration value may be set according to L1_CACHE_BYTES.
> Of course I'm fine with a default value set to 0, which is closer to my 
> end of the spectrum :-)

The nice thing with 0 is that you do not get negative latency values.
But for me, any number is OK.

Wolfgang.

RE: [Xenomai-core] PATCH: fix ppc64 calibration

[Fillod Stephane]

Heikki Lindholm wrote:
> The old calibration value was from some ancient ppc32 embedded board,
I 
> guess. This reflects the awesome power of them ppc64 boxen better :)

Actually, the ppc32 calibration value was from some ancient x86 machine,
I 
guess. The same patch could be applied to asm-ppc/calibration.h. This 
reflects the awesome power of them ppc32 boxen better :)

-- 
Stephane

Re: [Xenomai-core] PATCH: fix ppc64 calibration

[Heikki Lindholm]

Fillod Stephane kirjoitti:
> Heikki Lindholm wrote:
> 
>>The old calibration value was from some ancient ppc32 embedded board,
> 
> I 
> 
>>guess. This reflects the awesome power of them ppc64 boxen better :)
> 
> 
> Actually, the ppc32 calibration value was from some ancient x86 machine,

Damn, that has been heretic from the processor wars POV, then! Some 
swift action IS necessary.

> I 
> guess. The same patch could be applied to asm-ppc/calibration.h. This 
> reflects the awesome power of them ppc32 boxen better :)

Probably, but there are less than awesome 4xx boards around and I'd 
guess they might even be more likely targets than G4 based machines, for 
example. Some tuning might be needed.

-- Heikki Lindholm

[Xenomai-core] PATCH: fix ppc64 calibration

[Heikki Lindholm]

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

The old calibration value was from some ancient ppc32 embedded board, I 
guess. This reflects the awesome power of them ppc64 boxen better :)

-- Heikki Lindholm

[-- Attachment #2: xenomai-ppc64-calibration.patch --]
[-- Type: text/plain, Size: 479 bytes --]

diff -Nru xenomai/include/nucleus/asm-ppc64/calibration.h xenomai-dev/include/nucleus/asm-ppc64/calibration.h
--- xenomai/include/nucleus/asm-ppc64/calibration.h	2005-10-11 10:30:03.000000000 +0300
+++ xenomai-dev/include/nucleus/asm-ppc64/calibration.h	2005-10-11 17:10:11.000000000 +0300
@@ -32,7 +32,7 @@
 #define __sched_latency CONFIG_XENO_HW_SCHED_LATENCY
 #else
 
-#define __sched_latency 18500
+#define __sched_latency 1000
 
 #endif /* CONFIG_XENO_HW_SCHED_LATENCY */