Slashdot Mirror
Major Problems with Rambus
A reader wrote in to alert us to the problems Intel is having with Rambus.
Problems arise on the motherboards with three slots of memory, if the third slot is empty, memory can be lost between motherboard and memory. Initial estimates from one analysts said that hundreds of thousands of machines may be affected.
Here's the skinny - (the latest) Rambus transfers data on a 16-bit bus at up to 800MHz (400MHz clock data moving on both edges) that's 1.6Gb/sec/channel. PC133's moving data on a 64-bit bus at 133MHz - that's 1.064GB/sec. EV6 (K7) moves 64-bit data on a 200MHz bus - but is limited by having a traditional memory backend (SDRAM performas as above, 100MHz DDR would give the full 1.6G).
Rambus has a major downside - slightly higher latency to memory (this has been somewhat mitigated in the latest RamBus incarnation).
It also has a really major upside - memory granularity - as memory densities go up if you don't need to increase your total memory you can use fewer and fewer RamBus DRAMs and still get the same performance - and you can upgrades at a chip level rather than SDRAMS which you must upgrade in increments of a whole SIMM. For low end PCs this will start to become important (unless M$ manages to waste another 64Mb in Win2K).
Another Rambus advantage is that it can handle many more parallel transactions (esp. overlapping RAS precharge and sense operations because it can have a lot more independant banks in memory) today this isn't so important (except maybe for graphics operations) because to get a big advantage from this you need a lot of concurrent transactions in the memory system and todays CPUs on bridges on the other side of buses don't see as much as you'd like - put directly it on the CPU and there's much more scope for performnce increases - esp. with ISAs like IA64 where much more memory system parallelism is exposed to the programmer.
On the purely physical side there is one other major RamBus down side - mostly because they're pushing the envelope with respect to clock speeds - building working memory systems is harder - PC board tolerences are much tighter (including on the SIMMS) and the bus interface is really analog rather than the digital one most designers are used too - my experience has been that it takes more chip debug time to get a working reliable RamBus system you have to fiddle and tweak a lot untill you have robust workable system - I have no inside knowledge but I suspect that Intel is working through exactly these issues.
RAMBUS is still a bleeding-edge technology. Signal integrity is a major headache, and Intel has the unlucky fortune to be the first to try it; there are bound to be problems.
RAMBUS is not a serial at the physical level, it is a parallel channel with a 16-bit width.
To offset the relatively small bus width, a super fast clock is used. Currently I think the i820 is designed for 600MHz, but I'm not 100% sure on that.
RAMBUS is a packet-based scheme, where multiple transactions can be pending at any given point in time (similar to TCP/IP). This allows non-blocking memory accesses and better bus utilization.
Intel's current RAMBUS implementation might not be cost effective over SDRAM, but given a year or two probably will be (if they can get past the current problems).
I don't know what you guys are thinking of when you say RAMBUS sucks. RAMBUS isn't another USB (yuk) -- it is an extremely well thought out technology that is (admittedly) somewhat ambitious. RAMBUS scales much better than any existing memory technology. I see people bitching about RAMBUS, but SDRAM will probably max out at 150 MHz next year.
Please understand that Intel != RAMBUS. Don't hate RAMBUS because you hate Intel; RAMBUS was founded by two people who were very smart guys and as a separate entity.
Intel's problem is probably not with the i820 itself, but the way the RAMBUS signals behave on the bus. They have noise and termination problems, which are very similar to SCSI problems. This is why the last slot on the bus is problematic -- having a RIMM or nothing at all makes a big difference to the the signalling scheme.
This problem will not affect SDRAM, even with an i820 (unless there is a different problem I don't know of).
The opinions I post here have nothing to do with my employer.
Your third point: Initially RAMBUS at 800MHz was specified, but when manufacturing and quality difficulties occurred, it was stepped down to 600MHz and lower. And PC133 was added as well.
I don't know about SDRAM maxing out at 150MHz. Word is that Apple is working on DDRAM, which uses both clock edges, as well as working it at 266MHz. Now this may just be Double the rate at 133MHz, or Double the rate at 266MHz, I don't know. Link is
http://www.macosrumors.com/8-99.html
But otherwise I have to agree with most of your points.
-AS
-AS
*Pikachu*
Rambus memory is a big deal for a few reasons. First of all, most modern chips are becoming very pin-limited, so the 80 or so pins to implement an SDRAM interface compared to the 20 or so pins necessary to implement an RDRAM interface is very important. Routing 80 or so signals at 133MHz is very difficult; routing 20 signals at 400MHz is easier.
RDRAM is also "multi-symbolic", meaning that there are multiple transactions on the bus at any one time. The clock speed is faster than than the propogation of the signal, so it's possible to have multiple pieces of data on the bus at the same time. This allows higher speeds; higher even than the 400MHz clock (800MHz data transfer rate) that RDRAM uses today.
I heard someone else mention DDR SDRAM... this may work in a server, but it requires a huge amount of power, which in turn means cooling, which in turn means cost. It's not terribly suitable for a general desktop. RDRAM manages power better.
While RDRAM may or may not be the future, SDRAM and deriviatves are definately not. They simply cost to much to scale to higher throughputs. Intel tried to move to something better, but got burned because it was to technically difficult for a generic OEM to produce. Oops.
#include "standard_disclaimer.h"
Apparently they miscalculated the tolerences. If they make the memory bus long enough to have three slots, it occasionally scrambles data, regardless of which slots are filled.
Remember DIMMs without SPD-EPROMS? Same sort of thing. Although this time, from what I understand of RDRAM, you need a terminator card in each slot that is NOT used, which explains why the three-slot board is a problem.
RDRAM is a waste of time and money. Why bother converting to an unproven memory technology when PC133 and PC150 SDRAM give much better bang for the buck with today's technology, and are even faster according to most benchmarks.
I understand why Intel has to go with RDRAM. It's part of their legal obligation with Rambus to push RDRAM into the marketplace until the end of year 2002 - http://www.theregister.co.uk/990906-000003.html - but that doesn't mean we the public have to even acknowledge that the 820 chipset exists. Go VIA or stick with the tried, true, overclockable 440BX and supercool those AGP cards.
It amazes me that Intel could have been suckered into this RDRAM quandry. They should have known better, or at least have the backbone to tell the Rambus guys that they're nuts to release a slower alternative to SDRAM, and waited until RDRAM was ready before forcing it on the industry.
Just my $0.02
-- Perry Ketter, a.k.a. IceStorm
RDRAM has significant advantages to SDRAM. In overall latency and performance, it is true that RDRAM is only about as good as SDRAM. And true, RDRAM is more expensive now because of those outrageous royalties paid to Rambus, and the low volume.
But in overall production costs, ignoring the price premiums tacked on the price by companies, RDRAM is more cost-effective. That is, RDRAM is actually cheaper to produce.This alone makes it attractive in the long run.
There are several good papers about comparisons of modern DRAM architectures, which highlight this point. The more technically oriented among you might want to take a look at the following:
A Performance Comparison of Contemporary DRAM Architectures
Zigbee Central: A Zigbee weblog
usual gritty Intel detail site - now w/ Dr. Dobbs
Chuck
try { do() || do_not(); } catch (JediException err) { yoda(err); }