I'm inclined to say 'let's just do it right the first time' meaning
let's implement the 3D table we designed a few weeks ago. This would
allow for arbitrary storage of performance data. But would take a
considerable amount of effort.
However, it would probably be quicker to implement a NBC performance
table and do the right plumbing to make it work. The problem is that
next time we want to add a new performance data table will have to do
all this all over again. :/
I'll have to see the layout of the data when Torsten gets back to
determine how complex the database table will need to be. I suspect
it won't be too bad, but can't say for sure at the moment.
Unfortunately I'm swamped at the moment, so I probably won't be able
to work on this for a few months out, but I can help with planning
On Oct 8, 2007, at 12:49 PM, Jeff Squyres wrote:
> Ethan/Josh --
> Torsten's libnbc benchmark program outputs a whole bunch of numbers
> that we are not currently recording. Essentially, it outputs a fixed
> number of double precision numbers for each message size (each of
> which has a different meaning). We obviously currently cannot record
> all of these numbers in the database.
> Torsten will come find Josh when he returns to IU to discuss if it
> would be easy/hard to store this stuff in the database -- that would
> be the first step. Next we will need to update submit.php and the
> client to submit the data properly and then store it in the DB.
> Finally, we will need to update the reporter to visualize this
> information in a new way (it's more than just standard latency/
> bandwidth information).
> There is no immediate need to get this all done, but it should be
> added to the "to do" list to eventually get done. I'll file a ticket
> about it.
> I think that this is different than the SKaMPI storage problem
> because the number of values that are output for each message size is
> fixed (the extended SKaMPI output has a number for each MPI
> process). So I *think* it should be fairly easy to add a new table
> for libnbc data in the database...?
> Jeff Squyres
> Cisco Systems
> mtt-devel mailing list