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.
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