8.10.2: Timing tests on loading of DEIMOS-sized images

The timing tests below show that it is essential for the DEIMOS workstations to have enough RAM to hold several images; i.e., at least 512 Mbytes. These tests are scheduled to be repeated on the recently acquired Dec alpa which has 256 Mbytes of RAM. The scaling of the test below leads us to expect no significant lags in response when we perform the tests on the alpha. For the operational DEIMOS system the challenge will be to ensure adequate bandwidth to the disk drives and to other hosts on the network.

8.10.2.1: Sparc2/SunOS

These were conducted on gardiner.ucolick.org, a SparcStation 10 running SunOS with 128 Mbytes of RAM. The background load average during these tests was 1.0 due to a Sybase dataserver. Unix filesystem caching was avoided in order that read times would accurately reflect SCSI access.

SAOimage permits monitoring of the time required to allocate memory. This allocation need only be done once for images of a given size. However, if extremely large images are loaded, subsequent smaller images will suffer from the paging implied by the size of the largest previous image. SAOimage appears to read first, then process the image.

ximtool also takes time for initial allocation of memory, but the time required for the subtasks is harder to determine. Also, the behavior of ximtool is affected by the graphcap configuration used to drive it from IRAF. ximtool appears to read the image in small pieces and process as it goes.

When an image will fit in RAM SAOimage is four times faster. When an image is too big to fit in RAM ximtool is faster.

In each of these cases the display tool image window was 512x512 pixels. 

image size              SAOimage                IRAF/ximtool

2k x 8k
		10 s to allocate mem
		 8 s to read image
		 7 s to process
		--
		15 s after first time           1:00 into matched frame

8k x 4k
		10 s to allocate mem
		25 s to read image
		11 s to process
		--
		36 s after first time           2:15 into matched frame

8k x 8k
		50 s to allocate mem, paging
		~8 m to read image, paging
		~3 m to process, paging
		--
	       ~11 m while paging               5:00 into matched frame
These timings are consistent with a SCSI transfer rate of ~2Mbytes/s.

8.10.2.1.1: Interactivity with DEIMOS-sized images

Interaction with the above images in SAOimage was not a problem. Panning and tracking across the image gave responses within 2 seconds even in the case of the 8k x 8k image which did not fit within RAM. For images which fit within RAM the interaction is as fast as human reflexes. However interactions which required rereading the image, such as recalculating the colormap, took again as long as the processing stage listed above.

8.10.2.1.2: Interactivity with large virtual windows

The X Window System permits windows to be larger than the physical screen up to 32k pixels on a side. A virtual window manager can be used to traverse such a large image. A test with an SAOimage window of size 8k pixels demonstrated that this is not a viable strategy for image display. The SAOimage client on gardiner required many minutes to allocate virtual memory before displaying the image. Interactivity with the large image was extremely sluggish. When the virtual window manager was used to pan across the image it took most of a minute to remap the image.

8.10.2.2: Alpha/Digital Unix

These were conducted on radec.ucolick.org, a Dec Alpha with 288 Mbytes of RAM. There were no other significant processes running during the tests. Unix filesystem caching was avoided in order that read times would accurately reflect SCSI access.

With Digital Unix on alpha SAOimage and ximtool perform approximately equally when all of the image fits within the available RAM.

SAOtng version 1.5 is reported to build successfully on alpha, but it repeatedly suffered from SEGVIO when operating on radec.

ESORTD is apparently not 64-bit clean at this time. The executable did build and run successfully. The underlying pattern of pixel values was visible, but the displayed images had values which were nonsensical.

In each of these cases the display tool image window was 512x512 pixels. 

image size              SAOimage        IRAF/ximtool

2k x 8k
		10 s to read image      13 s into matched frame
		 1 s to process
					IRAF processing times

					16->16  rfits        18 s
					16->32  rfits        26 s
					int     imarith +     8 s (cache)
					int     imarith +    27 s (nocache)
					int->fp imarith /    35 s (nocache)
					int->fp imarith /    15 s (cache)
					fp      imarith +    57 s (nocache)
					fp      imarith +    15 s (cache)
					fp      imarith /    15 s (cache)
					fp      imfunc  sqrt 15 s (cache)
					fp      imfunc  log  15 s (cache)
					fp      imfunc  sin  15 s (cache)
					16->16  wfits           s

8k x 4k
		21 s to read image      26 s into matched frame
		 2 s to process
					IRAF processing times

					16->16  rfits        43 s
					16->32  rfits        59 s
					int     imarith +    15 s (cache)
					int     imarith +    56 s (nocache)
					int->fp imarith /    72 s (nocache)
					int->fp imarith /    30 s (cache)
					fp      imarith +   114 s (paging)
					fp      imarith /   122 s (paging)
					fp      imfunc  sqrt 83 s (nocache)
					fp      imfunc  sqrt 31 s (cache)
					fp      imfunc  log  31 s (cache)
					fp      imfunc  sin  31 s (cache)
					32->16  wfits        16 s

8k x 8k
		40 s to read image      42 s into matched frame
		 4 s to process
					IRAF processing times

					16->16  rfits        67 s
					16->32  rfits       112 s
					int     imarith +   107 s (nocache)
					int     imarith /    70 s (cache?)
					16->16  wfits        71 s
Disk space limitations precluded the binary floating point tests with
the full size images, but it is clear that paging would be happening
with radec's current configuration.
These timings are consistent with a SCSI transfer rate of ~4Mbytes/s. Because Digital Unix on alpha performs lazy evaluation of VM there is not a long time of memory allocation visible before each operation as there is with SunOS.

8.10.2.2.1: Interactivity with DEIMOS-sized images

Interaction with the above images in SAOimage and ximtool was not a problem. Panning and tracking across the image gave responses within a second. The interaction is as fast as human reflexes.
Steve Allen <sla@ucolick.org>
$Date: 1996/03/19 06:47:16 $