[Xenomai-help] test result on at91rm9200

[Xenomai-help] test result on at91rm9200

[robert165]

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

Hi,
I have tested xenomai on my at91rm9200 board, I used
xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
Test result seems very poor, is that correct?
And is there any introduction of the tests, as their purper, their meanling...

Test is under loads as followed,
    dd if=/dev/zero of=/dev/null > /dev/null &
    ping 172.18.23.10 > /dev/null &
    while ls; do ls; done > /dev/null &
Test info are:
running: cat /proc/cpuinfo
Processor    : ARM920T rev 0 (v4l)
BogoMIPS    : 89.53
Features    : swp half 
CPU implementer    : 0x41
CPU architecture: 4T
CPU variant    : 0x1
CPU part    : 0x920
CPU revision    : 0

Hardware    : Atmel AT91RM9200-DK
Revision    : 0000
Serial        : 0000000000000000

Thu Jan  1 00:15:21 UTC 1998
running: ./run -- -p 1000 -T 180 -t0 # latency
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 1000 us
== Test mode: periodic user-mode task
== All results in microseconds
RTS|      12.286|      64.102|     158.119|       0|    00:03:00/00:03:00

Thu Jan  1 00:18:29 UTC 1998
running: ./run -- -p 1000 -T 180 -t1 # latency
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 1000 us
== Test mode: in-kernel periodic task
== All results in microseconds
RTS|       5.298|      40.892|     123.382|       0|    00:03:00/00:03:00

Thu Jan  1 00:21:37 UTC 1998
running: ./run -- -p 1000 -T 180 -t2 # latency
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 1000 us
== Test mode: in-kernel timer handler
== All results in microseconds
RTS|      -3.750|      11.424|      66.755|       0|    00:03:00/00:03:00

Thu Jan  1 00:24:45 UTC 1998
running: ./run -- -T 120 # switchtest
*
*
* Type ^C to stop this application.
*
*
== Testing FPU check routines...
== FPU check routines: unimplemented, skipping FPU switches tests.
== Threads: sleeper-0 rtk-1 rtk-2 rtup-3 rtup-4 rtus-5 rtus-6 rtuo-7 rtuo-8
...
RTD|        1161|      133272
RTD|        1152|      134424
RTD|        1143|      135567
RTD|        1137|      136704
RTD|         432|      137136

Thu Jan  1 00:26:53 UTC 1998
running: ./run -- -p 1000 # switchbench
*
*
* Type ^C to stop this application.
*
*
== Sampling period: 1000 us
== Do not interrupt this program
RTH|     lat min|     lat avg|     lat max|        lost
RTD|      17.094|      45.940|     111.111|           0

Thu Jan  1 00:28:39 UTC 1998
running: ./run -- -p 10 -n -l 1000 # cyclictest
*
*
* Type ^C to stop this application.
*
*
3.68 3.49 2.28 5/32 15633  


Thanks for helps!

regards 
Robert

