* [Adeos-main] switchbench tests with IPIPE tracer disabled
@ 2007-02-01 5:28 poornima r
2007-02-01 7:51 ` Wolfgang Grandegger
0 siblings, 1 reply; 10+ messages in thread
From: poornima r @ 2007-02-01 5:28 UTC (permalink / raw)
To: adeos-main
Hi,
I was able to run latency and switchbench tests on
MPC860 board with IPIPE tracer feature
enabled/disabled.
Interrupt & scheduling Latencies and switching
latencies (with IPIPE tracer option disabled) were
having lower values when compared to latency values
with IPIPE tracer enabled.
cyclictest test results were same with or without
IPIPE tracer enabled.
Is this reduced context switching latency in
switchbench test due to timer interrupt?
Thanks,
Poornima
____________________________________________________________________________________
TV dinner still cooling?
Check out "Tonight's Picks" on Yahoo! TV.
http://tv.yahoo.com/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 5:28 [Adeos-main] switchbench tests with IPIPE tracer disabled poornima r
@ 2007-02-01 7:51 ` Wolfgang Grandegger
2007-02-01 9:54 ` poornima r
0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Grandegger @ 2007-02-01 7:51 UTC (permalink / raw)
To: poornima r; +Cc: adeos-main
poornima r wrote:
> Hi,
>
> I was able to run latency and switchbench tests on
> MPC860 board with IPIPE tracer feature
> enabled/disabled.
Nice, what versions of Linux and Xenomai did you use for your tests? It
is known that Linux 2.6 does not yet work properly for 8xx. It would
also be nice if you could briefly post your results on this list as well.
> Interrupt & scheduling Latencies and switching
> latencies (with IPIPE tracer option disabled) were
> having lower values when compared to latency values
> with IPIPE tracer enabled.
The ipipe tracer introduces some overhead (extra code) and as this CPU
is very slow, you will notice it.
> cyclictest test results were same with or without
> IPIPE tracer enabled.
Your results would really be of interest.
> Is this reduced context switching latency in
> switchbench test due to timer interrupt?
Likely it also due to overhead introduced by the ipipe tracer.
BTW: the switchtest should run as well with the option "-n" (for not
using the FPU),
Wolfgang.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 7:51 ` Wolfgang Grandegger
@ 2007-02-01 9:54 ` poornima r
2007-02-01 10:38 ` Wolfgang Grandegger
0 siblings, 1 reply; 10+ messages in thread
From: poornima r @ 2007-02-01 9:54 UTC (permalink / raw)
To: adeos-main
Hi,
Thanks for the reply.
Linux version:linux-2.6.18
Xenomai: xenomai-2.3.0 (Stable version)
adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
The tests were run as follows:
1)The sampling period in the code for latency and
switchbench was changed to 1000000000ns(to remove
overrun error)
2)switchtest was run with -n5 option
3)cyclictest was run with -t5 option(5 threads
were created.)
4)cyclictest was terminated with Illegal instruction
(after creating 5 threads) with IPIPE tracer enabled.
These were the results without I-PIPE Tracer option:
(All the tests were run without any load)
1)LATENCY TEST:-
User mode:-
/mnt/out_xen/bin# ./latency -t0
== Sampling period: 1000000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 167.000| 167.000| 167.000| 0|
167.000| 167.000
RTD| 176.000| 176.000| 176.000| 0|
167.000| 176.000
RTD| 168.000| 168.000| 168.000| 0|
167.000| 176.000
RTD| 171.000| 171.000| 171.000| 0|
167.000| 176.000
Kernel mode:-
root@domain.hid# ./latency -t1
== Sampling period: 1000000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT| 00:00:00 (in-kernel periodic task, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 123.000| 123.000| 123.000| 0|
123.000| 123.000
RTD| 125.000| 125.000| 125.000| 0|
123.000| 125.000
RTD| 128.333| 128.333| 128.333| 0|
123.000| 128.333
RTD| 127.000| 127.000| 127.000| 0|
123.000| 128.333
Interrupt mode:-
root@domain.hid# ./latency -t2
== Sampling period: 1000000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel timer handler, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 45.334| 45.334| 45.334| 0|
45.334| 45.334
RTD| 45.000| 45.000| 45.000| 0|
45.000| 45.334
RTD| 46.000| 46.000| 46.000| 0|
45.000| 46.000
RTD| 47.334| 47.334| 47.334| 0|
45.000| 47.334
RTD| 46.334| 46.334| 46.334| 0|
45.000| 47.334
2)CYCLICTEST RESULTS:-
root@domain.hid# ./cyclictest -t5
5.14 3.71 1.72 6/31 216
T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 2 ( 212) P:97 I: 2000 C: 8112 Min: 169
Act: 189 Avg: 204 Max: 288
T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 4 ( 216) P:95 I: 3000 C: 21596 Min: 180
Act: 1279 Avg: 702 Max: 1336
3)SWITCHBENCH TEST RESULTS:-
root@domain.hid# ./switchbench -n5
== Sampling period: 1000000 us
== Do not interrupt this program
RTH| lat min| lat avg| lat max|
lost
RTD| 229.333| 45.666| 229.333|
0
Test results with IPIPE tracer enabled
1)LATENCY TEST RESULTS:-
User mode:-
root@domain.hid# ./latency -t0
== Sampling period: 1000000 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
RTT| 00:00:01 (periodic user-mode task, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 340.000| 340.000| 340.000| 0|
340.000| 340.000
RTD| 338.666| 338.666| 338.666| 0|
338.666| 340.000
RTD| 341.000| 341.000| 341.000| 0|
338.666| 341.000
RTD| 342.000| 342.000| 342.000| 0|
338.666| 342.000
2)kernel mode:-
root@domain.hid# ./latency -t1
== Sampling period: 1000000 us
== Test mode: in-kernel periodic task
== All results in microseconds
warming up...
RTT| 00:00:00 (in-kernel periodic task, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 303.333| 303.333| 303.333| 0|
303.333| 303.333
RTD| 309.666| 309.666| 309.666| 0|
303.333| 309.666
RTD| 325.000| 325.000| 325.000| 0|
303.333| 325.000
RTD| 306.333| 306.333| 306.333| 0|
303.333| 325.000
Interrupt mode:-
root@domain.hid# ./latency -t2
== Sampling period: 1000000 us
== Test mode: in-kernel timer handler
== All results in microseconds
warming up...
RTT| 00:00:01 (in-kernel timer handler, 1000000 us
period, priority 99)
RTH|-----lat min|-----lat avg|-----lat
max|-overrun|----lat best|---lat worst
RTD| 153.334| 153.334| 153.334| 0|
153.334| 153.334
RTD| 154.667| 154.667| 154.667| 0|
153.334| 154.667
RTD| 164.334| 164.334| 164.334| 0|
153.334| 164.334
RTD| 154.667| 154.667| 154.667| 0|
153.334| 164.334
RTD| 163.667| 163.667| 163.667| 0|
153.334| 164.334
2)CYCLICTEST RESULTS:-
root@domain.hid# ./cyclictest -t5
0.18 0.15 0.09 3/26 194
T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 2 ( 190) P:97 I: 2000 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
T: 4 ( 193) P:95 I: 3000 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
Illegal instruction
3)SWITCHBENCHTEST RESULTS:-
root@domain.hid# ./switchbench -n5
== Sampling period: 1000000 us
== Do not interrupt this program
RTH| lat min| lat avg| lat max|
lost
RTD| 667.333| 133.333| 667.333|
0
SWITCHTEST:-
Since FPU is not enabled for ppc, I was not able to
get proper results for switchtest. Please mail the
results of switchtest.
Thanks,
Poornima
--- Wolfgang Grandegger <wg@domain.hid> wrote:
> poornima r wrote:
> > Hi,
> >
> > I was able to run latency and switchbench tests on
> > MPC860 board with IPIPE tracer feature
> > enabled/disabled.
>
> Nice, what versions of Linux and Xenomai did you use
> for your tests? It
> is known that Linux 2.6 does not yet work properly
> for 8xx. It would
> also be nice if you could briefly post your results
> on this list as well.
>
> > Interrupt & scheduling Latencies and switching
> > latencies (with IPIPE tracer option disabled) were
> > having lower values when compared to latency
> values
> > with IPIPE tracer enabled.
>
> The ipipe tracer introduces some overhead (extra
> code) and as this CPU
> is very slow, you will notice it.
>
> > cyclictest test results were same with or without
> > IPIPE tracer enabled.
>
> Your results would really be of interest.
>
> > Is this reduced context switching latency in
> > switchbench test due to timer interrupt?
>
> Likely it also due to overhead introduced by the
> ipipe tracer.
>
> BTW: the switchtest should run as well with the
> option "-n" (for not
> using the FPU),
>
> Wolfgang.
>
>
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 9:54 ` poornima r
@ 2007-02-01 10:38 ` Wolfgang Grandegger
2007-02-01 11:25 ` poornima r
2007-02-01 11:34 ` Jan Kiszka
0 siblings, 2 replies; 10+ messages in thread
From: Wolfgang Grandegger @ 2007-02-01 10:38 UTC (permalink / raw)
To: poornima r; +Cc: adeos-main
poornima r wrote:
> Hi,
>
> Thanks for the reply.
>
> Linux version:linux-2.6.18
> Xenomai: xenomai-2.3.0 (Stable version)
> adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
OK, I'm curious, did you use the vanilla kernel from kernel.org?
More comments below.
> The tests were run as follows:
> 1)The sampling period in the code for latency and
> switchbench was changed to 1000000000ns(to remove
> overrun error)
> 2)switchtest was run with -n5 option
> 3)cyclictest was run with -t5 option(5 threads
> were created.)
> 4)cyclictest was terminated with Illegal instruction
> (after creating 5 threads) with IPIPE tracer enabled.
>
> These were the results without I-PIPE Tracer option:
> (All the tests were run without any load)
> 1)LATENCY TEST:-
> User mode:-
> /mnt/out_xen/bin# ./latency -t0
> == Sampling period: 1000000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 167.000| 167.000| 167.000| 0|
> 167.000| 167.000
> RTD| 176.000| 176.000| 176.000| 0|
> 167.000| 176.000
> RTD| 168.000| 168.000| 168.000| 0|
> 167.000| 176.000
> RTD| 171.000| 171.000| 171.000| 0|
> 167.000| 176.000
>
> Kernel mode:-
> root@domain.hid# ./latency -t1
> == Sampling period: 1000000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 123.000| 123.000| 123.000| 0|
> 123.000| 123.000
> RTD| 125.000| 125.000| 125.000| 0|
> 123.000| 125.000
> RTD| 128.333| 128.333| 128.333| 0|
> 123.000| 128.333
> RTD| 127.000| 127.000| 127.000| 0|
> 123.000| 128.333
>
> Interrupt mode:-
> root@domain.hid# ./latency -t2
> == Sampling period: 1000000 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 45.334| 45.334| 45.334| 0|
> 45.334| 45.334
> RTD| 45.000| 45.000| 45.000| 0|
> 45.000| 45.334
> RTD| 46.000| 46.000| 46.000| 0|
> 45.000| 46.000
> RTD| 47.334| 47.334| 47.334| 0|
> 45.000| 47.334
> RTD| 46.334| 46.334| 46.334| 0|
> 45.000| 47.334
I remember similar figures from measurements under 2.4. I guess you
tested without load!? Nevertheless, most of the latency is due to code
execution time because the system is very slow and the caches are small.
The sampling period is 1 second. I think "-p500" should already work.
> 2)CYCLICTEST RESULTS:-
> root@domain.hid# ./cyclictest -t5
> 5.14 3.71 1.72 6/31 216
>
> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 2 ( 212) P:97 I: 2000 C: 8112 Min: 169
> Act: 189 Avg: 204 Max: 288
> T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 4 ( 216) P:95 I: 3000 C: 21596 Min: 180
> Act: 1279 Avg: 702 Max: 1336
Hm, this looks bogus. What returns "./cyclictest" without options (or -t1)?
> 3)SWITCHBENCH TEST RESULTS:-
> root@domain.hid# ./switchbench -n5
> == Sampling period: 1000000 us
> == Do not interrupt this program
> RTH| lat min| lat avg| lat max|
> lost
> RTD| 229.333| 45.666| 229.333|
> 0
>
> Test results with IPIPE tracer enabled
> 1)LATENCY TEST RESULTS:-
> User mode:-
> root@domain.hid# ./latency -t0
> == Sampling period: 1000000 us
> == Test mode: periodic user-mode task
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (periodic user-mode task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 340.000| 340.000| 340.000| 0|
> 340.000| 340.000
> RTD| 338.666| 338.666| 338.666| 0|
> 338.666| 340.000
> RTD| 341.000| 341.000| 341.000| 0|
> 338.666| 341.000
> RTD| 342.000| 342.000| 342.000| 0|
> 338.666| 342.000
>
> 2)kernel mode:-
> root@domain.hid# ./latency -t1
> == Sampling period: 1000000 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 303.333| 303.333| 303.333| 0|
> 303.333| 303.333
> RTD| 309.666| 309.666| 309.666| 0|
> 303.333| 309.666
> RTD| 325.000| 325.000| 325.000| 0|
> 303.333| 325.000
> RTD| 306.333| 306.333| 306.333| 0|
> 303.333| 325.000
>
> Interrupt mode:-
> root@domain.hid# ./latency -t2
> == Sampling period: 1000000 us
> == Test mode: in-kernel timer handler
> == All results in microseconds
> warming up...
> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD| 153.334| 153.334| 153.334| 0|
> 153.334| 153.334
> RTD| 154.667| 154.667| 154.667| 0|
> 153.334| 154.667
> RTD| 164.334| 164.334| 164.334| 0|
> 153.334| 164.334
> RTD| 154.667| 154.667| 154.667| 0|
> 153.334| 164.334
> RTD| 163.667| 163.667| 163.667| 0|
> 153.334| 164.334
The IPIPE tracer seems to add quit some code, Jan, does this look OK for
you?
> 2)CYCLICTEST RESULTS:-
> root@domain.hid# ./cyclictest -t5
> 0.18 0.15 0.09 3/26 194
>
> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 2 ( 190) P:97 I: 2000 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> T: 4 ( 193) P:95 I: 3000 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> Illegal instruction
Can you post the output of /proc/xenomai/faults after the illegal
instruction.
> 3)SWITCHBENCHTEST RESULTS:-
> root@domain.hid# ./switchbench -n5
> == Sampling period: 1000000 us
> == Do not interrupt this program
> RTH| lat min| lat avg| lat max|
> lost
> RTD| 667.333| 133.333| 667.333|
> 0
>
>
> SWITCHTEST:-
> Since FPU is not enabled for ppc, I was not able to
> get proper results for switchtest. Please mail the
> results of switchtest.
"switchtest -n" will not use FPU instructions. Does this work?
Thanks.
Wolfgang.
> Thanks,
> Poornima
>
>
> --- Wolfgang Grandegger <wg@domain.hid> wrote:
>
>> poornima r wrote:
>>> Hi,
>>>
>>> I was able to run latency and switchbench tests on
>>> MPC860 board with IPIPE tracer feature
>>> enabled/disabled.
>> Nice, what versions of Linux and Xenomai did you use
>> for your tests? It
>> is known that Linux 2.6 does not yet work properly
>> for 8xx. It would
>> also be nice if you could briefly post your results
>> on this list as well.
>>
>>> Interrupt & scheduling Latencies and switching
>>> latencies (with IPIPE tracer option disabled) were
>>> having lower values when compared to latency
>> values
>>> with IPIPE tracer enabled.
>> The ipipe tracer introduces some overhead (extra
>> code) and as this CPU
>> is very slow, you will notice it.
>>
>>> cyclictest test results were same with or without
>>> IPIPE tracer enabled.
>> Your results would really be of interest.
>>
>>> Is this reduced context switching latency in
>>> switchbench test due to timer interrupt?
>> Likely it also due to overhead introduced by the
>> ipipe tracer.
>>
>> BTW: the switchtest should run as well with the
>> option "-n" (for not
>> using the FPU),
>>
>> Wolfgang.
>>
>>
>
>
>
>
> ____________________________________________________________________________________
> 8:00? 8:25? 8:40? Find a flick in no time
> with the Yahoo! Search movie showtime shortcut.
> http://tools.search.yahoo.com/shortcuts/#news
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 10:38 ` Wolfgang Grandegger
@ 2007-02-01 11:25 ` poornima r
2007-02-01 13:52 ` Wolfgang Grandegger
2007-02-01 11:34 ` Jan Kiszka
1 sibling, 1 reply; 10+ messages in thread
From: poornima r @ 2007-02-01 11:25 UTC (permalink / raw)
To: adeos-main
Hi,
1)I am using open source kernel from Kernel.org,
but what is meant by vanilla kernel from Kernel.org?
2)With sampling period of 500usec the system simply
hangs without printing any results (./latenct -p500)
3)cyclictest with -t1 option (without IPIPE-tracer)
root@domain.hid# ./cyclictest -t1
2.04 0.50 0.17 8/27 174
T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
Act: 0 Avg: 0 Max:-1000000
Illegal instruction
4)Output of /proc/xenomai/faults after the illegal
instruction:-
root@domain.hid# cat
/proc/xenomai/faults
TRAP CPU0
0: 0 (Data or instruction access)
1: 0 (Alignment)
2: 0 (Altivec unavailable)
3: 0 (Program check exception)
4: 0 (Machine check exception)
5: 0 (Unknown)
6: 0 (Instruction breakpoint)
7: 0 (Run mode exception)
8: 0 (Single-step exception)
9: 0 (Non-recoverable exception)
10: 1 (Software emulation)
11: 0 (Debug)
12: 0 (SPE)
13: 0 (Altivec assist)
5)Running switchtest:-
root@domain.hid# ./switchtest -n
--The system hangs wihtout printing any results
Thanks,
Poornima
--- Wolfgang Grandegger <wg@domain.hid> wrote:
> poornima r wrote:
> > Hi,
> >
> > Thanks for the reply.
> >
> > Linux version:linux-2.6.18
> > Xenomai: xenomai-2.3.0 (Stable version)
> > adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
>
> OK, I'm curious, did you use the vanilla kernel from
> kernel.org?
> More comments below.
>
> > The tests were run as follows:
> > 1)The sampling period in the code for latency and
> > switchbench was changed to 1000000000ns(to remove
> > overrun error)
> > 2)switchtest was run with -n5 option
> > 3)cyclictest was run with -t5 option(5 threads
> > were created.)
> > 4)cyclictest was terminated with Illegal
> instruction
> > (after creating 5 threads) with IPIPE tracer
> enabled.
>
> >
> > These were the results without I-PIPE Tracer
> option:
> > (All the tests were run without any load)
> > 1)LATENCY TEST:-
> > User mode:-
> > /mnt/out_xen/bin# ./latency -t0
> > == Sampling period: 1000000 us
> > == Test mode: periodic user-mode task
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:01 (periodic user-mode task, 1000000
> us
> > period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat
> > max|-overrun|----lat best|---lat worst
> > RTD| 167.000| 167.000| 167.000|
> 0|
> > 167.000| 167.000
> > RTD| 176.000| 176.000| 176.000|
> 0|
> > 167.000| 176.000
> > RTD| 168.000| 168.000| 168.000|
> 0|
> > 167.000| 176.000
> > RTD| 171.000| 171.000| 171.000|
> 0|
> > 167.000| 176.000
> >
> > Kernel mode:-
> > root@domain.hid# ./latency -t1
> > == Sampling period: 1000000 us
> > == Test mode: in-kernel periodic task
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:00 (in-kernel periodic task, 1000000
> us
> > period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat
> > max|-overrun|----lat best|---lat worst
> > RTD| 123.000| 123.000| 123.000|
> 0|
> > 123.000| 123.000
> > RTD| 125.000| 125.000| 125.000|
> 0|
> > 123.000| 125.000
> > RTD| 128.333| 128.333| 128.333|
> 0|
> > 123.000| 128.333
> > RTD| 127.000| 127.000| 127.000|
> 0|
> > 123.000| 128.333
> >
> > Interrupt mode:-
> > root@domain.hid# ./latency -t2
> > == Sampling period: 1000000 us
> > == Test mode: in-kernel timer handler
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:01 (in-kernel timer handler, 1000000
> us
> > period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat
> > max|-overrun|----lat best|---lat worst
> > RTD| 45.334| 45.334| 45.334|
> 0|
> > 45.334| 45.334
> > RTD| 45.000| 45.000| 45.000|
> 0|
> > 45.000| 45.334
> > RTD| 46.000| 46.000| 46.000|
> 0|
> > 45.000| 46.000
> > RTD| 47.334| 47.334| 47.334|
> 0|
> > 45.000| 47.334
> > RTD| 46.334| 46.334| 46.334|
> 0|
> > 45.000| 47.334
>
> I remember similar figures from measurements under
> 2.4. I guess you
> tested without load!? Nevertheless, most of the
> latency is due to code
> execution time because the system is very slow and
> the caches are small.
> The sampling period is 1 second. I think "-p500"
> should already work.
>
> > 2)CYCLICTEST RESULTS:-
> > root@domain.hid# ./cyclictest
> -t5
> > 5.14 3.71 1.72 6/31 216
> >
> > T: 0 ( 0) P:99 I: 1000 C: 0 Min:
> 1000000
> > Act: 0 Avg: 0 Max:-1000000
> > T: 1 ( 0) P:98 I: 1500 C: 0 Min:
> 1000000
> > Act: 0 Avg: 0 Max:-1000000
> > T: 2 ( 212) P:97 I: 2000 C: 8112 Min:
> 169
> > Act: 189 Avg: 204 Max: 288
> > T: 3 ( 0) P:96 I: 2500 C: 0 Min:
> 1000000
> > Act: 0 Avg: 0 Max:-1000000
> > T: 4 ( 216) P:95 I: 3000 C: 21596 Min:
> 180
> > Act: 1279 Avg: 702 Max: 1336
>
> Hm, this looks bogus. What returns "./cyclictest"
> without options (or -t1)?
>
> > 3)SWITCHBENCH TEST RESULTS:-
> > root@domain.hid# ./switchbench
> -n5
> > == Sampling period: 1000000 us
> > == Do not interrupt this program
> > RTH| lat min| lat avg| lat max|
> > lost
> > RTD| 229.333| 45.666| 229.333|
>
> > 0
> >
> > Test results with IPIPE tracer enabled
> > 1)LATENCY TEST RESULTS:-
> > User mode:-
> > root@domain.hid# ./latency -t0
> > == Sampling period: 1000000 us
> > == Test mode: periodic user-mode task
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:01 (periodic user-mode task, 1000000
> us
> > period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat
> > max|-overrun|----lat best|---lat worst
> > RTD| 340.000| 340.000| 340.000|
> 0|
> > 340.000| 340.000
> > RTD| 338.666| 338.666| 338.666|
> 0|
> > 338.666| 340.000
> > RTD| 341.000| 341.000| 341.000|
> 0|
> > 338.666| 341.000
> > RTD| 342.000| 342.000| 342.000|
> 0|
> > 338.666| 342.000
> >
> > 2)kernel mode:-
> > root@domain.hid# ./latency -t1
> > == Sampling period: 1000000 us
> > == Test mode: in-kernel periodic task
> > == All results in microseconds
> > warming up...
> > RTT| 00:00:00 (in-kernel periodic task, 1000000
> us
> > period, priority 99)
> > RTH|-----lat min|-----lat avg|-----lat
> > max|-overrun|----lat best|---lat worst
> > RTD| 303.333| 303.333| 303.333|
> 0|
> > 303.333| 303.333
> > RTD| 309.666| 309.666| 309.666|
> 0|
> > 303.333| 309.666
> > RTD| 325.000| 325.000| 325.000|
> 0|
> > 303.333| 325.000
> > RTD| 306.333| 306.333| 306.333|
> 0|
> > 303.333| 325.000
> >
> > Interrupt mode:-
> > root@domain.hid# ./latency -t2
>
=== message truncated ===
____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http://videogames.yahoo.com/platform?platform=120121
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 10:38 ` Wolfgang Grandegger
2007-02-01 11:25 ` poornima r
@ 2007-02-01 11:34 ` Jan Kiszka
2007-02-01 13:44 ` Wolfgang Grandegger
1 sibling, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2007-02-01 11:34 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: adeos-main
[-- Attachment #1: Type: text/plain, Size: 7001 bytes --]
Wolfgang Grandegger wrote:
> poornima r wrote:
>> Hi,
>>
>> Thanks for the reply.
>>
>> Linux version:linux-2.6.18
>> Xenomai: xenomai-2.3.0 (Stable version)
>> adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
>
> OK, I'm curious, did you use the vanilla kernel from kernel.org?
> More comments below.
>
>> The tests were run as follows:
>> 1)The sampling period in the code for latency and
>> switchbench was changed to 1000000000ns(to remove
>> overrun error) 2)switchtest was run with -n5 option
>> 3)cyclictest was run with -t5 option(5 threads were created.)
>> 4)cyclictest was terminated with Illegal instruction
>> (after creating 5 threads) with IPIPE tracer enabled.
>
>>
>> These were the results without I-PIPE Tracer option:
>> (All the tests were run without any load)
>> 1)LATENCY TEST:-
>> User mode:-
>> /mnt/out_xen/bin# ./latency -t0
>> == Sampling period: 1000000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 167.000| 167.000| 167.000| 0| 167.000|
>> 167.000
>> RTD| 176.000| 176.000| 176.000| 0| 167.000|
>> 176.000
>> RTD| 168.000| 168.000| 168.000| 0| 167.000|
>> 176.000
>> RTD| 171.000| 171.000| 171.000| 0| 167.000|
>> 176.000
>>
>> Kernel mode:-
>> root@domain.hid# ./latency -t1
>> == Sampling period: 1000000 us
>> == Test mode: in-kernel periodic task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 123.000| 123.000| 123.000| 0| 123.000|
>> 123.000
>> RTD| 125.000| 125.000| 125.000| 0| 123.000|
>> 125.000
>> RTD| 128.333| 128.333| 128.333| 0| 123.000|
>> 128.333
>> RTD| 127.000| 127.000| 127.000| 0| 123.000|
>> 128.333
>>
>> Interrupt mode:-
>> root@domain.hid# ./latency -t2
>> == Sampling period: 1000000 us
>> == Test mode: in-kernel timer handler
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 45.334| 45.334| 45.334| 0| 45.334|
>> 45.334
>> RTD| 45.000| 45.000| 45.000| 0| 45.000|
>> 45.334
>> RTD| 46.000| 46.000| 46.000| 0| 45.000|
>> 46.000
>> RTD| 47.334| 47.334| 47.334| 0| 45.000|
>> 47.334
>> RTD| 46.334| 46.334| 46.334| 0| 45.000|
>> 47.334
>
> I remember similar figures from measurements under 2.4. I guess you
> tested without load!? Nevertheless, most of the latency is due to code
> execution time because the system is very slow and the caches are small.
> The sampling period is 1 second. I think "-p500" should already work.
>
>> 2)CYCLICTEST RESULTS:-
>> root@domain.hid# ./cyclictest -t5
>> 5.14 3.71 1.72 6/31 216
>>
>> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
>> Act: 0 Avg: 0 Max:-1000000
>> T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
>> Act: 0 Avg: 0 Max:-1000000
>> T: 2 ( 212) P:97 I: 2000 C: 8112 Min: 169
>> Act: 189 Avg: 204 Max: 288
>> T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
>> Act: 0 Avg: 0 Max:-1000000
>> T: 4 ( 216) P:95 I: 3000 C: 21596 Min: 180
>> Act: 1279 Avg: 702 Max: 1336
>
> Hm, this looks bogus. What returns "./cyclictest" without options (or -t1)?
>
>> 3)SWITCHBENCH TEST RESULTS:-
>> root@domain.hid# ./switchbench -n5
>> == Sampling period: 1000000 us
>> == Do not interrupt this program
>> RTH| lat min| lat avg| lat max| lost
>> RTD| 229.333| 45.666| 229.333| 0
>>
>> Test results with IPIPE tracer enabled
>> 1)LATENCY TEST RESULTS:-
>> User mode:-
>> root@domain.hid# ./latency -t0
>> == Sampling period: 1000000 us
>> == Test mode: periodic user-mode task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 340.000| 340.000| 340.000| 0| 340.000|
>> 340.000
>> RTD| 338.666| 338.666| 338.666| 0| 338.666|
>> 340.000
>> RTD| 341.000| 341.000| 341.000| 0| 338.666|
>> 341.000
>> RTD| 342.000| 342.000| 342.000| 0| 338.666|
>> 342.000
>>
>> 2)kernel mode:-
>> root@domain.hid# ./latency -t1
>> == Sampling period: 1000000 us
>> == Test mode: in-kernel periodic task
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 303.333| 303.333| 303.333| 0| 303.333|
>> 303.333
>> RTD| 309.666| 309.666| 309.666| 0| 303.333|
>> 309.666
>> RTD| 325.000| 325.000| 325.000| 0| 303.333|
>> 325.000
>> RTD| 306.333| 306.333| 306.333| 0| 303.333|
>> 325.000
>>
>> Interrupt mode:-
>> root@domain.hid# ./latency -t2
>> == Sampling period: 1000000 us
>> == Test mode: in-kernel timer handler
>> == All results in microseconds
>> warming up...
>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>> period, priority 99)
>> RTH|-----lat min|-----lat avg|-----lat
>> max|-overrun|----lat best|---lat worst
>> RTD| 153.334| 153.334| 153.334| 0| 153.334|
>> 153.334
>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>> 154.667
>> RTD| 164.334| 164.334| 164.334| 0| 153.334|
>> 164.334
>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>> 164.334
>> RTD| 163.667| 163.667| 163.667| 0| 153.334|
>> 164.334
>
> The IPIPE tracer seems to add quit some code, Jan, does this look OK for
> you?
I've seen almost 2 times higher numbers on an old Pentium I 133 MHz. But
I'm lacking information to relate this particular system to that values.
The increment appears to be fairly high.
BTW, latests i-pipe patches for x86 now include a simple calibration
loop to estimate the minimum tracing overhead per function call. So,
when looking at a real trace, one might be able to asses the impact better.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 11:34 ` Jan Kiszka
@ 2007-02-01 13:44 ` Wolfgang Grandegger
2007-02-01 13:53 ` Jan Kiszka
0 siblings, 1 reply; 10+ messages in thread
From: Wolfgang Grandegger @ 2007-02-01 13:44 UTC (permalink / raw)
To: Jan Kiszka; +Cc: adeos-main
Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> poornima r wrote:
>>> Hi,
>>>
>>> Thanks for the reply.
>>>
>>> Linux version:linux-2.6.18
>>> Xenomai: xenomai-2.3.0 (Stable version)
>>> adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
>> OK, I'm curious, did you use the vanilla kernel from kernel.org?
>> More comments below.
>>
>>> The tests were run as follows:
>>> 1)The sampling period in the code for latency and
>>> switchbench was changed to 1000000000ns(to remove
>>> overrun error) 2)switchtest was run with -n5 option
>>> 3)cyclictest was run with -t5 option(5 threads were created.)
>>> 4)cyclictest was terminated with Illegal instruction
>>> (after creating 5 threads) with IPIPE tracer enabled.
>>> These were the results without I-PIPE Tracer option:
>>> (All the tests were run without any load)
>>> 1)LATENCY TEST:-
>>> User mode:-
>>> /mnt/out_xen/bin# ./latency -t0
>>> == Sampling period: 1000000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 167.000| 167.000| 167.000| 0| 167.000|
>>> 167.000
>>> RTD| 176.000| 176.000| 176.000| 0| 167.000|
>>> 176.000
>>> RTD| 168.000| 168.000| 168.000| 0| 167.000|
>>> 176.000
>>> RTD| 171.000| 171.000| 171.000| 0| 167.000|
>>> 176.000
>>>
>>> Kernel mode:-
>>> root@domain.hid# ./latency -t1
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 123.000| 123.000| 123.000| 0| 123.000|
>>> 123.000
>>> RTD| 125.000| 125.000| 125.000| 0| 123.000|
>>> 125.000
>>> RTD| 128.333| 128.333| 128.333| 0| 123.000|
>>> 128.333
>>> RTD| 127.000| 127.000| 127.000| 0| 123.000|
>>> 128.333
>>>
>>> Interrupt mode:-
>>> root@domain.hid# ./latency -t2
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel timer handler
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 45.334| 45.334| 45.334| 0| 45.334|
>>> 45.334
>>> RTD| 45.000| 45.000| 45.000| 0| 45.000|
>>> 45.334
>>> RTD| 46.000| 46.000| 46.000| 0| 45.000|
>>> 46.000
>>> RTD| 47.334| 47.334| 47.334| 0| 45.000|
>>> 47.334
>>> RTD| 46.334| 46.334| 46.334| 0| 45.000|
>>> 47.334
>> I remember similar figures from measurements under 2.4. I guess you
>> tested without load!? Nevertheless, most of the latency is due to code
>> execution time because the system is very slow and the caches are small.
>> The sampling period is 1 second. I think "-p500" should already work.
>>
>>> 2)CYCLICTEST RESULTS:-
>>> root@domain.hid# ./cyclictest -t5
>>> 5.14 3.71 1.72 6/31 216
>>>
>>> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 2 ( 212) P:97 I: 2000 C: 8112 Min: 169
>>> Act: 189 Avg: 204 Max: 288
>>> T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 4 ( 216) P:95 I: 3000 C: 21596 Min: 180
>>> Act: 1279 Avg: 702 Max: 1336
>> Hm, this looks bogus. What returns "./cyclictest" without options (or -t1)?
>>
>>> 3)SWITCHBENCH TEST RESULTS:-
>>> root@domain.hid# ./switchbench -n5
>>> == Sampling period: 1000000 us
>>> == Do not interrupt this program
>>> RTH| lat min| lat avg| lat max| lost
>>> RTD| 229.333| 45.666| 229.333| 0
>>>
>>> Test results with IPIPE tracer enabled
>>> 1)LATENCY TEST RESULTS:-
>>> User mode:-
>>> root@domain.hid# ./latency -t0
>>> == Sampling period: 1000000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 340.000| 340.000| 340.000| 0| 340.000|
>>> 340.000
>>> RTD| 338.666| 338.666| 338.666| 0| 338.666|
>>> 340.000
>>> RTD| 341.000| 341.000| 341.000| 0| 338.666|
>>> 341.000
>>> RTD| 342.000| 342.000| 342.000| 0| 338.666|
>>> 342.000
>>>
>>> 2)kernel mode:-
>>> root@domain.hid# ./latency -t1
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 303.333| 303.333| 303.333| 0| 303.333|
>>> 303.333
>>> RTD| 309.666| 309.666| 309.666| 0| 303.333|
>>> 309.666
>>> RTD| 325.000| 325.000| 325.000| 0| 303.333|
>>> 325.000
>>> RTD| 306.333| 306.333| 306.333| 0| 303.333|
>>> 325.000
>>>
>>> Interrupt mode:-
>>> root@domain.hid# ./latency -t2
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel timer handler
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 153.334| 153.334| 153.334| 0| 153.334|
>>> 153.334
>>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>>> 154.667
>>> RTD| 164.334| 164.334| 164.334| 0| 153.334|
>>> 164.334
>>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>>> 164.334
>>> RTD| 163.667| 163.667| 163.667| 0| 153.334|
>>> 164.334
>> The IPIPE tracer seems to add quit some code, Jan, does this look OK for
>> you?
>
> I've seen almost 2 times higher numbers on an old Pentium I 133 MHz. But
> I'm lacking information to relate this particular system to that values.
> The increment appears to be fairly high.
It's a MPC860 at 50 MHz, I guess, which is slower than a Pentium I at
133 MHz. The factor of 2 matches fine (= twice as as much code).
> BTW, latests i-pipe patches for x86 now include a simple calibration
> loop to estimate the minimum tracing overhead per function call. So,
> when looking at a real trace, one might be able to asses the impact better.
Is it already in IPIPE v1.5?
Wolfgang.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 11:25 ` poornima r
@ 2007-02-01 13:52 ` Wolfgang Grandegger
0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Grandegger @ 2007-02-01 13:52 UTC (permalink / raw)
To: poornima r; +Cc: adeos-main
poornima r wrote:
> Hi,
>
> 1)I am using open source kernel from Kernel.org,
> but what is meant by vanilla kernel from Kernel.org?
It's the kernel from kernel.org. This means that the Linux kernel 2.6.18
is running fine on your MPC860 platform as is? Thanks for the info.
> 2)With sampling period of 500usec the system simply
> hangs without printing any results (./latenct -p500)
OK.
> 3)cyclictest with -t1 option (without IPIPE-tracer)
> root@domain.hid# ./cyclictest -t1
> 2.04 0.50 0.17 8/27 174
>
> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
> Act: 0 Avg: 0 Max:-1000000
> Illegal instruction
>
> 4)Output of /proc/xenomai/faults after the illegal
> instruction:-
> root@domain.hid# cat
> /proc/xenomai/faults
> TRAP CPU0
> 0: 0 (Data or instruction access)
> 1: 0 (Alignment)
> 2: 0 (Altivec unavailable)
> 3: 0 (Program check exception)
> 4: 0 (Machine check exception)
> 5: 0 (Unknown)
> 6: 0 (Instruction breakpoint)
> 7: 0 (Run mode exception)
> 8: 0 (Single-step exception)
> 9: 0 (Non-recoverable exception)
> 10: 1 (Software emulation)
> 11: 0 (Debug)
> 12: 0 (SPE)
> 13: 0 (Altivec assist)
Hm, I see a software emulation exception which is also the reason for
the illegal instructions. What toolchain do you use? The toolchain
should support software FP emulation.
> 5)Running switchtest:-
> root@domain.hid# ./switchtest -n
> --The system hangs wihtout printing any results
>
> Thanks,
> Poornima
>
>
> --- Wolfgang Grandegger <wg@domain.hid> wrote:
>
>> poornima r wrote:
>>> Hi,
>>>
>>> Thanks for the reply.
>>>
>>> Linux version:linux-2.6.18
>>> Xenomai: xenomai-2.3.0 (Stable version)
>>> adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
>> OK, I'm curious, did you use the vanilla kernel from
>> kernel.org?
>> More comments below.
>>
>>> The tests were run as follows:
>>> 1)The sampling period in the code for latency and
>>> switchbench was changed to 1000000000ns(to remove
>>> overrun error)
>>> 2)switchtest was run with -n5 option
>>> 3)cyclictest was run with -t5 option(5 threads
>>> were created.)
>>> 4)cyclictest was terminated with Illegal
>> instruction
>>> (after creating 5 threads) with IPIPE tracer
>> enabled.
>>
>>> These were the results without I-PIPE Tracer
>> option:
>>> (All the tests were run without any load)
>>> 1)LATENCY TEST:-
>>> User mode:-
>>> /mnt/out_xen/bin# ./latency -t0
>>> == Sampling period: 1000000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000000
>> us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 167.000| 167.000| 167.000|
>> 0|
>>> 167.000| 167.000
>>> RTD| 176.000| 176.000| 176.000|
>> 0|
>>> 167.000| 176.000
>>> RTD| 168.000| 168.000| 168.000|
>> 0|
>>> 167.000| 176.000
>>> RTD| 171.000| 171.000| 171.000|
>> 0|
>>> 167.000| 176.000
>> >
>>> Kernel mode:-
>>> root@domain.hid# ./latency -t1
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:00 (in-kernel periodic task, 1000000
>> us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 123.000| 123.000| 123.000|
>> 0|
>>> 123.000| 123.000
>>> RTD| 125.000| 125.000| 125.000|
>> 0|
>>> 123.000| 125.000
>>> RTD| 128.333| 128.333| 128.333|
>> 0|
>>> 123.000| 128.333
>>> RTD| 127.000| 127.000| 127.000|
>> 0|
>>> 123.000| 128.333
>>>
>>> Interrupt mode:-
>>> root@domain.hid# ./latency -t2
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel timer handler
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (in-kernel timer handler, 1000000
>> us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 45.334| 45.334| 45.334|
>> 0|
>>> 45.334| 45.334
>>> RTD| 45.000| 45.000| 45.000|
>> 0|
>>> 45.000| 45.334
>>> RTD| 46.000| 46.000| 46.000|
>> 0|
>>> 45.000| 46.000
>>> RTD| 47.334| 47.334| 47.334|
>> 0|
>>> 45.000| 47.334
>>> RTD| 46.334| 46.334| 46.334|
>> 0|
>>> 45.000| 47.334
>> I remember similar figures from measurements under
>> 2.4. I guess you
>> tested without load!? Nevertheless, most of the
>> latency is due to code
>> execution time because the system is very slow and
>> the caches are small.
>> The sampling period is 1 second. I think "-p500"
>> should already work.
>>
>>> 2)CYCLICTEST RESULTS:-
>>> root@domain.hid# ./cyclictest
>> -t5
>>> 5.14 3.71 1.72 6/31 216
>>>
>>> T: 0 ( 0) P:99 I: 1000 C: 0 Min:
>> 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 1 ( 0) P:98 I: 1500 C: 0 Min:
>> 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 2 ( 212) P:97 I: 2000 C: 8112 Min:
>> 169
>>> Act: 189 Avg: 204 Max: 288
>>> T: 3 ( 0) P:96 I: 2500 C: 0 Min:
>> 1000000
>>> Act: 0 Avg: 0 Max:-1000000
>>> T: 4 ( 216) P:95 I: 3000 C: 21596 Min:
>> 180
>>> Act: 1279 Avg: 702 Max: 1336
>> Hm, this looks bogus. What returns "./cyclictest"
>> without options (or -t1)?
>>
>>> 3)SWITCHBENCH TEST RESULTS:-
>>> root@domain.hid# ./switchbench
>> -n5
>>> == Sampling period: 1000000 us
>>> == Do not interrupt this program
>>> RTH| lat min| lat avg| lat max|
>>> lost
>>> RTD| 229.333| 45.666| 229.333|
>>
>>> 0
>>>
>>> Test results with IPIPE tracer enabled
>>> 1)LATENCY TEST RESULTS:-
>>> User mode:-
>>> root@domain.hid# ./latency -t0
>>> == Sampling period: 1000000 us
>>> == Test mode: periodic user-mode task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:01 (periodic user-mode task, 1000000
>> us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 340.000| 340.000| 340.000|
>> 0|
>>> 340.000| 340.000
>>> RTD| 338.666| 338.666| 338.666|
>> 0|
>>> 338.666| 340.000
>>> RTD| 341.000| 341.000| 341.000|
>> 0|
>>> 338.666| 341.000
>>> RTD| 342.000| 342.000| 342.000|
>> 0|
>>> 338.666| 342.000
>>>
>>> 2)kernel mode:-
>>> root@domain.hid# ./latency -t1
>>> == Sampling period: 1000000 us
>>> == Test mode: in-kernel periodic task
>>> == All results in microseconds
>>> warming up...
>>> RTT| 00:00:00 (in-kernel periodic task, 1000000
>> us
>>> period, priority 99)
>>> RTH|-----lat min|-----lat avg|-----lat
>>> max|-overrun|----lat best|---lat worst
>>> RTD| 303.333| 303.333| 303.333|
>> 0|
>>> 303.333| 303.333
>>> RTD| 309.666| 309.666| 309.666|
>> 0|
>>> 303.333| 309.666
>>> RTD| 325.000| 325.000| 325.000|
>> 0|
>>> 303.333| 325.000
>>> RTD| 306.333| 306.333| 306.333|
>> 0|
>>> 303.333| 325.000
>>>
>>> Interrupt mode:-
>>> root@domain.hid# ./latency -t2
> === message truncated ===
>
>
>
>
> ____________________________________________________________________________________
> Be a PS3 game guru.
> Get your game face on with the latest PS3 news and previews at Yahoo! Games.
> http://videogames.yahoo.com/platform?platform=120121
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 13:44 ` Wolfgang Grandegger
@ 2007-02-01 13:53 ` Jan Kiszka
2007-02-01 14:19 ` Philippe Gerum
0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2007-02-01 13:53 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: adeos-main
[-- Attachment #1: Type: text/plain, Size: 7854 bytes --]
Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> poornima r wrote:
>>>> Hi,
>>>>
>>>> Thanks for the reply.
>>>>
>>>> Linux version:linux-2.6.18
>>>> Xenomai: xenomai-2.3.0 (Stable version)
>>>> adeos patch: adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>> OK, I'm curious, did you use the vanilla kernel from kernel.org?
>>> More comments below.
>>>
>>>> The tests were run as follows:
>>>> 1)The sampling period in the code for latency and
>>>> switchbench was changed to 1000000000ns(to remove
>>>> overrun error) 2)switchtest was run with -n5 option
>>>> 3)cyclictest was run with -t5 option(5 threads were created.)
>>>> 4)cyclictest was terminated with Illegal instruction
>>>> (after creating 5 threads) with IPIPE tracer enabled.
>>>> These were the results without I-PIPE Tracer option:
>>>> (All the tests were run without any load)
>>>> 1)LATENCY TEST:-
>>>> User mode:-
>>>> /mnt/out_xen/bin# ./latency -t0
>>>> == Sampling period: 1000000 us
>>>> == Test mode: periodic user-mode task
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 167.000| 167.000| 167.000| 0| 167.000|
>>>> 167.000
>>>> RTD| 176.000| 176.000| 176.000| 0| 167.000|
>>>> 176.000
>>>> RTD| 168.000| 168.000| 168.000| 0| 167.000|
>>>> 176.000
>>>> RTD| 171.000| 171.000| 171.000| 0| 167.000|
>>>> 176.000
>>>>
>>>> Kernel mode:-
>>>> root@domain.hid# ./latency -t1
>>>> == Sampling period: 1000000 us
>>>> == Test mode: in-kernel periodic task
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 123.000| 123.000| 123.000| 0| 123.000|
>>>> 123.000
>>>> RTD| 125.000| 125.000| 125.000| 0| 123.000|
>>>> 125.000
>>>> RTD| 128.333| 128.333| 128.333| 0| 123.000|
>>>> 128.333
>>>> RTD| 127.000| 127.000| 127.000| 0| 123.000|
>>>> 128.333
>>>>
>>>> Interrupt mode:-
>>>> root@domain.hid# ./latency -t2
>>>> == Sampling period: 1000000 us
>>>> == Test mode: in-kernel timer handler
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 45.334| 45.334| 45.334| 0| 45.334|
>>>> 45.334
>>>> RTD| 45.000| 45.000| 45.000| 0| 45.000|
>>>> 45.334
>>>> RTD| 46.000| 46.000| 46.000| 0| 45.000|
>>>> 46.000
>>>> RTD| 47.334| 47.334| 47.334| 0| 45.000|
>>>> 47.334
>>>> RTD| 46.334| 46.334| 46.334| 0| 45.000|
>>>> 47.334
>>> I remember similar figures from measurements under 2.4. I guess you
>>> tested without load!? Nevertheless, most of the latency is due to code
>>> execution time because the system is very slow and the caches are small.
>>> The sampling period is 1 second. I think "-p500" should already work.
>>>
>>>> 2)CYCLICTEST RESULTS:-
>>>> root@domain.hid# ./cyclictest -t5
>>>> 5.14 3.71 1.72 6/31 216
>>>>
>>>> T: 0 ( 0) P:99 I: 1000 C: 0 Min: 1000000
>>>> Act: 0 Avg: 0 Max:-1000000
>>>> T: 1 ( 0) P:98 I: 1500 C: 0 Min: 1000000
>>>> Act: 0 Avg: 0 Max:-1000000
>>>> T: 2 ( 212) P:97 I: 2000 C: 8112 Min: 169
>>>> Act: 189 Avg: 204 Max: 288
>>>> T: 3 ( 0) P:96 I: 2500 C: 0 Min: 1000000
>>>> Act: 0 Avg: 0 Max:-1000000
>>>> T: 4 ( 216) P:95 I: 3000 C: 21596 Min: 180
>>>> Act: 1279 Avg: 702 Max: 1336
>>> Hm, this looks bogus. What returns "./cyclictest" without options (or
>>> -t1)?
>>>
>>>> 3)SWITCHBENCH TEST RESULTS:-
>>>> root@domain.hid# ./switchbench -n5
>>>> == Sampling period: 1000000 us
>>>> == Do not interrupt this program
>>>> RTH| lat min| lat avg| lat max| lost
>>>> RTD| 229.333| 45.666| 229.333| 0
>>>>
>>>> Test results with IPIPE tracer enabled
>>>> 1)LATENCY TEST RESULTS:-
>>>> User mode:-
>>>> root@domain.hid# ./latency -t0
>>>> == Sampling period: 1000000 us
>>>> == Test mode: periodic user-mode task
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:01 (periodic user-mode task, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 340.000| 340.000| 340.000| 0| 340.000|
>>>> 340.000
>>>> RTD| 338.666| 338.666| 338.666| 0| 338.666|
>>>> 340.000
>>>> RTD| 341.000| 341.000| 341.000| 0| 338.666|
>>>> 341.000
>>>> RTD| 342.000| 342.000| 342.000| 0| 338.666|
>>>> 342.000
>>>>
>>>> 2)kernel mode:-
>>>> root@domain.hid# ./latency -t1
>>>> == Sampling period: 1000000 us
>>>> == Test mode: in-kernel periodic task
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:00 (in-kernel periodic task, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 303.333| 303.333| 303.333| 0| 303.333|
>>>> 303.333
>>>> RTD| 309.666| 309.666| 309.666| 0| 303.333|
>>>> 309.666
>>>> RTD| 325.000| 325.000| 325.000| 0| 303.333|
>>>> 325.000
>>>> RTD| 306.333| 306.333| 306.333| 0| 303.333|
>>>> 325.000
>>>>
>>>> Interrupt mode:-
>>>> root@domain.hid# ./latency -t2
>>>> == Sampling period: 1000000 us
>>>> == Test mode: in-kernel timer handler
>>>> == All results in microseconds
>>>> warming up...
>>>> RTT| 00:00:01 (in-kernel timer handler, 1000000 us
>>>> period, priority 99)
>>>> RTH|-----lat min|-----lat avg|-----lat
>>>> max|-overrun|----lat best|---lat worst
>>>> RTD| 153.334| 153.334| 153.334| 0| 153.334|
>>>> 153.334
>>>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>>>> 154.667
>>>> RTD| 164.334| 164.334| 164.334| 0| 153.334|
>>>> 164.334
>>>> RTD| 154.667| 154.667| 154.667| 0| 153.334|
>>>> 164.334
>>>> RTD| 163.667| 163.667| 163.667| 0| 153.334|
>>>> 164.334
>>> The IPIPE tracer seems to add quit some code, Jan, does this look OK for
>>> you?
>>
>> I've seen almost 2 times higher numbers on an old Pentium I 133 MHz. But
>> I'm lacking information to relate this particular system to that values.
>> The increment appears to be fairly high.
>
> It's a MPC860 at 50 MHz, I guess, which is slower than a Pentium I at
> 133 MHz. The factor of 2 matches fine (= twice as as much code).
Yeah, might explain it. Seeing some back trace might explain it even
better...
>
>> BTW, latests i-pipe patches for x86 now include a simple calibration
>> loop to estimate the minimum tracing overhead per function call. So,
>> when looking at a real trace, one might be able to asses the impact
>> better.
>
> Is it already in IPIPE v1.5?
http://www.denx.de/cgi-bin/gitweb.cgi?p=ipipe-2.6.git;a=commitdiff;h=fbf44bc1edb77d433a327d1796128d036188635e
(there are no tags in the non-arch branch, are there?)
In the x86 branch, that was merged for 1.6-05.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Adeos-main] switchbench tests with IPIPE tracer disabled
2007-02-01 13:53 ` Jan Kiszka
@ 2007-02-01 14:19 ` Philippe Gerum
0 siblings, 0 replies; 10+ messages in thread
From: Philippe Gerum @ 2007-02-01 14:19 UTC (permalink / raw)
To: Jan Kiszka; +Cc: adeos-main, Wolfgang Grandegger
On Thu, 2007-02-01 at 14:53 +0100, Jan Kiszka wrote:
> http://www.denx.de/cgi-bin/gitweb.cgi?p=ipipe-2.6.git;a=commitdiff;h=fbf44bc1edb77d433a327d1796128d036188635e
> (there are no tags in the non-arch branch, are there?)
>
No.
> In the x86 branch, that was merged for 1.6-05.
>
> Jan
>
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
--
Philippe.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-02-01 14:19 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-01 5:28 [Adeos-main] switchbench tests with IPIPE tracer disabled poornima r
2007-02-01 7:51 ` Wolfgang Grandegger
2007-02-01 9:54 ` poornima r
2007-02-01 10:38 ` Wolfgang Grandegger
2007-02-01 11:25 ` poornima r
2007-02-01 13:52 ` Wolfgang Grandegger
2007-02-01 11:34 ` Jan Kiszka
2007-02-01 13:44 ` Wolfgang Grandegger
2007-02-01 13:53 ` Jan Kiszka
2007-02-01 14:19 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.