SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?


To: Boplicity who wrote (46111)6/26/2000 6:08:00 PM
From: jim kelley  Read Replies (3) | Respond to of 93625
 
Greg,

As Mr. Spock would say , "insufficient data Captain."

Perhaps, this is what they are talking about:

Message 13947217

This appears to be a cache mechanism combined with a compression algorithm similar to the one STAC used.

The cache mechanism probably uses an LRU replacement technique and store the most frequently used data and instructions. The compression and decompression is done in hardware. So it is sort of a solid state disk system which uses hardware compression and decompression. This can be done with any kind of memory.

This does not have anything to do with RAMBUS directly.



To: Boplicity who wrote (46111)6/26/2000 6:16:00 PM
From: gnuman  Read Replies (3) | Respond to of 93625
 
Greg, re: <IBM Unveils Technology To Boost Memory Capacity>
I think this new chip provides a compression algorithm in hardware. Here's a better article.
news.cnet.com



To: Boplicity who wrote (46111)6/26/2000 6:38:00 PM
From: Steve Lee  Read Replies (2) | Respond to of 93625
 
Re: Impact of IBM's memory "doubling" on RMBS.

This is either insignificant or a small positive for RMBS. It reinforces the point discussed a week or two ago here that in a server, the amount of RAM available is more important than the performance of the RAM. As was evident in Intel's decision to choose the lower performing DDR RAM over RDRAM due to the higher capacities available and now evidenced by IBM's decision to sacrifice performance through compression in favour of absolute capacity.

Of course the reason behind both these preferences is that servers usually serve a massive amount of data compared to the RAM installed, whereas a workstation is likely to be repeatedly reading the same data over and over. Thus the performance hit for a server comes when the required data is read from disk rather than RAM, and the performance hit of that is massive compared to the performance hit from either a slower RAM architecture or a compression stage.

The impact to RMBS, if this works as IBM claims is that the capacity limitations of Rambus will be reduced. I.e: where it was previously only possible to provide 1GB of RDRAM per channel, it will now be possible to make that 1GB appear to perform as if 2GB are installed. So an OR840 based system can now sport a RAM capacity that appears to be 4GB - which is approaching a respectable level for a server.

Of course, the same technology can be applied to DDR RAM or other forms of SDRAM, but these technologies did not have the capacity limitation in the first instance, so have less to gain.

Despite the above, the server specifier would still be wise in most instances to use available budget to maximise RAM rather than to optimise the RAM architecture. So with today's prices, the sensible choice would be to spec a large amount of cheap RAM - i.e. SDRAM