Messages in this thread | | | Date | Thu, 23 Jun 2005 03:34:51 +0200 | From | Ingo Molnar <> | Subject | Re: PREEMPT_RT vs I-PIPE: the numbers, part 2 |
| |
* Karim Yaghmour <karim@opersys.com> wrote:
> If I wanted to show "my" project in such a good light, would I have > gone back and redone tests, and then published them even if those > numbers now showed that the "other" project was as good as "mine"? > Would I have even listened to any of your suggestions and gone back > and had the tests changed to fit your requirements? Would I still be > telling that we're going to further fix the tests based on your > feedback?
if anything i wrote offended you i'd like to apologize for it. I feel pretty strongly about the stuff i do, but i always regret 99.9% of the flames in the next morning :) Also, i only realized when reading your reply that you took my "vendor sponsored benchmarking" remark literally (and that's my bad too). I never thought of you as a 'vendor' or having any commercial interest in this benchmarking - it was just a stupid analogy from me. I should have written "supporter driven benchmarking" or so - that would still have been a pretty nice flame ;)
also please consider the other side of the coin. You posted numbers that initially put PREEMPT_RT in a pretty bad light. Those numbers are still being linked to from your website, without any indication to suggest that they are incorrect. Even in your above paragraph you are not talking about flawed numbers, you are talking about 'changing the tests to fit my requirements'. Heck i have no 'requirements' other than to see fair numbers. And if adeos/ipipe happens to beat PREEMPT_RT in a fair irq latency test you wont hear a complaint from me. (you might see a patch quite soon though ;)
And i know what irq latencies to expect from PREEMPT_RT. It takes me 5 minutes to do a 10 million samples irq test using LPPTEST, the histogram takes only 200 bytes on the screen, and the numbers i'm getting differ from your numbers - but obviously i cannot run it on your hardware. The rtc_wakeup and built-in latency-tracer numbers differ too. They could be all wrong though, so i'm curious what your independent method will yield.
your lmbench results look accurate and fair, the slowdown during irq-load is a known and expected effect of IRQ threading. If you flood ping a box and generate context-switches instead of plain interrupts, there will be noticeable overhead. I checked some of the lmbench numbers today on my testbox, and while there's overhead, it's significantly less than the 90% degradation you were seeing. That's why i suggested to you to retest using the current base - but you of course dont 'have to'. There were a number of bugs fixed in the past few dozen iterations of patches that affected various components of lmbench :)
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/
| |