Messages in this thread | | | Date | Wed, 22 Jun 2005 15:04:11 -0400 | From | Karim Yaghmour <> | Subject | Re: PREEMPT_RT vs I-PIPE: the numbers, part 2 |
| |
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@opersys.com || 1-866-677-4546 - 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/
| |