Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: Dan3 who wrote (35105)	11/24/1999 12:10:00 AM
From: Tenchusatsu	Read Replies (1) \| Respond to of 93625

OK, Dan, here are my takes on DDR's shortcomings: 1) Unbehaved electricals. Say what you want about Rambus, but DDR has its own challenges as well. I'm not an electricals kind-of-guy, but I don't think it's a trivial matter to double-pump data (except in a point-to-point connection, but DDR isn't P2P). In other words, I don't believe it's as easy as the anti-Rambus coalition states. (The reason why Rambus makes the big jump to 400/800 MHz is because the nicer electricals allow for a huge jump in transfer speeds.) 2) One DDR channel requires at least 180 pins. One RDRAM channel requires about 80 pins, I think. No, pins do not come for free. It's one of the reasons why multiple RDRAM channels can be grouped together rather easily. In contrast, an upcoming chipset supporting dual Athlons and (I believe) dual DDR channels will require over 1,000 pins on the north bridge. (The 840 north bridge requires half the number of pins.) 3) Granuality is still an issue with DDR. To go with less than eight chips per DIMM, DDR will require higher pin counts per chip, and that isn't trivial. With Rambus, the minimum number of chips per channel is one. Of course, this isn't much of an issue with current memory densities, but at those densities increase, the granularity will become a bigger issue. 4) It is still hotly debated as to whether DDR SDRAM demonstrates a higher effective bandwidth over RDRAM. (Micron and Bert McComas say yes, Toshiba and Intel/Rambus say no.) At least it's obvious that DDR isn't as efficient as RDRAM, despite its higher theoretical peak bandwidth. And to address your points: <400MHZ logic on chip makes it expensive to manufacture> You know, I really don't know what makes Rambus so expensive to manufacture. One thing is for sure, it seems that the low yields plaguing PC800 RDRAM can be fixed by going to 0.18u manufacturing. And that's also the same solution proposed by Toshiba to increase the yields of CAS-2 PC133 SDRAM. <400MHZ is too big a jump right now, and runs into too many speed of light issues, limits total memory size.> No, it's the nature of Rambus that limits total memory size. As for 400 MHz being "too big a jump," I already talked about how Rambus' well-behaved electricals allows for that big jump to occur in the first place. <The latency in the controller is too high - don't know if that's fixable or not> Latency is a rather fuzzy issue, yet I think the anti-Rambus coalition continues to use "latency" like a political buzzword. Yes, the packetization of RDRAM does add a few nanoseconds of latency, but to me, that only adds one more FSB clock of latency. Then the chipset design of 820/840 might add another clock, but that's not a fundamental issue w/ Rambus. Besides, "latency" as a buzzword actually refers to a lightly-loaded system. If you care about every nanosecond of latency when running applications like MS Office, then yes, latency in a lightly-loaded system is absolutely critical. But it's more important to talk about average latency in a highly-loaded system. Right now, I've seen a couple of articles arguing that the power management features of the 820 (and maybe 840) is hurting performance in a highly-loaded system. I don't know if that power management is something that is permanently required for Rambus support, or just a temporary "1st implementation" pain. Whew. That's my story, and I'm sticking to it (at least until the story changes). Tenchusatsu