Well, that was a fast and furious response. Since everyone said about the
same thing, I will summarize and give credit later:
1) Speed - most reported between 50-100% increase in cpu bound applications.
As expected, those that are I/O or graphics bound reported a lot less.
Some did say that Openwindows seemed a lot "snappier" than before.
Some people benchmarked with homegrown C programs, and a lot made the
excellent suggestion to get an evaluation and see if my particular
application would see an improvement (it will, it's cpu bound).
2) Chip Puller - comments ranged from "Don't even try it without it" to
"Don't even try it without it". Bottom line is you need this wonderful
tool. At least 5 people offered to lend me theirs, and I want to
extend a gracious thank you to those people (I may be writing you to
take advantage of your offer :). This is the type of neighborly act
that makes you proud to be a member of the net community.
3) Problems - david r coelho <ppt!drc@uunet.uu.net> points out that he
tried the upgrade in a Tatung Sparcstation 2 clone, but kept getting
cpu errors so they dropped back to the original cpu.
Thanks also to Peter Watkins <peter@jrc.nl>, who points out that you
have to have something greater than the v2.0 Open Boot PROM, and
gave a nice command to check:
echo '*romp+c/xx' |adb /vmunix /dev/kmem
which will respond with something like:
not core file = /dev/kmem
0xffe8eb24: 2 0
where the "2 0" would indicate v2.0.
And a late breaking development -
Randy Banks (Banks B J <randy@essex.ac.uk>) reports:
>we're trying (with a SS 2, 64 mbyte, SunOs 4.1.3) but having some
>difficulties - the chip we've got causes certain applications to fail
>(well, one anyways that we've so far discovered) and we've never
>got up to a 40% increase in throughput even with a cpu intensive
>application.
>
>the last we heard from our supplier is a) that our problems are not
>necessarily unique and potentially a function of interference with the
>clock, and, b) that they can be rectified by a specially "bonded"
>version of the chip which we're still awaiting.
Thanks to:
Drew Montag <djm@navy.Millipore.COM>
craigw <Craig.Warner@Ceram.COM>
David Burwell <dburwell@telecom.telecom.com>
Charles Mengel - LGI - Systems Eng Mgr <crm@lgi.com>
Charles Chip Buchholtz <chip@eniac.seas.upenn.edu>
John Royere <john.royere@medtronic.com>
Gene Rackow <rackow@mcs.anl.gov>
"J. William Yu" <jwilliam@lattice.com>
Jay Lessert <jayl@lattice.com>
david r coelho <ppt!drc@uunet.uu.net>
Peter Samuel <Peter.Samuel@nms.otc.com.au>
Jim Ray <jdr@mlb.semi.harris.com>
Pat Cain <pjc@denver.ssds.com>
Gene Loriot <epl@Kodak.COM>
raoul@MIT.EDU
Peter Watkins <peter@jrc.nl>
"Birger A. Wathne" <Birger.Wathne@vest.sdata.no>
James Rae <rae@nvg_troy.nvg.com>
"Roger E. Stoller 576-7886" <rkn@stc06.ctd.ornl.gov>
"Timothy P. Henrion" <tph@sbctri.sbc.com>
Donald McLachlan <don@mars.dgrc.doc.ca>
Banks B J <randy@essex.ac.uk>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:03 CDT