RE: [Xenomai-help] Questions porting existing rtai-24.1.12 app toxenomai

RE: [Xenomai-help] Questions porting existing rtai-24.1.12 app toxenomai

[Fillod Stephane]

Philippe Gerum wrote:
>Randy Smith wrote:
>> I have inherited some linux 2.4.25 kernel module code for a powerpc
that 
>> uses rtai-24.1.12.  In my xenomai enabled kernel, I have disabled
native 
>> support and enabled the RTAI emulator.  This works as far as I know.
I 
>> can insmod it at least but to test it, I need some user mode code and

>> that is where I am running into problems.
>> 
>> The kernel module runs as a periodic task and uses kernel mode shared

>> memory to communicate with the user mode application.  The user mode 
>> application uses rtai_malloc to allocate the shared memory that the 
>> kernel module created with rtai_kmalloc.  My application fails to
link 
>> since librtai.so cannot resolve the call to rtai_malloc.  What should
I 
>> migrate the rtai_malloc call to in order to use the rtai skin with 
>> xenomai??
>
>The thing is that the RTAI emulator provided currently covers a minimal

>set of kernel-space only RTAI services, and does not provide any 
>user-space interface to these calls. The librtai.so library that would 
>contain the user-space interface mimicking LXRT is actually empty, and 
>basically a placeholder, waiting for someone to be motivated enough to 
>extend the existing support and flesh it. (hint, hint...).

Ok, got the hint ;-)

> Can I not communicate kernel to user via shared memory in that skin?
> 

RTAI shared memory access from user space works here. Just let me some
time
to make up the patch and post it to GNA. I have a RT-fifo patch also
that 
removes the I/O size limitation (reader<write) that will make Philippe 
scream.

>In fact, it's just that the RTAI emulator over Xenomai currently 
>provides only a small subset of the > 300 routines the original RTAI
API 
>exports, and solely in kernel space. The reason for that is likely that

>people porting from the RTAI API to Xeno usually switch to Xeno's
native 
>API directly.

Indeed, switching directly to Xeno native is worth the advice (sigh).

-- 
Stephane

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Philippe Gerum]

Randy Smith wrote:
> Thanks Philippe and Fillod for your explanations of the situation wrt 
> rtai skin and the gentle nudge to port the code to the native skin.  I 
> have decided to go that route as I am going to have to go there 
> eventually and there isn't that much code (famous last words.)
>

Make sure to read this then (also includes simple porting tips from RTAI 
to the native API):

http://download.gna.org/xenomai/documentation/branches/v2.1.x/pdf/Native-API-Tour.pdf

> I must have installed xenomai incorrectly as my code is not compiling 
> without some header files complaining about basic types like atomic_t 
> not being defined.  I have a kernel source tree installed in a 
> non-standard place, lets call it /home/randy/linux and the xenomai 
> package under /home/randy/xenomai-2.1.0.  I have applied the adios patch 
> and done the prepare_kernel.sh thing.  So far so good.  I can then do 
> make menuconfig and setup the realtime stuff then make uImage and the 
> kernel builds correctly (yes, I am cross-compiling for a powerpc).  That 
> all works ok.
> 
> Where I'm confused is this.  Do I then do something like
> 
> $ cd /home/randy
> $ mkdir xenomai && cd xenomai
> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
> --prefix=/home/randy
> $ make all
> $ make install

Make sure reading configure's output that the right ppc (cross-)compiler 
is found and used.

> 
> OR should I be in the kernel tree such as
> 
> $ cd /home/randy/linux
> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
> --prefix=/home/randy/linux
> 

This part is to build the user-space (only) support, so #1 is the right 
one. Since 2.1, Xenomai clearly splits the kernel side from the 
user-space support, so building the RT subsystem is just a matter of 
configuring yet-another-linux-subsystem using the regular Linux Kconfig 
interface, instead of fiddling with yet-another-nonstandard-kconfig. It 
also makes possible to build such RT subsystem statically into the 
kernel, and not only as external modules, which is good for our poor TLBs.

If we keep on being good boys in the future and don't change the skin 
system call numbers and prototypes each time at full moon, we might even 
reach some kind of reasonably stable ABI, so that the user-space stuff 
could run on the largest possible set of older versions of the kernel side.

README.INSTALL gives simple examples for building the user-space support 
for various archs; maybe this would help.

> ???
> 
> One of the problems I am seeing is that after the make all and make 
> install, there is built, an include file tree under /home/randy/include 
> and when I include this path on the compiler command line, I get 
> circular references such as
> 
> #include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h
> 
> which should refer to the kernel include of 
> /home/randy/linux/include/asm/atomic.h but instead picks up itself again 
> and doesn't define the atomic_t (among other things)
> 
> Obviously I'm doing something wrong and any help would be appreciated.
> 

Something looks like being badly trashed in your source tree, which 
would be quite possible if #2 is current.

> Fillod Stephane wrote:
> 
>> Philippe Gerum wrote:
>>  
>>
>>> people porting from the RTAI API to Xeno usually switch to Xeno's
>>>     
>>
>> native  
>>
>>> API directly.
>>>     
>>
>>
>> Indeed, switching directly to Xeno native is worth the advice (sigh).
>>
>>   
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

[Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith]

Thanks Philippe and Fillod for your explanations of the situation wrt 
rtai skin and the gentle nudge to port the code to the native skin.  I 
have decided to go that route as I am going to have to go there 
eventually and there isn't that much code (famous last words.)

I must have installed xenomai incorrectly as my code is not compiling 
without some header files complaining about basic types like atomic_t 
not being defined.  I have a kernel source tree installed in a 
non-standard place, lets call it /home/randy/linux and the xenomai 
package under /home/randy/xenomai-2.1.0.  I have applied the adios patch 
and done the prepare_kernel.sh thing.  So far so good.  I can then do 
make menuconfig and setup the realtime stuff then make uImage and the 
kernel builds correctly (yes, I am cross-compiling for a powerpc).  That 
all works ok.

Where I'm confused is this.  Do I then do something like

$ cd /home/randy
$ mkdir xenomai && cd xenomai
$ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=/home/randy
$ make all
$ make install

OR should I be in the kernel tree such as

$ cd /home/randy/linux
$ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=/home/randy/linux

???

One of the problems I am seeing is that after the make all and make 
install, there is built, an include file tree under /home/randy/include 
and when I include this path on the compiler command line, I get 
circular references such as

#include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h

which should refer to the kernel include of 
/home/randy/linux/include/asm/atomic.h but instead picks up itself again 
and doesn't define the atomic_t (among other things)

Obviously I'm doing something wrong and any help would be appreciated.

Fillod Stephane wrote:
> Philippe Gerum wrote:
>   
>
>> people porting from the RTAI API to Xeno usually switch to Xeno's
>>     
> native 
>   
>> API directly.
>>     
>
> Indeed, switching directly to Xeno native is worth the advice (sigh).
>
>   

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith]

