Slashdot Mirror

← Back to Stories (view on slashdot.org)

Will Rambus Go Bust?

Posted by timothy on from the those-whom-the-gods-would-destroy dept.

retep writes: "32BitsOnline has a interesting article about how the new memory standard RAMBUS may go bust. Essentially a bunch of missteps with Intel's Camino chipset, high costs, the rise in popularity of alternative CPU's such as the Athlon and a lack of performance may prove its undoing. I remember a story in Wired just a year or two ago praising RAMBUS for its innovative tactics; look what's happened now."

18 of 104 comments (clear)

  1. The problem with Rambus compared to SDRAM... by Telcontar · · Score: 4

    is a higher latency. This means the CPU has to wait longer until the memory is read, but can read memory faster from then on.
    The consequence of this is that compilers would have to be optimized for that kind of memory access - i. e. accessing a few pages is expensive (and slow) under Rambus, slower than under SDRAM. Accessing many pages is more effective.
    The question is, why did Intel chose this kind of tradeoff? Was there no alternative that did not increase the latency by the factor of 10 (according to the link to Tom's hardware)?

    1. Re:The problem with Rambus compared to SDRAM... by Bryan+Andersen · · Score: 3
      The problem with Rambus compared to SDRAM... is a higher latency. This means the CPU has to wait longer until the memory is read, but can read memory faster from then on.
      The consequence of this is that compilers would have to be optimized for that kind of memory access - i. e. accessing a few pages is expensive (and slow) under Rambus, slower than under SDRAM. Accessing many pages is more effective.

      And that's a really difficult optimization as you basically have to optimize data accesses as well as code. Data is where it is, locality really can't be improved easily. Systems can be tuned to grab a few pages in a row, but then that may still slow you down if you only used data or code on one of them.

    2. Re:The problem with Rambus compared to SDRAM... by overshoot · · Score: 4

      the idea is that boosting frequency down the line (for RDRAMs) will be easier than adding more lines to SDRAM, or trying to boost SDRAM frequency (due to its more parallel nature).

      DDR-SDRAM is actually less parallel than Rambus. DDR has a strobe (clock) line for each eight data lines, where Rambus uses a common clock for sixteen. DDR-II also moves to a dedicated differential strobe. The result is that the skew within byte lanes (the main limit on the transfer rate for source-synchronous signaling schemes) is lower and therefore the data rate can be higher.

      In contrast, Rambus tries to keep the clock rate low by doing four transfers per clock cycle. Since the data has a frequency half of the transfer rate, more width, and is single-ended, there's really no engineering advantage to the 4x multiplier. There is a honking great cost, though, since it requires the devices to oversample the data in between clock edges. This leads to more jitter (sampling-point variability) and makes the Rambus interface (RAC) very complex and expensive. The primarily-analog circuitry in the RAC is one of the main reasons that RDRAMS have such hideously low yield -- it's just ugly getting all of those comparators and timing paths to match up in a cost-means-everything DRAM process which is basically oriented to making lots and lots of cheap capacitors.

      Early DDR devices are already running at over 400 MT/s (million transfers per second) in small systems such as graphics controllers and Transmeta's low-power systems. JEDEC is now putting the finishing touches on DDR and most of the hairy design work is moving to DDR-II. As usual, the second pass mostly applies the lessons learned on the first pass. DDR-II will have less legacy support and will remove some features in the "nice but not worth the speed cost" category.
      The objective is to run early parts with >400 MT/s data rates in large systems -- or in other words, your 72-bit DIMM is going to have more than twice the bandwidth of those still-not-available 800 MT/s Rambus parts -- and the DDR-II parts won't require water cooling, either.

      --
      Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
    3. Re:The problem with Rambus compared to SDRAM... by jeff_bond · · Score: 3

      Your right about the latency of RDRAMS being higher, but the raw throughput of 133MHz DDR SDRAM is faster than the fastest (800MHz) RDRAMs.

      133MHz DDR = 266MHz x 64bits = 2.128 Gbytes/sec
      800MHz RDRAM = 800MHz x 16 bits = 1.6 Gbytes/sec

      Rambus is crap whichever way you look at it.

      Jeff

      --
      stty erase ^H
  2. The Real Problem by Digital+Commando · · Score: 3

    The real problem with Rambus is that Intel tried to squeeze the market for RAM, the same way it has tried with chipsets, graphics, and networking. And it is getting kicked in the teeth everywhere. Didn't they learn anything from IBM's MCA disaster?

  3. Re:One world: DUH by jht · · Score: 4

    You're dead right on the Rambus pricing issue - it costs way too much. Part of that is the royalty factor, but it's more (right now) caused by low yields on Rambus parts and a very small amount of makers. There's no flood of RDRAM on the market to drive prices down the way there is with SDRAM. If yields were equivalent to SDRAM and more people were making the parts, the prices would be a lot more competitive, but still somewhat pricier because of the royalty issue.

    As far as USB/Firewire goes, though - it isn't royalties that have slowed Firewire acceptance. Intel had included USB in every chipset since the LX several years ago - in fact, USB support was in silicon before any OS had support for it. That's why it was on motherboards - It's part of the chipset whether or not you want it, so you might as well build the ports. Firewire royalties are tiny (below $1/port), and it's split between Apple and the other patent holders (I believe TI and Canon are in the group, too). Firewire would have been adopted quicker had Intel followed through with their earlier plans to include it in newer chipsets.

    The other thing that sped acceptance of USB versus Firewire is that USB 1.0 was ready a (relative) long time ago, and Firewire is only a couple of years old. The DV cameras that really take advantage of Firewire have just begun to be priced approriately for the casual camcorder buyer. Sony and Apple build the ports onto virtually all their systems, and are selling them as fast as they can build them.

    Also a Good Thing for USB - since the CPU controls the bus and it's a simple protocol, it's well-suited for cheap, simple peripherals like modems, digital still cameras, low-end scanners, audio devices, etc. Firewire aims a lot higher.

    - -Josh Turiel

    --
    -- Josh Turiel
    "2. Do not eat iPod Shuffle."
  4. Rambus was doomed from the start by jht · · Score: 5

    When Rambus was being designed, EDO RAM was the current standard, and Rambus is competitive in a head-to-head with EDO - with latencies in the same class or faster but much better transfer speeds. SDRAM was intended as a stopgap measure to provide a memory technology that could keep up with the faster Pentium/Pentium II systems during the wait for Rambus to make it to market. But a few things happened to screw it all up:

    SDRAM took off as a standard, and other chipset makers adopted it - and extended it to PC100 and PC133 from the original PC66.

    CPU speeds accelerated faster than anyone planned (a year ago, 600 MHz was state of the art!)

    Rambus was late to market, as were the systems designed to use it. This gave SDRAM more of an opportunity to become entrenched.

    Rambus has proven to be difficult to manufacture to this point, with horrible yields.

    And finally, SDRAM turned out to be a lot more scalable than anyone anticipated at the beginning.

    If Intel had expected DDR PC133 SDRAM, Rambus might never have made it out of the starting blocks in the first place. But given the lead time on their chipset and CPU design cycles, they had to make a call based on what the trend appeared to be - and they bet on the wrong one. The 810 chipset is a lot more important to Intel right now than they had expected it to be, and the 815 wasn't even planned - they also were hoping to retire BX by now. Some of their supply problems of late have been driven by this misforecast. When the dust settles, I expect to see Rambus slowly squeezed out of the mainstream and Intel to quietly write off their investment. It seemed like a good idea at the time...

    - -Josh Turiel

    --
    -- Josh Turiel
    "2. Do not eat iPod Shuffle."
  5. Re:One world: DUH by Spruitje · · Score: 3


    Nobody really likes new technologies that add significant cost through royalties -- see FireWire (ahem) IEEE 1394. USB was free, which is why everyone had those controllers on their motherboards years before they had anything to plug into them.

    Wrong!!!
    Like Firewire to add USB costs money.
    To be precise $ 0,25 a port.
    Contrary to firewire where this fee is split in 7 the fee for USB goes directly to Intel.
    At first you had to pay $ 1- a port for Firewire to the Firewire consortium (existing of Apple, Sony, JVC, Intel (yep, Intel is a member of it too!!!) and 3 other company's.
    Second, because Intel did build USB in their chipsets USB was on the market a little bit longer.
    The biggest problem was not the availibility of USb but the drivers and support.
    That's the biggest difference between Firewire and USB.
    Firewire is a much more mature technology and is aimed at video and data storage instead of input and output devices like mouses and printers.

  6. Interleving memory banks by Bryan+Andersen · · Score: 4

    What ever happened to interleaving memory banks for more speed? It does raise the pin counts, but package technologies have been developed that mitigate that. I have an old 486DX2-66 motherboard that does interleving between two banks of ram. Each cache load loaded two memory words into the external cache instead of one. It won't lead to better write performance, but read rates will nearly double (You get something like a 1.8x effective increase).

    1. Re:Interleving memory banks by overshoot · · Score: 3

      Basically, interleaving moved onchip. What interleaving did was allow you to overlap accesses when the access time was dictated by the handshake between the controller and the RAM. By having two out-of-phase banks of memory transferring at once the bandwidth could be doubled.

      Since DRAMs are inherently much wider internally than externally, it's much more economical to do this inside the DRAM itself. SDRAM etc. read an entire row at once and then shift out chunks in very high speed bursts. Meanwhile they have four or more internal banks which can be accessed for overlapping row accesses. Interleaving would require either making the data bus twice as wide (fuggedaboutit) or switching ownership of the databus on every clock (which is even dumber). Thus, no more interleaving.

      --
      Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
  7. Rambus=phft! by Khan · · Score: 4

    Well, I can tell you that yesterday at COMDEX, I saw an Itanium chip running in a demo box. When I asked what kind of ram it was using, I was told that it was PC133. When I asked why it wasn't using RAMBUS, the guy stuttered and said that he wasn't allowed to comment on rambus. 'Nuff said.

    --

    "Klaatu, verada, necktie!" -Ash

  8. Re:RAMBUS in PlayStation 2 by overshoot · · Score: 3

    RAMBUS memory is being used in the PlayStation 2. Considering that 2 million systems have shipped in Japan and the PS2 hasn't been released to the rest of the world yet, I think RAMBUS is going to get some nice business. Remember, the original PlayStation has sold over 75 million units.

    This isn't even in the noise. DRAM volumes are measured in millions per day, not per year. Industry unit volumes are on the order of thirty billion devices per year. Somehow I doubt that Playstations will make a serious impact on that.

    --
    Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
  9. Re:A more tempered look at DRDRAM by overshoot · · Score: 3

    Granularity - don't discount this one. Presently DIMMs are made with 8 chips, each organized with X8 outputs. That says that 64Mb technology makes 64MB DIMMs. It also says that 256Mb technology makes 256MB DIMMs, even though mainstream PCs today are only now making the transition from 64MB to 128MB. That's part of the reason we've dropped the 4X-per-generation habit, and are bringing out 128Mb SDRAM, because the market just isn't ready for 256Mb. 512Mb and 1Gb are on the drawing boards and early hardware now, so this problem is going to get worse. A single 1Gb chip holds 128MB. (Obviously)

    Which is why DDR parts are moving to x16 wide rather than x8 for the largest volumes. Remember when DRAM was x1 and only a few x4 parts were around? x32 and x64 are on the roadmap for later generations. Basically, the width grows more slowly than the devices' size because the increasing appetite for RAM (thanks, Bill!) keeps raising the level of granularity that anyone really wants (who does 32 MB main-memory granularity any more?) Small systems are a bit different, which is why graphics controllers use x32 parts today.

    --
    Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
  10. The wired effect ? by steve.m · · Score: 4

    Didn't wired also say that interactive movies, push content and Iridium were 'the next big thing'. Look where they are now.

  11. One world: DUH by LocalYokel · · Score: 4
    Regardless of what these EE majors and other so-called experts have to say, the real reason Rambust is going nowhere is cost. Sure, Grambus is not offering a significant/if any performance benefit, but even if it did, the price would have to match performance.

    Nobody really likes new technologies that add significant cost through royalties -- see FireWire (ahem) IEEE 1394. USB was free, which is why everyone had those controllers on their motherboards years before they had anything to plug into them.

    Rambus would have a great chance if it was not commanding a 500% premium, and perhaps cost only 10-15% more than current SDRAM. If they can get the prices down, which they will not, Intel would have been able to release a four channel solution that would significantly reduce its latency (this is coming) and increase its performance. As the technology became financially reasonable for everyone to use, mass production would bring the price down even further.

    Besides, who wants to go back to paying 1995 prices for RAM?

    --

    --

    --
    E2 IN2 IE?

  12. A more tempered look at DRDRAM by dpilot · · Score: 5

    Two forenotes:

    1 - I've been involved in the design of DRDRAM for several years, now. I've been in memory design for 18 years, also. I'm slightly more informed on this than the average geek-on-the-street.

    2 - I really don't like the principle behind DRDRAM. Proprietary things are supposed to eventually become commodities, not the other way around. Memory has long been THE commodity in a computer, and here they are trying to make it go the other way. But it's technically interesting, my contributions won't make or break the whole scheme, and the kids gotta eat.

    Cons:

    Fundamentally, for at least the near future, it simply takes more silicon to implement the Rambus interface. No matter how much learning you do, that area doesn't go away. Perhaps after the spec stabilizes fully, it may be possible to come up with better fully custom circuit implementations, but that's at least a little ways in the future. Plus in the performance race, it's possible that the spec may never stabilize sufficiently before a given generation is obsolete.

    It's very complex. My boss would have slapped me silly had I ever even thought of coming up with this. In years past I've been slapped silly for coming up with stuff a fraction of this complexity.

    Latency - Obvious, though there is a second side to this, under Pros.

    Wash:

    The frequencies are high, and the margins tight. I suspect EVERYONE is going to have to cope with the same realm, sooner or later. DRDRAM is simply a bit ahead of its time on this on, and is taking the pain, first. I remember when it was tough getting the whole chip to run at 100MHz for SDRAM, or even 150nS for page mode DRAM.

    Pros:

    Granularity - don't discount this one. Presently DIMMs are made with 8 chips, each organized with X8 outputs. That says that 64Mb technology makes 64MB DIMMs. It also says that 256Mb technology makes 256MB DIMMs, even though mainstream PCs today are only now making the transition from 64MB to 128MB. That's part of the reason we've dropped the 4X-per-generation habit, and are bringing out 128Mb SDRAM, because the market just isn't ready for 256Mb. 512Mb and 1Gb are on the drawing boards and early hardware now, so this problem is going to get worse. A single 1Gb chip holds 128MB. (Obviously)

    Pin count - As more integration happens, the reduced pincount of DRDRAM may become a bigger factor. It's a simple matter of 168 vs 55, though the 55 need to be at a higher frequency. It's simply easier to integrate a DRDRAM interface and have enough pins to do all of those other things, like an AGP bus.

    Banking (Latency) - While simple latency is poorer, under situations with multiple threads of access (multithreading and/or DMA streams) the higher bank count of Rambus becomes an advantage. If a bank is left open, or even if it has just been closed following a prior operation, you need to wait a 'restore time' before you can access that bank, again. With DRDRAM there are usually more accessable banks, so odds are better that the next access will be to a bank that is currently closed. Even if the simple latency is longer, if you don't have to pay the 'restore time' penalty, the effective latency becomes shorter. This doesn't show up unless you have multiple memory access streams, though.

    No summary

    --
    The living have better things to do than to continue hating the dead.
  13. RamBus DRDRAM vs. DDR SDRAM by Halo1 · · Score: 5
    I think you may find the following article quite interesting: "DDR SDRAM vs. RAMBUS DRDRAM". It's not written by the mosr staff (it was actually a reaction to a feature containing incorrect/skewed information), so all you mosr-haters can calm down already.

    The author explains why he thinks DDR SDRAM is better dan DRDRAM and shows once again that MHz isn't everything.



    --
    --
    Donate free food here
  14. a more clever title... by dirtmerchant · · Score: 4

    ... then wouldn't a more clever title have been rambust? sorry, its early and i need sleep. i realize that was unforgivably stupid.
    -----BEGIN GEEK CODE BLOCK-----
    v.3.12
    GCS d-(--) s+: a-- C+++$>++++$$ UL++$>++++$$ P+>++++$ L++>++++$ E--- W++$>++