Print

Print


Dear Hedok, Darren and others,

I promise to provide some numbers as soon as I have some time. But a few 
thougths on your observations:

Neither a simple file transfer nor a benchmark on SPM segmentation are a 
good stress test for filesystem performance in SPM, because
- file transfer only tests _either_ read _or_ write performance 
- segmentation loads data once and does a lengthy computation before
   writing once.

A more realistic test is e.g. realignment, writing normalised images, 
smoothing or running a fMRI first level stats estimation, where you have 
lots of data to read, less data to write (and to different files than the 
originals).

On Fri, 6 Apr 2007, Hedok Lee wrote:

> Dear Darren and SPMers.
>
> There are only two computers in my set up, and there is no NAS.  One computer 
> for running SPM analyses and another one for storage.  I've been considering 
> NAS, but it was difficult to find the ones which support NFS.  NFS and FTP 
> are the only servers that I'm currently running.
>
> As for performance improvements, exporting NFS as "async" has improved 
> transfer rate by 300%.  Also, people use "Jumbo" frame by changing packet 
> size from 1024 to 8192.  I ran some testing to see the differences in 
> performance under different conditions.
>
> This link may help you about "async"
> http://www.mythtv.org/wiki/index.php/Optimizing_Performance
>
> I'm no IT guru, but try to provide some information that may be useful.
>
> Computers
> Intel P4(3.0Gx2) Non-RAID SCSI 10000rpm built-in gigabit card by DELL. 
> running RH4 WS with ext3 partition
> Intel P3(1.0x2) Non-RAID IDE 7200rpm PCI gigabit card.    running CentOS4 
> with ext3 partition
> Router: Linksys 5ports gigabit with full duplex support.
> Note: Not sure if these cards support jumbo frame.
>
> Files to transfer
> 167MB(1297 DICOM files by Siemens) x5=835MB
>
> Total time it took to copy 835MB from P4->P3
> 216sec(3.9MB/sec) default setting
> 74sec(11.3MB/sec)   async turned on
> 63sec(13MB/sec)   async+Jumbo frame turned on
>
> Total time it took to copy 835MB from P3->P4
> 29sec(29MB/sec) default setting
> 30sec(28MB/sec)   async turned on
> 36sec(23MB/sec)   async+Jumbo frame turned on
> Note: I have no idea why it's so much faster when I transfer P3->P4.  Perhaps 
> it has to with writing speed in SCSI?
>
> SPM test
> Default SPM5 segmentation of 3 high resolution anatomical images, SPGR 
> (1.0x1.0x1.5)
> Total time to complete the segmentation
> Local storage (SCSI): 25minutes
> Remote storage (NFS): 25minutes
>
> Conclusion:
> I'm beginning to think that SPM over NFS may be ok as total time it took to 
> complete segmentation was the same.
>
> I'm still curious if I can improve the performance.
>
> Hedok
>
>
> [log in to unmask] wrote:
>>  Dear Hedok, Volkmar,
>>
>>  I'd be interested in hearing about (on or off list) what file systems
>>  (nfs, samba, etc) you are
>>  using to enable higher performance data transfers on linux systems for mri
>>  data analysis.  Are you
>>  using NAS-type of data storage? 
>>
>>  thanks
>>  darren
>>
>>  ==============Original message text===============
>>  On Thu, 05 Apr 2007 1:26:23 pm CDT Hedok Lee wrote:
>>
>>  Dear Volkmar and SPMers
>>
>>  Regarding this post,
>>
>>  http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0704&L=SPM&P=R3600&I=-3
>> 
>> >  I've just investigated this because I am doing a transition of our 
>> >  network filesystem away from
>> >
>>  NFS and had to resolve some performance issues as well. 
>>
>>  As our data continue to grow, I was thinking about having a storage server
>>  and mount the data
>>  through NFS.  This way, I can keep adding more hard drives onto a storage
>>  server if necessary.  I
>>  was wondering if there is any particular reason why you decided to move
>>  away from NFS.  If you have a better solution to manage storage server,
>>  please let me know.  All of our machines are linux
>>  based, and they are connected through gigabit but my experience with NFS
>>  has been pretty slow
>> ~ 15MB/sec.  I tried jumbo frame and etc, but had not luck to reach 
>> ~ ~40MB/sec.
>>
>>  This is probably too slow to carry out SPM analysis over NFS isn't it? 
>>
>>  With regards,
>>
>>  Hedok
>> 
>> 
>> 
>>
>>  ----- Original Message -----
>>  From: Volkmar Glauche <[log in to unmask]>
>>  Date: Thursday, April 5, 2007 3:42 am
>>  Subject: Re: SPM5 slower with 4D files
>>  To: [log in to unmask]
>>
>> 
>> >  Hi Jerome,
>> > 
>> >  yes, SPM will probably slower on 4D files than on 3D files. Also it will 
>> >  be slower on .nii files than on .hdr/.img pairs. The reason is, that for 
>> >  combined header and data files (as in 3D .nii and 4D cases) SPM needs 
>> >  something like random-write-access to your file to store small bits of 
>> >  information. This is more expensive in terms of I/O time (especially on 
>> >  large disks/RAID systems/network file storage) than storing 3D data with 
>> >  separate .hdr/.img files. However, storing one large file is more 
>> >  efficient in terms of disk usage (if you have partitioned/formatted your 
>> >  disk to efficiently store large files). In short, there is no free 
>> >  lunch, and you have to decide what is more important to you: saving time 
>> >  or saving disk space...
>> >  I've just investigated this because I am doing a transition of our 
>> >  network filesystem away from NFS and had to resolve some performance 
>> >  issues as well.
>> > 
>> >  Volkmar
>> > 
>> >  On Wed, 4 Apr 2007, Paul Macey wrote:
>> > 
>> > 
>> > >  Hi Jérôme
>> > > 
>> > >  I just wrote something to split 4D to 3D; run the attached 
>> > > 
>> >  script 
>> > 
>> > >  (cspm_im_4Dto3D, from SPM5 only) and it will prompt for a 4D 
>> > > 
>> >  file to split. 
>> > 
>> > >  You can also use it in batch mode with a couple more options 
>> > > 
>> >  (see help). The 
>> > 
>> > >  3D files should be the same as in the 4D file, so I don't think 
>> > > 
>> >  you will 
>> > 
>> > >  loose anything by converting.
>> > > 
>> > >  Best wishes,
>> > >  Paul
>> > > 
>> > >  Jérôme Redouté wrote:
>> > > 
>> > > >   Dear SPMers,
>> > > >   My parameters estimation process is extremely slow. Could 
>> > > > 
>> >  this slowness
>> > 
>> > > >   be due to using a 4D-Niftii dataset?
>> > > >   In order to check that, I would like to convert my sw_xxxx.nii 
>> > > > 
>> >  4D files
>> > 
>> > > >   into a set of 3D files.
>> > > >   My questions are:
>> > > >   -SPM has a function to convert 3D -> 4D , but is the reverse 
>> > > > 
>> > function>>   available? Where can I find such a converter?
>> > 
>> > > >   -These images are preprocessed (realignment, normalisation, 
>> > > > 
>> >  smoothing), do
>> > 
>> > > >   I risk to lose these parameters by converting to 4D to 3D?
>> > > >   Thanks for your help
>> > > >   Jerome
>> > > > 
>> > > > 
>> >  -- 
>> >  Volkmar Glauche
>> >  -
>> >  Department of Neurology        	[log in to unmask]
>> >  Universitaetsklinikum Freiburg	Phone	49(0)761-270-5331
>> >  Breisacher Str. 64        	Fax	49(0)761-270-5416
>> >  79106 Freiburg 
>> >  http://fbi.uniklinik-freiburg.de/===========End of original message 
>> >  text===========
>> > 
>> 
>> 
>>
>>  --------------------------------
>>  Darren R. Gitelman, M.D.
>>  Department of Neurology
>>  710 N. Lake Shore Dr. #1122
>>  Chicago, IL 60611
>>  Voice: (312) 908-8614
>>  Fax:   (312) 908-5073
>>  --------------------------------
>> 
>>
>> 
>
>

-- 
Volkmar Glauche
-
Department of Neurology		[log in to unmask]
Universitaetsklinikum Freiburg	Phone	49(0)761-270-5331
Breisacher Str. 64		Fax	49(0)761-270-5416
79106 Freiburg			http://fbi.uniklinik-freiburg.de/