Philippe Gerum wrote:
>
> Make sure to read this then (also includes simple porting tips from 
> RTAI to the native API):
>
> http://download.gna.org/xenomai/documentation/branches/v2.1.x/pdf/Native-API-Tour.pdf 
>

Thanks...Already been looking it over.
>
>> I must have installed xenomai incorrectly as my code is not compiling 
>> without some header files complaining about basic types like atomic_t 
>> not being defined.  I have a kernel source tree installed in a 
>> non-standard place, lets call it /home/randy/linux and the xenomai 
>> package under /home/randy/xenomai-2.1.0.  I have applied the adios 
>> patch and done the prepare_kernel.sh thing.  So far so good.  I can 
>> then do make menuconfig and setup the realtime stuff then make uImage 
>> and the kernel builds correctly (yes, I am cross-compiling for a 
>> powerpc).  That all works ok.
>>
>> Where I'm confused is this.  Do I then do something like
>>
>> $ cd /home/randy
>> $ mkdir xenomai && cd xenomai
>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>> --prefix=/home/randy
>> $ make all
>> $ make install
>
> Make sure reading configure's output that the right ppc 
> (cross-)compiler is found and used.
Yes, the correct cross-compiler is being used.
>
>>
>> OR should I be in the kernel tree such as
>>
>> $ cd /home/randy/linux
>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>> --prefix=/home/randy/linux
>>
>
> This part is to build the user-space (only) support, so #1 is the 
> right one. Since 2.1, Xenomai clearly splits the kernel side from the 
> user-space support, so building the RT subsystem is just a matter of 
> configuring yet-another-linux-subsystem using the regular Linux 
> Kconfig interface, instead of fiddling with 
> yet-another-nonstandard-kconfig. It also makes possible to build such 
> RT subsystem statically into the kernel, and not only as external 
> modules, which is good for our poor TLBs.
>
> If we keep on being good boys in the future and don't change the skin 
> system call numbers and prototypes each time at full moon, we might 
> even reach some kind of reasonably stable ABI, so that the user-space 
> stuff could run on the largest possible set of older versions of the 
> kernel side.
>
> README.INSTALL gives simple examples for building the user-space 
> support for various archs; maybe this would help.
It got me started, but I was unsure (since my case is such a unique one 
of cross-compiling and source tree in non-standard place) of what to do.

>
>> ???
>>
>> One of the problems I am seeing is that after the make all and make 
>> install, there is built, an include file tree under 
>> /home/randy/include and when I include this path on the compiler 
>> command line, I get circular references such as
>>
>> #include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h
>>
>> which should refer to the kernel include of 
>> /home/randy/linux/include/asm/atomic.h but instead picks up itself 
>> again and doesn't define the atomic_t (among other things)
>>
>> Obviously I'm doing something wrong and any help would be appreciated.
>>
>
> Something looks like being badly trashed in your source tree, which 
> would be quite possible if #2 is current.
No, I haven't done the second case yet.  I am having so many problems 
compiling the kernel modules with case #1 that I thought I did something 
wrong.

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Philippe Gerum]

Randy Smith wrote:
> 
> 
> Philippe Gerum wrote:
> 
>>
>> Make sure to read this then (also includes simple porting tips from 
>> RTAI to the native API):
>>
>> http://download.gna.org/xenomai/documentation/branches/v2.1.x/pdf/Native-API-Tour.pdf 
>>
> 
> 
> Thanks...Already been looking it over.
> 
>>
>>> I must have installed xenomai incorrectly as my code is not compiling 
>>> without some header files complaining about basic types like atomic_t 
>>> not being defined.  I have a kernel source tree installed in a 
>>> non-standard place, lets call it /home/randy/linux and the xenomai 
>>> package under /home/randy/xenomai-2.1.0.  I have applied the adios 
>>> patch and done the prepare_kernel.sh thing.  So far so good.  I can 
>>> then do make menuconfig and setup the realtime stuff then make uImage 
>>> and the kernel builds correctly (yes, I am cross-compiling for a 
>>> powerpc).  That all works ok.
>>>
>>> Where I'm confused is this.  Do I then do something like
>>>
>>> $ cd /home/randy
>>> $ mkdir xenomai && cd xenomai
>>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>>> --prefix=/home/randy
>>> $ make all
>>> $ make install
>>
>>
>> Make sure reading configure's output that the right ppc 
>> (cross-)compiler is found and used.
> 
> Yes, the correct cross-compiler is being used.
> 
>>
>>>
>>> OR should I be in the kernel tree such as
>>>
>>> $ cd /home/randy/linux
>>> $ ../xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
>>> --prefix=/home/randy/linux
>>>
>>
>> This part is to build the user-space (only) support, so #1 is the 
>> right one. Since 2.1, Xenomai clearly splits the kernel side from the 
>> user-space support, so building the RT subsystem is just a matter of 
>> configuring yet-another-linux-subsystem using the regular Linux 
>> Kconfig interface, instead of fiddling with 
>> yet-another-nonstandard-kconfig. It also makes possible to build such 
>> RT subsystem statically into the kernel, and not only as external 
>> modules, which is good for our poor TLBs.
>>
>> If we keep on being good boys in the future and don't change the skin 
>> system call numbers and prototypes each time at full moon, we might 
>> even reach some kind of reasonably stable ABI, so that the user-space 
>> stuff could run on the largest possible set of older versions of the 
>> kernel side.
>>
>> README.INSTALL gives simple examples for building the user-space 
>> support for various archs; maybe this would help.
> 
> It got me started, but I was unsure (since my case is such a unique one 
> of cross-compiling and source tree in non-standard place) of what to do.
> 
>>
>>> ???
>>>
>>> One of the problems I am seeing is that after the make all and make 
>>> install, there is built, an include file tree under 
>>> /home/randy/include and when I include this path on the compiler 
>>> command line, I get circular references such as
>>>
>>> #include <asm/atomic.h> from line 29 of /home/randy/include/asm/atomic.h
>>>
>>> which should refer to the kernel include of 
>>> /home/randy/linux/include/asm/atomic.h but instead picks up itself 
>>> again and doesn't define the atomic_t (among other things)
>>>
>>> Obviously I'm doing something wrong and any help would be appreciated.
>>>
>>
>> Something looks like being badly trashed in your source tree, which 
>> would be quite possible if #2 is current.
> 
> No, I haven't done the second case yet.  I am having so many problems 
> compiling the kernel modules with case #1 that I thought I did something 
> wrong.

Ok, just to be 100% sure, I've just tried the following on a stock 2.1.0 
grabbed from the mirror:

../somewhere/xenomai-2.1.0/configure --build=i686-linux --host=ppc-linux 
--prefix=$HOME/xenomai-install  CC=ppc_82xx-gcc CXX=ppc_82xx-gcc 
AR=ppc_82xx-ar LD=ppc_82xx-ld

The resulting tree builds and install fine under $HOME/xenomai-install 
afterwards. There is no kernel dependency whatsoever since the 
user-space support does not even know about the kernel version which is 
going to be used in the first place, so we should be able to get the 
same user-space setup. Could you try rebuilding in a clean build tree 
using equivalent switches at config time, and let me know of the 
outcome? TIA,

