Intel Encounters Another Problem with RAMBUS
Palin Majere writes, "News.com is reporting that Intel is once again having problems with its RAMBUS memory chipsets. This time, it's affecting the i820 and i840 chipsets, and is located in the chipsets (MRH and MTH) that allow customers to use regular SDRAM memory instead of RAMBUS memory.
It causes memory corruption and has already caused Intel to cancel three motherboard designs as a result. " With the continuing shortage of high-end Pentium processors, and stuff like this, it's no wonder that AMD has been doing better and better.
Correction: DDR-DRAM is much faster then Rambus. 100MHz DDR-DRAM has bandwidth of 1.6GB/s, same as Rambus. 133MHz DDR-DRAM has a bandwidth of 2.1 GB/s (that's giga *bytes*, btw, not bits). DDR-DRAM, as well as regular SDRAM, also have a significantly lower latency.
And as it happens now, memory bandwidth is not the bottleneck. Even 800MB/s of regular PC100 SDRAM is plenty for 99% of applications, including the latest 3d games. Just about the only thing that would make use of the higher bandwidth is large databases. Too bad you can't put more than 512MB of RDRAM in a machine... ;-)
However, lower latency is guaranteed to boost performance a bit, no matter what kind of application you are running. This is where standard SDRAM and the upcoming DDR-DRAM have an advantage over Rambus. Not to mention the cost...
So, the whole situation can be summed up in one sentence: Rambus is just an inferior product with a ridiculously high price.
___
___
If you think big enough, you'll never have to do it.
DDR-SDRAM is great, but while you can get them in quantity, FINDING a motherboard that supports it natively is quite something else. :-/
I want to know when will the VIA Apollo KX133 chipset be upgraded so it will support DDR-SDRAM.
Raymond in Mountain View, CA
While I don't think that this is the death of Intel, for they have too many fingers in too many lucrative pots, it suggests that they have misstepped badly with RAMBUS are are going to lose their market dominance in CPUs if AMD keeps it's act together... which other than Irongate and a scarcity of Athlon MBs, they have been doing fairly well.
As far as Irongate's AGP issues, there isn't a whole lot of difference performance-wise at this point between AGP 1x and AGP 2x. Maybe in the next iteration of video cards we'll see a more significant difference, but I'd rather have a CPU that is 15%-20% faster than sweating about a 4% hit on the AGP bus. Some people feel that Athlon is not being entirely honest & ethical with the issue, which may taint their reputation in the long run.
My next machine will be an Athlon based system. I've suffered extreme technolust since they were released, and they just get better and better.
It will be quite some time before Intel has anything in market to compete with Athlon, and by that time it might be too little too late. Their most recent efforts have yielded uncertain results in comparison to the Athlon.
-- benton.
Rambus (Inc.) is a company!
They(Rambus Inc.) have designed a memory type called DRDRAM that only uses a 16bit wide external databus, and 8*16bit wide bus internaly.
As always when it comes to Intel it's only MHz that counts, not what they do with those. DRDRAM can handle 800MHz but as the bus is only 16bit wide it wont be very much faster than the 64bits(At most twise.).
I'd put my money on SLDRAM, it will be atleast twise as fast as DRDRAM and is, unlike DRDRAM, an open standard. SLRAM shouldn't have a problem doing 3GB/s+, at much lower clock speeds.
"Last words are for fools who haven't said enough." - Karl Marx
Here are some specs if anyone is interested (the athlon 700 is my 600 overclocked with a GFD (goldfinger device) and stock FSB):
this is a buddies P3 coppermine 700 running with full speed L2 cache.
Summary * (1) 700 MHz * 2024±4.2(0.21%) MIPS (Integer operations) * 799±0.031(0.0039%) MFLOPS (Floating point operations) * 174±0.046(0.026%) (Integer application simulation) * 172±0.14(0.079%) (Floating point application simulation) * 172±0.017(0.0099%) (MMX application simulation)
CPU Details * CPU load: 25 * low MIPS: 1400 * CPUID: 0x0681 0x383F9FF * MMX Present: True * 3DNow Present: False * Streaming SIMD Extensions Present: True * Processor Serial Number Present & Enabled: False * dhrystone time (s): 0.99 * whetstone time (s): 0.013 * Integer time (s): 4.5 * Floating point time (s): 4.2 * MMX time (s): 5.4
another buddies AMD Athlon 600 O/C'd to 700 with ½ speed cache
Summary * (1) 700 MHz * 2114±3.4(0.16%) MIPS (Integer operations) * 846±22(2.7%) MFLOPS (Floating point operations) * 168±4(2.4%) (Integer application simulation) * 205±5.2(2.5%) (Floating point application simulation) * 164±3.4(2.1%) (MMX application simulation)
CPU Details * CPU load: 0 * low MIPS: 1400 * CPUID: 0x0612 0x81F9FF * MMX Present: True * 3DNow Present: True * Streaming SIMD Extensions Present: False * Processor Serial Number Present & Enabled: False * dhrystone time (s): 0.95 * whetstone time (s): 0.012 * Integer time (s): 4.6 * Floating point time (s): 3.4 * MMX time (s): 5.6
Now you can see that the athlon beat the coppermine in every category except Interger application simulation and MMX application simulation...not by much tho. The athlon destroys the coppermine in FPU and leaves it behind in Interger Operations. It should also be noted that the athlon is running ½ cache speed and still beats the coppermine. So just wait until the full speed cache athlon thunderbirds come out. And for those who want more, we did a benchmark on this Athlon 550 (650 core) O/C'd to 832 MHz. This is with a GFD, FSB adjustments and 2/5 speed cache.
Summary * (1) 832 MHz * 2542±0.2(0.0078%) MIPS (Integer operations) * 1031±0.71(0.069%) MFLOPS (Floating point operations) * 197±0.08(0.041%) (Integer application simulation) * 253±0.06(0.024%) (Floating point application simulation) * 194±0.044(0.022%) (MMX application simulation)
CPU Details * CPU load: 2 * low MIPS: -1 * CPUID: 0x0612 0x81F9FF * MMX Present: True * 3DNow Present: True * Streaming SIMD Extensions Present: False * Processor Serial Number Present & Enabled: False * dhrystone time (s): 0.79 * whetstone time (s): 0.0097 * Integer time (s): 4 * Floating point time (s): 2.8 * MMX time (s): 4.8
Shut up brain or I'll stab you with a Q-Tip. - Homer Simpson
It's failed.
I hope Intel, and other chip manufacturers learn from this. Secrecy and control aren't cool. They can, and will, turn around and bite you.
IMHO, Intel's best hope of survival, never mind market domination, is to open the RAMBUS specs completely. Do a hardware variation of the GPL. If they don't, it's going to bleed them dry. If they do, sure, there'll be clones, but Intel will still exist.
Given the choice of pride or survival, Intel needs to think about that survival option a bit more.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The MRH's are Memory Repeater Hubs, and come in two flavors - MRH-S and MRH-R. The -S does translation from rambus to normal SDRAM. The -R is to let you get aronud the 2GB limit on rambus. A rambus channel can have up to 32 256Mb devices, or 1GB. An MRH-R has two channels dangling off it, doubling capacity. Put two MRH-R's on one channel from the chipset, and you can have 4GB.
One interesting thing about this solution is that it takes time to go through the chips, increasing the already high latency of rambus.
I wonder if Intel would alter their decision on Rambus, were they able to go back in time and do so. They might pull it off yet, but it won't be easy. If it does work, it will only be because they are Intel.
The enemies of Democracy are
Reading the article my take on it is that the problem is in the device that does the SDRAM to RamBus conversion (ie it's a channel adaptor that lets them mix and match rams types) - and the problem only occurs when you use ECC.
I can think of 2 reasons this might happen - either they got the ECC logic wrong (probably likely), or there's a noise problem on the sdram side when they drive 72 data pins [for ecc] rather than the usual 64 (less likely). Either way it isn't a RamBus problem.
There's a lot of noise made about the various merits of memory types - my personal take on it is that it's mostly a wash, RamBus drams do have some advantages - but for main memory systems they are more in the future (and revolve around how many chips it takes to make a minimum memory sized system as memory continues to move down the memory density curve - M$ may of course make this moot). Their main disadvantage is cost - and it's rather a chicken and egg sort of thing - if people use them a lot the marginal cost of RDRAMS will probably go close to 0 - but if people don;t use them in volume because they cost more that won't happen. Remember in the core of a RDRAM is the same core that's in an SDRAM it's just the interface circuitry to the pads that's different.
Rambus is a design for a memory system from Rambus Inc. It is extraordinarily fast on paper. Intel chose their design and decided to support it on a lot of their new products.
The implementation took a long time to get around to getting around. It is now here. Intel bet a LOT on Rambus, because it would give them significant control over a lot of markets. (IE: They own rambus designs)
Rambus is significantly different from the DRAM used commonly today. It requires changes to how stuff is laid out on the motherboard. And it is manufactured differently, to very demanding tolerances.
It is now in production and is competing with DDR-DRAM, which uses existing manufacturing processes, generally works with existing chipsets, and is easy to support. And it doesn't require a fan setup for the memory alone. And runs far cooler. And gives almost as good performance when set up correctly as a RAMBUS setup. And is also capable of being manufactured in quantity, whereas RDRAM is extremely difficult to manufacture. DDRDRAM is also about a fifth of the cost of a RDRAM setup.
You do the math, and read up on it a bit.. I think you will agree that for all intents and purposes (read: mainstream pcs, servers, et al), Rambus is DOA.
Toodles.
-troll taker