Subject: RE: CPU vs Total Time

From: [email-masked]
Date: Wed, 4 Jan 1995 11:59:00 -0500

If you're system is basically running single jobs, which is assumed 
throughout this discussion, it is reasonable to assume that the difference 
between the CPU time and the total time, also referred to as clock or wall 
time, is due to disk I/O, input/output.  There is some overhead for memory 
access but it's negligible compared to I/O.  The I/O overhead generally 
arises from either:  updating job files, the output your generating;  
reading/writing temporary or scratch files;  and/or, swapping, that is 
accessing virtual memory which is disk based.  You'll have to take a closer 
look at your programs operations and monitor your system activity to 
identify the principal culprit but generally, anything you can do to 
improve I/O should speed up that portion of the job.  

The simple solutions:

   General - boost I/O

   Swapping - install more RAM

   Minimize job output - only ask for what you really need

   Scratch files - boost I/O and may also be minimized by selecting 
        appropriate job options, e.g., for very I/O demanding Gaussian 92 
        MP2 calculations with frequencies, a "frequently asked question": 
             Direct MP2=Stingy Opt=CalcHFFC FREQ=NoRaman

        NOTE:  Minimizing scratch file size will also help you stay within 
        current common "workstation" UNIX operating system (SGI Irix 
        5.2/6.0, IBM AIX, HP UX but not DEC OSF/1) file limitations, about 
        8-14 GB (gigabytes) for a file system and 2 GB for a single file.

There are a few methods for boosting I/O.  Some are simple with minimal 
additional expense while others may be major.  Keep in mind that this only 
reduces I/O proportionately and will not effect CPU time when determining 
cost-benefit.  To boost I/O, implement file systems, including swap space 
(virtual memory), which:

   Use disks with higher transfer rates

   Use higher bandwidth buses (MBs = megabytes per second, maximum):

        Fast-Wide Differential SCSI-2   20 MBs  common on high-end systems
        Fast-Wide SCSI-2                10 MBs  very common
        SCSI                             5 MBs  almost defunct

   Implement disk striping across multiple SCSI buses to get near aggregate 
   speedups, e.g., 2 * F/W Diff. SCSI-2 = 40 MBS max.  Striping on a single 
   SCSI bus still limits you to the bus maximum.  

      NOTE:  Large scratch files generally will readily exceed cache 
      memories available in some storage subsystems, i.e. RAID subsystems, 
      essentially eliminating their benefit in this specific case.

   Implement special I/O subsystems, e.g., HIPPI, but it can be expensive.

Good luck!

Karl F. Moschner

[email-masked]
Unilever Research U. S.