-- 

Philippe.

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith]

Philippe Gerum wrote:
>
> Ok, just to be 100% sure, I've just tried the following on a stock 
> 2.1.0 grabbed from the mirror:
>
> ../somewhere/xenomai-2.1.0/configure --build=i686-linux 
> --host=ppc-linux --prefix=$HOME/xenomai-install  CC=ppc_82xx-gcc 
> CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld
>
> The resulting tree builds and install fine under $HOME/xenomai-install 
> afterwards. There is no kernel dependency whatsoever since the 
> user-space support does not even know about the kernel version which 
> is going to be used in the first place, so we should be able to get 
> the same user-space setup. Could you try rebuilding in a clean build 
> tree using equivalent switches at config time, and let me know of the 
> outcome? TIA,
>
Philippe,

Thanks for your patient help.  I did what you asked and it works fine 
for the user side.

The kernel side is what is screwed up.  I am using the ELDK 3.1 from the 
DENX CD and when I try applying the Adeos patch, it fails in several 
places.  I ended up applying the patch by hand and I only had a few 
places where I was scratching my head as to where to apply the changes 
so that might be what I screwed up.  Is the 
xenomai-2.1.0/ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-ppc-denx-1.0-03.patch 
supposed to apply to the develop tree for ELDK 3.1 instead??  I couldn't 
make heads or tails of the numbering scheme used on the patch wrt the 
"denx-1.0-03" part. 

I'm so close...and I really want to figure this out.

-Randy

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Philippe Gerum]

Randy Smith wrote:
> 
> 
> Philippe Gerum wrote:
> 
>>
>> Ok, just to be 100% sure, I've just tried the following on a stock 
>> 2.1.0 grabbed from the mirror:
>>
>> ../somewhere/xenomai-2.1.0/configure --build=i686-linux 
>> --host=ppc-linux --prefix=$HOME/xenomai-install  CC=ppc_82xx-gcc 
>> CXX=ppc_82xx-gcc AR=ppc_82xx-ar LD=ppc_82xx-ld
>>
>> The resulting tree builds and install fine under $HOME/xenomai-install 
>> afterwards. There is no kernel dependency whatsoever since the 
>> user-space support does not even know about the kernel version which 
>> is going to be used in the first place, so we should be able to get 
>> the same user-space setup. Could you try rebuilding in a clean build 
>> tree using equivalent switches at config time, and let me know of the 
>> outcome? TIA,
>>
> Philippe,
> 
> Thanks for your patient help.  I did what you asked and it works fine 
> for the user side.
> 
> The kernel side is what is screwed up.  I am using the ELDK 3.1 from the 
> DENX CD and when I try applying the Adeos patch, it fails in several 
> places.  I ended up applying the patch by hand and I only had a few 
> places where I was scratching my head as to where to apply the changes 
> so that might be what I screwed up.  Is the 
> xenomai-2.1.0/ksrc/arch/powerpc/patches/adeos-ipipe-2.4.25-ppc-denx-1.0-03.patch 
> supposed to apply to the develop tree for ELDK 3.1 instead??  I couldn't 
> make heads or tails of the numbering scheme used on the patch wrt the 
> "denx-1.0-03" part.

Wrt 2.4 kernels, the project provides patches against snapshots of 
Denx's development tree, accessible from 
http://www.denx.de/en/Software/CVS. The date of the snapshot was missing 
in the patch filenames, which introduced a fair amount of confusion; 
this has been fixed in the repository. All 2.4-based Adeos patches for 
ppc have been built against Denx's devel tree as of 2005-11-09 so far. 
The Adeos version is always given by the trailing rev. number of any 
patch filename, e.g. 1.0-04 is the latest Adeos rev. for 2.4/ppc kernels.

For 2.6/ppc kernels, we provide patches against vanilla kernel trees as 
released by kernel.org.

> I'm so close...and I really want to figure this out.
> 

Ok, it's a bit early for Xmas gifts, but anyway, try this patch on 
2.4.25-11 as shipped with the ELDK 3.1:

http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch

-- 

Philippe.

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith]

Philippe Gerum wrote:
> Wrt 2.4 kernels, the project provides patches against snapshots of 
> Denx's development tree, accessible from 
> http://www.denx.de/en/Software/CVS. The date of the snapshot was 
> missing in the patch filenames, which introduced a fair amount of 
> confusion; this has been fixed in the repository. All 2.4-based Adeos 
> patches for ppc have been built against Denx's devel tree as of 
> 2005-11-09 so far. The Adeos version is always given by the trailing 
> rev. number of any patch filename, e.g. 1.0-04 is the latest Adeos 
> rev. for 2.4/ppc kernels.
>
> For 2.6/ppc kernels, we provide patches against vanilla kernel trees 
> as released by kernel.org.
Thanks,  That clears that up.
>
> Ok, it's a bit early for Xmas gifts, but anyway, try this patch on 
> 2.4.25-11 as shipped with the ELDK 3.1:
>
> http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch 
>
>
I have downloaded the patch and will try it over the next few days and 
report back.  Thanks again and Feliz Navidad or perhaps I should say 
Joyeux Noël?

-Randy

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Philippe Gerum]

Randy Smith wrote:
> 
> 
> Philippe Gerum wrote:
> 
>> Wrt 2.4 kernels, the project provides patches against snapshots of 
>> Denx's development tree, accessible from 
>> http://www.denx.de/en/Software/CVS. The date of the snapshot was 
>> missing in the patch filenames, which introduced a fair amount of 
>> confusion; this has been fixed in the repository. All 2.4-based Adeos 
>> patches for ppc have been built against Denx's devel tree as of 
>> 2005-11-09 so far. The Adeos version is always given by the trailing 
>> rev. number of any patch filename, e.g. 1.0-04 is the latest Adeos 
>> rev. for 2.4/ppc kernels.
>>
>> For 2.6/ppc kernels, we provide patches against vanilla kernel trees 
>> as released by kernel.org.
> 
> Thanks,  That clears that up.
> 
>>
>> Ok, it's a bit early for Xmas gifts, but anyway, try this patch on 
>> 2.4.25-11 as shipped with the ELDK 3.1:
>>
>> http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch 
>>
>>
> I have downloaded the patch and will try it over the next few days and 
> report back.  Thanks again and Feliz Navidad or perhaps I should say 
> Joyeux Noël?
>

Joyeux Noël would be perfect. Merry Christmas to you too.
[Redshift effect is ongoing on Xenomai-core]

-- 

Philippe.

[Xenomai-help] question about the latency test running on Blackfin

[adam li]

Hi,

I tried to run the "latency" test on Blackfin 533-STAMP board, in
different modes. Here is the output of the test result:

