This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: ISR Latency & Jitter @x86 hardware platform
- From: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- To: Evgeny Belyanko <evgenylist at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 12 Dec 2007 11:11:05 +0200
- Subject: Re: [ECOS] ISR Latency & Jitter @x86 hardware platform
- References: <475e264a.05be260a.1af2.ffffc343SMTPIN_ADDED@mx.google.com> <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