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 : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Tenchusatsu who wrote (83312)	6/13/1999 2:08:00 PM
From: dumbmoney	Read Replies (1) \| Respond to of 186894

Uh, KZNerd, I'm not certain about this, but I really don't think latency will be affected by slowing DRDRAM down to 600 MHz. The transmission speed is independent of latency. Of course, this is all assuming that Rambus isn't just slowing the clock down when it downbins DRDRAM modules to 600 MHz, that Rambus is also adjusting the number of latency clocks to compensate. Even if the core access time is the same, NET latency will definitely increase. Not 33% of course, but 5-10%. If Camino ends up being slower than the BX/PC100, there will be hell to pay.

To: Tenchusatsu who wrote (83312)	6/13/1999 7:21:00 PM
From: grok	Read Replies (1) \| Respond to of 186894

RE: <Uh, KZNerd, I'm not certain about this, but I really don't think latency will be affected by slowing DRDRAM down to 600 MHz.> The latency does increase but I can see that my original statement contained a mistake. Where I said: "latency increases by 33%" I meant to say "the latency increase over sdram increases by 33%." I'll try to explain why. The reason people complain about drdram latency is that address and control get piped into the drdram over a narrow channel and even though the data rate is high it still takes longer than just sending an address in parallel as is done for sdram. Click here: rambus.com and scroll to page 7 and you can see that to send a row address takes 4 of the 400 MHz cycles = 10 nsec. (If you're really interested this is because in those four cycles they have 3 pins that can send 3pins4cyles2bitspercycle=24 bits of info. They have to send 5 bits of device address since there could be 32 devices on the channel and 4 bits of bank address since there are 16 banks and 9 bits of row address plus a few bits of misc so it just takes that long.) Now in going to 300 MHz drdrams this 10 nsec increases by 33%. That's what I meant to say. The internal access time of the dram core can be programmed so that it requires fewer cycles at 300 MHz than at 400 MHz. That part is no problem.

To: Tenchusatsu who wrote (83312)	6/13/1999 7:57:00 PM
From: grok	Read Replies (1) \| Respond to of 186894

RE: <The story of Rambus is one big high-tech soap opera. But I still firmly believe that Rambus will end up the victor in the end. Tenchusatsu> Sure, it is almost a foregone conclusion that Rambus will win in the end. The problem is in the near term and it is in uniprocessor desktop systems. The other day someone pointed out the Microprocessor Report article (Oct 26, 1998, page 12) on the 21364. That article referenced another article written by Dick Sites called "It's the Memory, Stupid!" which covered work he had done analyzing a 400 MHz 21164 running TPC-C benchmark showed that the memory system was badly bandwidth limited and there was no point in providing a faster processor until a better memory was provided. So the 21364 has 4 drdram ports directly connected to the processor. This is great since it provides massive bandwidth and reduces latency since it removes chip set delay. The chip also has 1.5 MB of on-chip L2 cache. I'm sure that this product will blow away more conventional products in the Transaction Processing Server market. The above paragraph is the good news about Rambus. Now the bad news is that most computers are not wide SMP Transaction Processing Servers. They're just simple desktops and don't need all that bandwidth. Except for Gamers people are running Word and Netscape and stuff like that and srams do the job pretty well. Now if drdrams could be slipped in at the same price at the same performance invisibly to the customer then no one would care. But what we're looking at now is higher prices, limited availability, and no performance gain and probably even a performance loss. Now if you were a box maker and you had a choice of: 1. Coppermine at Intel's typical high price with Camino with Intel's typical high price with drdram at 2x or 3x sdram prices or 2. K7 priced below Coppermine with AMD chip set priced below Camino with dirt cheap sdrams available in massive supply from everyone. And with 2. out performing 1. perhaps by a substantial margin, which would you choose to bring to market? And if you're a consumer which would you buy? Intel should have brought drdrams into the market in servers and waited until they were ready for desktop before forcing this on everyone. In fact that is how they are treating IA-64.