(I am using xenomai-2.1.0 with default configuration,(adding "timer
benchmark" driver)).

1. # latency -h -t0 -T30
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        29|      9.862|      0.581
HSS|    avg|    299964|     11.380|      2.676
HSS|    max|        29|     49.759|      5.296

# cat /proc/xenomai/stat
CPU  PID    MSW        CSW        PF    STAT      NAME
  0  0      0/0        288239     0     00400080  ROOT
  0  47     23/22      145        0     00300082  display
  0  48     1/0        220501     0     00300084  sampling


2. # latency -h -t1 -T30
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        29|      6.552|      0.686
HSS|    avg|    299985|      8.849|      1.601
HSS|    max|        29|     35.379|      6.383

cat /proc/xenomai/stat
CPU  PID    MSW        CSW        PF    STAT      NAME
  0  0      0/0        436079     0     00400080  ROOT
  0  58     6/5        42         0     00300082  display
  0  0      0/0        57685      0     00000084  timerbench


3. # latency -h -t2 -T30
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|      -5.340|      -4.385|       8.064|       0|      -5.340|
8.064
RTD|      -6.848|      -4.359|       8.907|       0|      -6.848|
8.907
RTD|      -6.443|      -4.518|      23.878|       0|      -6.848|
23.878
RTD|      -5.757|      -4.240|      23.377|       0|      -6.848|
23.878
RTD|      -6.153|      -4.144|      24.107|       0|      -6.848|
24.107
RTD|      -5.446|      -4.040|      18.754|       0|      -6.848|
24.107
RTD|      -7.697|      -4.690|      20.319|       0|      -7.697|
24.107

HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        29|      5.621|      0.820
HSS|    avg|    299979|      3.990|      0.774
HSS|    max|        29|     15.966|      6.248


And my questions are:

1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
space task), the average latency of Mode 1 is shorter. In Mode 1, the
"timerbench" thread is running in primary mode, but what makes the
latency in secondary mode longer?

2) From the output of Mode 0, the "MSW" field of "sampling" thread is
always 1/0, does that mean the "sampling" thread will switch to primary
mode and keep stay in primary mode throughout the test?

3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
avg" is negative, is this correct? If it is correct, why the latency is
much shorter than mode 1(kernel space task)?

And finally a general question:
4) why there is RTDM? What is the design purpose? If I were to write
Realtime device drivers, shall I use RTDM?


Thanks,

-Li Yi

Re: [Xenomai-help] question about the latency test running on Blackfin

[Philippe Gerum]

adam li wrote:
> Hi,
> 
> I tried to run the "latency" test on Blackfin 533-STAMP board, in
> different modes. Here is the output of the test result:
> 
> (I am using xenomai-2.1.0 with default configuration,(adding "timer
> benchmark" driver)).
> 
> 1. # latency -h -t0 -T30
> HSH|--param|--samples-|--average--|---stddev--
> HSS|    min|        29|      9.862|      0.581
> HSS|    avg|    299964|     11.380|      2.676
> HSS|    max|        29|     49.759|      5.296
> 
> # cat /proc/xenomai/stat
> CPU  PID    MSW        CSW        PF    STAT      NAME
>   0  0      0/0        288239     0     00400080  ROOT
>   0  47     23/22      145        0     00300082  display
>   0  48     1/0        220501     0     00300084  sampling
> 
> 
> 2. # latency -h -t1 -T30
> HSH|--param|--samples-|--average--|---stddev--
> HSS|    min|        29|      6.552|      0.686
> HSS|    avg|    299985|      8.849|      1.601
> HSS|    max|        29|     35.379|      6.383
> 
> cat /proc/xenomai/stat
> CPU  PID    MSW        CSW        PF    STAT      NAME
>   0  0      0/0        436079     0     00400080  ROOT
>   0  58     6/5        42         0     00300082  display
>   0  0      0/0        57685      0     00000084  timerbench
> 
> 
> 3. # latency -h -t2 -T30
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 100 us period)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|      -5.340|      -4.385|       8.064|       0|      -5.340|
> 8.064
> RTD|      -6.848|      -4.359|       8.907|       0|      -6.848|
> 8.907
> RTD|      -6.443|      -4.518|      23.878|       0|      -6.848|
> 23.878
> RTD|      -5.757|      -4.240|      23.377|       0|      -6.848|
> 23.878
> RTD|      -6.153|      -4.144|      24.107|       0|      -6.848|
> 24.107
> RTD|      -5.446|      -4.040|      18.754|       0|      -6.848|
> 24.107
> RTD|      -7.697|      -4.690|      20.319|       0|      -7.697|
> 24.107
> 
> HSH|--param|--samples-|--average--|---stddev--
> HSS|    min|        29|      5.621|      0.820
> HSS|    avg|    299979|      3.990|      0.774
> HSS|    max|        29|     15.966|      6.248
> 
> 
> And my questions are:
> 
> 1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
> space task), the average latency of Mode 1 is shorter. In Mode 1, the
> "timerbench" thread is running in primary mode, but what makes the
> latency in secondary mode longer?
> 

Both modes 0 and 1 exhibit threads running in primary mode. The 
difference is that mode 1 runs kernel based threads which are mostly 
seen as co-routines, whilst mode 0 runs user-space based ones. Mode 0 
involves the additional cost of dealing with full user-space context 
switches.

> 2) From the output of Mode 0, the "MSW" field of "sampling" thread is
> always 1/0, does that mean the "sampling" thread will switch to primary
> mode and keep stay in primary mode throughout the test?
> 

Yes.

> 3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
> avg" is negative, is this correct?

Yes, it only means that your pre-calibrated jitter compensation value is 
over-pessimistic, and could be lowered. This value is substracted from 
timer shot dates in order to take into account the intrinsic latency of 
your board and of Xenomai-related scheduling latency. See 
ksrc/include/asm-blackfin/calibration.h. You can override this value 
using the "timing" configuration menu.

  If it is correct, why the latency is
> much shorter than mode 1(kernel space task)?
> 

Because mode 1 measures the scheduling latency, whilst mode 2 only 
measures the interrupt latency.

> And finally a general question:
> 4) why there is RTDM? What is the design purpose?

It's a unifying, RTOS-agnostic, driver-class agnostic, API-agnostic 
framework for building real-time device drivers. It's the cornerstone of 
  Xenomai's real-time device support.

  If I were to write
> Realtime device drivers, shall I use RTDM?
> 

Yes, definitely.

> 
> Thanks,
> 
> -Li Yi
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] question about the latency test running on Blackfin

[adam li]

Thanks for the reply. 

I tried to set "CONFIG_XENO_OPT_TIMING_SCHEDLAT=10000" and run the test
in Mode 2 again:
# ./latency -t2 -h -T30
== Sampling period: 100 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT|  00:00:01  (in-kernel timer handler, 100 us period)
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
worst
RTD|       4.878|       6.021|      16.922|       0|       4.878|
16.922
RTD|       4.992|       6.199|      22.921|       0|       4.878|
22.921
RTD|       4.927|       6.258|      27.482|       0|       4.878|
27.482
...
HSH|--param|--samples-|--average--|---stddev--
HSS|    min|        29|      3.724|      0.591
HSS|    avg|    299981|      5.538|      1.196
HSS|    max|        29|     24.379|      5.192

