This is a note which Martin Clayton added on dated 4-May-1995. It may still be of some relevance for current systems.
I've been doing a little experimenting with ECHOMOP on our alphas.
We found that when one user is running an echelle data reduction job this takes a fair while, and that the machine is very slow for all other users (You can type faster than the machine can echo the characters...). This appears to be because the echelle process is spending a lot of time in WAIT states while accessing data on disk.
I've run a single reduction (options 1 to 8 in ECHOMOP) in a few different configurations: with data on a local disk, with data on an nfs mounted disk and with data on a local RAM disk. The data were all 1024x512 pixel CCD frames.
These are the results:
Machine: zuaxp0, DEC Alpha 2000/300, OSF/1 v3.2.
Data location U.CPU S.CPU Elapsed %CPU Remote disk 73 156 20:20 19 Local disk 85 113 13:54 23 RAM disk 71 95 4:32 60These were one-off tests with the echelle job being the only "CPU-hungry" user process (I did the timed tests one evening).
It's clear that running with data on a local disk instead of remote saves time - as you would expect.
The RAM disk used was 50Mbytes - more than enough for a single dataset of this type. We found that apart from the faster echelle reduction process the general performance of the machine for other users was "better" when using the RAM disk. Of course, this depends what everyone else is doing at the time...
Some extra time should be added for copying the dataset to and from the ram disk (<3s CPU time, <30s elapsed time) and the CPU time required by the mount_mfs process which runs the ramdisk (~25% of the echelle CPU time).
It's not at all difficult to set up a ramdisk on the alphas - Adrian did so in a couple of minutes. Anyone using ECHOMOP (especially using it a lot) may like to experiment with a ramdisk at their site.
Go back to the EDR home page.
Martin Clayton