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.
Impedance over the course of the entire channel is very difficult to control. The motherboard, connectors, RIMMs, etc all need to be impedance matched, or the reflections from the discontinuties in the signal propagation path cause big problems at the reciever.
:).
The third slot just adds enough noise to use up all the margin, and "bad things" happen. BTW, very carefully designed boards work just fine at 400MHz with 3 slots; it's the fringe cases which are the problem. Unfortunately, the fringe cases are significant enough to make it not worth shipping. It's not unlike overclocking... it will usually work, except when you really, really need it to
Adding a terminator pack as the third RIMM would indeed work well, but there are three problems, all non-technical:
1) User instruction: a user has to know that the third slot can't be filled with RAM, causing headaches for OEM support teams..
2) The additional terminator card adds cost
3) The chipset was spec'd to use three RIMMs, and two don't provide enough memory.
#include "standard_disclaimer.h"
This kind of thing is typical when rolling out entirely new technologies like RDRAM, although with the i820's relatively long development time, and the delays already experienced, Intel should have been expected to have already found and corrected the problem.
No one in their right mind would be deploying RDRAM or i820-based boards in server or other mission-critical applications at this early stage of development anyway - it simply hasn't been proven to work reliably yet, and given what little benchmarking I've seen comparing performance with AMD's and existing Intel chipsets, for home and gaming use the supposed performance improvements seem more a promise for the future than a current reality, rather like AGP before AGP 2X was implemented. With the caveat that this could, of course, be due to the use of preliminary or experimental BIOS versions in the machines being benchmarked.
Advice: wait until it has been proven to work, before jumping onto the Rambus.
Intel weren't suckered, it was just another lame attempt in a series of lame attempts to dictate PC platform standards in a way that hurts it's competitors and makes them play "catch-up".
I'm very glad it's blowing up in their monopolistic faces.
Alternatives are looking more and more attractive every day.
"The number of suckers born each minute doubles every 18 months."
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
It was obvious for some time that the 820 and RAMbus was a bad idea. I was really hoping Intel would come to their senses and move it to PC133 - for instance the 810 performs well... if you use a real video card.
Alas, now that means the early PC133 systems are going to be paired up with the 810e, which if they didn't add ECC support and external AGP support is gonna be lame. (The taiwanese don't like the 810 much either.)
I wonder how this is going to affect Micron's 533B/600B annoucement - since they decided to opt for the VIA PC133 chipset. :)
Oh, and you can actually use a Celeron with the VIA Apollo Pro 133. Heh.
Um, your comparing two different sets of numbers. C|Net was saying that the new 2 slot rambus boards only support a maximum of 512 Meg, while current 4 slot BX boards can support 1 Gig. Then they go on to say that the broken 3 slot rambut boards could have supported 768 Meg. They just didn't phrase it very well. So there math is right.
(bx) 1024MB / (new rambus) 512MB = 1/2 the mem
(bx) 1024MB / (old rambus) 768MB = 2/3 the mem
(old rambus) 768MB / (new rambus) 512 = 2/3 the mem of old rambus.
Analysis from InQuest, including Dell Office+Rambus benchmarks
A performance comparison of contemporary DRAM architectures. Vinodh Cuppu, Bruce Jacob, Brian Davis, and Trevor Mudge. Proc. 26th International Symposium on Computer Architecture
(ISCA-26), pp. 222-233. Atlanta GA, May 1999.
Or here to pick up Intel documentation on it here and here.
--LP
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.
Some old systems used to really lose bits. There were a couple of models of core memory that quite literally dropped their little rings over time, accumulating a pile at the bottom. Fortunately, core tended to have spare banks . . .
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"
TurkishGeek wrote:
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.
Dunno where you get this. I work with memory manufacturers and the lowest quoted die-size penalty for Rambus is 20% over DDR SDRAM. If you talk to the engineers instead of the spokesuits the number is more like 40%, and the yield is quite a bit lower.
Rambus advocates will argue over the amounts of the price premium and the performance changes relative to PC100 SDRAM. Based on whether you highball the performance and lowball the price adder or highball the price adder and lowball the performance you can either conclude that RDRAM is the inevitable next mainstream memory or that it's DOA, but nobody in the trade is claiming that RDRAM is cheaper to produce than SDRAM or DDR.
Lacking <sarcasm> tags,
Losing memory on a motherboard is a little different than losing data on a motherboard. I prefer the article's reference to losing data to the original /. phrasing.
While the concept of Rambus looks really nice I think Intel really screwed up on its implementation. They should have waited a little longer and done some thorough developing work on it because at the current state Rambus is starting to look ridiculous. Apart from that I hope that they'll manage to get it working properly as soon as possible, especially when I consider the current memory prices. (Which are still rising here in Luxembourg)
"The existence of the third memory slot can cause data to get lost while being transferred between memory and the main processor"
Has anyone seen any other reports with specifics on the problem? A problem like this would cause severe system instability, and basically make any machine built on top of it worthless. Since according to the article, some manufacturers have opted to ship computers with the problem, either 1) the author of the original CNET article got it wrong, or 2) computer manufacturers have a severe lack of ethics.
---
"Go Metallica. Die RIAA." -- Linus Torvalds
Read the article a bit more carefully. It states that data can be lost whether the third slot is being used or not. All of the current rambus mobos will have to be scrapped.
Very correct. The RAMBUS channel needs to be terminated, exactly like a 10bT or SCSI channel. The signal reflections from an unterminated stub cause major headaches, to the point where the system won't work. That's why either a memory stick or a continuity stick must be in each socket, so that the signal can propogate all the way to the terminator resistors on the motherboard at the end of the channel.
#include "standard_disclaimer.h"
Since when is 512 half of 768?
512 is 2/3 of 768, which makes sense if you can only use 2 slots instead of 3.
I don't know the answer to your question, but one nit picking correction: 10BaseT is not a chain, it is a star topology physically, and thus doesn't require termination. 10Base2 and 10Base5 are the ones that use a bus topology terminated on both ends.
I have to admit the numbers I have are from "spokesuits" (trade publications). If the lowest quoted die-size penalty is %20 over DDR SDRAM, the yield should not be significantly lower in the long run. DRAM processes are relatively very mature, if we consider that DRAMs have been around for a while.
I am not a RDRAM advocate per se. But I like RDRAM because it is a new approach-a fresh, welcome improvement for solving the memory bottleneck problem. It looks like ordinary DRAM can only be improved so much, while with RDRAM, there seems to be more opportunity for further improvement.
Thanks for the useful information. If you don't mind, may I ask you what kind of work with memory manufacturers you are involved in? Based on some of your previous posts, I guess you are more involved in process technology rather..
Zigbee Central: A Zigbee weblog
No way is DRDRAM cheaper to produce. I know, because I'm currently employed in a DRDRAM design department. There are clear fundamental reasons adding to the expense - silicon area, tighter tolerances, higher frequency testers, etc. From this point you have to ask, "What is the value of the extras DRDRAM offers?" Then you have to decide if it's worth it. In a heavily loaded, multitasking system, the increased bank count of DRDRAM translates to better availability and therefore performance. At some level of chip integration, (we're not there, yet) DRDRAM will be a great solution to system-DRAM-on-a-chip. But there's another perspective. Here we are, in one of the ultimate bastions of open-ness, debating the Intel/Rambus attempt to take the ultimate VLSI commodity, memory, and making it proprietary and royalty-bearing. It's given me real ethical headaches over the past few years. But kids gotta eat, and my ability to 'make a difference' toward killing off 'free' (speech, the beer's getting expensive, these days) memory negligible.
The BP6 uses the "Old" BX chipset with lots of wierd stuff built onto it by ABIT. It doesn't use the Rambus memory (unless I'm SORELY mistaken), so we don't have a problem.
I highly recommend this motherboard, it's nice and reliable and I LOVE the dual celerons. YMMV of course, but all the reviews I've read say about the same thing.
-- IANAEG - I am not an elder god.
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
"It's a feature, really." "It is a minor flaw that will only affect a very small minority of users in scientific and engineering applications."
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
Red Herring wrote:
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.
Interesting observation, but I'm curious where you get the power comparison. RDRAM certainly has more power-management features than DDR but that doesn't mean it uses less power. The proof would be in actual power-usage comparisons.
FWIW SSTL-2 drivers run about 8 mA/bit during active signaling, for a total across 64 bit memory of about 512 mA. RDRAM burns 25mA per bit per node times 16 bits times 2-4 nodes for a total signaling current of 800-1600 mA.
WRT on-chip power the memory arrays, sense amps, etc are all standard in both cases. There is a difference in the DLL (DDR's DLL can be run without static power) and I/O circuits (Rambus runs current-mode signaling and therefore has some analog circuitry with attendant static currents in the RAC.)
Lacking <sarcasm> tags,
usual gritty Intel detail site - now w/ Dr. Dobbs
Chuck
try { do() || do_not(); } catch (JediException err) { yoda(err); }
c't (famous german computer magazine) writes that they could not measure any stability problems on the RamBus boards they tested, not even with fully loaded RAM-banks. So this must either be a very rare problem, or it affects only certain board designs.
--Coke
Why is rambus memory such a big deal? It seems to me (I may be wrong) that the advantage of Rambus is that it's serial and thus transfers really really fast.
Aren't current DIMMS 64 bits wide and running at 100MHz? Wouldn't that mean that Rambus memory would need to run at 6400 MHz to match the throughput we have right now? Or are they mounting many banks of RDRAM on a single module and running those in parallel at the speed of the CPU? But then we get back to running the memory in parallel, but faster, creating more errors presumably?
Can someone who knows more please shed some light?
Thanks
Computer companies which hype the claims of companies like Rambus (or in this case, really Rambus / Intel) are partly to blame.
...
I know that the computer catalogs my company works on have been hyping the advantages of Rambus / RDRAM for a little while, based on the input given us by our client. Since they're in the position presumably to know the truth of such claims / realism of the release schedules (and since they're the client) we don't have a lot of choice about it.
So the question might have been facietious (about 'who else but intel to blame?' but
cheers,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5