But since the output test result depends on the
"CONFIG_XENO_OPT_TIMING_SCHEDLAT" and "CONFIG_XENO_OPT_TIMING_TIMERLAT",
how do I know the "actual" interrupt latency? That is, what is the
average interrupt latency in this case?

Thanks,

-Li Yi


On Thu, 2006-04-06 at 09:05 +0200, Philippe Gerum wrote:
> adam li wrote:
> > Hi,
> > 
> > I tried to run the "latency" test on Blackfin 533-STAMP board, in
> > different modes. Here is the output of the test result:
> > 
> > (I am using xenomai-2.1.0 with default configuration,(adding "timer
> > benchmark" driver)).
> > 
> > 1. # latency -h -t0 -T30
> > HSH|--param|--samples-|--average--|---stddev--
> > HSS|    min|        29|      9.862|      0.581
> > HSS|    avg|    299964|     11.380|      2.676
> > HSS|    max|        29|     49.759|      5.296
> > 
> > # cat /proc/xenomai/stat
> > CPU  PID    MSW        CSW        PF    STAT      NAME
> >   0  0      0/0        288239     0     00400080  ROOT
> >   0  47     23/22      145        0     00300082  display
> >   0  48     1/0        220501     0     00300084  sampling
> > 
> > 
> > 2. # latency -h -t1 -T30
> > HSH|--param|--samples-|--average--|---stddev--
> > HSS|    min|        29|      6.552|      0.686
> > HSS|    avg|    299985|      8.849|      1.601
> > HSS|    max|        29|     35.379|      6.383
> > 
> > cat /proc/xenomai/stat
> > CPU  PID    MSW        CSW        PF    STAT      NAME
> >   0  0      0/0        436079     0     00400080  ROOT
> >   0  58     6/5        42         0     00300082  display
> >   0  0      0/0        57685      0     00000084  timerbench
> > 
> > 
> > 3. # latency -h -t2 -T30
> > == Sampling period: 100 us
> > == Test mode: in-kernel timer handler
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel timer handler, 100 us period)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> > worst
> > RTD|      -5.340|      -4.385|       8.064|       0|      -5.340|
> > 8.064
> > RTD|      -6.848|      -4.359|       8.907|       0|      -6.848|
> > 8.907
> > RTD|      -6.443|      -4.518|      23.878|       0|      -6.848|
> > 23.878
> > RTD|      -5.757|      -4.240|      23.377|       0|      -6.848|
> > 23.878
> > RTD|      -6.153|      -4.144|      24.107|       0|      -6.848|
> > 24.107
> > RTD|      -5.446|      -4.040|      18.754|       0|      -6.848|
> > 24.107
> > RTD|      -7.697|      -4.690|      20.319|       0|      -7.697|
> > 24.107
> > 
> > HSH|--param|--samples-|--average--|---stddev--
> > HSS|    min|        29|      5.621|      0.820
> > HSS|    avg|    299979|      3.990|      0.774
> > HSS|    max|        29|     15.966|      6.248
> > 
> > 
> > And my questions are:
> > 
> > 1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
> > space task), the average latency of Mode 1 is shorter. In Mode 1, the
> > "timerbench" thread is running in primary mode, but what makes the
> > latency in secondary mode longer?
> > 
> 
> Both modes 0 and 1 exhibit threads running in primary mode. The 
> difference is that mode 1 runs kernel based threads which are mostly 
> seen as co-routines, whilst mode 0 runs user-space based ones. Mode 0 
> involves the additional cost of dealing with full user-space context 
> switches.
> 
> > 2) From the output of Mode 0, the "MSW" field of "sampling" thread is
> > always 1/0, does that mean the "sampling" thread will switch to primary
> > mode and keep stay in primary mode throughout the test?
> > 
> 
> Yes.
> 
> > 3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
> > avg" is negative, is this correct?
> 
> Yes, it only means that your pre-calibrated jitter compensation value is 
> over-pessimistic, and could be lowered. This value is substracted from 
> timer shot dates in order to take into account the intrinsic latency of 
> your board and of Xenomai-related scheduling latency. See 
> ksrc/include/asm-blackfin/calibration.h. You can override this value 
> using the "timing" configuration menu.
> 
>   If it is correct, why the latency is
> > much shorter than mode 1(kernel space task)?
> > 
> 
> Because mode 1 measures the scheduling latency, whilst mode 2 only 
> measures the interrupt latency.
> 
> > And finally a general question:
> > 4) why there is RTDM? What is the design purpose?
> 
> It's a unifying, RTOS-agnostic, driver-class agnostic, API-agnostic 
> framework for building real-time device drivers. It's the cornerstone of 
>   Xenomai's real-time device support.
> 
>   If I were to write
> > Realtime device drivers, shall I use RTDM?
> > 
> 
> Yes, definitely.
> 
> > 
> > Thanks,
> > 
> > -Li Yi
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> > 
> 
> 

Re: [Xenomai-help] question about the latency test running on Blackfin

[Philippe Gerum]

adam li wrote:
> Thanks for the reply. 
> 
> I tried to set "CONFIG_XENO_OPT_TIMING_SCHEDLAT=10000" and run the test
> in Mode 2 again:
> # ./latency -t2 -h -T30
> == Sampling period: 100 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT|  00:00:01  (in-kernel timer handler, 100 us period)
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> worst
> RTD|       4.878|       6.021|      16.922|       0|       4.878|
> 16.922
> RTD|       4.992|       6.199|      22.921|       0|       4.878|
> 22.921
> RTD|       4.927|       6.258|      27.482|       0|       4.878|
> 27.482
> ...
> HSH|--param|--samples-|--average--|---stddev--
> HSS|    min|        29|      3.724|      0.591
> HSS|    avg|    299981|      5.538|      1.196
> HSS|    max|        29|     24.379|      5.192
> 
> But since the output test result depends on the
> "CONFIG_XENO_OPT_TIMING_SCHEDLAT" and "CONFIG_XENO_OPT_TIMING_TIMERLAT",
> how do I know the "actual" interrupt latency? That is, what is the
> average interrupt latency in this case?
> 

Set the schedlat to 1 (ns) to cancel the compensation and re-run the test.

