From: "K.R. Foley" <kr@cybsft.com>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: Tim Bird <tim.bird@am.sony.com>,
CE Linux Developers List <celinux-dev@tree.celinuxforum.org>,
linux-rt-users@vger.kernel.org, RTWG@LIST.CELINUXFORUM.ORG
Subject: Re: [Celinux-dev] Rt-preempt testing best practices
Date: Wed, 16 May 2007 09:24:59 -0500 [thread overview]
Message-ID: <464B143B.7060505@cybsft.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0705160511090.649@rtl14.hofr.at>
Nicholas Mc Guire wrote:
>
>> I'm writing to tell you about a project I'm working on.
>> I'm trying to collect as much information as I can about
>> testing real time performance of Linux.
>
>> I've started a wiki page at:
>> http://tree.celinuxforum.org/CelfPubWiki/RealtimeTestingBestPractices
>> (which is on CELF's wiki)
>
> The tests noted in the LKML post on this page are very problematic, ping
> -f is not testing RT at all, it keeps the kernel in a very small active
> page set thus reducing page related penalties, the while loop using dd
> is also not too helpfull as it will de-facto run only in memory and cause
> absolutely no disk/mass-storage related interaction (try the same with
> mount -o remount,sync / first and it will be devastating ! (limited to
> ext2/ext3/ufs))
>
> The big problem with RT tests published is that they are all looking at
> the good case, they are loading the system but assuming successfull
> operations. The worst cases pup up when you run in the error paths of
> the kernel - then a trivial application can induce very large jitter in
> the system (run crashme in the background and rerun the tests...)
>
> Also lmbench can give a statistic view of things (and not even that very
> precisely in some case i.e. context switch measurements are flawed) so
> this is not of much help for descision makers which variant to use - it
> does not help if the average performance is good but the mobile phone or
> mp3 klicks at 1s intervales "deterministically" - so I guess RT
> benchmarks need a notion of usage-profile to be of value.
>
>
>> However, I think this material would be better placed
>> on the Linux RT wiki at: http://rt.wiki.kernel.org/index.php/Main_Page
>> Does anyone have any problem with me moving the content to there,
>> and continuing my attempt to document this on that site?
>
>
> Note that this page is dedicated to RT-preempt and will most likely not
> cover the other variants of RT Linux availabe - so it might well be a
> good idea to maintain an independant page but cross-link them ?
>
>> Note that there's some duplication of content with other
>> pages on the RT wiki. I'll try to clean this up during the move.
>
>> Any comments or suggestions are welcome.
>
>> If you have done RT testing, and especially if you have published
>> information I can look at (and link to), please contact me.
>
> There are a number of publications related to both benchmarking and
> analysis of hardware related artefacts (cache,BTB,TLB,etc.) which were
> published at the real-time Linux Workshops - should I collect them
> together and send you those as tar.bz2 or just the links ?
>
I would definitely be interested in such material myself. We are
actually using the RT patches in real world scenarios on probably 50+
systems (some are development workstations and others are
hardware-in-the-loop simulation test systems) and they perform very
well. However, it would be nice to have a battery of tests (both
correctness and determinism)that could be used to compare future versions.
> hofrat
-
To unsubscribe from this list: send the line "unsubscribe
linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
kr
next prev parent reply other threads:[~2007-05-16 14:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 0:26 Rt-preempt testing best practices Tim Bird
2007-05-16 3:22 ` [Celinux-dev] " Nicholas Mc Guire
2007-05-16 14:24 ` K.R. Foley [this message]
2007-05-16 17:02 ` Tim Bird
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=464B143B.7060505@cybsft.com \
--to=kr@cybsft.com \
--cc=RTWG@LIST.CELINUXFORUM.ORG \
--cc=celinux-dev@tree.celinuxforum.org \
--cc=der.herr@hofr.at \
--cc=linux-rt-users@vger.kernel.org \
--cc=tim.bird@am.sony.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.