On Thu, 10 Sep 2009, Burke, Stephen (STFC,RAL,PPD) wrote:
> LHC Computer Grid - Rollout
>> [mailto:[log in to unmask]] On Behalf Of Gonçalo Borges said:
>> but since we have
>> sufficient memory per core, we allow some overbooking, and I
>> wonder if I
>> should publish the total number of slots (allowed jobs) instead...
>
> No. The CPU power for your whole site is LogicalCPUs*HEPSPEC - you can't
> make your hardware more powerful just by defining more job slots!
>
> In theory you could say that you could reduce the benchmark to compensate, but in practice it would be too complicated and the gain would be very small. Also it would only apply if your site is completely full, most of the time you are probably only running 1 job per core or fewer.
>
>> 3./ I've set up "GlueHostProcessorOtherDescription:
>> Cores=8,Benchmark=54.90-HEP-SPEC06". I assume that the
>> benchmark value
>> should be published by server (and not by core), and that the
>> number of
>> cores is the total number of cores per server, and not per
>> CPU as stated
>> in the docs (which in my case would be 4 since each host has
>> 2 quadcore
>> cpus). Is my assumption right?
>
> No, as I just replied privately the benchmark is per core. Most HEP jobs
> can only run on a single core (at least at the moment!) so that's what
> we're interested in.
The hep-spec benchmark is per node, at least that the number the official
benchmark script outputs (which automatically runs one spec 2006 all_cpp
instance per cpu reported in /proc/cpuinfo - including hyperthreading-
"CPU:s").
So if the infosys benchmark number is per job slot or per core, you should
divide the benchmark number by that. And 54.9 is definately the aggregate
for all 8 cores on the node.
/Mattias Wadenstein
|