> Thanks,
> 
> -Li Yi
> 
> 
> On Thu, 2006-04-06 at 09:05 +0200, Philippe Gerum wrote:
> 
>>adam li wrote:
>>
>>>Hi,
>>>
>>>I tried to run the "latency" test on Blackfin 533-STAMP board, in
>>>different modes. Here is the output of the test result:
>>>
>>>(I am using xenomai-2.1.0 with default configuration,(adding "timer
>>>benchmark" driver)).
>>>
>>>1. # latency -h -t0 -T30
>>>HSH|--param|--samples-|--average--|---stddev--
>>>HSS|    min|        29|      9.862|      0.581
>>>HSS|    avg|    299964|     11.380|      2.676
>>>HSS|    max|        29|     49.759|      5.296
>>>
>>># cat /proc/xenomai/stat
>>>CPU  PID    MSW        CSW        PF    STAT      NAME
>>>  0  0      0/0        288239     0     00400080  ROOT
>>>  0  47     23/22      145        0     00300082  display
>>>  0  48     1/0        220501     0     00300084  sampling
>>>
>>>
>>>2. # latency -h -t1 -T30
>>>HSH|--param|--samples-|--average--|---stddev--
>>>HSS|    min|        29|      6.552|      0.686
>>>HSS|    avg|    299985|      8.849|      1.601
>>>HSS|    max|        29|     35.379|      6.383
>>>
>>>cat /proc/xenomai/stat
>>>CPU  PID    MSW        CSW        PF    STAT      NAME
>>>  0  0      0/0        436079     0     00400080  ROOT
>>>  0  58     6/5        42         0     00300082  display
>>>  0  0      0/0        57685      0     00000084  timerbench
>>>
>>>
>>>3. # latency -h -t2 -T30
>>>== Sampling period: 100 us
>>>== Test mode: in-kernel timer handler
>>>== All results in microseconds
>>>warming up...
>>>RTT|  00:00:01  (in-kernel timer handler, 100 us period)
>>>RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
>>>worst
>>>RTD|      -5.340|      -4.385|       8.064|       0|      -5.340|
>>>8.064
>>>RTD|      -6.848|      -4.359|       8.907|       0|      -6.848|
>>>8.907
>>>RTD|      -6.443|      -4.518|      23.878|       0|      -6.848|
>>>23.878
>>>RTD|      -5.757|      -4.240|      23.377|       0|      -6.848|
>>>23.878
>>>RTD|      -6.153|      -4.144|      24.107|       0|      -6.848|
>>>24.107
>>>RTD|      -5.446|      -4.040|      18.754|       0|      -6.848|
>>>24.107
>>>RTD|      -7.697|      -4.690|      20.319|       0|      -7.697|
>>>24.107
>>>
>>>HSH|--param|--samples-|--average--|---stddev--
>>>HSS|    min|        29|      5.621|      0.820
>>>HSS|    avg|    299979|      3.990|      0.774
>>>HSS|    max|        29|     15.966|      6.248
>>>
>>>
>>>And my questions are:
>>>
>>>1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
>>>space task), the average latency of Mode 1 is shorter. In Mode 1, the
>>>"timerbench" thread is running in primary mode, but what makes the
>>>latency in secondary mode longer?
>>>
>>
>>Both modes 0 and 1 exhibit threads running in primary mode. The 
>>difference is that mode 1 runs kernel based threads which are mostly 
>>seen as co-routines, whilst mode 0 runs user-space based ones. Mode 0 
>>involves the additional cost of dealing with full user-space context 
>>switches.
>>
>>
>>>2) From the output of Mode 0, the "MSW" field of "sampling" thread is
>>>always 1/0, does that mean the "sampling" thread will switch to primary
>>>mode and keep stay in primary mode throughout the test?
>>>
>>
>>Yes.
>>
>>
>>>3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
>>>avg" is negative, is this correct?
>>
>>Yes, it only means that your pre-calibrated jitter compensation value is 
>>over-pessimistic, and could be lowered. This value is substracted from 
>>timer shot dates in order to take into account the intrinsic latency of 
>>your board and of Xenomai-related scheduling latency. See 
>>ksrc/include/asm-blackfin/calibration.h. You can override this value 
>>using the "timing" configuration menu.
>>
>>  If it is correct, why the latency is
>>
>>>much shorter than mode 1(kernel space task)?
>>>
>>
>>Because mode 1 measures the scheduling latency, whilst mode 2 only 
>>measures the interrupt latency.
>>
>>
>>>And finally a general question:
>>>4) why there is RTDM? What is the design purpose?
>>
>>It's a unifying, RTOS-agnostic, driver-class agnostic, API-agnostic 
>>framework for building real-time device drivers. It's the cornerstone of 
>>  Xenomai's real-time device support.
>>
>>  If I were to write
>>
>>>Realtime device drivers, shall I use RTDM?
>>>
>>
>>Yes, definitely.
>>
>>
>>>Thanks,
>>>
>>>-Li Yi
>>>
>>>_______________________________________________
>>>Xenomai-help mailing list
>>>Xenomai-help@domain.hid
>>>https://mail.gna.org/listinfo/xenomai-help
>>>
>>
>>
> 


-- 

Philippe.

Re: [Xenomai-help] question about the latency test running on Blackfin

[Li Yi]

Hi Philippe,

