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 : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: Dave B who wrote (41081)	4/27/2000 5:46:00 PM
From: jim kelley	Read Replies (2) \| Respond to of 93625

Dave, I believe those figures derive from the page hit rate. RDRAM performs better because of the higher hit rate. DDR ram should suffer from the same problem as regular Sdram. Of course, the relatively low hit rate on the SDRAM should be figured into the average latency of the SDRAM. The AMDroids of course have neglected such phenomenon in their trenchant analysis of initial latency. <G> JK

To: Dave B who wrote (41081)	4/27/2000 7:20:00 PM
From: Ali Chen	Respond to of 93625

Dave, <maximum sustainable transfer rate> Your problem is ill-formulated. There is nothing like "general sustainable" transfer rate. The rate depends on application and operating system, but mostly on system cache organization. Why? Because the PC operates on caches and by cachelines. Every new read from main memory needs to find a space in the cache. If the cache is heavily modified as a result of application work, every read can face a write-back, and the sustained read rate may be even below 50% of the theoretical bandwidth. If it is better, it means that the cache is only partially modified, and the write-back traffic is not so heavy. All depends on application. If some benchmark show off better results, it means that the benchmark does not represent the real workload. The amount of OS activity also counts since usually L2 cache shares code and data, so OS code also occupies the cache space and needs to be restored if it was trashed by data. This leads to additional traffic that is not accounted by benchmark but eats up the bandwidth, so the results are lower. On the other hand, in carefully crafted benchmark the sustained transfer rate may approach the theoretical limit, but it will have no resemblance to real world performance. Now you can speculate as long as you want about how better the Rambus bandwidth and (presumably) better DRAM page hit rate got bogged down by enormous initial latency, ( see Message 13507564 ), all it does not matter. The fact is that at comparable front-side-bus speed the old SDRAM beats RDRAM in all real application benchmarks, see TomsHardware.com. Quod Erat Demonstrandum. The research project is being terminated. :) :)