Re: [Adeos-main] test results for switchtest and cyclictest on x86

[poornima r <rpoornar@domain.hid>]

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

Hello,
   
  There were the results for cyclictest and switchbench test results run on X86
  (without load)
   
  System specifications:-
  Xenomai: xenomai-2.3.0
  Linux kernel: linux-2.6.19.3
  CPU speed : 2.79GHz
  Cache: 512KB
  
 
  a) Switchtest:-
   
  Results:
   
  ./switchtest -T 50 -n rtk rtup rtus
  (-T:limit of test duration i.e 50 seconds
  -n:disables any use of FPU instructions.
  threadspec:rtk i.e kernel-space realtime thread ,rtup i.e for a user-space real-time thread running in primary mode,rtus i.e user-space real-time thread running in secondary mode)
   
  RTT| 00:00:01
  RTH|ctx switches|-------total
  RTD| 1000| 1000
  RTD| 1004| 2004
  RTD| 1002| 3006
  RTD| 1006| 4012
  RTD| 1004| 5016
  RTD| 1002| 6018
  RTD| 1006| 7024
  RTD| 998| 8022
  RTD| 1006| 9028
  RTD| 1004| 10032
  RTD| 516| 10548
  RTD| 504| 11052
  RTD| 504| 11556
  RTD| 504| 12060
  RTD| 504| 12564
  RTD| 504| 13068
  RTD| 504| 13572
  RTD| 504| 14076
  RTD| 504| 14580
  RTD| 504| 15084
  RTD| 504| 15588
  RTT| 00:00:22
  RTH|ctx switches|-------total
  RTD| 510| 16098
  RTD| 846| 16944
  RTD| 996| 17940
  RTD| 1002| 18942
  RTD| 996| 19938
  RTD| 1006| 20944
  RTD| 1004| 21948
  RTD| 1000| 22948
  RTD| 1004| 23952
  RTD| 1002| 24954
  RTD| 1006| 25960
  RTD| 1004| 26964
  RTD| 1002| 27966
  RTD| 1006| 28972
  RTD| 1004| 29976
  RTD| 1002| 30978
  RTD| 1006| 31984
  RTD| 998| 32982
  RTD| 1006| 33988
  RTD| 1004| 34992
  RTD| 1002| 35994
  RTT| 00:00:43
  RTH|ctx switches|-------total
  RTD| 1002| 36996
  RTD| 1002| 37998
  RTD| 1006| 39004
  RTD| 1004| 40008
  RTD| 1002| 41010
  RTD| 1002| 42012
  RTD| 1002| 43014
  RTD| 790| 43804
   
  Total no of context switches between kernel-space realtime thread ,user-space real-time 
  thread running in primary mode and user-space real-time thread running in secondary mode is 43804.
   
  b)cyclictest:-
   
  Results:- 
   
  ./cyclictest -l 100
  0.59 0.13 0.06 1/99 25688
  T: 0 (25688) P:99 I: 1000 C: 100 Min: 7 Act: 7 Avg: 9 Max: 24
   
  1) Please comment on these results.
  2) What are we benchmarking from the above cyclictest result?
   
  Thanks and Regards,
  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
> 
> 



 
---------------------------------
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
 
---------------------------------
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.

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