Subject: Long jobs - Steve Ellis report on SPARC 20 performance
Date: Thu, 08 May 1997 17:48:22 EDT
From: "Naomi B. Schmidt" <nschmidt@MIT.EDU>


------- Forwarded Message

Received: from SOUTH-STATION-ANNEX.MIT.EDU by po6.MIT.EDU (5.61/4.7) id AA05451; Wed, 20 Sep 95 16:31:15 EDT
Received: from MITHRIL.MIT.EDU by MIT.EDU with SMTP
	id AA15481; Wed, 20 Sep 95 16:30:31 EDT
Received: by mithril.MIT.EDU (5.0/4.7) id AA12631; Wed, 20 Sep 1995 16:30:50 -0400
Message-Id: <9509202030.AA12631@mithril.MIT.EDU>
To: nschmidt@MIT.EDU
Subject: Sparc
Date: Wed, 20 Sep 1995 16:30:49 EDT
From: Steve Ellis <ellis@MIT.EDU>
Content-Length: 1642


   Naomi 

      I have done a little more work on determining performance for
a multi-processor Sparc.  Here is a summary of what I've found:

   a) For cases where memory and swap are not factors, I didn't find
      any "slow down" due to numbers of jobs. 

   b) For memory intensive jobs, performance begins to degrade when
      memory required is about twice the RAM installed.  In the 
      worst case, i.e. all memory and swap used, jobs got only
      20 minutes of CPU time over a 5 day period. This was about 1%
      of the time available.  For the "in-between" cases, performance
      becomes very erratic. Here are some "ps" numbers for jobs
      started together (18 total jobs):
    
         UID   PID  PPID  C    STIME TTY      TIME COMD
       ellis 10542 10538 80 14:15:22 pts/0   37:53 ../linpackd
       ellis 10532 10517 80 14:15:18 pts/0   16:00 ../linpackd
       ellis 10530 10516 80 14:15:18 pts/0    8:30 ../linpackd
       ellis 10536 10522 80 14:15:19 pts/0    4:31 ../linpackd
       ellis 10533 10519 80 14:15:18 pts/0    2:29 ../linpackd
       ellis 10546 10537 80 14:15:22 pts/0    1:02 ../linpackd

   
      As you can see there is a wide range of values for CPU time.
      The machine does not appear to handle large scale swapping gracefully.

For reference, the jobs I was running required about 16 Mb of memory,
similar to what ADINA might take. The machine had 2 processors and 128 Mb
memory.  From this I'd say that even with large amounts of memory, a Sparc 
based batch server would be extremely susceptible to thrashing unless there
is active operator intervention or management.


Steve 


------- End of Forwarded Message

