From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10005 invoked by alias); 12 Dec 2007 09:11:36 -0000 Received: (qmail 9996 invoked by uid 22791); 12 Dec 2007 09:11:35 -0000 X-Spam-Check-By: sourceware.org Received: from stelecom.gomel.by (HELO stelecom.gomel.by) (82.209.213.61) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Dec 2007 09:11:26 +0000 Received: from localhost (unknown [86.57.140.24]) by stelecom.gomel.by (Postfix) with ESMTP id 71230B010497; Wed, 12 Dec 2007 11:11:12 +0200 (EET) Date: Wed, 12 Dec 2007 09:11:00 -0000 From: Sergei Gavrikov To: Evgeny Belyanko Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20071212091105.GA6993@ubuntu> References: <475e264a.05be260a.1af2.ffffc343SMTPIN_ADDED@mx.google.com> <1719361890.20071212004029@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1719361890.20071212004029@gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] ISR Latency & Jitter @x86 hardware platform X-SW-Source: 2007-12/txt/msg00037.txt.bz2 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