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

James R Bruce wrote:
> It seems that running lmbench improves the maximum response time
> considerably compared to an idle system, unless you touch the
> hard drive. That sort of thing makes very little sense though,
> and thus is likely an artifact of the testing. Maybe the test
> needs to be run for longer, or maybe each test should be
> duplicated a few times? I realize the max is always going to be
> pretty noisy, but we can't really compare approaches much if it
> jumps around by a factor of 2.5. Then again, maybe lmbench *does*
> improve latency and that would definitely be a bug somewhere that
> you've uncovered :)

Actually I personally read these numbers as being very good. What
I see here is that there were exactly two maximums on 5 different
configs and that standard deviation was always close to 0. What that
means is that Adeos' performance degradation is stepwise and can be
studied (i.e. in order to obtain things like: 60% of the time your
maximum will be 53us and 40% of the time, it'll be 22us.) I don't
think there's any correlation between the setup and the maximum
observed. Instead, it's more like ints were generated by the logger
every 1ms and 1ms is an eternity, so on every odd moon, a combination
of factors resulted in the 53 us actually occuring, but on other
setups, with luck, the maximum was less.

The real remedy to this would be to certainly run longer tests, but
more importantly, it would be to generate a lot more interrupts from
the logger at random times instead of just every 1ms. This would
avoid any sort of artificial sync that may occur between the logger
and the target by virtue of having the logger generate interrupts at
exactly every 1ms. This type of test, though, would be more
complicated and it would require very careful design on the logger
side to avoid introducing any sort of articial latency into the
measurement process.

> The nicest results would be CDFs or histograms of the response
> times, plotted againts each other for east comparison. Obviously
> that makes more work for you, however. If we can get full traces
> from the logger as text, then its easy for us to make such graphs,
> or add some scripts to your testbed once its released to generate
> them automatically with gnuplot/etc.

We will be providing full traces, amongst other things. And
getting additions/modifications allowing the automatic generation
of graphs, and other stuff would be great.

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 21:50    [W:0.732 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site