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.
-- .sig files go when they die?
Child: Mommy, where do
Mother: HELL! Straight to hell!
I've never been the same since.
Just like driving a car:
(D) to go forward
(R) to go backward
Why is it that Mr. Coward never seems to know where his post is in the ranks?
It's funny the company that came up with it couldn't fix it first. btw-- did anyone else see that wonderful Microsoft "news brief" on the side bar?
I'm not looking forward to propritary memory modules.
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.
NT is based on the premise that anyone who can manipulate a mouse can administer a system. Huh?!?
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,
Who is petty enough to give a damn about having a first post?
Macintosh: Why bother with a real computer?
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?"
The Lakers fired that Rambus guy a long time ago...
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?
That's something that I am curious about. Is AMD making any kind of contributions to the Linux community or pumping money into a distrobution? It seems to me that it would be in their best interest.
Petition Text:
As you can see the petition is a simple request to motherboard makers to recognize consumer demand for this high performance alternative to the reigning monopoly. You can reach the petition site here. Please take the minute or two necessary to visit the site and sign up --your vote counts. Thanks.I had wondered, myself, when this whole Rambus issue was first posted on
Would Intel consider recalling those affected units and replacing them?
I'm going to assume no, tragically enough, but I wish they would. Those people who have received such poor, faulty equipment shouldn't have to live with it. I also realize that I'm probably making it to sound worse than it really is, but I'm just wondering:
- How big of an issue is this (for those who have the faulty MBs/etc).?
- What is Intel planning to do about what they've already shipped?
- Do we really care about Rambus? (from the other posts, I would guess no, and I know I don't want any Intel crap/Rambus stuff.)
- Did the people who purchased the faulty Intel/Rambus equipment know they were buying Rambus technology? If so, did they buy it for the Rambus claims? (I realize this is a question we can't really answer b/c we don't know what was going on in their minds when they purchased said hardware.)
I also realize that most of those questions are rather poorly thought out questions, and of little import, but I was just wondering...Insert mind here.
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
AMD cop Intel's FUD all the time. The general public is currently deluded into thinking that Intel's processors are SO much faster then AMD's. They say that AMD processors are unreliable. They say that AMD processors are slow. The truth is, a K6-2/400 is almost equally as fast as a PII/400, and easily just as reliable. And now Intel are trying to tell us that the new Athlons are slow.....
What has this got to do with the i820? Well, all of the OEM's will get back on board, and it is because of this FUD campaign. Due to Intel's monopoly of the market, and the FUD about reliablity and speed, OEM's have to use Intel chipsets with Intel processors. The computer illerate family is going to buy a Pentium computer, because thats the one they have heard of.
This stinks. Intel is the M$ that people don't hate as much. Well, if you like to support the little guy, go AMD. With the Athlons shitting over everything Intel has at the moment, make your next PC "Athlon Inside".
M$'s domination has gone too far. Intel's domination has gone too far. AMD boxes with Linux are the way to go, unless you like giving monopolies your money....
MCA vs ISA - MCA was prprietary IBM technology that was definitely faster than ISA, but for what was out back then ISA was more than good enough.
Beta vs VHS - This was mentioned during the previous article on the Rambus problem, but deserves mentioning again. Beta was better, but how many could actually tell the difference, and how many wanted to pay for a marginal difference.
PC vs MAC - Of course MACOS has weaknesses that are well described, but it was well ahead of DOS.
In the end the succesful technoglogy was the one that had the blend of "just enough performance to do what I want" and low cost. Rambus doesn't do it, PC133 barely does, mostly because the marginal cost of PC133 vs PC100 isn't too bad. PC266 probably has sometime to go just because there isn't a killer app for it.
Rambus only has a chance if the follwing conditions are met:
1) There is a killer app that requires multiple rambus channel type speed.
2) There is not a cheaper alternative that is adequate.
Neither conditon exists today in the mass market PC or workstation. And, even with servers a single Rambus channel really isn't anything special.
Dastardly
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...
OK so intel does not have the 820 working with rambus yet. Sun does and a bunch of networking hubs do too. This memory technology will exist in EVERYTHING from playstations to very large servers. I think the price will come down and the speed will go up. It is not the beta max of the century and it will enable full motion video on pc's. Rambus will give more head room for pc box makers as they pass the pc133 sdram standards. Someone may even figure out how to get sdram to go even faster. That is good, but will they get to 1.6 gig / second?!! I doubt it. Remember the modem? 9600 was the theoretical limit, then 28, 36 now 56. It has hung at 56 for a while for lots of reasons. Most importantly it hit the theoretical limit. sdram has a similar kind of limit! Buy RAMBUS and get it working in pc's.
thats what prefetch instructions are for. The idea is that the programmer (or the compiler, hopefully soon) will know better what memory might be needed. So by increasing your memory bandwidth you get the ability to preload into cache the data needed by the branches coming up. Hence for an optimized program (and a large L2 cache), the 'observed' RDRAM latency drops to zero. This is a big feature of Merced (and a feature of SIMD, although that is both optional and P3-only)
Your 50 clock/30 clock example makes an erroneous assumption. Let me put it this way: chip A, clocked at 50MHz has a 50 clock latency cycle while chip B clocked at 30MHz has a 30 clock latency cycle. How long does chip C have to wait for it's request to be fulfilled from Chip A or B?
Your error is assuming that latency is measured only by clock cycle delay on the processor side, when the latency is the actual time it takes from going to the RAM instead.
If SDRAM can keep up with Rambus technology two years from now I'll be mighty impressed, but Rambus will probably be cheaper and faster at that point, with similar latencies but much more bandwidth. SDRAM just hasn't run out of steam at this point...
Pretty much the whole measuring delay by clock cycles is pretty ambiguous. The correct way is to use measure the latency in ns, then at least you can compare across clock speeds.
It is interesting to note that if you look sat the first cycle delays in DRAM from FPM to EDO to SDRAM they are pretty consistent. 60ns FPM was 5-3-3-3 at 66MHZ and 70ns EDO is 5-2-2-2 (4-2-2-2 at 60ns) at 66MHZ, at 100MHZ SDRAM is 5-1-1-1-3(2)-1-1-1. Note the middle number is the CAS we hear about not the first one. So, first cycle number has been from 70-50ns from FPM to SDRAM, but that can be attributed to process technology improvement, there really hasn't been an architectural improvement in latency.
You also have to specify which latency you are talking about especially with SDRAM and DRDRAM because the latency depends a lot on the access pattern.
So, before we get inot arguments, let's make sure there is a consistent measurement. Just one point DRDRAM has numberous latency numbers depending on what is being accessed and when.
I don't see any possibel way DRDRAM could be cheaper than (DDR)SDRAM on the same process given similar economies of scale. The extra die area of the DRDRAM alone kills that, then combine it with royalties on the chips, RIMMS, and chipsets, and it is absolutely impossible for DRDRAM to cost less tham SDRAM all other things being equal.
Also, JEDEC is working on memory that will be faster than DDR-SDRAM leveraging on work from the SLDRAM group, and going even beyond that. And, the JEDEC designs don't carry the baggage that DRDRAM carries.
Dastardly
Goodwill is more important than companies seem to realize, though.
No it's not. People won't pick a slower chip over a faster one when they are comparably priced. Fuck good will. It's about benchmarks, cost and availability.
Allow me to illustrate my point with an outrageously obtuse analogy. Let's say you're buying a new car and looking at the Porsche Boxter and a Tie Fighter. For the sake of argument, they are the same price. The Tie Fighter is manufactured by The Empire--the same people who blew up Aldaron. The Boxster is made by a German company that supports Linux (let's just say...)
I want the Tie Fighter. It can fly and has lasers. I would find a way to rationalize the purchase.
Saying "Our distribution will rock your socks on the Athlon" is certainly cool, but I don't think it will help AMD as much as if they were able to produce large volumes of chips and have compatable mother boards on the market!
heh.
:P
:)
The n64 was overhyped as well
Maybe its an omen
smash
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.