Re: PREEMPT_RT vs IPIPE: the numbers, part 2
From: Paul E. McKenney
Date: Wed Jun 22 2005  16:47:54 EST
On Wed, Jun 22, 2005 at 09:04:22PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney <paulmck@xxxxxxxxxx> wrote:
>
> > Any way of getting the logger's latency separately? Or the target's?
>
> with lpptest (PREEMPT_RT's builtin parallelport latency driver) that's
> possible, as it polls the target with interrupts disabled, eliminating
> much of the loggerside latencies. The main effect is that it's now only
> a single worstcase latency that is measured, instead of having to have
> two worstcases meet.
>
> Here's a rough calculation to show what the stakes are: if there's a
> 1:100000 chance to trigger a worstcase 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 worstcase 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 worstcase latencies in your expected
> lifetime, you truly never want to serially couple the probabilities of
> worstcase 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

To unsubscribe from this list: send the line "unsubscribe linuxkernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomoinfo.html
Please read the FAQ at http://www.tux.org/lkml/