home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / sgi / 11123 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  3.2 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!fido!zola!twilight!zuni!europa!steve
  2. From: steve@europa.esd.sgi.com (Loopy - the spineless boy)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Memory upgrades for R4000 Indigos
  5. Message-ID: <nj2m9s0@zuni.esd.sgi.com>
  6. Date: 21 Jul 92 17:53:23 GMT
  7. References: <1992Jul17.204254.6599@microunity.com> <1992Jul21.004035.27345@donau.et.tudelft.nl> <1992Jul21.064111.1619@microunity.com>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Organization: Silicon Graphics, Inc.  Mountain View, CA
  10. Lines: 53
  11.  
  12. In <1992Jul21.064111.1619@microunity.com> jsw@microunity.com (Jeff Weinstein) writes:
  13.  
  14. >In article <1992Jul21.004035.27345@donau.et.tudelft.nl>, reinoud@dutecai.et.tudelft.nl (R. Lamberts) writes:
  15. >> From article <1992Jul17.204254.6599@microunity.com>, by jsw@microunity.com (Jeff Weinstein):
  16. >> > 
  17. >> >   The simms used in the R4k indigo are industry standard 36-bit wide
  18. >> > 80ns simms.  The prices quoted me by SGI are $1500 for 16Meg and $3000
  19. >> > for 32Meg.  You should be able to get about half that price from
  20. >> > the usual workstation memory vendors.
  21. >> > 
  22. >> >     --Jeff
  23. >> 
  24. >> Very interesting... Considering the expensive special SIMMs in an
  25. >> R3k Indigo, does this mean that:
  26. >> 
  27. >> - main memory on a R4k Indigo is slower than on a R3k Indigo, or
  28. >> 
  29. >> - the special SIMMs in the R3k Indigo are just to shake some more
  30. >>   money out of us?
  31.  
  32. >  Actually neither is true.  The main problem with the r3k indigo was that
  33. >there just wasn't room on the CPU board to put the chips that did the
  34. >memory interleaving/control, so they had to go on the back of the simms.
  35. >It was definitely not a conspiracy on the part of SGI marketing to squeeze
  36. >more money out of customers.  The engineers sincerely felt bad to have
  37. >to make that sort of engineering trade-off, and vowed never to do it
  38. >again.  They have lived up to it in the new r4k indigo.
  39.  
  40. >    --Jeff
  41.  
  42. Well put, Jeff, and accurate, too!.  Room was found on the R4K board by offloading
  43. the R4K and 2nd level cache on a daughter board.  I'll let the reader draw
  44. his/her own conclusions about removeable CPU modules.
  45.  
  46. Putting the CPU and cache on a module was considered for the R3K design, but was 
  47. rejected due to cost and complexity.  It cost more to make a separate PC board,
  48. and all the logistics that go with it.  Where do you divide the CPU subsystem? 
  49. If you put the R3K and cache on one board, then you would have to drag the
  50. high speed CPU bus down the connector to the read/write buffer (5 glue chips
  51. and a gate array).  This bus was marginal to begin with.  Putting the read/write
  52. buffer on the module makes the module too big to fit, and also compromises the
  53. main memory and GIO bus timing.  The R4000 CPU interface is much cleaner and
  54. easier to deal with, so it can be (carefully) placed on a module.
  55.  
  56. It was definitely *NOT* our intent to ream the customer with custom SIMMS.  Even
  57. SGI's lowest cost machine designs refuse to make big sacrifices on performance
  58. in order to cut the cost a little. No one here likes to design mediocre machines!  
  59. I'll take off my rose-colored corporate patriotism glasses now and get back to 
  60. work...
  61.  
  62. --
  63. Steve Valin        Silicon Graphics - Interactive Systems Division
  64. 4153901379        "Same shit, different name"
  65.