Re: [Xenomai-core] PATCH: fix ppc64 calibration
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 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
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
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
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] PATCH: fix ppc64 calibration
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 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.0 +0300 +++ xenomai-dev/include/nucleus/asm-ppc64/calibration.h 2005-10-11 17:10:11.0 +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 */
RE: [Xenomai-core] PATCH: fix ppc64 calibration
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
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
Re: [Xenomai-core] PATCH: fix ppc64 calibration
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
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.
