SUMMARY: weitek processor upgrade

From: Mike (crumrine@erenj.com)
Date: Tue Jun 14 1994 - 20:59:30 CDT


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