Thu, Nov 15, 2018 at 10:30:50AM CET, olichtne(a)redhat.com wrote:
On Thu, Nov 15, 2018 at 10:23:42AM +0100, Jan Tluka wrote:
> Wed, Nov 14, 2018 at 04:04:46PM CET, olichtne(a)redhat.com wrote:
> >+class Recipe(BaseRecipe):
> >+ def perf_test(self, recipe_conf):
> >+ results = RecipeResults(recipe_conf)
> >+
> >+ for i in range(recipe_conf.iterations):
> >+ run_results = []
> >+ for measurement in recipe_conf.measurements:
> >+ measurement.start()
> >+ for measurement in reversed(recipe_conf.measurements):
>
> I don't understand why it needs to be reversed here.
>
> If I start the measurements as: m1 m2 m3 m4
> I'd expect to finish them in the same order.
>
> Please explain.
Start and finish isn't perfectly synchronized, specifying an order (m1 m2 m3)
makes the tester (at least in my case) feel that they'll start at the
same time or at worst in the specified order, in that case I'd expect
that m1 starts first and will include measurement for the full duration
of m2. And that m2 will include measurement for the full duration of m3
and so on. To do that you need to start them in the specified order and
then finish them in the reverse order.
Does that answer the question?
-Ondrej
Not really :-)
So if we consider the "worst case":
reversed finish call
|
m1.start() ----------| ----- m1.finish()
m2.start() -------| -- m2.finish()
m3.start() ----| m3.finish()
So m1 lasts much longer than m3. Ideally we want them to last the same
time, no?
>>
>> >+ measurement.finish()
>> >+ for measurement in recipe_conf.measurements:
>> >+ measurement_results = measurement.collect_results()
>> >+ results.add_measurement_results(
>> >+ measurement, measurement_results)
>> >+
>> >+ return results
>> >+