All of lore.kernel.org
 help / color / mirror / Atom feed
From: poornima r <rpoornar@domain.hid>
To: Wolfgang Grandegger <wg@domain.hid>
Cc: adeos-main@gna.org
Subject: Re: [Adeos-main] latency results for ppc and x86
Date: Wed, 21 Feb 2007 01:33:11 -0800 (PST)	[thread overview]
Message-ID: <725115.56324.qm@domain.hid> (raw)
In-Reply-To: <45DBF120.2040202@domain.hid>

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


Hello, 

Thankx for the reply.
These tests were actually run without loading the system

Thanks,
Poornima
Wolfgang Grandegger <wg@domain.hid> wrote: Hello,

poornima r wrote:
> Hello,
> 
> These were the scheduling latency and interrupt
> latency test results on ppc and x86 with IPIPE tracer
> option disabled.
> 
> 1.Please comment on these results (whether valid) and 

Your results are OK. These are actually the figures I remember from my 
own tests in the past.

> 2.Is there any method to optimize these results.

No that I know of. There are a few ideas how to reduce latencies further 
like cache locking or TLB pinning.

> 1)PPC:-
> (MPC-860 at 48 MHz, 4 kB I-Cache and 4 kB D-Cache) 
> 
> 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|-----latmax|-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|-----latmax|-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|-----latmax|-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

On the MPC860, the latencies are mainly due code execution time as this 
processor is very slow.

> 2)X86:-
> (Pentium4, 3.06GHz, 1024 KB cache size)
> User mode:-
> Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> 
> RTT|  00:00:01  (periodic user-mode task, 100 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD|       3.807|      12.825|      21.565|       0|  
>     3.807|      21.565
> RTD|       3.796|      12.792|      21.483|       0|  
>     3.796|      21.565
> RTD|       3.770|      12.799|      21.501|       0|  
>     3.770|      21.565
> RTD|       3.578|      12.806|      20.890|       0|  
>     3.578|      21.565
> RTD|       3.755|      12.809|      21.486|       0|  
>     3.578|
> 
> kernel mode:-
> Sampling period: 100 us
> == Test mode: in-kernel periodic task
> == All results in microseconds
> warming up...
> 
> RTT|  00:00:01  (in-kernel periodic task, 100 us
> period, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD|       2.381|       3.451|      19.620|       0|  
>     2.381|      19.620
> RTD|       2.332|       3.480|      19.930|       0|  
>     2.332|      19.930
> RTD|       2.382|       3.649|      19.609|       0|  
>     2.332|      19.930
> RTD|       2.323|       2.786|      14.351|       0|  
>     2.323|      19.930
> RTD|       2.375|       2.532|       5.519|       0|  
>     2.323|      19.930
> RTD|       2.332|       3.971|      19.617|       0|  
>     2.323|      19.930
> 
> Interrupt mode:-
> 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, priority 99)
> RTH|-----lat min|-----lat avg|-----lat
> max|-overrun|----lat best|---lat worst
> RTD|      -1.563|       7.553|      15.736|       0|  
>    -1.563|      15.736
> RTD|      -1.579|       7.558|      15.804|       0|  
>    -1.579|      15.804
> RTD|      -1.584|       7.529|      16.167|       0|  
>    -1.584|      16.167
> RTD|      -1.548|       7.553|      16.186|       0|  
>    -1.584|      16.186
> RTD|      -1.585|       7.556|      16.275|       0|  
>    -1.585|      16.275

Latencies are mainly due to cache refills on the P4. Have you already 
put load onto your system? If not, worst case latencies will be even longer.

Wolfgang.

> Thanks,
> Poornima
> 
> 
> --- Wolfgang Grandegger  wrote:
> 
>> Hello,
>>
>> poornima r wrote:
>>> Hello,
>>>
>>> Srry for not replying all these days...
>>> (Was not in in station, may be too personal!!!!!)
>>>
>>> About software emulation error:
>>>
>>> 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.
>>> 1)I am using open source too chain with software
>>> floating point emulation support.
>>> (#ppc_8xx-gcc --v
>>>
> /lib/gcc/powerpc/3.4.3/../../../../target_powerpc/usr/include/c++/3.4.3
>>> --with-numa-policy=no --with-float=soft)
>>>
>>> 2)And the kernel is included with code to emulate
>> a
>>> floating-point                                    
>>    
>>>          unit, which will allow programs that 
>>> use floating-point                                
>>    
>>>                           instructions to run
>>>
>>> Kernel configuration 
>>> ----CONFIG_MATH_EMULATION:y
>> If you build with "--with-float=soft" there is no
>> need for math 
>> emulation in the kernel. Likely, there is something
>> wrong with your 
>> tool-chain. Could you please try a known-to-work
>> tool-chain like the 
>> ELDK v4.x from http://www.denx.de.
>>
>> Wolfgang.
>>
>>> Thanks,
>>> Poornima
>>>
>>> --- Wolfgang Grandegger  wrote:
>>>
>>>> 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 
>> 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
> === message truncated ===
> 
> 
> 
>  
> ____________________________________________________________________________________
> Get your own web address.  
> Have a HUGE year through Yahoo! Small Business.
> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
> 
> 



 
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.

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

  reply	other threads:[~2007-02-21  9:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <45CD730A.6000405@domain.hid>
2007-02-20  7:21 ` [Adeos-main] latency results for ppc and x86 poornima r
2007-02-21  7:13   ` Wolfgang Grandegger
2007-02-21  9:33     ` poornima r [this message]
2007-02-21  9:33       ` Nicholas Mc Guire
2007-02-21 10:49         ` Jan Kiszka
2007-02-21 10:26           ` Nicholas Mc Guire
2007-02-21 12:29             ` Jan Kiszka
2007-02-21 12:14               ` Nicholas Mc Guire
2007-02-21 13:51                 ` Jan Kiszka
2007-02-21 14:52                   ` Wolfgang Grandegger
2007-02-21 15:10                     ` Nicholas Mc Guire
2007-02-21 18:27                       ` Jan Kiszka
2007-02-21 19:07                         ` Nicholas Mc Guire
2007-02-21 21:05                           ` Jan Kiszka
2007-03-14 12:51     ` [Adeos-main] test results for switchtest and cyclictest on x86 poornima r

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=725115.56324.qm@domain.hid \
    --to=rpoornar@domain.hid \
    --cc=adeos-main@gna.org \
    --cc=wg@domain.hid \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.