All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Yeoh, Ee Peng" <ee.peng.yeoh@intel.com>,
	 "'openembedded-core@lists.openembedded.org'"
	<openembedded-core@lists.openembedded.org>
Cc: "Eggleton, Paul" <paul.eggleton@intel.com>
Subject: Re: [PATCH 1/2 v5] resultstool: enable merge, store, report and regression analysis
Date: Thu, 31 Jan 2019 23:39:52 +0000	[thread overview]
Message-ID: <19906ffeb347386b4b1ffbb66105dd98c97f0732.camel@linuxfoundation.org> (raw)
In-Reply-To: <9DDD2658D1FE414E99172D2DB1E4D04348172764@PGSMSX109.gar.corp.intel.com>

On Thu, 2019-01-31 at 05:23 +0000, Yeoh, Ee Peng wrote:
> Hi RP,
> 
> I looked into ptest and regression. The existing "resultstool
> regression" can be used to perform regression on ptest, since the
> testresults.json capture ptest status. I had executed regression
> script for the below 2 ptest testresults.json. Attached was the
> regression report for ptest. 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-2.7_M2.rc1/testresults/qemux86-64-ptest/testresults.json
> https://autobuilder.yocto.io/pub/releases/yocto-2.7_M1.rc1/testresults/qemux86-64-ptest/testresults.json
> 
> The only challenges now was since ptest result set was relatively
> large, it was taking some time for computing the regression. Also
> there was this "ptestresult.rawlogs" testcase that does not contain
> status but the large rawlog. 
> 
> I did an experiment where I run the regression on testresults.json
> with and without the ptest rawlog. It shows the time taken for
> regression was significantly larger when it contain the rawlog. I
> will try to improve the regression time by throw away the rawlog at
> runtime when perform computing. 
> testresults.json with rawlog
> Regression start time: 20190131122805
> Regression end time:   20190131124425
> Time taken: 16 mins 20 sec
> 
> testresults.json without rawlog
> Regression start time: 20190131124512
> Regression end time:   20190131124529
> Time taken: 17 sec

Analysing the rawlog makes no sense so the tool needs to simply ignore
that. 16 minutes is far too long! 

I've just merged some changes which mean there are probably some other
sections it will need to ignore now too since the logs are now being
split out per ptest (section). I've left rawlogs in as its useful for
debugging but once the section splits are working we could remove it.

This adds in timing data so we know how long each ptest took to run (in
seconds), it also adds in exit code and timeout data. These all
complicate the regression analysis but the fact that lttng has been
timing out (for example) has been overlooked until now and shows we
need to analyse these things.

I'm considering whether we should have a command in resulttool which
takes json data and writes it out in a "filesystem" form.

The code in logparser.py already has a rudimentary version of this for
ptest data. It could be extended to write out a X.log for each ptest
based on the split out data and maybe duration and timeout information
in some form too.

The idea behind flat filesystem representations of the data is that a
user can more easily explore or compare them, they also show up well in
git.

Its also worth thinking about how we'll end up using this. testresult
will get called at the end of builds (particularly) release builds and
we'll want it to generate a QA report for the automated test data. The
autobuilder will likely put an http link in the "release build ready"
email to an html like report stored alongside the testresults json
files.

I'm still trying to figure out how to make this all fit together and
allow automated comparisons but the build performance data would also
fit into this (and already has html reports).

Cheers,

Richard



  reply	other threads:[~2019-01-31 23:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22  9:42 [PATCH 0/2 v5] test-case-mgmt Yeoh Ee Peng
2019-01-22  9:42 ` [PATCH 1/2 v5] resultstool: enable merge, store, report and regression analysis Yeoh Ee Peng
2019-01-24  5:50   ` Yeoh, Ee Peng
2019-01-25 15:44   ` Richard Purdie
2019-01-28  2:12     ` Yeoh, Ee Peng
2019-01-28 16:29       ` Richard Purdie
2019-01-29  9:15         ` Yeoh, Ee Peng
     [not found]         ` <E0805CCB83E6104E80E61FD34E5788AE55DD30DC@PGSMSX110.gar.corp.intel.com>
2019-01-31  5:23           ` Yeoh, Ee Peng
2019-01-31 23:39             ` Richard Purdie [this message]
2019-02-14  6:48               ` Yeoh, Ee Peng
2019-01-25 16:18   ` Richard Purdie
2019-01-22  9:42 ` [PATCH 2/2 v5] scripts/resultstool: enable manual execution and result creation Yeoh Ee Peng

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=19906ffeb347386b4b1ffbb66105dd98c97f0732.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=ee.peng.yeoh@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@intel.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.