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 : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Joe NYC who wrote (79946)	5/11/2002 1:03:06 PM
From: combjelly	Respond to of 275872

"Are you saying that part of the latency problem is caused by the fact that there may be several devices on the same channel with signal daisy chained between them and the host?" Yes. While you are correct that the creation and decoding of packets does produce some overhead, the bulk of it is the addition RC delays because of the loads on the bus, and the time allowed for the signal propagation. In addition, when a command is given on a DRDRAM channel, the command goes to the first RIMM, which is then passed to the next, and so on. So every RIMM added to the system cranks another 5ns or so into the latency. To be fair, a HTT system using tunnels would do the same. Which is why you would want to keep the memory system wide, but shallow. The overhead on a traditional north bridge configuration is on the order of 20 clocks, where each clock is the FSB frequency. Which is usually 50-133MHz...