lkml.org 
[lkml]   [2005]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-06-22 21:05    [W:4.193 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site