John, what cpus does Liverpool have? I notice from gstat that you are publishing 14.13 HS06/core. I cannot spot any entries in the HEPiX database http://w3.hepix.org/benchmarks/doku.php?id=bench:results_sl5_x86_64_gcc_412 of more than 14 per core.
If you have a new type of cpu then it is worth adding it to the HEPiX list.
I also note that you have published 3805 as SI2000 which is the number APEL uses. How did you get this from your HS06 measurement of 14.13? The ratio of your normalised/raw cpu in APEL is 15.22 HS06 which corresponds to the 3805.
You are not the only one whose numbers look odd. Brunel also has one cluster publishing 4400 but they publish multiple clusters separately and I don't understand their setup.
Is there perhaps some normalising issue with your local batch system? Or are you running fewer job slots than cores?
Thanks
John (G)
-----Original Message-----
From: Testbed Support for GridPP member institutes [mailto:[log in to unmask]] On Behalf Of John Bland
Sent: 07 June 2011 18:06
To: [log in to unmask]
Subject: Re: HS06 factor is missing for Durham ATLAS production
On 07/06/11 17:30, Alessandra Forti wrote:
>> instead which is 9.6 then Manchester's 3.5 becomes 7.5
>
> 7.5 is more correct than 3.5. It is a value at least between the hepspec
> range. Liverpool should perhaps check what they run on their
> T3 which isn't included in the value they are publishing.
For the last month or two, absolutely nothing.
John
> cheers
> alessandra
>
>
> On 07/06/2011 16:32, Steve Lloyd wrote:
>> Hi Alessandra,
>> HS06 Prod is arbitrarily normalised to the mean of HS06 ATLAS. This
>> is just a number common to all sites and doesn't affect the shares at
>> all because it cancels out. At the moment that factor is 4.5
>> (indicating Apel is lagging way behind). If I were to normalise it to
>> the mean of HS06 Apel (the next but one column) instead which is 9.6
>> then Manchester's 3.5 becomes 7.5. (HS06 Apel is dodgy as well because
>> for Liverpool it gives a bigger value than any they are publishing.
>> Also I wouldn't trust June yet).
>> The 4% is the change in overall score for Manchester that a 14%
>> change to HS06 would cause (31.8% of 14%). Others would also change so
>> it may actually be slightly more or less than this.
>> Cheers
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> + Steve Lloyd Queen Mary, University of
>> London +
>> + E-mail: [log in to unmask] School of
>> Physics +
>> + Phone: +44-(0)20-7882-5057 Mile End
>> Road +
>> + Fax: +44-(0)20-8981-9465 London E1 4NS,
>> UK +
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>
>>
>>
>>
>> On 7 Jun 2011, at 16:06, Alessandra Forti wrote:
>>
>>> Hi Steve,
>>>
>>> my point is that this is not a transparent method we asked over a
>>> year ago in RHUL. You are mixing and matching columns and trying to
>>> get out a single number that you can't get out. It might fix QMUL
>>> mismatch of cpu hours but it screws up other sites. HSAtlas is
>>> proportional to HSApel which depends heavily on where production jobs
>>> run. If you look at June Manchester figures HSApel is up to 8.1 so it
>>> is getting closer to the 8.8 value we publish while HS-Prod has
>>> dropped to a miserable 3.5. So at the moment we a falling down to
>>> 3.5/8.1=43% (i.e. 57% less). If I complete the move the difference
>>> might become even more dramatic.
>>>
>>>> As it only affects the Analysis and Production categories that's 4%
>>>> on the overall points score.
>>> The weights in the Atlas metrics table [1] give a 31.8%
>>> (35+35/220=31.8%) and if the cpu availability table gets excluded the
>>> weight will become higher. So I'm not sure where you get that 4%.
>>>
>>> But if it is really 4%, which means the CPU output counts almost 0,
>>> which is questionable then I see no point in changing in the middle
>>> of the accounting period to a method that is not well tested , not
>>> very well understood, nor widely recognised.
>>>
>>> cheers
>>> alessandra
>>>
>>> [1] http://pprc.qmul.ac.uk/~lloyd/gridpp/metrics.html
>>>
>>> On 07/06/2011 15:13, Steve Lloyd wrote:
>>>> Hi Alessandra,
>>>> Sorry I don't understand your point at all. I'm proposing to
>>>> switch from HS06 ATLAS to HS06 Prod (col 16 to 17) on
>>>> http://pprc.qmul.ac.uk/~lloyd/gridpp/hs06.html. It's actually 14%
>>>> for May now as I updated the Apel numbers. As it only affects the
>>>> Analysis and Production categories that's 4% on the overall points
>>>> score.
>>>> Cheers Steve
>>>> PS Also HS06 Prod is doesn't require an understanding of hyperthreading
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>> + Steve Lloyd Queen Mary, University of
>>>> London +
>>>> + E-mail: [log in to unmask] School of
>>>> Physics +
>>>> + Phone: +44-(0)20-7882-5057 Mile End
>>>> Road +
>>>> + Fax: +44-(0)20-8981-9465 London E1 4NS,
>>>> UK +
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 7 Jun 2011, at 09:55, Alessandra Forti wrote:
>>>>
>>>>> No, Steve,
>>>>>
>>>>> it doesn't drop 10%. It drops 28% (25% if we want to use APEL HS).
>>>>> We have already discussed the fact that Atlas HS depends on the
>>>>> ration of cpu hours between Apel and Atlas and if the measures in
>>>>> Apel are not complete that affect HS-Atlas.
>>>>>
>>>>> HSAtlas= (CPUApel/CPUAtlas)*HS06.
>>>>>
>>>>> Which transforms your
>>>>>
>>>>> AnalysisHours*HSAtlas and ProdHours*HSAtlas in the orginal
>>>>> AnalysisHoursFrac*HS06 and ProdHoursFrac*HS06
>>>>>
>>>>> so it is 28% you are removing especially because I'm moving all
>>>>> production on the fastest CPUs.
>>>>>
>>>>> Atlas Kit and Hepspec are in line at 99% according to the papers
>>>>> widely accepted measures.
>>>>>
>>>>> cheers
>>>>> alessandra
>>>>>
>>>>>
>>>>>
>>>>> On 07/06/2011 09:47, Steve Lloyd wrote:
>>>>>> Hi Alessandra,
>>>>>> I'm proposing to use the ATLAS production cpu/event as the
>>>>>> benchmark. In May switching from Apel to this would only make 10%
>>>>>> change to Manchester (6.8 -> 6.2). This also solves the problem
>>>>>> at Cambridge where there is no reliable Apel number. Although it
>>>>>> was discussed to drop the CPU availability column there was no
>>>>>> conclusion but investigations into Lancaster are still continuing.
>>>>>> It may be revisited. The proposal was to cap at 20% but this was
>>>>>> not agreed. Glasgow were above 20% but now QMUL has it's new disk
>>>>>> up no-one is. We don't know the total money that will be spent so
>>>>>> you can't translate this into £s.
>>>>>> Cheers Steve
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>> + Steve Lloyd Queen Mary, University
>>>>>> of London +
>>>>>> + E-mail: [log in to unmask] School of
>>>>>> Physics +
>>>>>> + Phone: +44-(0)20-7882-5057 Mile End
>>>>>> Road +
>>>>>> + Fax: +44-(0)20-8981-9465 London E1 4NS,
>>>>>> UK +
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 Jun 2011, at 09:01, Alessandra Forti wrote:
>>>>>>
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>> are we going to discuss this later at the ops meeting? Are you
>>>>>>> using the Atlas Validation Kit [1] to take your measures? Most of
>>>>>>> my objections depend on the fact that I don't trust the software
>>>>>>> but if it was something recognised by WLCG and Hepix I might
>>>>>>> quiet down even if Manchester CPU hours get cut down by 28% with
>>>>>>> this change.
>>>>>>>
>>>>>>> There are other two points in the PMB minutes [2] that would be
>>>>>>> interesting to discuss.
>>>>>>>
>>>>>>> 1) How likely it is that the cpu availability column will be
>>>>>>> dropped and when will we know it?
>>>>>>> 2) It seems a cap will be applied so that no site can get more
>>>>>>> than £200k but the final number hasn't been decided yet. I'm not
>>>>>>> against
>>>>>>> this but it'd be better to know it in advance.
>>>>>>>
>>>>>>> cheers
>>>>>>> alessandra
>>>>>>>
>>>>>>> [1] http://tinyurl.com/65r2k2g
>>>>>>> [2] http://www.gridpp.ac.uk/pmb/minutes/110531.txt
>>>>>>>
>>>>>>>
>>>>>>> On 06/06/2011 22:51, Steve Lloyd wrote:
>>>>>>>> Hi Peter,
>>>>>>>> It looks like Apel hasn't updated yet for June. It seems to
>>>>>>>> be somewhat sluggish. It's fine for previous months so it will
>>>>>>>> probably be OK eventually. Anyway we're probably going to stop
>>>>>>>> using it and use the Production HS06 anyway.
>>>>>>>> Cheers
>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>
>>>>>>>> + Steve Lloyd Queen Mary, University
>>>>>>>> of London +
>>>>>>>> + E-mail:
>>>>>>>> [log in to unmask]
>>>>>>>> School of Physics +
>>>>>>>> + Phone: +44-(0)20-7882-5057 Mile End
>>>>>>>> Road +
>>>>>>>> + Fax: +44-(0)20-8981-9465 London E1 4NS,
>>>>>>>> UK +
>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6 Jun 2011, at 15:07, Peter Grandi wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> In the usual metrics prototype page:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://pprc.qmul.ac.uk/~lloyd/gridpp/metrics.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Durham does not get points for production because the HS6 factor
>>>>>>>>> for that is missing. Looking at the HS factor page:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://pprc.qmul.ac.uk/~lloyd/gridpp/hs06.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the BDII reported value is right, what is missing is the APEL
>>>>>>>>> reported value for HS06. But the APEL reported CPU time is
>>>>>>>>> there, so it is perplexing.
>>>>>>>>>
>>>>>>>>> Unless the APEL value that matters is that for analysis jobs
>>>>>>>>> even for production CPU scaling, which is missing because we
>>>>>>>>> don't do those (yet).
>>>>>>>>>
>>>>>>>>> Where can I look or what can I do?
>>>>>>>>>
--
Dr John Bland [log in to unmask]
System Administrator office: 220
High Energy Physics Division tel (int): 42911
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2911
University of Liverpool http://www.liv.ac.uk/physics/hep/
"I canna change the laws of physics, Captain!"
|