Re: PREEMPT_RT vs I-PIPE: 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 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.
> If indeed there are 6 events on a single-side which are worst-case,
> 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 lower-order critical paths - i.e. a worst-case 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
worst-case latency total.

>From all the test i've done, 600,000 samples are not enough to trigger
the worst-case latency - even with the polling method! Also, your tests
dont really load the system, so you have a fundamentally lower chance of
seeing worst-case latencies. My tests do a dd test, a flood ping, an
LTP-40-copies 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 worst-case
path! (which i cannot know for sure to be the worst-case 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

so ... give the -50-12 -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 counter-point because i'm obviously biased :-) I'll let
people without an axe to grind do the measurements. ]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at