From: Karim Yaghmour <karim@opersys.com>
To: James R Bruce <bruce@andrew.cmu.edu>
Cc: Kristian Benoit <kbenoit@opersys.com>,
linux-kernel@vger.kernel.org, paulmck@us.ibm.com, bhuey@lnxw.com,
andrea@suse.de, tglx@linutronix.de, mingo@elte.hu,
pmarques@grupopie.com, nickpiggin@yahoo.com.au, ak@muc.de,
sdietrich@mvista.com, dwalker@mvista.com, hch@infradead.org,
akpm@osdl.org, rpm@xenomai.org
Subject: Re: PREEMPT_RT vs ADEOS: the numbers, part 1
Date: Sun, 12 Jun 2005 15:49:55 -0400 [thread overview]
Message-ID: <42AC91E3.7090509@opersys.com> (raw)
In-Reply-To: <39352.210.137.194.5.1118574705.squirrel@210.137.194.5>
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
next prev parent reply other threads:[~2005-06-12 19:42 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-11 4:36 PREEMPT_RT vs ADEOS: the numbers, part 1 Kristian Benoit
2005-06-11 6:14 ` Nick Piggin
2005-06-11 9:15 ` Sven-Thorsten Dietrich
2005-06-11 14:15 ` Kristian Benoit
2005-06-12 15:48 ` Philippe Gerum
2005-06-11 14:39 ` Karim Yaghmour
2005-06-11 22:14 ` Philippe Gerum
2005-06-11 13:57 ` Kristian Benoit
2005-06-11 14:28 ` Zwane Mwaikambo
2005-06-11 7:08 ` Ingo Molnar
2005-06-11 7:44 ` Nick Piggin
2005-06-11 9:27 ` Sven-Thorsten Dietrich
2005-06-12 15:31 ` Philippe Gerum
2005-06-11 14:28 ` Kristian Benoit
2005-06-11 10:37 ` Ingo Molnar
2005-06-11 14:23 ` Kristian Benoit
2005-06-11 14:56 ` Ingo Molnar
2005-06-11 14:31 ` Karim Yaghmour
2005-06-11 14:52 ` Ingo Molnar
2005-06-11 14:52 ` Karim Yaghmour
2005-06-11 17:40 ` Karim Yaghmour
2005-06-11 18:15 ` Ingo Molnar
2005-06-11 18:34 ` Ingo Molnar
2005-06-11 22:27 ` Karim Yaghmour
2005-06-12 10:47 ` James R Bruce
2005-06-12 14:54 ` Ingo Molnar
2005-06-13 2:39 ` Kristian Benoit
2005-06-11 19:14 ` Ingo Molnar
2005-06-11 22:31 ` Karim Yaghmour
2005-06-12 6:11 ` Ingo Molnar
2005-06-12 15:26 ` Daniel Walker
2005-06-12 19:29 ` Karim Yaghmour
2005-06-12 20:59 ` Ingo Molnar
2005-06-13 0:45 ` Andrea Arcangeli
2005-06-13 1:20 ` Karim Yaghmour
2005-06-13 5:47 ` Ingo Molnar
2005-06-12 22:20 ` Andrea Arcangeli
2005-06-12 23:03 ` Sven-Thorsten Dietrich
2005-06-13 0:53 ` randy_dunlap
2005-06-13 1:12 ` Karim Yaghmour
2005-06-13 6:51 ` Sven-Thorsten Dietrich
2005-06-13 15:00 ` Ingo Molnar
2005-06-13 15:12 ` Kristian Benoit
2005-06-11 19:27 ` Ingo Molnar
2005-06-12 4:21 ` Karim Yaghmour
2005-06-11 20:14 ` Paul E. McKenney
2005-06-11 22:33 ` Karim Yaghmour
2005-06-12 20:36 ` Paul E. McKenney
2005-06-12 11:11 ` James R Bruce
2005-06-12 19:49 ` Karim Yaghmour [this message]
2005-06-13 2:32 ` Kristian Benoit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42AC91E3.7090509@opersys.com \
--to=karim@opersys.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=bhuey@lnxw.com \
--cc=bruce@andrew.cmu.edu \
--cc=dwalker@mvista.com \
--cc=hch@infradead.org \
--cc=kbenoit@opersys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=paulmck@us.ibm.com \
--cc=pmarques@grupopie.com \
--cc=rpm@xenomai.org \
--cc=sdietrich@mvista.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox