From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10709 invoked by alias); 8 Aug 2007 08:10:23 -0000 Received: (qmail 10602 invoked by uid 22791); 8 Aug 2007 08:10:22 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 08 Aug 2007 08:10:19 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1IIgcR-0000C1-00; Wed, 08 Aug 2007 10:10:15 +0200 Date: Wed, 08 Aug 2007 08:10:00 -0000 From: Andrew Lunn To: "Alois Z." Cc: eCos Disuss Message-ID: <20070808081015.GB29246@lunn.ch> Mail-Followup-To: "Alois Z." , eCos Disuss References: <20070807140234.264490@gmx.net> <20070807144047.GF14598@lunn.ch> <20070808075810.250840@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070808075810.250840@gmx.net> User-Agent: Mutt/1.5.16 (2007-06-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] Thread activation disturbed by lower priority threads] X-SW-Source: 2007-08/txt/msg00040.txt.bz2 On Wed, Aug 08, 2007 at 09:58:10AM +0200, Alois Z. wrote: > > -------- Original-Nachricht -------- > Datum: Tue, 7 Aug 2007 16:40:47 +0200 > Von: Andrew Lunn > An: "Alois Z." > CC: ecos-discuss@ecos.sourceware.org > Betreff: Re: [ECOS] Thread activation disturbed by lower priority threads] > > > On Tue, Aug 07, 2007 at 04:02:34PM +0200, Alois Z. wrote: > > > Hi, > > > > > > as I got no response to me questions (see below) I may have to add a > > > few things for clarification. > > > > > > First of all I'm running an an AT91M5580A processor (thy phytec > > > board). I changed the ecos settings so that the timer tick is now > > > 1ms. The reason for this is that I need such a small tick for my > > > application. Does this anyhow influence the scheduling > > > algorithm. Are there settings that need to be adjusted appart from > > > denominator, nominator and timesclice value? > > > > > > I did more measurements and found out that the timer DSR is really > > > stable. even more stable than on some other systems (non ecos) I'm > > > using. The problem is that the time between posting on the semaphore > > > (the thread is waiting on) until the thread starts executing is > > > varying largly. It seems that it is prolonged by other execution > > > elements. And this even when the thread under question is the thread > > > with the highest priority. would be great if this clearifies my > > > problem a little bit more. > > > > If it is the highest priority runnable thread, as soon as the DSR > > finished it should get to run. The only exception i can think of is if > > some other thread has the scheduler locked. This would prevent a > > context switch until the scheduler was unlocked. > > > > How to you do your timing between the DSR timer and thread running? > > I just set bits in both and can than see the timing on an > oscilloscope. This works really good and I did the same measurements > on different boards. Do you set the bits just after the semaphore operations, or later, when it does the real work? I'm just thinking about the mutex issue. > > Does this high priority thread need to acquire a mutex etc? It could > > be that something else has the mutex. So it has to wait for it to be > > released. Priority inversion then happens. The lower priority thread > > which holds the mutex gets boosted in priority to the priority of the > > waiting thread. This should allow the low priority thread to finish > > what it is doing and release the mutex. However there is one > > wrinkle. eCos only undoes priority inversion when the thread releases > > all its mutex, not just the mutex of interest. > > > > Andrew > > > There is may be a mutex the high priority thread has to wait for. It > is just one and typically the lock time is rather > short. Unfortunatly every thread will use this mutex so maybe thats > the reason for my problem. As I think now of it it may be a bad > design, but because of other constraints it will not be possible to > remove this mutex. By the way it works on other real-time operating > systems (e.g. ThreadX). So I should think on the riority inversion > protocol for the mutexes, i'm right? Just for the purpose of testing a theory, take out the mutex. If the timing gets better, you know the mutex is the problem. You might also want to look at kernel instrumentation. http://ecos.sourceware.org/docs-latest/user-guide/kernel-instrumentation.html Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss