Configure the settings to your preference in the graphical user interface and
click the start button to begin testing. To stop testing, just click the same
button again.
It is recommended to run the test for at least 10 minutes before drawing any
conclusions about the stability of your system memory.
To detect intermittent memory errors you should let the test run for at least one hour.
This thread will now also include results posted for the Z270 platform. However please try to remember the rules below to keep the discussion from becoming confusing, as what may work on one platform may not be viable on the other.
Quote:
[UPDATE JAN 2016]
This thread will now also include results posted for the X99 platform. However please try to remember the following to keep the discussion from becoming confusing, as what may work on one platform may not be viable on the other.
Please try to remember the following
Clarify what platform and CPU you are speaking about when asking a particular question or speaking about your experience.
Quote the user you are replying to when replying.
When posting stability results, be sure to include the CPU as described in the posting results instructions.
Overview
This thread is dedicated to showing the various memory configurations of users with DDR4 on Z170/Z270 and X99 chipsets.
There is no strict criteria here, all things Z170/X99 memory overclocking welcome. However to enter the stability chart certain criteria is to be met as this is generally speaking dedicated to showing what is obtainable on both platforms at an operational level.
If using ASUS within North America you can post here:
Memory Presets: This is the place to start when overclocking memory. Identify the ICs used on the memory modules and select the relevant profile. We've put a tremendous amount of time configuring settings to get the most from each memory type. Once the profile is selected, various parameters in the DRAM timing section will be applied for you. From there, manual tweaking is possible as required.
Maximus Tweak: Leave on auto unless experiencing instability. Mode 1 may allow more compatibility, while Mode 2 is better for performance and some memory modules. Auto defaults to Mode 2.
Memory timings will automatically be offset according to memory module SPD and memory frequency. Should you wish to make manual adjustments, the primary settings and third timings are the most important for overall memory performance. Most timings are set in DRAM clock cycles, hence a lower value results in a more aggressive setting (unless otherwise stated).
As always, performance increases from memory tuning are marginal and are generally only noticeable during synthetic benchmarks. Either way, voltage adjustments to VDIMM, VCCIO-D, Cache Voltage and to a lesser extent CPU Core Voltage & VCCIO-A may be necessary to facilitate tighter timings.
Primary Timings
CAS: Column Address Strobe, defines the time it takes for data to be ready for burst after a read command is issued. As CAS factors in more transactions than other primary timings, it is considered to be the most important in relation to random memory read performance. (See third timing section for further info on important timings).
To calculate the actual time period denoted by the number of clock cycles set for CAS we can use the following formula:
tCAS in Nano seconds=(CAS*2000)/Memory Frequency
This same formula can be applied to all memory timings that are set in DRAM clock cycles.
DRAM RAS TO CAS Latency: Also known as tRCD. Defines the time it takes to complete a row access after an activate command is issued to a rank of memory. This timing is of secondary importance behind CAS as memory is divided into rows and columns (each row contains 1024 column addresses). Once a row has been accessed, multiple CAS requests can be sent to the row the read or write data. While a row is "open" it is referred to as an open page. Up to eight pages can be open at any one time on a rank (a rank is one side of a memory module) of memory.
DRAM RAS# PRE Time: Also known as tRP. Defines the number of DRAM clock cycles it takes to precharge a row after a page close command is issued in preparation for the next row access to the same physical bank. As multiple pages can be open on a rank before a page close command is issued the impact of tRP towards memory performance is not as prevalent as CAS or tRCD - although the impact does increase if multiple page open and close requests are sent to the same memory IC and to a lesser extent rank (there are 8 physical ICs per rank and only one page can be open per IC at a time, making up the total of 8 open pages per rank simultaneously).
DRAM RAS Active Time: Also known as tRAS. This setting defines the number of DRAM cycles that elapse before a precharge command can be issued. The minimum clock cycles tRAS should be set to is the sum of CAS+tRCD+tRTP.
DRAM Command Mode: Also known as Command Rate. Specifies the number of DRAM clock cycles that elapse between issuing commands to the DIMMs after a chip select. The impact of Command Rate on performance can vary. For example, if most of the data requested by the CPU is in the same row, the impact of Command Rate becomes negligible. If however the banks in a rank have no open pages, and multiple banks need to be opened on that rank or across ranks, the impact of Command Rate increases.
Most DRAM module densities will operate fine with a 1N Command Rate. Memory modules containing older DRAM IC types may however need a 2N Command Rate.
Latency Boundary A sets timings for the main set of Third timings, lower is faster and tighter.
Latency Boundary B sets timings for the secondary set of Third timings, lower is faster and tighter.
Manipulating Latency Boundary A and B, negates the need for setting third timings manually, unless granular control of an individual setting is required. For most users, we recommend tuning via the Latency Boundary settings. Advanced users who are tuning for Super Pi 32M may wish to set timings manually instead.
Latency Compensator when enabled tries to make opportunistic latency compensation that may increase performance or smoothen out the Memory training process. So try and compare overclocking and performance with it enabled and disabled. You can also trying enabling it when the whole system hangs at '55' or '03' or '69' when pushing tight timings with high frequencies.
Secondary Timings
DRAM RAS to RAS Delay:Also known as tRRD (activate to activate delay). Specifies the number of DRAM clock cycles between consecutive Activate (ACT) commands to different banks of memory on the same physical rank. The minimum spacing allowed at the chipset level is 4 DRAM clocks.
DRAM Ref Cycle Time: Also known as tRFC. Specifies the number of DRAM clocks that must elapse before a command can be issued to the DIMMs after a DRAM cell refresh.
DRAM Refresh Interval: The charge stored in DRAM cells diminishes over time and must be refreshed to avoid losing data. tREFI specifies the maximum time that can elapse before all DRAM cells are refreshed. The value for tREFI is calculated according to module density. A higher number than default is more aggressive as the cells will be refreshed less frequently.
During a refresh, the memory is not available for read or write transactions. Setting the memory to refresh more often than required can impact scores negatively in memory sensitive benchmarks. It can be worth tweaking the refresh interval to a larger value for improved performance. For 24/7 use, this setting is best left at default, as real world applications do not benefit to a noticeable degree by increasing this value.
DRAM Write Recovery Time: Defines the number of clock cycles that must elapse between a memory write operation and a precharge command. Most DRAM configurations will operate with a setting of 9 clocks up to DDR3-2500. Change to 12~16 clocks if experiencing instability.
DRAM Read to Precharge Time: Also known as tRTP. Specifies the spacing between the issuing of a read command and tRP (Precharge) when a read is followed by a page close request. The minimum possible spacing is limited by DDR3 burst length which is 4 DRAM clocks.
Most 2GB memory modules will operate fine with a setting of 4~6 clocks up to speeds of DDR3-2000 (depending upon the number of DIMMs used in tandem). High performance 4GB DIMMs (DDR3-2000+) can handle a setting of 4 clocks provided you are running 8GB of memory in total and that the processor memory controller is capable.
If running 8GB DIMMs a setting below 6 clocks at speeds higher than DDR3-1600 may be unstable so increase as required.
DRAM Four Activate Window: Also known as tFAW. This timing specifies the number of DRAM clocks that must elapse before more than four Activate commands can be sent to the same rank. The minimum spacing is tRRD*4, and since we know that the minimum value of tRRD is 4 clocks, we know that the minimum internal value for tFAW at the chipset level is 16 DRAM clocks.
As the effects of tFAW spacing are only realised after four Activates to the same DIMM, the overall performance impact of tFAW is not large, however, benchmarks like Super Pi 32m can benefit by setting tFAW to the minimum possible value.
As with tRRD, setting tFAW below its lowest possible value will result in the memory controller reverting to the lowest possible value (16 DRAM clocks or tRRD * 4).
DRAM Write to Read Delay: Also known as tWTR. Sets the number of DRAM clocks to wait before issuing a read command after a write command. The minimum internal spacing is 4 clocks. As with tRTP this value may need to be increased according to memory density and memory frequency.
DRAM CKE Minimum Pulse width: This setting can be left on Auto for all overclocking. CKE defines the minimum number of clocks that must elapse before the system can transition from normal operating to low power state and vice versa.
CAS Write Latency: CWL is column access time for write commands to the DIMMs. Typically, CWL is needs to be set at or +1 over the read CAS value. High performance DIMMs can run CWL equal to or up to 3 clocks below read CAS for benchmarking (within functional limits of the DIMMs and chipset).
On modern architectures like Haswell, page access is optimized such that back to back read timings in the third timing section can have a bigger impact on performance than primary settings. Memory interleaving and addressing optimization leads to the possibility of lots back to back read and writes (page hits) rather than random access (page misses).
In layman terms, the best way to describe this is to use the analogy of a hard drive. If data is fragmented, the head needs to move back and forth over the platter reading small bits of data. Similarly on memory, this would mean that CAS, wCL, tRCD, tRP and tRAS would factor more often - opening and closing memory pages across the DIMMs to read or write parts of data.
If data is not fragmented, the head can seek an area of the disc and read the data without needed to move back and forth. On a crude level, memory interleaving works in a similar way, ensuring that data is arranged into rows across ICs so that pages don't have to be open and closed as often to access it - this saves on excessive primary timing command requirements. That's why some of the back to back read and write timings in the third timing section of UEFI have a bigger impact on performance than the primary timings which were more important on older platforms.
If the required data is in sequence, CAS can be performed to access it and subsequent requests can be spaced by tRDRD (as low as 4 clocks). A lot of these requests can be sent before a page close request is required - which relies on the primary timing set (tRAS then tRP (tRC must elapse) followed by tRCD and then CAS). That's why the third timing spacing has more impact in memory sensitive benchmarks (memory frequency and other factors aside).
tRDRD: Sets the delay between consecutive read requests to the same page. From a performance perspective, this setting is best kept at 4 clocks. Relax only if the memory is not stable or the system will not POST. Very few memory modules can handle a setting of 4 clocks at speeds above DDR3-2400 so you may need to relax accordingly, although the performance hit may negate any gains in frequency.
tRDRD_dr: Sets the delay between consecutive read requests where the subsequent read is on a different rank. A setting of 6 clocks or higher is required for most DIMMs.
tRDRD (dd): Sets the delay between consecutive read requests where the subsequent read is on a different DIMM. A setting of 6 clocks or higher is required for most DIMMs.
tWRRD: Sets the delay between a write transaction and read command. The minimum value we recommend is tWCL+tWTR.
Auto is preferred from a stability perspective, while setting as close to the minimum value as possible is best from a performance perspective. For Super Pi 32m, try tWCl+tWTR+2 as a starting point. If that is stable, then try -1 clock, if not, add+1 and repeat until stable.
tWRRD_dr: Sets the delay between a write transaction and read command where the subsequent read is on a different rank. Keeping this setting as close to 4 clocks as possible is advised, although it will need to be relaxed to 6+ clocks at high operating frequency or when using high density memory configurations.
tWRRD_dd: Sets the delay between a write transaction and read command where the subsequent read is on a different DIMM. Keeping this setting as close to 4 clocks as possible is advised, although it will need to be relaxed to 6+ clocks at high operating frequency or when using high density memory configurations.
Dec_WRD: May give a small performance increase at speeds lower than DDR3-1600 with CAS 6. Can be left on Auto for all other use.
The following timings have a minimum spacing of Read CAS. The default rules space these settings well, so adjustment should not be required unless as a last resort. Setting equal to CAS is stressful on the DIMMs and IMC. Voltages may need to be increased to run the minimum value that POSTs.
tRDWR: Sets the delay from a read to a write transaction.
tRDWR_dr: Sets the delay from a read to a write transaction where the write is on a different rank.
tRDWR_dd: Sets the delay from a read to a write transaction where the write is on a different DIMM.
MISC
MRC Fast BOOT: When enabled, bypasses memory retraining on warm resets. Disabled retrains memory to counter any drift due to thermal changes. At higher memory frequencies the retraining process can interfere with system stability, hence this setting is enabled with auto by default. Should not need changing from Auto unless the system becomes unstable.
DRAM CLK Period: Allows the application of different memory timing settings than default for the operating frequency. Each number in the scale corresponds to a DRAM divider. The lowest setting being DDR3-800. Ordinarily, the timing set applied automatically tracks the DRAM ratio selected. This setting allows us to force timing sets from different dividers to be used with the selected DRAM ratio.
A setting of 14 is recommended for high DRAM operating frequencies. For all other use, leave on Auto.
Scrambler Setting: Alternates data patterns to minimize the impact of load transients and noise on the memory bus. A setting of optimized is recommended for most configurations.
DQ, DQS and CMD Sense Amplifier: Alters the bias on signal lines to avoid mis-reads. The Sense Amplifiers work good at Auto which lets BIOS decide the best for each. Reducing usually is better. Reducing DQ Sense and CMD Sense to -1~ -6 may stabilize things further when high VDIMM is used (2.2+v for example)
DRAM Swizzling Bit 0, 1 ,2, 3:
Enable Bit 0 for best OC most times, but disabling may help uncommon DRAM setups.
Enable Bit 1 for best OC most times, but disabling may sometimes help some 4GB DRAM modules.
Disabling Bit 2 helps high frequency overclocking at the expense of performance. Enabling improves performance but may need several tries to boot when frequencies are high and timings are tight. You can retry training when the system hangs at '55' or '03' or '69' by pressing reset here and waiting for the rig to complete a full reset.
Enabling Bit 3 usually helps overclocking and stability unless the IMC is unstable at cold temperatures (Ln2 cooling) in which case try disabling.
RAW MHz Aid: May help to improve stability when using DRAM ratios above DDR3-3100 at the expense of performance.
IC Optimizer: IC Optimizer sets background invisible tweaks for the various DRAM ICs. Note that these were fine-tuned with specific DRAM and CPUs so it may help or harm depending on the likeness of the ones on your hands. So try with Auto first, then try with the one for your ICs and compare. These will get updated over time in future BIOSes.
For stability results, using the recommendations from Raja@ASUS found below and in the overview seem the most requisite on recent platforms:
Quote:
Google stressapp test via Linux Mint (or another compatible Linux disti) is the best memory
stress test available. Google use this stress test to evaluate memory stability of their servers
- nothing more needs to be said about how valid that makes this as a stress test tool.
GSAT Results For sake of simplicity submitted results will only record primary timing sets, but feel free to show subsequent secondary and terts within screenshot.
Linux Mint's Stressapp test needs to be run for a minimum of 1 hour by typing stressapptest -W -s 3600 in the Terminal.
To take a screenshot in Terminal type: gnome-screenshot
HCI
HCI consider 1000% to be the 'golden standard' however for larger densities this can be time consuming. A minimal coverage of two laps (200%) is required to be added to the table for HCI for density over 16GB. 16GB or less requires a minimum of 4 laps (400%)
NOTE:This is not a leaderboard, as it is not a benchmark. This threads main purpose is to both discuss information and various results and to gauge what is possible between different configurations, DIMM capabilities and CPU samples. Results are welcome all the way up the frequency spectrum. If it's obtainable, it should be posted!
.
Should go without staying that general system and CPU stability should be gauged via the suggested means before attempting an outright memory stability test.
I will organise the results at some point (as well as post some of my own) this weekend and update whenever I get time
If the sticks have a DTS, HWi will read it. in aid64 you may need to enable "DIMM thermal sensor support" under Stability in preferences. Bios may not have the sensor reading at all.
SIV64 also has dimm dts readout:
Yes it is, they reach max of 45ºC, it's because in my country is really hot so the ambient temp isn't the best here in my room, but not for my surprise, the same settings in BIOS that made me stable in HCI 500% failed in MemTest86 at the very end of the test (like 2h of it running), so I think I will just back to 1.43v DRAM, 1.15 IO/SA and 16-17-17-37 (that I am stable MemTest86 at these settings but not at 500% HCI) and live like this. Even knowing it's not stable at 500% HCI, I don't think I can get the stability in both HCI and MemTest86 at the same time...
The only fan I have is the on the top, two Corsair ML120 exausting the air, maybe if I set them pushing air from outside would help, but I think the GPU would get hotter and the only exaust fan would be the back one. But I think if a small fan exists, like I saw one one time you plug it to the 3-pin and it has like an elastic arm with the little fan on top, where you can shape the arm to set the fan in the direction you want, but I don't know where I can buy one of those.
I am currently testing my 32GB (4x8GB) gskill trident Z CL14 3200MHz at 3400MHz.
I never went beyond 3200MHz as I preferred lowering timings (see my stable RAM OC in sig, tested with HCI 1000% minimum on each thread, 3200MHz 13-14-13-34-250-1T)
Currently, HCI is running since 3 hours without errors with following settings
3400MHz
14-15-14-34-250-1T
Vccin=1,808V
Vdimm=1,41V
Vccsa = 0,8V
Vccin=1,048V
Crossing fingers it will pass 1000%. Test will finish in 6 hours roughly (9 hours in total).
About 10% of the time RTL and IO-L on one channel goes way higher than required. Clamping them to good values drops another couple of cycles off of memory access
Yes it is, they reach max of 45ºC, it's because in my country is really hot so the ambient temp isn't the best here in my room, but not for my surprise, the same settings in BIOS that made me stable in HCI 500% failed in MemTest86 at the very end of the test (like 2h of it running), so I think I will just back to 1.43v DRAM, 1.15 IO/SA and 16-17-17-37 (that I am stable MemTest86 at these settings but not at 500% HCI) and live like this. Even knowing it's not stable at 500% HCI, I don't think I can get the stability in both HCI and MemTest86 at the same time...
yeah, at 45C you may see that kind of inconsistency between tests (HCi, memtest etc). try to keep the temps below 40C during the test(s). Normal use will not hit those temps, so do what ever you can to keep 'em cool during memtest or any other stressor.
JP saves the day again, can't count the times you've come through with my questions over the years. Thanks brotha! :cheers:
Can you try to zip tie a fan and point it towards the ram? See if that can help with the temps. :thumb:
DDR4 training is so whack.
About 10% of the time RTL and IO-L on one channel goes way higher than required. Clamping them to good values drops another couple of cycles off of memory access
Doesn't show any signs of instability... What VCCIO are people running for 4DIMM 1R?
I guess I should get around to buying some replacement b-die... my X299 has been dual channel for long enough lol. Any good ones to try other than 3200c14? (have two sets of it, want to try something different)
I guess I should get around to buying some replacement b-die... my X299 has been dual channel for long enough lol. Any good ones to try other than 3200c14? (have two sets of it, want to try something different)
I guess I should get around to buying some replacement b-die... my X299 has been dual channel for long enough lol. Any good ones to try other than 3200c14? (have two sets of it, want to try something different)
With the new 2002 bios compatible with Cascade Lake X I have taken the surprise that I can boot the memory to 4.000 Mhz. Until now, I couldn't, I couldn't even boot the bios. I'm not going to break any records, but I'm very happy to have gotten the 4.000 Mhz of my 4x8 Kit 3.200. I currently value a "light" and silence overclock on the radiator fans, with moderate voltages, so the 7900X at 4.600 Mhz, the 2080 TI at 2.025 Mhz, and the Ram at 4.000 Mhz is a round result for me:
as chibi posted, the 3600c16 8GB stick-kits are very solid performers. I mixed 2 4x8GB kits on the R6EO and the ram was rock solid stable at 4200c17 with 1.5V. I plugged one kit in to the Apex VI and it runs 4000c16 easy (1.45V). I currently have 2 2x8GB 3600c15 gskill kits back on the Apex VI (which have been there since the platform launched), they run 4000c16 the same (maybe tighter secondaries, but I did not spend any real time with the 3600c16s on the Apex). Frankly, the 3200c14s and 3600c16 are the same ICs. the 3600c15s are a higher bin IC.
I'd go with the 3600c16s or try to push the 3200c14s to 4000 (most will).
The only fan I have is the on the top, two Corsair ML120 exausting the air, maybe if I set them pushing air from outside would help, but I think the GPU would get hotter and the only exaust fan would be the back one. But I think if a small fan exists, like I saw one one time you plug it to the 3-pin and it has like an elastic arm with the little fan on top, where you can shape the arm to set the fan in the direction you want, but I don't know where I can buy one of those.
Looks like I can get 3400 on this 3200 CL14 64GB Royal kit (4x F4-3200C14-16GTRS sticks) without having to change timings. 1.35v IO/SA 1.15v, haven't tried turning those down at this speed. Any time I try 3600 with higher voltage and higher timings I can't post to BIOS and have to reflash. I've gone as high as 1.45v and up to 17 17 17 38. Guessing it may be due to the capacity being so high or maybe IO/SA too low, timings are wrong, or I just don't know enough to OC higher. I was getting tired of reflashing. I'm just happy I can OC 64GB at all! Not 100% validated since I haven't done an extended overnight memory test yet, but so far games and DCC software have been running fine with slight speed improvements overall.
vccio and vsa up to 1.25 is routine. Higher is "not uncommon".
as chibi posted, the 3600c16 8GB stick-kits are very solid performers. I mixed 2 4x8GB kits on the R6EO and the ram was rock solid stable at 4200c17 with 1.5V. I plugged one kit in to the Apex VI and it runs 4000c16 easy (1.45V). I currently have 2 2x8GB 3600c15 gskill kits back on the Apex VI (which have been there since the platform launched), they run 4000c16 the same (maybe tighter secondaries, but I did not spend any real time with the 3600c16s on the Apex). Frankly, the 3200c14s and 3600c16 are the same ICs. the 3600c15s are a higher bin IC.
I'd go with the 3600c16s or try to push the 3200c14s to 4000 (most will).
My 3200c14 are already at (or past) 4000 Problem is I need 6 sticks total and I own 4. I had to RMA my Z390 kit (think it was 4400c19?) due to a bad stick. Borrowed a pair of 3200c14 from my X299 and never got around to buying a replacement set. So I have been on dual channel over there and missing half my bandwidth which I'd like to fix, lol
The 3600c15 looks like a solid choice... only $165 on the Egg
Or maybe 4000c17 1.35V diamond encrusted? Only $100 more lol
My 3200c14 are already at (or past) 4000 Problem is I need 6 sticks total and I own 4. I had to RMA my Z390 kit (think it was 4400c19?) due to a bad stick. Borrowed a pair of 3200c14 from my X299 and never got around to buying a replacement set. So I have been on dual channel over there and missing half my bandwidth which I'd like to fix, lol
The 3600c15 looks like a solid choice... only $165 on the Egg
Or maybe 4000c17 1.35V diamond encrusted? Only $100 more lol
I have a 4600C18 TZ Royal kit sitting in the box here. Not decided yet if I want to use it in my next build, or wait for the 4800C18 to come back in stock. Anyone have working experience between the two, and is the 4800 kit worth the extra $$$?
I'm going to be aiming for 4600C16 1T paired with a 9900KS and Gene / Apex XI once the CPU is released.
With the new 2002 bios compatible with Cascade Lake X I have taken the surprise that I can boot the memory to 4.000 Mhz. Until now, I couldn't, I couldn't even boot the bios. I'm not going to break any records, but I'm very happy to have gotten the 4.000 Mhz of my 4x8 Kit 3.200. I currently value a "light" and silence overclock on the radiator fans, with moderate voltages, so the 7900X at 4.600 Mhz, the 2080 TI at 2.025 Mhz, and the Ram at 4.000 Mhz is a round result for me:
Looks like I can get 3400 on this 3200 CL14 64GB Royal kit (4x F4-3200C14-16GTRS sticks) without having to change timings. 1.35v IO/SA 1.15v, haven't tried turning those down at this speed. Any time I try 3600 with higher voltage and higher timings I can't post to BIOS and have to reflash. I've gone as high as 1.45v and up to 17 17 17 38. Guessing it may be due to the capacity being so high or maybe IO/SA too low, timings are wrong, or I just don't know enough to OC higher. I was getting tired of reflashing. I'm just happy I can OC 64GB at all! Not 100% validated since I haven't done an extended overnight memory test yet, but so far games and DCC software have been running fine with slight speed improvements overall.
why are you reflashing the bios (really)? Just hold down the start button for 5 sec (until it powers down) it will enter bios is "safe mode" which is a temp loading of the defaults. Adjust timings (loosen for 3600 to 16-18-18-44-2T) set 1.4V, all other timings at auto and it should boot. leave vsa at 1V or lower for x299 and vccio at 1.05 to 1.15V
The premier forum for overclocking experts and enthusiasts. Discuss hardware optimization, custom builds, benchmarking, cooling solutions, and pushing the boundaries of computing performance. From beginner guides to extreme overclocking, join our technical community to master system tuning.
