The current FSL code base is not parallelised in this manner, most
parts of the toolkit being single threaded programs. The larger tools
(FEAT, bedpostx) are parallelised through the splitting up of the task
into smaller sections and then relying on Grid Engine
(gridengine.sunsource.net) to farm that out to multiple compute nodes.
Consequently, the latencies of the interconnect between nodes is
fairly immaterial, unless you expect to be accessing/transferring
large amounts of data between the processing nodes. Once the task has
started only file reads/writes are significant.
We run a cluster (which includes several G5 Xserves) which reads/
writes data over NFS and find that gigabit ethernet is fine. In this
case the performance of your NFS server is much more important - we
use Apple's XSan and haven't been that impressed with its speed.
We have a wiki page on Grid Engine (https://www.fmrib.ox.ac.uk/phpwiki/index.php/FslSge
) which includes information on installation (Debian and Mac OS X) and
example queue setup.
Duncan
On 23 Jan 2008, at 18:28, Michael Lipton wrote:
> Hello,
>
> I am looking to purchase an Xserve cluster from Apple and am unclear
> about the requirements for fully parrallelized processing vis the
> nature of the FSL code. It seems that we will have the option of
> connecting the cluster nodes via a 10GB ethernet backbone that will
> allow for very short latencies. This, of course adds to the cost and
> I am keen to know whether it would confer an advantage when running
> FSL.
>
> In addition, are specs for an optimal configuration available?
>
> Thanks,
>
> Michael
>
--
Duncan A B Mortimer DPhil MChem
Computing Officer, FMRIB Centre, University of Oxford,
John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK.
Tel: (0)1865 222713
WWW: http://www.fmrib.ox.ac.uk/~duncan email: [log in to unmask]
|