I agree with Stephen. You should choose the number of jobs per node by whatever criteria you want (HS06, Hammercloud, whatever) and whatever your sweetspot number N is, run the HS06 benchmark with N jobs, divide the total HS06 by N, publish N as the number of cores/cpu and HS06/N as the benchmark/core. That way, as long as you configure the batch system to run N jobs/node you will get the right installed capacity. I didn't understand the comment about the accounting being wrong.
John
> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Stephen Burke
> Sent: 09 March 2012 17:18
> To: [log in to unmask]
> Subject: Re: CPU publishing (again)
>
> Testbed Support for GridPP member institutes [mailto:TB-
> > [log in to unmask]] On Behalf Of Rob Fay said:
> > This creates a bit of a headache in publishing. My understanding is
> > that the Glue Schema Usage doc (
> > https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallen
> > ges/WLCG_GlueSchemaUsage-1.8.pdf
> > - is this the latest?) explicitly forbids publishing 'overallocations':
>
> But what you seem to be proposing is underallocating rather than
> overallocating, i.e. with HT on you have 24 logical CPUs but you will only
> allow 16 jobs. As long as the 16 is a hard limit I don't see any problem
> with calculating the HEPSPEC by running 16 copies of the benchmark, and
> publishing 16 logical CPUs per node - in effect that's what jobs will see,
> i.e. each (single-threaded) job will get one hyperthread to itself, and the
> maximum contention is from 15 other jobs. And your installed capacity is
> right because although the other 8 logical CPUs per node exist they aren't
> usable.
>
> Stephen
|