Re: PREEMPT_RT vs I-PIPE: the numbers, part 2

[Ingo Molnar <mingo@elte.hu>]

* Karim Yaghmour <karim@opersys.com> 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 
possible.

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. ]

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