From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21188 invoked by alias); 20 May 2010 11:30:55 -0000 Received: (qmail 21174 invoked by uid 22791); 20 May 2010 11:30:54 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM X-Spam-Check-By: sourceware.org Received: from mail-fx0-f49.google.com (HELO mail-fx0-f49.google.com) (209.85.161.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 May 2010 11:30:50 +0000 Received: by fxm7 with SMTP id 7so2114976fxm.36 for ; Thu, 20 May 2010 04:30:47 -0700 (PDT) Received: by 10.223.64.205 with SMTP id f13mr6597128fai.98.1274355047481; Thu, 20 May 2010 04:30:47 -0700 (PDT) Received: from sg-desktop.local ([86.57.137.251]) by mx.google.com with ESMTPS id 2sm3610682fav.1.2010.05.20.04.30.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 May 2010 04:30:46 -0700 (PDT) Date: Thu, 20 May 2010 11:52:00 -0000 From: Sergei Gavrikov To: Nikolay Marusov cc: ecos-discuss@ecos.sourceware.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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] Non-stationary DSR and thread resuming latencies X-SW-Source: 2010-05/txt/msg00065.txt.bz2 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