LHC Computer Grid - Rollout
> [mailto:[log in to unmask]] On Behalf Of Mattias Wadenstein
said:
> Ah, totally new documents to me.
As I just said, I'm not sure that the GOC wiki document is right at the
moment, I'll check on that ...
> Wouldn't it make more sense to run the all_cpp benchmarks in the same
> number of copies as the job slots on the node though?
> Especially if one
> would use those numbers for brokering, which I think is one of the
> intended uses.
I don't think so, at least for our way of running. Most sites don't
overcommit cores at all and if they do it's usually only a small factor,
e.g. CERN allow n+1 jobs per n-core CPU. Also if the system is
load-balancing properly that won't make a difference unless the system
is completely full, which is mostly not the case. You could argue the
other way too, if a CPU is only running 1 job the effective benchmark is
probably a bit bigger, but it would be too complicated to allow for that
and a benchmark is only an approximate measure of power anyway.
Also the main goal of overcommitting is to get more efficient use of
the CPU hardware, e.g. if one job is waiting for i/o another job could
be using the core rather than leaving it idle, so the reduction in the
effective benchmark rating seen by each job should be small. If any site
is overcommitting by a big factor, e.g. running two jobs per core, that
would probably be a mistake, at least for HEP where memory is also very
important. For other user communities the situation could be different;
GLUE2 allows sites to publish multiple benchmarks, but with glue 1 we
have to force things a bit.
Stephen
--
Scanned by iCritical.
|