According to your answers, I updated the document on Xenomai on
Blackfin: (http://docs.blackfin.uclinux.org/doku.php?id=adeos) with the
test result of different modes, setting  XENO_OPT_TIMING_SCHEDLAT = 1.
But I still have some question about the test result, hoping for your
help:

When running this test in mode 0, the worst case latency is 65 us, (HSD|
max| 65 - 66 | 1). This result is get when there is no workload. Can I
say this system is "Hard Real-time" because most of the latency samples
are in a  limited range?  

That is, from the test result:
HSS|    min|        59|     31.746|      0.632
HSS|    avg|    599965|     33.365|      2.151
HSS|    max|        59|     53.339|      2.739

Can I make the conclusion that the schedule latency is "determinative" and the system is "hard real-time"? If not,
what is the expected test result? Xenomai is able to provide hard real-time, right?

Thanks,
-Li Yi


On Fri, 2006-04-07 at 14:37 +0200, Philippe Gerum wrote:
> adam li wrote:
> > Thanks for the reply. 
> > 
> > I tried to set "CONFIG_XENO_OPT_TIMING_SCHEDLAT=10000" and run the test
> > in Mode 2 again:
> > # ./latency -t2 -h -T30
> > == Sampling period: 100 us
> > == Test mode: in-kernel timer handler
> > == All results in microseconds
> > warming up...
> > RTT|  00:00:01  (in-kernel timer handler, 100 us period)
> > RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> > worst
> > RTD|       4.878|       6.021|      16.922|       0|       4.878|
> > 16.922
> > RTD|       4.992|       6.199|      22.921|       0|       4.878|
> > 22.921
> > RTD|       4.927|       6.258|      27.482|       0|       4.878|
> > 27.482
> > ...
> > HSH|--param|--samples-|--average--|---stddev--
> > HSS|    min|        29|      3.724|      0.591
> > HSS|    avg|    299981|      5.538|      1.196
> > HSS|    max|        29|     24.379|      5.192
> > 
> > But since the output test result depends on the
> > "CONFIG_XENO_OPT_TIMING_SCHEDLAT" and "CONFIG_XENO_OPT_TIMING_TIMERLAT",
> > how do I know the "actual" interrupt latency? That is, what is the
> > average interrupt latency in this case?
> > 
> 
> Set the schedlat to 1 (ns) to cancel the compensation and re-run the test.
> 
> > Thanks,
> > 
> > -Li Yi
> > 
> > 
> > On Thu, 2006-04-06 at 09:05 +0200, Philippe Gerum wrote:
> > 
> >>adam li wrote:
> >>
> >>>Hi,
> >>>
> >>>I tried to run the "latency" test on Blackfin 533-STAMP board, in
> >>>different modes. Here is the output of the test result:
> >>>
> >>>(I am using xenomai-2.1.0 with default configuration,(adding "timer
> >>>benchmark" driver)).
> >>>
> >>>1. # latency -h -t0 -T30
> >>>HSH|--param|--samples-|--average--|---stddev--
> >>>HSS|    min|        29|      9.862|      0.581
> >>>HSS|    avg|    299964|     11.380|      2.676
> >>>HSS|    max|        29|     49.759|      5.296
> >>>
> >>># cat /proc/xenomai/stat
> >>>CPU  PID    MSW        CSW        PF    STAT      NAME
> >>>  0  0      0/0        288239     0     00400080  ROOT
> >>>  0  47     23/22      145        0     00300082  display
> >>>  0  48     1/0        220501     0     00300084  sampling
> >>>
> >>>
> >>>2. # latency -h -t1 -T30
> >>>HSH|--param|--samples-|--average--|---stddev--
> >>>HSS|    min|        29|      6.552|      0.686
> >>>HSS|    avg|    299985|      8.849|      1.601
> >>>HSS|    max|        29|     35.379|      6.383
> >>>
> >>>cat /proc/xenomai/stat
> >>>CPU  PID    MSW        CSW        PF    STAT      NAME
> >>>  0  0      0/0        436079     0     00400080  ROOT
> >>>  0  58     6/5        42         0     00300082  display
> >>>  0  0      0/0        57685      0     00000084  timerbench
> >>>
> >>>
> >>>3. # latency -h -t2 -T30
> >>>== Sampling period: 100 us
> >>>== Test mode: in-kernel timer handler
> >>>== All results in microseconds
> >>>warming up...
> >>>RTT|  00:00:01  (in-kernel timer handler, 100 us period)
> >>>RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat
> >>>worst
> >>>RTD|      -5.340|      -4.385|       8.064|       0|      -5.340|
> >>>8.064
> >>>RTD|      -6.848|      -4.359|       8.907|       0|      -6.848|
> >>>8.907
> >>>RTD|      -6.443|      -4.518|      23.878|       0|      -6.848|
> >>>23.878
> >>>RTD|      -5.757|      -4.240|      23.377|       0|      -6.848|
> >>>23.878
> >>>RTD|      -6.153|      -4.144|      24.107|       0|      -6.848|
> >>>24.107
> >>>RTD|      -5.446|      -4.040|      18.754|       0|      -6.848|
> >>>24.107
> >>>RTD|      -7.697|      -4.690|      20.319|       0|      -7.697|
> >>>24.107
> >>>
> >>>HSH|--param|--samples-|--average--|---stddev--
> >>>HSS|    min|        29|      5.621|      0.820
> >>>HSS|    avg|    299979|      3.990|      0.774
> >>>HSS|    max|        29|     15.966|      6.248
> >>>
> >>>
> >>>And my questions are:
> >>>
> >>>1). Compared the output of Mode 0 (user space task) and Mode 1 (kernel
> >>>space task), the average latency of Mode 1 is shorter. In Mode 1, the
> >>>"timerbench" thread is running in primary mode, but what makes the
> >>>latency in secondary mode longer?
> >>>
> >>
> >>Both modes 0 and 1 exhibit threads running in primary mode. The 
> >>difference is that mode 1 runs kernel based threads which are mostly 
> >>seen as co-routines, whilst mode 0 runs user-space based ones. Mode 0 
> >>involves the additional cost of dealing with full user-space context 
> >>switches.
> >>
> >>
> >>>2) From the output of Mode 0, the "MSW" field of "sampling" thread is
> >>>always 1/0, does that mean the "sampling" thread will switch to primary
> >>>mode and keep stay in primary mode throughout the test?
> >>>
> >>
> >>Yes.
> >>
> >>
> >>>3) In Mode 2 (timer handler in kernel space), the "lat min" and "lat
> >>>avg" is negative, is this correct?
> >>
> >>Yes, it only means that your pre-calibrated jitter compensation value is 
> >>over-pessimistic, and could be lowered. This value is substracted from 
> >>timer shot dates in order to take into account the intrinsic latency of 
> >>your board and of Xenomai-related scheduling latency. See 
> >>ksrc/include/asm-blackfin/calibration.h. You can override this value 
> >>using the "timing" configuration menu.
> >>
> >>  If it is correct, why the latency is
> >>
> >>>much shorter than mode 1(kernel space task)?
> >>>
> >>
> >>Because mode 1 measures the scheduling latency, whilst mode 2 only 
> >>measures the interrupt latency.
> >>
> >>
> >>>And finally a general question:
> >>>4) why there is RTDM? What is the design purpose?
> >>
> >>It's a unifying, RTOS-agnostic, driver-class agnostic, API-agnostic 
> >>framework for building real-time device drivers. It's the cornerstone of 
> >>  Xenomai's real-time device support.
> >>
> >>  If I were to write
> >>
> >>>Realtime device drivers, shall I use RTDM?
> >>>
> >>
> >>Yes, definitely.
> >>
> >>
> >>>Thanks,
> >>>
> >>>-Li Yi
> >>>
> >>>_______________________________________________
> >>>Xenomai-help mailing list
> >>>Xenomai-help@domain.hid
> >>>https://mail.gna.org/listinfo/xenomai-help
> >>>
> >>
> >>
> > 
> 
> 

Re: [Xenomai-help] question about the latency test running on Blackfin

[Jan Kiszka]

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

