SUMMARY: Any hope to speed up an old Sparc 1+ ?

From: Karl Kopper (karl@dop.water.ca.gov)
Date: Wed Apr 10 1996 - 11:55:48 CDT


My Original Question:

----------------------------
Dear Sun Performance Experts,

Is there any way to bump up the speed of a Sparc 1+ (running 4.1.2)
applications which need to manipulate 50 MB+ (GIS) files?

We've not had real good luck putting Solaris 2.4 on this
type of machine tho I've heard 2.5 is faster?

We have a very small budget (< $1,000) if there is anything
this inexpensive which might help.

The bottle neck appears to be just Disk I/O. I've looked
at the "Sun Performance Tuning Overview" (December 1993)
but don't know if max users or adb kernel tuning would
do much good in this case (I've included iostat output below
if that helps).
 
Thanks very much in advance for your advice. I'll post
a summary if it seems relevant.
 
--Karl
------------------------------

Thank you for your expert help. Here is a summary of the
suggestions:

* Getting a better scsi controller and moving your data disks to it would help.

* SBUS Wide SCSI controller and disk

* Split the disk chain.

* Going to SunOS 4.1.4 will help some.

* Solaris 2.5 will give you - maybe 10 to 20% speed improvement in
  some areas; the higher numbers if you have more than one cpu (not
  the case for a 1+) where the increase threading has the most effect.

* Weitek CPU - 3x integer performance increase, but put about
  50% to 60% increase in overall system performance
  and 20% to 30% increase in IO - these are numbers
  are vague recollections only.

* Unfortunately, your machine is a Sparc1+, or I would suggest a Weitec cpu
  upgrade for $1k. (They are theoreticaly available for Sparc2 and IPX only.)
  For $2k you can replace the montherboard to a Sparc2 and also upgrade the cpu to
  the Weitec.

* definitely you should pursue a faster CPU.

* We upgraded our SPARCstation 1+ to a SPARC 5 by adding an Axil
  motherboard.

* I'd recommend purchasing more RAM. The SS1+ uses standard 32-pin
  parity SIMMs. It has 16 SIMMs sockets, which must be populated in
  groups of 4, and can use either 1MB or 4MB SIMMs (I'm not sure whether
  it can use 16MB SIMMs). I'd recommend purchasing as much RAM as you
  can afford, preferably going all the way up to 64MB (or more if 16MB
  SIMMs work).

From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
From: Glenn.Satchell@uniq.com.au (Glenn Satchell - Uniq Professional Services)

* Well, using mmap() instead of read()/write() is a good first move. With
  only 24MB, you've got to use what you have efficiently.

From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})

* If you control the appliction, then I'd suggest using mmap()/msync()/madvise()
  to do your access to the files. I have a paper called "Why aren't you using mmap() yet?"
  that details the various wins and shows how to use the facilities.

* Striping would surely help, and if you don't control the
  application code, tuning maxpgio up to allow more disk I/O to be devoted
  to paging will help a bit.

From: penrod@kazoo.er.usgs.gov (Dan Penrod)
From: Gene Rackow <rackow@mcs.anl.gov>
From: John Justin Hough <john@oncology.uthscsa.edu>
From: Paulo Licio de Geus <paulo@dcc.unicamp.br>
From: hurt <hurt@ionet.net>
From: John Valdes <valdes@geosun.uchicago.edu>
From: Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
From: Ric Anderson <ric@rtd.com>
From: Bert Shure <Bert_Shure%SOLSOURCE@notes.worldcom.com>
From: mike@borg.drss.state.sc.us (Mike Holland)
From: dougj@xray.ufl.edu (Doug Jones)

With many special thanks to Mary Lou Hinman for looking at
and explaining in detail vmstat and iostat output to determine
for this case the first thing to focus on is the CPU.

"You need more cpu power, followed by memory, followed by disk I/O."

From: Mary Lou Hinman <maryh@cea.Berkeley.EDU>

Thanks again everyone.

--Karl



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:57 CDT