[ECOS] Need help for tm_basic tests result interpretation [addon]

[ECOS] Need help for tm_basic tests result interpretation [addon]

[Guilly A]

I forgot some interesting lines :

eCos Kernel Timings
Notes: all times are in microseconds (.000001) unless otherwise stated

Reading the hardware clock takes 2306 'ticks' overhead
... this value will be factored out of all other measurements
Clock interrupt took 5257.09 microseconds (105141 raw clock ticks)

Testing parameters:
   Clock samples:            32
   Threads:                  12
   Thread switches:         128
   Mutexes:                  32
   Mailboxes:                32
   Semaphores:               32
   Scheduler operations:    128
   Counters:                 32
   Flags:                    32
   Alarms:                   32

It seems that my system is veeeeeeeeeery slow to measure the time.
I have no clue why it should me, but it can explain my weird results.
Any idea why it takes me 5 ms to read my system clock ????
TX

>From: "Guilly A" <guilly_work@hotmail.com>
>To: ecos-discuss@sources.redhat.com
>Subject: [ECOS] Need help for tm_basic tests result interpretation
>Date: Thu, 21 Jul 2005 15:06:19 +0000
>
>Hi,
>I ran the tm_basic test on my ARM9 Excalibur dev board (20 Mhz) to evaluate 
>task switching latency.
>I got those results :
>                                 Confidence
>     Ave     Min     Max     Var  Ave  Min  Function
>  ======  ======  ======  ====== ========== ========
>7666.09    0.00 9739.60 2525.44   75%    8%  Create thread
>3120.45 1566.91 6529.98 2069.60   66%   66%  Yield thread [all suspended]
>2378.00 1213.21 6114.28 1743.56   75%   75%  Suspend [suspended] thread
>2541.47 1299.91 6409.08 1859.62   75%   75%  Resume thread
>3267.81 1642.51 6784.58 2162.32   66%   66%  Set priority
>  115.81  114.80  117.40    0.56   66%   33%  Get priority
>8492.99 4557.72 9684.50 1311.31   83%   16%  Kill [suspended] thread
>3123.24 1568.71 6527.68 2071.16   66%   66%  Yield [no other] thread
>3492.77 1871.41 7374.19 2158.86   66%   66%  Resume [suspended low prio] 
>thread
>2524.19 1286.81 6737.48 1854.38   75%   75%  Resume [runnable low prio] 
>thread
>3143.01 1585.51 6678.78 2070.60   66%   66%  Suspend [runnable] thread
>3124.06 1569.71 6543.18 2070.63   66%   66%  Yield [only low prio] thread
>2383.53 1217.31 6110.78 1747.52   75%   75%  Suspend [runnable->not 
>runnable]
>7733.68 4604.72 9704.50 2020.48   66%   33%  Kill [runnable] thread
>5535.64 3034.92 8483.69 2494.61   41%   50%  Destroy [dead] thread
>3379.34 1591.41 7137.59 2225.98   66%   66%  Destroy [runnable] thread
>1324.72  464.40 5441.68  873.83   83%   83%  Resume [high priority] thread
>  348.40 2848.41 7894.09    0.00    0%    0%  Thread switch
>
>This last line gives me troubles. It seems that I can't rely on this 
>numbers, I don't understand how
>we can have such average value below the minimum value. And I found it very 
>slow to take more t han a millisecond to switch from a task to another. I'm 
>I wrong ?
>
>How mutch time should it take on such a target ?
>
>Regards...
>
>_________________________________________________________________
>Vidéoconférence plein écran avec MSN Messenger http://g.msn.fr/FR1001/866
>
>
>--
>Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
>and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Vidéoconférence plein écran avec MSN Messenger http://g.msn.fr/FR1001/866


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Need help for tm_basic tests result interpretation [addon]

[GONZALEZ Laurent]

hello,

I would bet for a misconfiguration in ecos.ecc, or a bug in excalibur HAL.

20 Mhz for an ARM9 ? Is this a typo, or did you really run at that speed ? In the latter case, did you change something in RTC constants defined by HAL ?

Moreever, it's worthy to note that I submitted a patch for tm_basic a few month ago, that fixes a scaling bug. See <http://ecos.sourceware.org/ml/ecos-patches/2005-02/msg00033.html> and try it.

regards,

On Thu, 21 Jul 2005 15:27:57 +0000
"Guilly A" <guilly_work@hotmail.com> wrote:

> I forgot some interesting lines :
> 
> eCos Kernel Timings
> Notes: all times are in microseconds (.000001) unless otherwise stated
> 
> Reading the hardware clock takes 2306 'ticks' overhead
> ... this value will be factored out of all other measurements
> Clock interrupt took 5257.09 microseconds (105141 raw clock ticks)
> 


-- 
GONZALEZ Laurent
-----------------------------------------
Real-Time OS Team Leader
TRANGO Systems - ELSYS Design Group
74, avenue des Martyrs
38000 Grenoble
Tel: 33 (0)4 76 12 28 44
Fax: 33 (0)4 76 12 28 49
-----------------------------------------
Trango, the real-time embedded hypervisor
http://www.trango-systems.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss