lkml.org 
[lkml]   [2005]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PREEMPT_RT vs ADEOS: the numbers, part 1

    Ingo Molnar wrote:
    > hackbench:
    >
    > http://developer.osdl.org/craiger/hackbench/
    > http://developer.osdl.org/craiger/hackbench/src/hackbench.c
    [snip]
    > this is good at triggering worst-case latencies too. Plus dbench is good
    > too:
    >
    > http://samba.org/ftp/tridge/dbench/
    > http://samba.org/ftp/tridge/dbench/dbench-3.03.tar.gz

    hackbench and dbench are fine by me, they seem good tests to run.

    However ...

    > also, there's a very good on-host IRQ-latency measurement tool as well:
    >
    > http://www.affenbande.org/~tapas/wiki/index.php?rtc_wakeup

    This tool I just can't trust. Any software tool that measures the
    interrupt latency of the system on which it runs is highly suspect.
    There are far too many things happening on the system itself for
    the tool to act as an "independent" observer. The only true way to
    measure interrupt latency is to have some outside system generate
    the interrupts and measure the target system's response time.

    In our early tests, we actually had an oscilloscope hooked onto
    the target and we had a function generator ready to go for pumping
    square waves into the target. However, after spending quite some
    time looking at the output on the scope, we concluded that there
    was just no way for us to measure the peaks (at least with the
    scope we had access to; there are very fancy scopes out there
    that can probably do a better job by collecting entire samples,
    but we don't have those at hand and so too will it be very likely
    that others who want to make such measurements may not have
    access to such scopes.) Hence the use of the logger to trigger
    and measure interrupts. The logger, target and host setup we
    put together can very well be implemented using even antiquated
    PCs, something any computer enthusiast can easily obtain very
    cheaply at any used computer parts store in their neighborhood.

    <background>
    A truly hard-rt deterministic system should be very easily
    viewed using a function generator and a scope. You pump the
    square wave, and the measured system generates a delayed
    wave. The interrupt latency is the distance between the two.
    You would then be able to increase the square wave's frequency
    and see the target system follow, up until it couldn't respond
    no more and then by turning the knob down back again, you would
    find the nice response square waves again. On modern PCs, even
    the hardware isn't deterministic, so you can't see such nice
    waves. Instead, you need to collect samples and determine
    maximums.
    </background>

    So hackbench and dbench yes, but rtc_wakeup ... hmm ...

    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-12 06:14    [W:3.735 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site