Re: PREEMPT_RT vs IPIPE: the numbers, part 2
From: Ingo Molnar
Date: Wed Jun 22 2005  15:31:37 EST
* Karim Yaghmour <karim@xxxxxxxxxxx> wrote:
> Ingo Molnar wrote:
> > 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.
>
> If indeed there are 6 events on a singleside which are worstcase,
> then you would have to also factor in the probability of obtaining an
> average or below average result on the other side. So again, if all
> runs were measuring average on each side, one would expect that at
> least one of the runs would have a bump over the 55us mark. Yet, they
> all have the same maximum.
if your likelyhood of getting a 'combo max' event is 1:10000000000 then
you'll basically never see the max! What you will see are combinations
of lowerorder critical paths  i.e. a worstcase path of 35 usecs
combined with another, more likely critical path of 20 usecs. You'll
still have the statistical appearance of having found a 'max'.
your only hope to have valid results would be if the likelyhood of the
maximum path is much higher than the one in my example. But even then,
you've significantly reduced the likelyhood of seeing an actual
worstcase latency total.
>From all the test i've done, 600,000 samples are not enough to trigger
the worstcase latency  even with the polling method! Also, your tests
dont really load the system, so you have a fundamentally lower chance of
seeing worstcase latencies. My tests do a dd test, a flood ping, an
LTP40copies test, an rtc_wakeup 8192 Hz test and an infinite loop of
hackbench test all in parallel, and even in such circumstances and with
a polling approach i need above 1 million samples to hit the worstcase
path! (which i cannot know for sure to be the worstcase path, but which
i'm reasonably confident about, based on the distribution of the
latencies and having done tens of millions of samples in overnight
tests.) Obviously it's a much bigger constraint on the IRQ subsystem if
_all_ interrupt _and_ DMA sources in the system are as active as
possible.
so ... give the 5012 RT tree a try and report back the lpptest
results you are getting. [ I know the results i am seeing, but i wont
post them as a counterpoint because i'm obviously biased :) I'll let
people without an axe to grind do the measurements. ]
Ingo

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/