Slashdot Mirror
Intel squashes Rambus Bugs
Fooster writes "According to this article in Forbes, Intel has indentified and solved the
problems in the i820 chip for Rambus. Few details on the nature
of the solution.
" As Forbes points out, the challenge is getting OEMs back on board - I'd be skittish as well.
However, I submit that this will be proof of Intel's monopoly hold on the chip market. They will have all OEMs back on board and satiated in no time.
Imagine what would happen to a smaller company if they scrwed up this bad....they'd be gone forever.
Oh well...i don't even care that much...just felt like pointing out the obvious.
Werd.
Rambus is another causality in the PC world where the best technology seems to get passed up for either the current technology or cheaper technology. The best technology doesn't necessarily dominate. The MacOS is a good example of this, as is the FireWire bus. Despite Intel's backing I would bet that this technology will only be used is niche market of high-end servers. The $200 PC's of the world will never want to pay a premium for a small increase in performance. The current SDRAM technology will be tweaked for years to come, and Rambus will never be the dominant standard.
Sig goes here
Intel had things all their own way for a long time, and wasted that time with stupid dudes in Typar suits. As an ISP, my Intel penetration is minimal... they just don't have anything I want.
As an OEM, Intel has alienated me in much the same way MS has. Intel has nothing to sell me anymore... they have lost the performance edge, and the shoddy and hurried design is showing through their cracks. RAMBus, while a nice idea, was not executed well, and Intel deserves to take it on the chin. Didn't a major RAM mfg company just switch thier production line to DIMM production?
The industry will eventually come back to RAMBus, but this is just the wake up call Intel, and more importantly its' competition, needs.
The minute Intel started selling its product like beer and cars, I knew they were in deep trouble... the only reason you do that is to hide the fact that they have no real technically compelling reason to give you, to buy a new system.
Intel P-III processors do NOTHING to enhance your Internet experience.
harumph
Rambus is dead. Rambus has numerous drawbacks, such as a higher manufacturing cost and licensing fees. DDRAM has a nice window to kill it. DDRAM is basically SDRAM with double edged clocking so it can operate at speeds up to around 266MHz. It also costs little or nothing extra to produce than SDRAM and there are no licensing fees or royalties that need to be paid. Expect some non-Intel chipsets to appear shortly that take advantage of this.
Furthermore, most of the memory manufacturers are not supporting Rambus. Samsung just dropped Rambus and is going back to SDRAM.
Intel really shot themselves in the foot WRT Rambus.
This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
We knew that eventually Intel and Rambus would solve the glitches with the 820 chipset. But the big question who wants 820 based PCs? Intel is unlikely to be able to show much performance benefit of DRDRAM over PC100 let alone PC133 or DDR. Most PC programs play quite nicely in a two level cache hierarchy and don't much resemble McCalpin's STREAM memory bandwidth benchmark. DRDRAM has a lot of latency problems, especially those related to management of which memory devices are kept active and which are put into low power modes. Also since DRDRAM yields at 800 Mbps/pin are so abysmal most mainstream 820 based PCs shipped in the next few quarters will have down-binned 600 or 700 Mbps RIMMs in them which will make them look bad compared to PC100 SDRAM.
Now what about cost? It is estimated that a typical 820 based PC will have about a $250 cost premium over a 440BX based PC with PC100. What is the cost difference to the PC buyer $300? $400? There are no simple fixes for this problem. The
economics of DRDRAM hurt in so many places - larger die size, low AC functional yield, sky high test costs, uBGA packaging costs, module and motherboard costs (you need special PWBs with tightly controlled characteristic impedance for those rambus transmission lines). These problems are so significant that the only DRAM vendor still building DRDRAMs is Toshiba and that is because it is contractual supplier to Sony for Playstation 2's.
There are some great articles regarding bandwith vs. latency in general and RamBus in particular at Tom's Hardware. To summarize the articles, even today's current SDRAM architecture provides more than enough bandwidth, especially with the current sophisticated cache systems that reduce memory accesses dramatically. However, what's tying up the CPU is latency, especially as CPU's get faster.
In other words, CPUs generally request small amounts of data with any given request, but it has to wait a long time for that request to get back. As CPU speed has increased, better cache systems have mitigated the resulting increased bandwidth demands but nothing has helped the resulting latency problems. So the way to speed up memory is to decrease latency and don't worry too much about bandwidth just yet. Unfortunately, RamBus goes in the exact opposite direction.
That said, I guess we should never underestimate the power of a behemoth like Intel to force acceptance of poor technologies :-/
In both cases new motherboard layouts will be needed, and since both will take up more space the whole floorplan may change. At best, this will take a few months to get the MBs designed, through validation and regulatory approval (not a trivial issue with this kind of bandwidth!) and into the production pipe. Kiss Q4 goodbye and probably Q1; the memory shops won't be seeing any demand until Q2 at soonest, if at all.
On top of that there will always be the charming issue (which Rambus seems to have in other areas as well) that the operating area for the memory subsystem will have a Swiss-cheese character. Instead of a 'schmoo' plot, with a maximum frequency of operation and constraints on voltage and temperature, there will be areas of operation and failure, alternating. Maybe 300 MHz and 800 MHz will be OK, but 700 will be out. In fact, that seems to be the situation right now.
Lacking <sarcasm> tags,
Actually, I find the whole latency argument specious at best. The whole point of serializing RAM allows the increased bandwidth _and_ clock speeds. Thus for this type of argument you may contend that the latency of Rambus is 30% (I'm not sure what the actual number is) longer than it's current DDR SDRAM competitor, but just remember that Rambus will easily scale upwards 30% faster than SDRAM. This _negates_ any latency advantage that SDRAM had, but also gives a huge pipeline burst advantage to the Rambus component, especially as the speeds increase. It's similar to the PowerPC versus Alpha comparison. The PowerPCs generally had short pipelines versus the Alpha long pipelines (usually more than double the length). This allows the lower clocked PowerPC to keep up with fast clocked Alpha for the most part, but the Alpha is easier to manufacture at higher clocks than PowerPCs. Just look at the '2nd gen' motorola G4 chip, moving from a 5 stage pipe to a 7 stage in order to make clock up easier. Rambus may be roughly equal to SDRAM today, but once the speeds crank up Rambus will leave SDRAM in the legacy parts bin.
- A.P. (I agree with the rest of the stuff, though. Rambus is for servers, let it linger and die there.)
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Intel has (IIRC) said that Rambus won't be used on Celerons, won't be used on 100-MHz FSB P-III's, won't be used on Xeons, won't be used on Itania (no I won't say Itaniums), and won't be used on systems with more than two CPUs.
So here we have a memory technology which is limited to 1- and 2-processor 133-MHzFSB Pentium III's. Those systems don't need Rambus, since they can work with PC-133.
Rambus claims to be faster than PC-133, but over and over again the benchmarks refuse to confirm that.
Where's the future in Rambus?
Another poster said in response to the above post that [the reason you haven't seen AMD back any distribution of Linux] is they "don't have 2 pennies to rub together."
...
That's true enough, as things go (AMD seems to consistently release great chips which feature a "Lower than expected quarterly earnings" bug), but supporting a Linux distribution is not the same as throwing money in to a blender just to watch the pretty paper shred. In fact, AMD places advertisements (that's a very real cost of business!) and supporting a Linux distribution would be great advertising for them.
Now I work in advertising for a big one-syllable computer maker that rhymes with Hell and so far does not make any computers with AMD Inside, though I think they should.
If AMD would sink as much into a single distribution of Linux as it does in a few days of straightforward advertising, the returns would be large and lasting. A company which supports linux and makes what mainstream publications (like PC World) say is the fastest chip they've ever run in a desktop might have a great following
Goodwill is more important than companies seem to realize, though.
But if say, SuSE linux were to feature a big graphic on the box that said "This product rules with Athlon processors!" (it's sort of plausible, considering that AMD has at least one factory in Germany), I think it would be cool.
Just a thought. Anyone from AMD listening?
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Not really. Even if RAM-DRAM(why don't they call it that, RAMbus Dynamic Random Access Memory?) in any case even if RDRAM gets a 50% bandwith increase, most games (what do you think pushes computers in consumer space?) have less than 150MB/sec bandwidth. Say the proc wants access to 1K of data. It wats 50 clocks for RDRAM and 30 Clocks for SDRAM. Even if RDRAM had 10GB/sec of bandwidth, it would not counter the fact that for a small piece of data such as this, their would still be the overhead. True, if you are doing streaming memory tests, RDRAM is faster, but increase the bandwidth all ya want, latency is not negated. Consider FPM DRAM (remember that) The whole reason that EDO replaced it because it had lower latency. (keeping the pages open longer allowed subsequent memory access to skip a lot of overhead I think.)SDRAM replaced EDO because that proc does not have to wait as long to get data since SDRAM is ready to transfer when the proc is ready to revieve. (Hence synchronus.)
A deep unwavering belief is a sure sign you're missing something...