steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) (01/29/91)
Steven Fisher writes: >.... Because of the way SGI did the memory on the 4D-35, >there may never be 3rd party memory for it (so they won't be as >pressured to lower the memory cost)...... Would someone at SGI comment on this? Will third party memory ever be available for the 4D-35, or does SGI plan to be the only source? Steve VanGorder steve@chaos.ocean.fsu.edu Dept. of Oceanography (128.186.3.34) Florida State University gorder@fsu.bitnet Tallahassee, Fl 32306 (904)644-2447
jmb@patton.wpd.sgi.com (Jim Barton) (01/30/91)
In article <9101281809.AA25565@chaos.ocean.fsu.edu>, steve@CHAOS.OCEAN.FSU.EDU (Steve Van Gorder) writes: > Steven Fisher writes: > > >.... Because of the way SGI did the memory on the 4D-35, > >there may never be 3rd party memory for it (so they won't be as > >pressured to lower the memory cost)...... > > Would someone at SGI comment on this? Will third party memory > ever be available for the 4D-35, or does SGI plan to be the only source? The memory design in the 4D35 was NOT done that way to keep third parties from providing memory. Each SIMM in a 4D35 includes a small ASIC (SGI is not the first, nor will it be the last, to do this). This ASIC allows us to provide extremely high memory bandwidth in the 4D35. Thus, cache fills happen at a 128Mb/s burst rate. This is one of the reasons for the high SPECmark rating. DRAM has problems providing the throughput needed by modern RISC processors, and the problem will only get worse with the next generation of these processors. There are several start-ups going trying to address the memory bandwidth problem in general, but SGI needed to solve it today. Will third-party memory every be available? Who knows? I suppose if someone gets aggressive enough they could reverse-engineer the ASIC and build those kind of SIMMs. -- Jim Barton Silicon Graphics Computer Systems jmb@sgi.com