Hi Goncalo,
the truth is that if the result is 3.84286 you have 3.84286 cores
per node at your cluster. And this is the correct number even for
accounting :).
But i'm not sure if this number is taken in account for the
accounting.
Anyway i'm using a non-integer for long now for Cores and none
complained thus i guess everyone is happy :).
Regards,
Christos
On Mar 2, 2010, at 12:31 PM, Gonçalo Borges wrote:
> Hi Christos
>
>> Try the exact result of CE_LOGCPU/CE_PHYSCPU for the Cores
>> definition in CE_OTHERDESCR. This doesn't have to be an integer.
>>
>
> OK... If I do that I get a 3.84286 value.
>
> The majority of my machines are 2 quadcore cpus with a 9.45-HEP-
> SPEC06 value per core, and for the ones which are different, I
> perform a rescaling on the cpu consumed time at the batch system
> level. So, my question is the following:
>
> - Changing CE_OTHERDESCR from
>
> CE_OTHERDESCR="Cores=4,Benchmark=9.45-HEP-SPEC06"
>
> to
>
> CE_OTHERDESCR="Cores=3.84286,Benchmark=9.45-HEP-SPEC06"
>
> may solve the GSTAT 2.0 issue but won't it bring additional other
> problems specially in the future accounting reference?
>
> Cheers
> Goncalo
>
>
>
|