From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262386AbVFVV1u (ORCPT ); Wed, 22 Jun 2005 17:27:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262540AbVFVV0v (ORCPT ); Wed, 22 Jun 2005 17:26:51 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]:31428 "EHLO e34.co.us.ibm.com") by vger.kernel.org with ESMTP id S262301AbVFVVTs (ORCPT ); Wed, 22 Jun 2005 17:19:48 -0400 Date: Wed, 22 Jun 2005 14:20:14 -0700 From: "Paul E. McKenney" To: Ingo Molnar Cc: Kristian Benoit , Karim Yaghmour , linux-kernel@vger.kernel.org, bhuey@lnxw.com, andrea@suse.de, tglx@linutronix.de, pmarques@grupopie.com, bruce@andrew.cmu.edu, nickpiggin@yahoo.com.au, ak@muc.de, sdietrich@mvista.com, dwalker@mvista.com, hch@infradead.org, akpm@osdl.org, Philippe Gerum Subject: Re: PREEMPT_RT vs I-PIPE: the numbers, part 2 Message-ID: <20050622212014.GH1296@us.ibm.com> Reply-To: paulmck@us.ibm.com References: <1119287612.6863.1.camel@localhost> <20050621015542.GB1298@us.ibm.com> <42B77B8C.6050109@opersys.com> <20050622011931.GF1324@us.ibm.com> <42B9845B.8030404@opersys.com> <20050622162718.GD1296@us.ibm.com> <1119460803.5825.13.camel@localhost> <20050622185019.GG1296@us.ibm.com> <20050622190422.GA6572@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050622190422.GA6572@elte.hu> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 22, 2005 at 09:04:22PM +0200, Ingo Molnar wrote: > > * Paul E. McKenney wrote: > > > Any way of getting the logger's latency separately? Or the target's? > > with lpptest (PREEMPT_RT's built-in parallel-port latency driver) that's > possible, as it polls the target with interrupts disabled, eliminating > much of the logger-side latencies. The main effect is that it's now only > a single worst-case latency that is measured, instead of having to have > two worst-cases meet. > > Here's a rough calculation to show what the stakes are: if there's a > 1:100000 chance to trigger a worst-case irq handling latency, and you > have 600000 samples, then with lpptest you'll see an average of 6 events > during the measurement. With lrtfb (the one Karim used) the chance to > see both of these worst-case latencies on both sides of the measurement > is 1:10000000000, and you'd see 0.00006 of them during the measurement. > I.e. the chances of seeing the true max latency are pretty slim. My concern exactly! > So if you want to reliably measure worst-case latencies in your expected > lifetime, you truly never want to serially couple the probabilities of > worst-case latencies on the target and the logger side. Sounds more practical than the analytical approach! (Take the Laplace transform of the density function, square root, and then take the inverse Laplace transform, if I remember correctly... Which would end up showing a small probability of the maximum latency being the full amount, which ends up really not telling you anything.) Thanx, Paul