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

[Karim Yaghmour]

Ingo Molnar wrote:
> you should take another look. The crutial difference is that AFAICS 
> lrtbf is using interrupts on _both_ the logger and the target side.  
> lpptest only uses interrupts on the target side (that is what we are 
> measuring), but uses polling _with all interrupts disabled_ on the 
> logger side. This makes things much more reliable, as it's not some 
> complex mix of two worst-case latencies, but a small constant overhead 
> on the logger side and the worst-case latency on the target side. This 
> also means i can run whatever lpptest version on the logger side, i dont 
> have to worry about its latencies because there are none that are 
> variable.

I see. Granted, this is different. We will redo a limited testset
with either lpptest or a modified version of LRTBF that does
exactly what you describe. Specifically, we will redo the testrun
that is the most painfull to vanilla Linux in terms of interrupt
latency, the HD test, for both preempt_rt and ipipe.

However, I have very serious doubts that this will make any
difference whatsoever. Granted the numbers will be slightly lowever,
but it won't invalidate the conclusions previously obtained and it
still won't allow any of us to isolate the exact hardware-
specific overhead of interrupt delivery. IOW, I want to make
sure that it is clear that we're not doing this because we doubt
our results. To the contrary, we're doing it to ensure that any
doubts regarding our results are dissipated.

> logger-side overhead does not matter at all, and the 8 bytes copy is not 
> measured in the overhead. (it is also insignificant.)

Maybe, but your user-space application does a printf on every data
point it gets ... Not the best that can be. The clean thing to do
here is to cumulate the stuff in a buffer and dump it all postmortem.

> well, LPPTEST works just fine with the i8259A PIC too. (which is much 
> more common in embedded setups than IO-APICs)

LRTBF doesn't have a problem with the i8259a, it's the hardware
we were using that didn't behave properly under high interrupt
load. This is a system-specific problem. I haven't run lpptest on
the actual target we used, but I have no reason to believe it
wouldn't behave the same types of problems we got with LRTBF.
There is no difference on the target-side between LRTBF and
lpptest.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@xxxxxxxxxxx || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/