public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Sergei Gavrikov <sergei.gavrikov@gmail.com>
To: Evgeny Belyanko <evgenylist@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] ISR Latency & Jitter @x86 hardware platform
Date: Wed, 12 Dec 2007 09:11:00 -0000	[thread overview]
Message-ID: <20071212091105.GA6993@ubuntu> (raw)
In-Reply-To: <1719361890.20071212004029@gmail.com>

On Wed, Dec 12, 2007 at 12:40:29AM +0300, Evgeny Belyanko wrote:
> Hi!
> 
> I use SM800PC/X smartModule based on the AMD LX800 at 500MHz.
> http://www.digitallogic.ch/index.php?id=143&L=1
> 
> eCos from CVS, date 6 Dec 2007. Loader is GRUB.
> 
> I need to process real rime events with 100uSec (10^-4 Sec) time base.
> Due to some reasons it is impossible to use separate real time MCU to
> make real time processing.
> 
> If I will program eCos system timer for 100 uSec interval, is it real
> on described hardware?

Don't do it! IMO, you shouldn't change a temp rate for the eCos system
timer. If the timer will switch context every .1 mS ... I think a CPU
load will be something like 99 percents and what will be do the CPU?

> If I will use separate IRQ event with 100 uSec interval, what
> interrupt latency (and jitter for this time) can be expected with my
> hardware? The data processing inside ISR very simple, just IO
> acquisition and pushing data in to software FIFO.

You can brief look at
http://ecos.sourceware.org/docs-latest/user-guide/real-time-characterization.html

It seems for me that you can expect the results around this table
http://ecos.sourceware.org/docs-latest/user-guide/rt-i386-pc.html

What does report eCos `tm_basic' benchmark for normal conditions on your
platform? Build the test as

ecosconfig new your_plf
cat << _EOF |ecosconfig import /dev/stdin
cdl_option CYGVAR_KERNEL_COUNTERS_CLOCK_LATENCY {
    user_value 1
};
_EOF
ecosconfig tree
make -s
make -s tests -C kernel/current TESTS=tests/tm_basic

It's just a success story...

For my target (ARM7TDMI/58MHz) I get, for example

     Ave     Min     Max     Var  Ave  Min  Function
  ======  ======  ======  ====== ========== ========

    1.46    1.42    1.70    0.00            Clock/interrupt latency

    3.00    2.59    4.56    0.00            Clock DSR latency

And such a productivity did let me to handle the external IRQ events
which happened every 125uS. That ISR just does fulfil a few I/O
operations and saves data in the small double buffers (buf16) and the
ISR calls DSR on every 16th IRQ event. Using a double-buffering, DSR
quite handles data with a temp rate is equal: .125 * 16 = 2 mS. And this
isn't issue, is it?  Having 7 eCos threads in my application, the
measured CPU load (measured using the eCos `cpuload' service) was 12-15%
when application handled those "hard real-time" IRQ events.


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

      reply	other threads:[~2007-12-12  9:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <475e264a.05be260a.1af2.ffffc343SMTPIN_ADDED@mx.google.com>
2007-12-11 21:40 ` Evgeny Belyanko
2007-12-12  9:11   ` Sergei Gavrikov [this message]

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=20071212091105.GA6993@ubuntu \
    --to=sergei.gavrikov@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=evgenylist@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).