[-- Attachment #2: Type: text/html, Size: 4024 bytes --]

Re: [Xenomai-help] test result on at91rm9200

[Gilles Chanteperdrix]

robert165 wrote:
> Hi,
> I have tested xenomai on my at91rm9200 board, I used
> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
> Test result seems very poor, is that correct?

Your test results are rather good for an at91rm9200 board, which is the
sure sign that you are not loading the system enough.

As I already told, you, the expected results are:
- user-space latency of 260us without FCSE
- user-space latency of 200us with FCSE
- kernel-space latency of 50us if running with unlocked context switches
(an option which is only available in the upcoming 2.5 branch).

> And is there any introduction of the tests, as their purper, their
> meanling...

The latency test computes some latencies (either user-space scheduling
latency, kernel-space scheduling latency, or kernel-space interrupt
latency, depending on the options). The switchtest tests context
switches. The switchbench measures context switching time. cyclictest
does the same thing as the latency test (only, you need to run it with
the right options to avoid running in fact with Linux timer), and in
general return similar results. Here I do not know what is the meaning
of cyclictest results you got, but if you want to know, I am afraid you
wil have to investigate, or simply ignore them.

> 
> Test is under loads as followed,
>     dd if=/dev/zero of=/dev/null > /dev/null &
>     ping 172.18.23.10 > /dev/null &
>     while ls; do ls; done > /dev/null &

This load is laughable. Do you find that they really stress the system,
that they make it really unresponsive? Do you really expect a test which
sends one packet every second over network to stress the system in some
way? That is what I meant when I said hammering the system real hard.

-- 
					    Gilles.

Re: [Xenomai-help] test result on at91rm9200

[robert165]

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






在2009-12-28，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>robert165 wrote:
>> Hi,
>> I have tested xenomai on my at91rm9200 board, I used
>> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
>> Test result seems very poor, is that correct?
>
>Your test results are rather good for an at91rm9200 board, which is the
>sure sign that you are not loading the system enough.
>
>As I already told, you, the expected results are:
>- user-space latency of 260us without FCSE
>- user-space latency of 200us with FCSE
>- kernel-space latency of 50us if running with unlocked context switches
>(an option which is only available in the upcoming 2.5 branch).
>
>> And is there any introduction of the tests, as their purper, their
>> meanling...
>
>The latency test computes some latencies (either user-space scheduling
>latency, kernel-space scheduling latency, or kernel-space interrupt
>latency, depending on the options). The switchtest tests context
>switches. The switchbench measures context switching time. cyclictest
>does the same thing as the latency test (only, you need to run it with
>the right options to avoid running in fact with Linux timer), and in
>general return similar results. Here I do not know what is the meaning
>of cyclictest results you got, but if you want to know, I am afraid you
>wil have to investigate, or simply ignore them.
>

Thanks for your introdution, and is there any document of it. 
The man pages just explain  parametres  of test scripts.  I could
not understand the output of some test.

>> 
>> Test is under loads as followed,
>>     dd if=/dev/zero of=/dev/null > /dev/null &
>>     ping 172.18.23.10 > /dev/null &
>>     while ls; do ls; done > /dev/null &
>
>This load is laughable. Do you find that they really stress the system,
>that they make it really unresponsive? Do you really expect a test which
>sends one packet every second over network to stress the system in some
>way? That is what I meant when I said hammering the system real hard.

The reason I procuce the load is: 
https://mail.gna.org/public/xenomai-help/2008-01/msg00023.html
How can I produce a real hard load. Are there any direction about it.

>-- 
>					    Gilles.

Thanks for your patient help .

Robert

[-- Attachment #2: Type: text/html, Size: 2573 bytes --]

Re: [Xenomai-help] test result on at91rm9200

[Gilles Chanteperdrix]

robert165 wrote:
> 
> 
> 
> 在2009-12-28，"Gilles Chanteperdrix" <gilles.chanteperdrix@domain.hid> 写道：
>>robert165 wrote:
>>> Hi,
>>> I have tested xenomai on my at91rm9200 board, I used
>>> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
>>> Test result seems very poor, is that correct?
>>
>>Your test results are rather good for an at91rm9200 board, which is the
>>sure sign that you are not loading the system enough.
>>
>>As I already told, you, the expected results are:
>>- user-space latency of 260us without FCSE
>>- user-space latency of 200us with FCSE
>>- kernel-space latency of 50us if running with unlocked context switches
>>(an option which is only available in the upcoming 2.5 branch).
>>
>>> And is there any introduction of the tests, as their purper, their
>>> meanling...
>>
>>The latency test computes some latencies (either user-space scheduling
>>latency, kernel-space scheduling latency, or kernel-space interrupt
>>latency, depending on the options). The switchtest tests context
>>switches. The switchbench measures context switching time. cyclictest
>>does the same thing as the latency test (only, you need to run it with
>>the right options to avoid running in fact with Linux timer), and in
>>general return similar results. Here I do not know what is the meaning
>>of cyclictest results you got, but if you want to know, I am afraid you
>>wil have to investigate, or simply ignore them.
>>
> 
> Thanks for your introdution, and is there any document of it. 
> The man pages just explain  parametres  of test scripts.  I could
> not understand the output of some test.

No there is no document. But patches are welcome, as usual. As far as I
can tell, I explained you what the tests do, there is not much more to
tell. Which test's output did you not understand?

> 
>>> 
>>> Test is under loads as followed,
>>>     dd if=/dev/zero of=/dev/null > /dev/null &
>>>     ping 172.18.23.10 > /dev/null &
>>>     while ls; do ls; done > /dev/null &
>>
>>This load is laughable. Do you find that they really stress the system,
>>that they make it really unresponsive? Do you really expect a test which
>>sends one packet every second over network to stress the system in some
>>way? That is what I meant when I said hammering the system real hard.
> 
> The reason I procuce the load is: 
> https://mail.gna.org/public/xenomai-help/2008-01/msg00023.html
> How can I produce a real hard load. Are there any direction about it.

The mail you are refering to is using ping -f, not ping, and talks about
stressing cache by running the cache calibrator. The way we do our tests
evolved a bit since then. We use netcat instead of ping -f, and the
hackbench test to stress the linux scheduler. That is when FCSE is
enabled in guaranteed mode. Without FCSE, we use ltp (the linux testing
project) and netcat.

-- 
					    Gilles.

Re: [Xenomai-help] test result on at91rm9200

[robert165]

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






在2009-12-29，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>robert165 wrote:
>> 
>> 
>> 
>> 在2009-12-28，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>>>robert165 wrote:
>>>> Hi,
>>>> I have tested xenomai on my at91rm9200 board, I used
>>>> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
>>>> Test result seems very poor, is that correct?
>>>
>>>Your test results are rather good for an at91rm9200 board, which is the
>>>sure sign that you are not loading the system enough.
>>>
>>>As I already told, you, the expected results are:
>>>- user-space latency of 260us without FCSE
>>>- user-space latency of 200us with FCSE
>>>- kernel-space latency of 50us if running with unlocked context switches
>>>(an option which is only available in the upcoming 2.5 branch).
>>>
>>>> And is there any introduction of the tests, as their purper, their
>>>> meanling...
>>>
>>>The latency test computes some latencies (either user-space scheduling
>>>latency, kernel-space scheduling latency, or kernel-space interrupt
>>>latency, depending on the options). The switchtest tests context
>>>switches. The switchbench measures context switching time. cyclictest
>>>does the same thing as the latency test (only, you need to run it with
>>>the right options to avoid running in fact with Linux timer), and in
>>>general return similar results. Here I do not know what is the meaning
>>>of cyclictest results you got, but if you want to know, I am afraid you
>>>wil have to investigate, or simply ignore them.
>>>
>> 
>> Thanks for your introdution, and is there any document of it. 
>> The man pages just explain  parametres  of test scripts.  I could
>> not understand the output of some test.
>
>No there is no document. But patches are welcome, as usual. As far as I
>can tell, I explained you what the tests do, there is not much more to
>tell. Which test's output did you not understand?
>

when running: ./run -- -p 1000 -T 180 -t2 # latency
result gave negative numbers like 
RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
RTD|      -3.739|      11.330|      39.530|       0|      -3.739|      39.530
Is that means timer interrupts are not perfect, and may occur before or after the exact moment.
If so, the avg should calculate by the absolute value of the latency, and the best should be 
the least absolute value.

Thanks again.

Robert

[-- Attachment #2: Type: text/html, Size: 2899 bytes --]

Re: [Xenomai-help] test result on at91rm9200

[Gilles Chanteperdrix]

robert165 wrote:
> 
> 
> 
> 在2009-12-29，"Gilles Chanteperdrix" <gilles.chanteperdrix@domain.hid> 写道：
>>robert165 wrote:
>>> 
>>> 
>>> 
>>> 在2009-12-28，"Gilles Chanteperdrix" <gilles.chanteperdrix@domain.hid> 写道：
>>>>robert165 wrote:
>>>>> Hi,
>>>>> I have tested xenomai on my at91rm9200 board, I used
>>>>> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
>>>>> Test result seems very poor, is that correct?
>>>>
>>>>Your test results are rather good for an at91rm9200 board, which is the
>>>>sure sign that you are not loading the system enough.
>>>>
>>>>As I already told, you, the expected results are:
>>>>- user-space latency of 260us without FCSE
>>>>- user-space latency of 200us with FCSE
>>>>- kernel-space latency of 50us if running with unlocked context switches
>>>>(an option which is only available in the upcoming 2.5 branch).
>>>>
>>>>> And is there any introduction of the tests, as their purper, their
>>>>> meanling...
>>>>
>>>>The latency test computes some latencies (either user-space scheduling
>>>>latency, kernel-space scheduling latency, or kernel-space interrupt
>>>>latency, depending on the options). The switchtest tests context
>>>>switches. The switchbench measures context switching time. cyclictest
>>>>does the same thing as the latency test (only, you need to run it with
>>>>the right options to avoid running in fact with Linux timer), and in
>>>>general return similar results. Here I do not know what is the meaning
>>>>of cyclictest results you got, but if you want to know, I am afraid you
>>>>wil have to investigate, or simply ignore them.
>>>>
>>> 
>>> Thanks for your introdution, and is there any document of it. 
>>> The man pages just explain  parametres  of test scripts.  I could
>>> not understand the output of some test.
>>
>>No there is no document. But patches are welcome, as usual. As far as I
>>can tell, I explained you what the tests do, there is not much more to
>>tell. Which test's output did you not understand?
>>
> 
> when running: ./run -- -p 1000 -T 180 -t2 # latency
> result gave negative numbers like 
> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
> RTD|      -3.739|      11.330|      39.530|       0|      -3.739|      39.530
> Is that means timer interrupts are not perfect, and may occur before or after the exact moment.
> If so, the avg should calculate by the absolute value of the latency, and the best should be 
> the least absolute value.

It is a matter of point of view. From our point of view, the timer
interrupt ticking in advance is a feature, it compensates a bit for the
latency. Anyway, if you do not like it, just
echo 0 > /proc/xenomai/latency

The timer interrupts happen at the time they are programmed, only it is
their handling which may be delayed, most probably due to interrupts
masking sections.

-- 
					    Gilles.

Re: [Xenomai-help] test result on at91rm9200

[robert165]

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






在2009-12-30，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>robert165 wrote:
>> 
>> 
>> 
>> 在2009-12-29，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>>>robert165 wrote:
>>>> 
>>>> 
>>>> 
>>>> 在2009-12-28，"Gilles Chanteperdrix" <gilles.chanteperdrix@xenomai.org> 写道：
>>>>>robert165 wrote:
>>>>>> Hi,
>>>>>> I have tested xenomai on my at91rm9200 board, I used
>>>>>> xenomai 2.4.10 + linux-2.6.28 + adeos-ipipe-2.6.28-arm-1.12-05.patch
>>>>>> Test result seems very poor, is that correct?
>>>>>
>>>>>Your test results are rather good for an at91rm9200 board, which is the
>>>>>sure sign that you are not loading the system enough.
>>>>>
>>>>>As I already told, you, the expected results are:
>>>>>- user-space latency of 260us without FCSE
>>>>>- user-space latency of 200us with FCSE
>>>>>- kernel-space latency of 50us if running with unlocked context switches
>>>>>(an option which is only available in the upcoming 2.5 branch).
>>>>>
>>>>>> And is there any introduction of the tests, as their purper, their
>>>>>> meanling...
>>>>>
>>>>>The latency test computes some latencies (either user-space scheduling
>>>>>latency, kernel-space scheduling latency, or kernel-space interrupt
>>>>>latency, depending on the options). The switchtest tests context
>>>>>switches. The switchbench measures context switching time. cyclictest
>>>>>does the same thing as the latency test (only, you need to run it with
>>>>>the right options to avoid running in fact with Linux timer), and in
>>>>>general return similar results. Here I do not know what is the meaning
>>>>>of cyclictest results you got, but if you want to know, I am afraid you
>>>>>wil have to investigate, or simply ignore them.
>>>>>
>>>> 
>>>> Thanks for your introdution, and is there any document of it. 
>>>> The man pages just explain  parametres  of test scripts.  I could
>>>> not understand the output of some test.
>>>
>>>No there is no document. But patches are welcome, as usual. As far as I
>>>can tell, I explained you what the tests do, there is not much more to
>>>tell. Which test's output did you not understand?
>>>
>> 
>> when running: ./run -- -p 1000 -T 180 -t2 # latency
>> result gave negative numbers like 
>> RTH|-----lat min|-----lat avg|-----lat max|-overrun|----lat best|---lat worst
>> RTD|      -3.739|      11.330|      39.530|       0|      -3.739|      39.530
>> Is that means timer interrupts are not perfect, and may occur before or after the exact moment.
>> If so, the avg should calculate by the absolute value of the latency, and the best should be 
>> the least absolute value.
>
>It is a matter of point of view. From our point of view, the timer
>interrupt ticking in advance is a feature, it compensates a bit for the
>latency. Anyway, if you do not like it, just
>echo 0 > /proc/xenomai/latency
>
>The timer interrupts happen at the time they are programmed, only it is
>their handling which may be delayed, most probably due to interrupts
>masking sections.
>
OK, I understand it now, thanks.

Robert

[-- Attachment #2: Type: text/html, Size: 4025 bytes --]