[daip] some questions on AP size, AIPSMARK

[Eric Greisen]

Lynn D. Matthews writes:
 > Our AIPS managers have been doing some testing on how AP size affects AIPS
 > performance, and have found that there seems to be a sharp peak in
 > efficiency when the AP size is set to 20 MW (compiled value was 81 MW).
 > They are discussing whether this should therefore be made the default for
 > our AIPS systems. Before they do this, I have a few questions.

   The AP size does matter.  For tests with Y2K LARGE, I found that
the 80 Mbyte AP was slower than the 20 Mbyte AP - presumably because
20 was all that was really needed and the 80 costs in overhead.

 > 
 > Could you explain why performance should drop precipitously if the AP size
 > is maximized? Or is it likely to be a function of some additional
factors?

    I will bet that swapping and that sort of thing matters a lot.

 > 
 > I find that if I try to image a 8192 image with a 4096 beam using a 20MW
 > AP (something I need to do a lot of), IMAGR tells me: "only 637 rows
 > in 5120k AP". I assume this means that in my case I am being slowed down
 > by the limited AP size?

    Yes - for such large images, a larger AP will certainly help.
BTW - that message says that the AP is compiled to be 20 Mbytes not
words.

Truth is that the algorithms are designed for small memory machines
and use disk more than they should in the presence of large memories.
I am slowly working on converting the pseudo AP to be dynamic memory
so that algorithms may be re-written to use memory more than they do
at present.  Since there are assumptions about disk built in, the
current ones use the disk even if they could just pass the data on to
the next step.

 > 
 > Finally, what is the role of the AIPSMARK parameter in SETPAR---i.e., does
 > changing this value affect performance?

There are all sorts of delays built into the system.  For example,
AIPS wakes up regularly while waiting for a task just to make sure
that the task is still running.  If we did not do a sleep in that
process, aips would use so much cpu that the task would not run.  If
the wake up is too fast on a slow machine, one gets much the same.  If
it is too slow on a fast machine, then aips sleeps on for a while
after the task finishes.  We find that puttin the approximate AIPSmark
for the machine into that parameter causes a reasonable balance.  If
it is too low, then DDT and Y2K take longer because AIPS does not wake
up as soon as it should to minimize real time.

Eric Greisen