On 28 June 2010 11:48, Christopher J.Walker <[log in to unmask]> wrote:
> Mike Kenyon wrote:
>>
>> Hi Ben,
>>
>> Responses inline
>>
>> On 26 June 2010 10:05, Ben Waugh <[log in to unmask]> wrote:
>
>>> There are of course other factors affecting job throughput, including
>>> hard disks and RAM. Is there some way of measuring the effect of
>>> these, or would you just set a minimum requirement on both and then
>>> maximise the HEPSPEC? If you would take the latter approach, what is a
>>> sensible trade-off between disk performance and price? Presumably
>>> 10kRPM SAS disks will be better than 7.5kRPM SATA, but maybe a striped
>>> pair of slow disks would be an alternative? And how much disk space do
>>> you allow per CPU core?
>>
>> At Glasgow, we've opted to buy our latest generation of WNs with 2 x
>> 15kRPM disks, and will configure them in a RAID0 array. This followed
>> extensive testing of various WN configs, using a range of SSDs (X25's
>> and Kingston Value) versus RAIDED disks. We found the best "bang per
>> buck" was given by the 2 HDD solution.
>>
>
> I don't think it applies in this case, but it will for QMUL - and we are
> going through a similar exercise.
>
> The bang for buck figure is presumably based on the assumption that jobs
> will copy input files to the worker node disks and this is what stresses the
> disks.
It is, yes.
>That will not be the case at sites using Lustre/GPFS for their SRM.
> QMUL is working on the assumption that a standard SATA disk is fine for
> that.
I'd guess you're right - I've not tested the case where the remote
instance is providing a parallel filesystem.
Sam
>
> Chris
>
|