On 17/07/17 13:58, Alessandra Forti wrote:
> the various columns are quire inconsistent .... and it would be
> useful to have the information.
There's a loud fire alarm going here which is making me very angry, so
forgive any mistakes.
I agree with you. I think made that point as well. The columns are
inconsistent (and/or inconsistently applied if you know what I mean).
So I intend (in the medium term) to address that problem in the
document. Not today though. Perhaps over the next couple of weeks. I
have thought much about what you are both saying. And I'm going to make
sure that Daniela has exactly the right information that she needs.
There are a lot of problems with the semantics of this information that
I will deal with, but for now I only want to talk about
a) memory,
b) hepspec06, and
c) threads, slots and "instances of the benchmark" (which are all the
same thing.)
> The numbers of threads is not useful if it is not = number of job
> slots since the HS06 value reported in the page
To be valid, the number of threads MUST EQUAL the number of job slots
(where threads == instances of the benchmark used in the measurement).
They are the same thing. That's easily confusing, so let me write about
that, for a minute. Please bear with me on this.
The exact same hardware may be measured with various "numbers of
instances of the benchmark", because the number of slots (which is the
same) varies depending on whether the system is used in VAC or Condor
(for example). VAC uses fewer slots (each job needs more memory than a
standard job). Also, maxHs06 is rarely == cores * 2 (HTs). So the
"instances of the benchmark/slots/threads/whatever" varies from
measurement to measurement, at the same site. Obviously, if
"instancesOfTheBenchmark" varies, then slots/threads change (since they
are the same thing) and memPerSlot varies, since totalMemory is constant!
The hepspec06 measurements are made with a "instancesOfTheBenchmark"
that represents the number of "job slots" that the measurement would be
valid for. Same thing. It would only be valid to use a measurement for a
node that is configured with the same "number of jobs slots" as "number
of instances of the benchmark" used in the calibration.
So, as for requirements:
One must somehow express the total memory used during the measurement
AND one must somehow express the "instancesOfTheBenchmark" used during
the measurement, AND the HS06 obtained.
memPerSlot = totalMem / instancesOfTheBenchmark /* aka "job
slots", for this test */
totalMem = memPerSlot * instancesOfTheBenchmark /* aka "job
slots", for this test */
instancesOfTheBenchmark (for this test) = totalMem / memPerSlot /* for
this test */
And obviously,
totalHS06 = hs06PerSlot * instancesOfTheBenchmark
hs06PerSlot = totalHS06/instancesOfTheBenchmark
instancesOfTheBenchmark = totalHS06/hs06PerSlot
Just like Ohm's law! Anyway, somehow we need to express those ideas
consistency. We've obviously failed in that. In my view, since totalMem
is _always_ constant, regardless of how many instancesOfTheBenchmark
were used, then that is the field to use.
Also give slots/instancesOfTheBenchmark/threads/whatever (they are all
the same), and you can express a totalHs06. If you have the other
fields, everything can be found.
So, in short, we need to update doc with standard field layouts, as
above. Then Daniela will have her data. In summary, I suggest
"totalMem", "totalHepSpec06" and "slots". Those should be the fields.
PS: The context of most of the data is obvious, but it may been some
processing to get the best answers.
Cheers,
Ste
--
Steve Jones [log in to unmask]
Grid System Administrator office: 220
High Energy Physics Division tel (int): 43396
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396
University of Liverpool http://www.liv.ac.uk/physics/hep/
|