[daip] FYI: Negative impact of mounted external drive on Mac Pro.

[R. Craig Walker]

I have been setting up for AIPS on my new Mac Pro at home and ran into an
interesting issue.  As a test, I mounted a firewire disk that I had been
using on a Linux box (both Intel, so no byte order issue).  That disk had
6 directories set up as AIPS disks so I set all of them in DADEVS.LIST and
NETSP.  VPLOT seemed happy to plot the UV data and the data transfer rate
showed as 20 MB/sec (the disk was at the end of a 2 disk daisy chain, for
whatever that's worth).  That's a bit slower than I was expecting, but not
a lot for this moderately old drive.  I then tried copying the data set to
the internal disk.  During the copy, there was a complaint about the data
being badly out of time order.  This was not the case on the Linux box so
I'm not sure what is going on.  I'll have to test that more.

I then tried a UVSRT.  That started fine.  It was reading the internal
disk at about 90 MB/s.  But as the program ran, with output to the
internal disk, the data transfer rate got stuck on about 700 kB/s.  After
something close to an hour, I aborted the task.  All this time the access
lights on the external drive were flashing like crazy.  Nothing else was
using that disk as far as I could tell although it might have been used
for scratch.  I then exited AIPS, dismounted the external drive, restarted
AIPS, and reran UVSRT.  This time, as the program got past the initial
read, the transfer rates settled into 30-50 MB/s and the task finished in
about 8 minutes, a dramatic difference.  Later, realizing BADDISK might
help, I remounted the external drive and reran UVSRT with all the external
drives in BADDISK.  It behaved like the one with the disk dismounted - ie
good performance.

My guess is that UVSRT, anyway, accesses every mounted disk not in BADDISK
at very frequent intervals while running and this takes a while on the
external drive, causing a massive performance hit.

I consider this more a curiosity than something that needs to be fixed. 
But I thought you might like to know.  The triggering issue with the time
order is something that actually interests me rather more.  I need to see
if the issue was unique to this file and if it also occurs when loading
from FITS.  Is there any way to get specific information on why the
programs think the data are not sorted properly?  I'm curious if it is one
bad point or something systematic.  I looked in RNXUPD.FOR, which reported
the problem and there seems to be a tolerance parameter that is set
dynamically, but I didn't try to figure it out.  I copied another file
later and it did not indicate a problem so it may have been a glitch in
that particular file.

Cheers,

Craig





---------------------------------------------------------------------
    R. Craig Walker            Array Operations Center
    cwalker at nrao.edu           National Radio Astronomy Observatory
    Phone  575 835 7247        P. O. Box O
    Fax    575 835 7027        Socorro NM 87801   USA
--------------------------------------------------------------web