From: Darren Hart <dvhltc@us.ibm.com>
To: subrata@linux.vnet.ibm.com
Cc: Clark Williams <williams@redhat.com>,
LTP <ltp-list@lists.sourceforge.net>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
amrith <amrith@linux.ibm.com>
Subject: Re: [LTP] realtime measurement tests: approach to criteria
Date: Tue, 04 Aug 2009 07:28:00 -0700 [thread overview]
Message-ID: <4A784570.4080201@us.ibm.com> (raw)
In-Reply-To: <1249387682.15587.32.camel@subratamodak.linux.ibm.com>
Subrata Modak wrote:
> Hi Darren,
>
> On Mon, 2009-08-03 at 16:30 -0700, Darren Hart wrote:
>> The current ltp/testcases/realtime tests belong to one of func, perf, or
>> stress. While strict pass/fail criteria make sense for functional tests
>> (did the tasks wake up in priority order?), the others use "arbitrary"
>> values and compare those against the whatever is being measured (wakeup
>> latency, etc.) and then determine pass/fail. Ideally the tests
>> themselves would not determine the pass/fail criteria, and would instead
>> simply report on their measurements since the criteria will vary in
>> every use-case based on requirements, workload, hardware, etc.
>>
>> I'd like to propose an approach where the tests only report their
>> measured values (with the exception of the func/* tests which will
>> maintain their pass/fail criteria). Users should be able to populate a
>> criteria.conf file that specified the criteria of each test. The
>> results could then be parsed, compared against the results, and a
>> pass/fail determined from there. I suspect it would be best for the .c
>> tests to just report the numbers and the statistics in a common format
>> and rely on python parser scripts to read the config file and determine
>> pass/fail from there.
>>
>> I'd like users thoughts on this approach before we jump in and start
>> changing things (as this is a fairly invasive change).
>
> This is indeed a good approach. Should we also ask the RT-USERS, who
> might be interested to comment on this ?
Thanks for including the rt-users list, yes I should have done that
originally as well.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
WARNING: multiple messages have this Message-ID (diff)
From: Darren Hart <dvhltc@us.ibm.com>
To: subrata@linux.vnet.ibm.com
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
LTP <ltp-list@lists.sourceforge.net>,
Clark Williams <williams@redhat.com>,
amrith <amrith@linux.ibm.com>,
Sripathi Kodi <sripathik@in.ibm.com>
Subject: Re: realtime measurement tests: approach to criteria
Date: Tue, 04 Aug 2009 07:28:00 -0700 [thread overview]
Message-ID: <4A784570.4080201@us.ibm.com> (raw)
In-Reply-To: <1249387682.15587.32.camel@subratamodak.linux.ibm.com>
Subrata Modak wrote:
> Hi Darren,
>
> On Mon, 2009-08-03 at 16:30 -0700, Darren Hart wrote:
>> The current ltp/testcases/realtime tests belong to one of func, perf, or
>> stress. While strict pass/fail criteria make sense for functional tests
>> (did the tasks wake up in priority order?), the others use "arbitrary"
>> values and compare those against the whatever is being measured (wakeup
>> latency, etc.) and then determine pass/fail. Ideally the tests
>> themselves would not determine the pass/fail criteria, and would instead
>> simply report on their measurements since the criteria will vary in
>> every use-case based on requirements, workload, hardware, etc.
>>
>> I'd like to propose an approach where the tests only report their
>> measured values (with the exception of the func/* tests which will
>> maintain their pass/fail criteria). Users should be able to populate a
>> criteria.conf file that specified the criteria of each test. The
>> results could then be parsed, compared against the results, and a
>> pass/fail determined from there. I suspect it would be best for the .c
>> tests to just report the numbers and the statistics in a common format
>> and rely on python parser scripts to read the config file and determine
>> pass/fail from there.
>>
>> I'd like users thoughts on this approach before we jump in and start
>> changing things (as this is a fairly invasive change).
>
> This is indeed a good approach. Should we also ask the RT-USERS, who
> might be interested to comment on this ?
Thanks for including the rt-users list, yes I should have done that
originally as well.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
next prev parent reply other threads:[~2009-08-04 14:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-03 23:30 [LTP] realtime measurement tests: approach to criteria Darren Hart
2009-08-04 12:08 ` Subrata Modak
2009-08-04 12:08 ` Subrata Modak
2009-08-04 14:28 ` Darren Hart [this message]
2009-08-04 14:28 ` Darren Hart
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=4A784570.4080201@us.ibm.com \
--to=dvhltc@us.ibm.com \
--cc=amrith@linux.ibm.com \
--cc=linux-rt-users@vger.kernel.org \
--cc=ltp-list@lists.sourceforge.net \
--cc=subrata@linux.vnet.ibm.com \
--cc=williams@redhat.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.