[MAGEEC] [mageec-magicians] Re: Structure of the Results Database

James Pallister James.Pallister at bristol.ac.uk
Wed Aug 28 19:08:51 BST 2013


Hi,

> A test (and test id) refers to a single combination of a platform,
> compiler, benchmark, and flag set.
> A run (and run id) refers to a single run of a test. A test can have
> multiple runs.
In the ERD, do the flags_tests and runs tables need test_id?

> The raw_results table is the bottleneck. We record 200,000+ individual
> results for a single run, so this table will get really quickly.
I'm guessing this is the power trace directly from the measurement
board? If so, the fields should be run_id, timestamp and power.

We may not want to store the entire trace in the database - with
millions of measurements, the database might get unmanagably large -
might be better if the raw_results was just the time, energy, average
power, peak power, etc for that specific run.

> We could split this out into a different results table, but it's a
> one-to-one relationship 
The join between tests and runs should be changed from one-to-many in
the diagram to one-to-one.


Looks good from the energy measurement side :)


James

On 28/08/13 18:24, Simon Hollis wrote:
> Hi Ashley,
>
> Thanks very much for starting this discussion. This is a really good
> starting point.
>
> What I would like is that if everybody who has an interest in the
> structure of this database can provide their feedback on the structure
> that Ashley has proposed and see if it will work for their anticipated
> needs.
>
> As I see it there are at least three interests we need to support:
> Energy Measurement; the MAGEEC framework; ML.
>
> Perhaps all sides could outline the suitability of the proposed
> structure for their needs?
>
> P.S. for Magicians: If you received this message, but not Ashley's
> original one, it is because you are not yet signed up for the external
> mageec at mageec.org mailing list. Please do so!
>
>
> On 28/08/13 17:21, Ashley Whetter wrote:
>> Hey everyone,
>>
>> At the last meeting we looked at the ER diagram
>> (http://mageec.org/wiki/Database) for the database that would store
>> the results that would be recorded by the test framework and used by
>> the plugin.
>>
>> I've taken some of the comments made at the meeting and made a more
>> detailed ER diagram to discuss.
>> (http://mageec.org/w/images/1/19/Results_ERD_Proposal.png)
>>
>> A test (and test id) refers to a single combination of a platform,
>> compiler, benchmark, and flag set.
>> A run (and run id) refers to a single run of a test. A test can have
>> multiple runs.
>>
>> Currently the flag table is only really storing a flag name (eg
>> "-fgcse", "-fno-gcse", etc). I've kept this as a separate table,
>> though, because eventually we'll want to start storing values for
>> flags that aren't just on or off. We could add this value field now,
>> keep the table as is for now, or get rid of flag_id all together and
>> just use the flag name in flags_tests instead.
>>
>> I've put summary data in the runs table. We could split this out into
>> a different results table, but it's a one-to-one relationship it
>> would add an unnecessary overhead of joining the runs and results
>> table when we want to search it. This isn't such a problem if we
>> search for results by run_id though.
>>
>> The raw_results table is the bottleneck. We record 200,000+
>> individual results for a single run, so this table will get really
>> quickly.
>>
>>
>> Ashley
>>
>>
>> _______________________________________________
>> mageec mailing list
>> mageec at mageec.org
>> http://mageec.org/cgi-bin/mailman/listinfo/mageec
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mageec.org/pipermail/mageec/attachments/20130828/172eb8b0/attachment.html>


More information about the mageec mailing list