Li Yi wrote:
> Hi Philippe,
> 
> According to your answers, I updated the document on Xenomai on
> Blackfin: (http://docs.blackfin.uclinux.org/doku.php?id=adeos) with the
> test result of different modes, setting  XENO_OPT_TIMING_SCHEDLAT = 1.
> But I still have some question about the test result, hoping for your
> help:
> 
> When running this test in mode 0, the worst case latency is 65 us, (HSD|
> max| 65 - 66 | 1). This result is get when there is no workload. Can I
> say this system is "Hard Real-time" because most of the latency samples
> are in a  limited range?  

Soft RT: the more samples remain under the required limit the higher is
         the quality of the system

Hard RT: ALL samples must be below the limit

So, for hard RT, those 65 us is the interesting number. How did you
create the system load? Typical tests contain some cache benchmarking
tool (I prefer calibrator: http://www.cwi.nl/~manegold/Calibrator) +
network load (e.g. ping -f) + hard disk or other persistent storage
access (e.g. dd if=<your-disk> of=/dev/null).

How much MHz does your board have, and to what can it be compared when
looking at other architectures. 65 us looks quite (too?) good for
low-end, but maybe the blackfin isn't actually low-end.

> 
> That is, from the test result:
> HSS|    min|        59|     31.746|      0.632
> HSS|    avg|    599965|     33.365|      2.151
> HSS|    max|        59|     53.339|      2.739
> 
> Can I make the conclusion that the schedule latency is "determinative" and the system is "hard real-time"? If not,
> what is the expected test result? Xenomai is able to provide hard real-time, right?

Yes, Xenomai is a hard-RT system. But this doesn't depend on a specific
worst-case latency number, rather on the fact that a hardware-dependent
upper limit can be provided that is independent of the (here:) Linux load.

Jan


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

Re: [Xenomai-help] question about the latency test running on Blackfin

[adam li]

Thanks for the suggestions. 

I am using Blackfin 533 on the STAMP board. The core frequency is 398
MHz.These data are got when there is not special workload, only uClinux
running.

I tried to run "latency" test in Mode 0 (user space task) for 60 sec,
with the "calibrator" as work load, this time the worst case schedule
latency becomes 82 us. 

As you mentioned:

">Yes, Xenomai is a hard-RT system. But this doesn't depend on a
specific
> worst-case latency number, rather on the fact that a hardware-dependent
> upper limit can be provided that is independent of the (here:) Linux load"

Can I understand like this: Given the hardware and the workload, the
upper limit (worst case latency) is "determinative", regardless of what
is happening in Linux?

But still another confusion, as we can see from the test result, given
the hardware and the workload, each time running the "latency" test case
will result in an average latency and a worst case value, but how can we
"make sure" that using such hardware and such workload, the worst case
latency is "sure" to bellow certain upper limit? In other words, is it
possible that in some case, the worst case latency may go beyond the
observed upper limit? Or can I say that, there is such possibility, but
the probability is rare (statistically).

Thanks,
-Li Yi


 




On Wed, 2006-04-12 at 09:46 +0200, Jan Kiszka wrote:
> Li Yi wrote:
> > Hi Philippe,
> > 
> > According to your answers, I updated the document on Xenomai on
> > Blackfin: (http://docs.blackfin.uclinux.org/doku.php?id=adeos) with the
> > test result of different modes, setting  XENO_OPT_TIMING_SCHEDLAT = 1.
> > But I still have some question about the test result, hoping for your
> > help:
> > 
> > When running this test in mode 0, the worst case latency is 65 us, (HSD|
> > max| 65 - 66 | 1). This result is get when there is no workload. Can I
> > say this system is "Hard Real-time" because most of the latency samples
> > are in a  limited range?  
> 
> Soft RT: the more samples remain under the required limit the higher is
>          the quality of the system
> 
> Hard RT: ALL samples must be below the limit
> 
> So, for hard RT, those 65 us is the interesting number. How did you
> create the system load? Typical tests contain some cache benchmarking
> tool (I prefer calibrator: http://www.cwi.nl/~manegold/Calibrator) +
> network load (e.g. ping -f) + hard disk or other persistent storage
> access (e.g. dd if=<your-disk> of=/dev/null).
> 
> How much MHz does your board have, and to what can it be compared when
> looking at other architectures. 65 us looks quite (too?) good for
> low-end, but maybe the blackfin isn't actually low-end.
> 
> > 
> > That is, from the test result:
> > HSS|    min|        59|     31.746|      0.632
> > HSS|    avg|    599965|     33.365|      2.151
> > HSS|    max|        59|     53.339|      2.739
> > 
> > Can I make the conclusion that the schedule latency is "determinative" and the system is "hard real-time"? If not,
> > what is the expected test result? Xenomai is able to provide hard real-time, right?
> 
> Yes, Xenomai is a hard-RT system. But this doesn't depend on a specific
> worst-case latency number, rather on the fact that a hardware-dependent
> upper limit can be provided that is independent of the (here:) Linux load.
> 
> Jan
> 

Re: [Xenomai-help] Questions porting existing rtai-24.1.12 app to xenomai (PART II)

[Randy Smith]

Randy Smith wrote:
>
>
> Philippe Gerum wrote:
>>
>> Ok, it's a bit early for Xmas gifts, but anyway, try this patch on 
>> 2.4.25-11 as shipped with the ELDK 3.1:
>>
>> http://download.gna.org/adeos/patches/v2.4/ppc/adeos-ipipe-2.4.25-11-ppc-denx-1.0-04.patch 
>>
>>
> I have downloaded the patch and will try it over the next few days and 
> report back.  Thanks again and Feliz Navidad or perhaps I should say 
> Joyeux Noël?
>
> -Randy
>
Philippe,

Thanks for all your help.  I started from scratch and applied the patch 
your pointed me to and yes it worked!  I must have had something wrong 
in my build tree.
I can now build kernel modules and the user side builds and installs 
correctly.

Thanks again!

-Randy

Re: [Xenomai-help] question about the latency test running on Blackfin

[Jan Kiszka]

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

adam li wrote:
> Thanks for the suggestions. 
> 
> I am using Blackfin 533 on the STAMP board. The core frequency is 398
> MHz.These data are got when there is not special workload, only uClinux
> running.
> 
> I tried to run "latency" test in Mode 0 (user space task) for 60 sec,
> with the "calibrator" as work load, this time the worst case schedule
> latency becomes 82 us. 

Dare to run the test for a longer period than just a minute. It may
happen that certain events (IRQs) hit your RT test only vary rarely, but
still cause a few more us latency. Basically, this is one reason why you
should run multiple i/o loads in parallel, as each of them can delay
your critical real-time job a bit more.

> 
> As you mentioned:
> 
> ">Yes, Xenomai is a hard-RT system. But this doesn't depend on a
> specific
>> worst-case latency number, rather on the fact that a hardware-dependent
>> upper limit can be provided that is independent of the (here:) Linux load"
> 
> Can I understand like this: Given the hardware and the workload, the
> upper limit (worst case latency) is "determinative", regardless of what
> is happening in Linux?

Yes. Xenomai's worst-case latencies do not depend on what kind of
programs are running under Linux and what Linux services they use, they
only depend on the hardware devices (IRQs, buses, etc.) they are using.

> 
> But still another confusion, as we can see from the test result, given
> the hardware and the workload, each time running the "latency" test case
> will result in an average latency and a worst case value, but how can we
> "make sure" that using such hardware and such workload, the worst case
> latency is "sure" to bellow certain upper limit? In other words, is it
> possible that in some case, the worst case latency may go beyond the
> observed upper limit? Or can I say that, there is such possibility, but
> the probability is rare (statistically).
> 

In theory, by a complete static code analysis in combination with a good
model of all involved hardware components of the system. But this is
impractical for such complex systems.

Therefore, one tries to reduce the amount of code to analyse and then
derives a rough model from it. Xenomai helps here by decoupling the RT
core from Linux with all its applications. Furthermore, one defines a
simplified hardware model for a specific system. And then tests are
performed to measure worst-case latencies of individual components or
the whole application to verify the model and generate input for
projections of non-testable scenarios.

Well, in practice, one only measures a lot of stuff over a real long
time, takes the numbers, multiplies them by 2 (or more), and prays that
this will be good enough. :)

Jan


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