This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: XIP some kernel parts


On Sat, Jul 11, 2009 at 07:40:00PM +0300, Sergei Gavrikov wrote:
> Why I ask about? I can successfully handle the ISRs every 125 uS using
> ROM startup, but, I cannot do the same when application is running in
> the external RAM (RAM or ROMRAM startup). And I thought about fast and
> unused SRAM for the eCos RTC ISR  handler, handler for pending DSRs,
> etc. i.e. to wrap some parts of the kernel with some attribute, e.g.

More info on issue. I get for my target

*Dhrystones* for *ROM* startup

Microseconds for one run through Dhrystone:    25.5 
Dhrystones per Second:                         39215.7 
VAX MIPS rating =     22.320 

*Dhrystones* for *ROMRAM* startup

Microseconds for one run through Dhrystone:    48.5 
Dhrystones per Second:                         20607.9 
VAX MIPS rating =     11.729 

Okay. You can see that run in external RAM take twice as many time.

The below is the most interesing for me. I could expect that runnig eCos
kernel timing test I will get for ROMRAM startup something multiplied on
2 against the values are getting for ROM startup. But, I get a few
timing faults (look the below, please).

*Kernel timing* for *ROM* startup

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

     Ave     Min     Max     Var  Ave  Min  Function
  ======  ======  ======  ====== ========== ========
    2.69    2.68    3.70    0.02   99%  99% Thread switch
   54.49   54.49   54.49    0.00  100% 100% Tick & fire counters [>1 together]

    1.39    1.37    1.63    0.00            Clock/interrupt latency
    2.49    2.15    4.10    0.00            Clock DSR latency

*Kernel timing* for *ROMRAM* startup

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

     Ave     Min     Max     Var  Ave  Min  Function
  ======  ======  ======  ====== ========== ========
    4.54    4.53    6.07    0.02   99%  99% Thread switch
  315.98   81.30 7591.15  454.70   96%  96% Tick & fire counters [>1 together]
                 ^^^^^^^

    2.10    2.07    2.37    0.00            Clock/interrupt latency
    3.93    3.32   75.29    0.00            Clock DSR latency
                   ^^^^^


Why I get these terrible 'Max' faults? What is a reason can be? Can
anybody commment this?

Thank you,

Sergei

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]