Re: [ECOS] Non-stationary DSR and thread resuming latencies

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

On Thu, 20 May 2010, Nikolay Marusov wrote:
> Does anyboby know why DSR latency and thead resuming time may SUDDENLY
> increase?

Hi Nikolay,

There are important notes about influences on performance in the eCos
documentation:
http://ecos.sourceware.org/docs-latest/ref/kernel-characterization.html

So, what would pend your DSRs you have to dig by yourself.

[snip]

> Beside all, it is interesting what may delay THE MOST PRIOTITY
> interrupt handler and thread? Maybe eCos scheduler is not so
> determinate?

The eCos `tm_basic` test is a good source to get own testcase and get a
clue. First, what DSR/ISR latency/deviation you get for real-time clock
timer in the test for your target? (RT ISR handler has the highest ISR
priority by default).

Import the below (to measure and RT clock ISR latency), build and run
`tm_basic` test on your target.

  cdl_option CYGVAR_KERNEL_COUNTERS_CLOCK_LATENCY {
      user_value 1
  };

Perhaps, you need to increase NSAMPLES value to get more continuous run
of the test. Note: you may get differ results for the differ types of
startup (ROM, RAM. GDB, etc.) and differ compiler optimization levels.

Well, tm_basic with alone RT ISR/DSR != your_app. But looking on its
output (ideal world) you will be know what you would expect for real
world. I'm sorry, we can only guess about your DSR "issue". For example,
if your program has continuous sections where scheduler locks itself
those can pend your DSR sometimes, etc. Try bitmap scheduler if you can.
Investigate! :-)

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