Advice
Beginners
BIOS Guide
CPUs
Links
Mainboards
Memory
Network
Storage
Video/Sound Cards
Contact
Forum
SiteMap
Sponsors
Home
PC Hardware from Made-in-China.com
Prices:
|
Advice Contact Forum SiteMap Sponsors Home PC Hardware from Made-in-China.com |
. | |
|
Prices: |
CAS# latency (tCL)
CAS latency is a programmable delay between reading the data from the sense amplifiers on a DRAM chip and the output of the data onto the memory bus. Specifically, it involves a number of pipeline stages that can be included into the data path or else be bypassed by shortcut switches that are set during the initialization of the memory devices through a so-called mode register set command. Hence the word “programmable CAS latency” – a feature originally invented by Rambus.Inc. In order to be able to function at any given CAS latency, the memory chip must have the necessary pipeline stages and the necessary switches to either activate the pipeline stages or else to bypass them.
This makes CAS latency fundamentally different from other memory access latencies that are only adding additional clock cycles without changing the actual hardware configuration in the memory subsystem. The availability of programmable delay stages is also the reason why it is not possible to arbitrarily execute every CAS latency setting offered in the CMOS setup utility, even if lowering of the frequency would generate the necessary timing window. If the specified latency is not supported by the memory chip's infrastructure, then the setting will result in an illegal mode register entry or else just be interpreted as one of the “other" settings that are available. Typically, a CL 1.5 setting as often added as marketing gimmick to BIOS settings will be executed as CL 2.5, which is the reason that the CL1.5 test results are often worse than the performance when CL 2 is selected.
From a functional standpoint, CAS latency specifies the number of clock cycles between a read command and the time when data are output on the memory data bus. One other interesting aspect of CAS latency is the fact that the read command can be given "in the background" while another read is still in progress. Specifically, during streaming read transfers, a read command is issued exactly one CAS latency before the completion of the ongoing transfer. This is called the “variable early read command” because in the case of a CAS-2 device the command is given 2 cycles before the completion of the burst transfer, in the case of a CAS-4 device, the command is issued 4 cycles before the ongoing burst completes. For the effective bandwidth of the memory bank, this means that CAS latency only matters for the first access within a page, all subsequent accesses will result in seamless back-to back transactions irrespective of the CAS latency. Because of this, and the consequent according optimization of memory controllers and also application software, CAS latency, which used to be the most critical latency in SDRAM, has lost most of its importance for system performance.
Min RAS# to Active time (tRAS)
The so-called RAS Pulse Width specifies the number of memory clock cycles necessary to stabilize the data in the sense amplifiers before they can be restored back to the memory cells of origin. From a command view, tRAS defines the time from the issuance of a bank activate command until the precharge command can be given. Undercutting the minimum RAS pulse width will inevitably lead to data corruption that is not necessarily apparent to the user but that will also result incorruption of the data on the hard disc upon executing the memory dump during shutdown.
Especially in dual memory channel systems, a short tRAS setting can cause performance degradation. The reason is that, depending on the architecture, the protocol used, and the front-end of the processor, getting the data from one channel may take long enough to exceed tRAS on the other channel. In practice, this means that there may be no activity on the second channel even though data transfers are outstanding. If the memory controller uses a closed page policy to minimize random access latencies, the result can be that the page that contains the desired data is just in the process of being closed (precharged) when the data are finally requested. The result is unnecessary closing and reopening of pages along with a noticeable performance degradation.
Consequently, it is often better to use a tRAS higher than the minimum time supported by the memory components since increasing tRAS will extend the bank open time even if no idle counter is implemented. As a result, even if conflicting accesses to the other channel or another bank occur, the extended bank open time will allow access to the first row without the penalty of reopening the page - since the extended tRAS setting prevented the premature closing of the page.
This phenomenon was particularly apparent in nForce2 chipset-based systems, however, also in current systems, bank interleaving policies can cause similar issues since pages are opened in a speculative manner and - if the read command is not issued in due time, the page will be closed (prematurely).
|
AMD Athlon64 X2-3800+ (AM2) |
next page: => RAS-to-CAS Delay (tRCD), Precharge Latency (tRP) and Row-to-Row latency (tRRP) =>
All advice and educational articles on LostCircuits are free, but if you feel you can, please make a small donation to us!
