To: Tenchusatsu who wrote (47181 ) 7/13/2000 8:15:08 PM From: Dan3 Read Replies (3) | Respond to Re: There isn't much of a difference in latency between sending all of the bits at once, and packetizing the data. micron.com , for example - notice that it comes in several grades for latency under a best case, ready mode chip. 40, 45, and 50 ns. That's where the 40 clocks comes from. micron.com - go to the bookmark for read latency. There is one 7.5 ns clock for Row select then (cas 2 @ 133) 15 ns for a total of 22.5 ns or clocks before data is available.What data do you have to back this up? Yes, RDRAM takes up slightly more width than a PC100 SDRAM channel because of the wider traces and the additional ground wires. (Thanks Carl.) But then again, PC100 SDRAM has been around for a long time, and it is relatively easy to implement compared to DDR. And DDR is the real competitor to RDRAM. Let's see just how much real estate DDR takes up on the motherboard. I'll bet it's almost twice as much as RDRAM. Message 13853059 . DDR 266 runs at the same 133MHZ frequency as PC133 - not the 400MHZ of Rambus. There is no obvious reason why DDR should be more difficult to implement or require more board space than other 133MHZ traces. Your claim that it will require twice the space of other 133MHZ runs makes no sense - why should it?Geez, where do you come up with this nonsense? Dan, why should it take PC800 RDRAM 40 clocks to read the cells? It's all the same DRAM inside the memory cells, no matter whether it's PC100 or DDR or RDRAM. RDRAM, like DDR, reads an entire row in the DRAM array, then uses column addresses to pick and choose the data chunks. It doesn't take 40 clocks for RDRAM, nor is the internal access magically instant for DDR. Second, once the data is obtained from the memory channel, it still must travel over the front side bus. That's why your original argument of "256-bit wide Coppermine L2 bus" really makes no sense, because no matter whether it's DDR or RDRAM, data still has to funnel through the FSB before it gets to L2. Third, where do you get the idea that it takes "1.5 clocks to put the first 4 bytes into the cpu, with 10.5 more needed to fill the line"? You're talking more nonsense here. Once again, data has to funnel through a FSB. The FSB is 64 bits wide, so eight bytes are transferred at a time, not four like you assume. In conclusion, Dan, I think you'd be better off arguing other points against RDRAM than its technical merits. (Or at least leave the technical arguments to Bilow Carl.) You simply do not know what the hell you are talking about. Period. By the way, if packetizing the data is such a latency hog, why is AMD going with a network of narrow P2P connections in their future LDT technology? You know that each narrow LDT port will require packetizing the data, right? But oh my God, packetizing data is a no-no because of the incredible latencies! What is AMD thinking?
