Sign in with
Sign up | Sign in
Your question

Intel to drop support of Rambus

Last response: in CPUs
Share
Anonymous
a b à CPUs
February 27, 2002 2:56:31 AM

Here's a news article that I thought you guys would be interested in.

http://www.ebnews.com/story/OEG20020226S0040
February 27, 2002 6:08:55 AM

That article is bunk. The headline is very misleading. Read further in the story and they finally wittle their own argument down to "Xeon chipsets at the end of the year are slated to be DDR." The public already knew this.

The reason for DDR in such platforms is that RDRAM does not currently exist in 1GB memory modules. This makes it impossible to equip such a Xeon system with a full 4GB of memory. High end servers and workstations of this nature demand the full 4GB of memory. Thus, DDR-SDRAM is currently the solution.

I assure you that RDRAM is the memory standard of the future and present for Intel desktop systems and the memory standard of the future for Intel server and workstations once 1GB modules appear. Further RDRAM chipsets will appear when they are needed.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
February 27, 2002 6:18:19 AM

Quote:
I assure you that RDRAM is the memory standard of the future and present for Intel desktop systems and the memory standard of the future for Intel server and workstations once 1GB modules appear. Further RDRAM chipsets will appear when they are needed.



Hey ray, can you tell us how intel/rambus, are going to get around the large latency penalties which come with adding additional modules to a system, especially in the case of said 4GB server.

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
Related resources
February 27, 2002 6:38:46 AM

The latency penalties are not all that huge, especially once speeds reach PC1066 and PC1200.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
February 27, 2002 6:51:58 AM

What~!!!


All of the articles I have read show the latency penalty for a second rimm(per channel) IS HUGE, due to the serial nature of the rambus.

I will get a link, one second ::sighs::



Quote:
The next drawback to the RAMBUS channel will be apparent after a good look at the previous diagram. Each SDRAM in an SDRAM system is no more than a few inches along a straight path to the chipset, so commands and data don't have very far to travel to reach their destination. The RAMBUS channel, on the other hand, gets longer as more RDRAMs are added to it, which means that the amount of time that commands and data must travel to reach the outermost device can get pretty high. What makes this even worse is that the system read latency of the entire system can be only as fast as that farthest (and, by extension, slowest) RDRAM. Here's why:

Remember how, way back at the beginning of the first edition of this RAM Guide, we said that, to the CPU, main memory looks just like one, single file line of 1-byte locations? When the CPU asks for data from a series of locations, it expects that it will come to it in the order that it asked for it. It doesn't care where that data lives, or how long it takes to get from one place to the other--it just cares that it sent out a series of requests for x, y, and z, one right after the other, and it expects x, y, and z to be fed to it in that exact order, one right after the other. Well, if x, y, and z each live in different RDRAM chips, where, say, y and z live close to the chipset but x lives way out there in the last chip on the outermost RIMM, then we've got problems. The packet that's farthest from the chipset, x, is going to take quite a bit longer than y and z to reach the chipset, but since x has to be there first and all three packets have to file in one right after the other, y and z will have to wait on x before they can go in.

Because of the need to be able to delay the output of read requests so that reads from different RDRAM chips can arrive at the chipset together and in the right order, a RAMBUS system has to go through an elaborate initialization ritual on boot-up in order to determine the amount of delay that needs to be inserted into each RDRAM. The read delay value for each individual RDRAM chip is programmed via the control pins into one of those control registers that we met in the previous section. These read delays effectively slow down the entire system so that each device has the same latency as the outermost RDRAM. As you add more devices to a RAMBUS system, the entire system has higher and higher read latency. So, while individual RDRAM chips might have a read latency (access time) of 20ns, which is about the same read latency as some SDRAMs, once you stick them in a system with three full RIMMs the overall system latency (which is the total amount of time from when the CPU sends out the read command and the data arrives back at it) will be either slightly better or significantly worse than the system latency for an SDRAM system, depending on a myriad of factors. (More on these factors in a second.)

Further aggravating the read latency situation is the fact that RAMBUS doesn't support critical word first bursting. When the CPU asks for 8 bytes of data from a conventional SDRAM, the memory system sends it back 16 bytes data along with under the presumption that it'll probably need those extra 8 bytes shortly. Nevertheless, the 8 bytes that were specifically asked for-- the critical word--arrive at the CPU first, with the other freebie bytes coming next. RDRAM doesn't do this. It just sends you a whole 16 byte train of data, and if the 8 bytes you asked for are at the end of that train, then you'll just have to wait until they get there.

Finally, since the bus is so long and passes through so many devices, the capacitances added in by the loads of all of the attached devices significantly increase bus signal propagation time. So again, the more devices you stick on the RAMBUS channel, the worse the latency gets. However, RAMBUS' signaling layer, high quality packaging, and strict specifications for producing RIMMs are aimed at reducing these types of unwanted electrical effects.



I would think that the effects would be rather signifigant since rambus already has quite the latency on it.

source.

<A HREF="http://arstechnica.com/paedia/r/ram_guide/ram_guide.par..." target="_new">http://arstechnica.com/paedia/r/ram_guide/ram_guide.par...;/A>

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
February 27, 2002 7:06:16 AM

I am not denying that there is a latency penalty for adding more RDRAM modules to a channel. I just believe the actual latency figures for the penalty have been exaggerated by those in the anti-Rambus camp. Add to that the 25% decrease in latency for the PC800 -> PC1066 move or the 33.3% decrease in latency for the PC800 -> PC1200 move, and the problem really starts to be minimized.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
February 27, 2002 7:08:10 AM

Just so Im clear, are you saying ars-technica, is in the anti rambus camp?


Or do you mean in general?

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
February 27, 2002 7:20:28 AM

I have no idea on their opinions of RDRAM. But all it takes is one writer to have a bias and write a story. A whole organization need not be involved.

However, since that article excerpt does not actually state how much latency there is... it becomes difficult to gauge whether or not they think it to be huge. In fact I find it odd that these numbers were not given.

-Raystonn


= The views stated herein are my personal views, and not necessarily the views of my employer. =
February 27, 2002 3:16:04 PM

Thats because its not a benchmark, its a technical black paper, discussing ram technology on a theory level, did you read the article?

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
February 27, 2002 3:24:48 PM

Have a look <A HREF="http://www.aceshardware.com/read.jsp?id=45000279" target="_new">here</A>, for some numbers on latency. Note that these are clock cycles, not real time. As RDRAM has a higher clock speed, the real time latency would be closer to DDR than these numbers would suggest.

Something I've always thought interesting is that basically the same chipset (P4X266 and KT266a) have different latencies. Apparently the P4 has more inherent memory latency than the Athlon.

<font color=orange>Quarter</font color=orange> <font color=blue>Pounder</font color=blue> <font color=orange>Inside</font color=orange>
Don't step in the sarcasm!
February 27, 2002 3:45:23 PM

The difference in clockspeed for the 2 competing chips is only 340, the numbers are pretty close for pc2100 and 1066rdram, but then again, the nforce has lower latency due to its pseudo dual channel nature.


The latency I am talking about however ray, is the latency you get when you add more than one rimm per channel, not the rdrams basic latency.


Due to rambus's serial nature, If I take 4 rimms, and put them all in, the resultant latency for the whole system goes up, some say drastically, some dont say so much.

But on a ddr system, the number of modules in the system is irrelevant, the latency stays the same and does not degrade, yet another benifit of ddr over rdram for large memory systems.

"The Cash Left In My Pocket,The BEST Benchmark"
No Overclock+stock hsf=GOOD!
!