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    [from the cache]
©2003-2011 Jasper Spaans