Overclock.net banner

[Official] AMD Ryzen DDR4 24/7 Memory Stability Thread

4M views 25K replies 1K participants last post by  xemblagogr 
#1 · (Edited)
AM4 Ryzen Memory Stability Thread


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.

NOTE: SOC voltage should ideally not exceed 1.2v Anything above 1.25v has the potential to cause irreversible damage.

Recommended settings ca be found here in the guide provided by ASUS: http://www.mediafire.com/file/mciue95x0a2xfq7/C6H_XOC_Guide_v05.pdf




Happy posting!


Overview
This thread is dedicated to showing the various memory configurations of users with DDR4 on AMD Ryzen platforms.
There is no strict criteria here, all things AM4 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 you can also post here for help:



For stability results, using the recommendations found below and in the overview seem the most requisite on recent platforms:

Quote:Google stressapp test via W10 Bash Terminal(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.


Windows 10 Installation
  • Install Bash Terminal: https://msdn.microsoft.com/en-gb/commandline/wsl/install_guide
  • Install the Google Stress App test by typing: sudo apt-get install stressapptest
  • Once installed open “Terminal” and type the following: stressapptest -W -s 3600
  • You can add argument "-M" and add the the amount of memory you wish to assign to the test (90% of available memory)
  • This will run the stressapp for one hour. The test will log any errors as it runs.

Mint Installation


Quote:HCI Memtest for Windows

HCI Memtest can be run via DOS or Windows. http://hcidesign.com/memtest/

An instance needs to be opened for each individual thread, covering a total of 90-95% of memory giving the OS a little breathing room.

As an example Ryzen 7 1700 - 16GB RAM

16 instances with 850MB per instance.





NOTE: Version 5.0 notes state that it's 30% faster than previous versions. For testing densities beyond 16GB - it's recommended you use 5.0 Pro.

http://hcidesign.com/memtest/





Stability Results

Please submit results with the following format.

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%)


Example:

Silent Scone--7000@3.7---3200Mhz-C14-13-13-36-2T---1.38v---SOC 1.2v---BIOS 0902---Stressapptest---1 Hour--F4-3200C14-8GTZ
Or
Silent Scone--7000@3.7---3200Mhz-C14-13-13-36-2T---1.38v---SOC 1.2v---BIOS 0902---HCI---400%---F4-3200C14-8GTZ


NOTE: This is not a leaderboard, as it is not a benchmark. This thread's 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 saying that general system and CPU stability should be gauged via the suggested means before attempting an outright memory stability test.






Have fun!​
 
See less See more
3
#3 ·
I'll do this in a bit but I wanted to ask a question

> SOC 1.3v

I have been running SOC 1.25v to get a stable 3.9Ghz w/ 3200Mhz @ 14-14-14-34-1T Timings. What is the safe upper bound on SOC? Gigabyte "claims" that it's safe to set SOC up to 1.35v with air/liquid but every other source claims that you're crazy to go above 1.2v.

My issue is that I am *really close* to getting 4GHz w/ 3600 16-16-16-36-1T but I don't know where I am going wrong. Previously I ran this a single time, but it was very unstable.

This is with the Gaming K7.
 
#4 ·
Quote:
Originally Posted by Secret Dragoon View Post

I'll do this in a bit but I wanted to ask a question

> SOC 1.3v

I have been running SOC 1.25v to get a stable 3.9Ghz w/ 3200Mhz @ 14-14-14-34-1T Timings. What is the safe upper bound on SOC? Gigabyte "claims" that it's safe to set SOC up to 1.35v with air/liquid but every other source claims that you're crazy to go above 1.2v.

My issue is that I am *really close* to getting 4GHz w/ 3600 16-16-16-36-1T but I don't know where I am going wrong. Previously I ran this a single time, but it was very unstable.

This is with the Gaming K7.
I've amended the post, as was going on older information. It's been brought to my attention that anything above 1.2v can be potentially lethal. So your sources are right. It's recommended you do not exceed this voltage.
 
#5 ·
If the crosshair is autoing 1.15v for the soc with 2933 and 3200 ratios shouldn't it be safe? i don't see a reason to modify it unless 1.15v's isn't enough. why run lower than the auto soc voltage?

also isn't the greater than 1.2v for the soc crosshair exclusive? since originally asus had a bug that caused soc voltages higher than 1.0v to fry the embed controller on the crosshair. they patched it in 0902. elmor did say in testing up to 1.25v's is fine. anything higher can bring back the motherboard bricking bug of frying the embed controller on the crosshair. he advised 1.2v limit to leave some headroom as 1.25v is the max. so gigabyte might be correct at least for their boards since they might not have the possibility of frying their embedded controllers. i can't recall if amd has released any info publicly about max soc voltages for ryzen.
 
#6 ·
I believe an "Auto rule" in UEFI is bumping SOC on RAM strap change. Not that UEFI "looks up a table" within CPU/SMU and say "hey set x for me".

I had 2x R7 1700, all same hardware :-

i) if UEFI on default and I changed RAM strap to 2400MHz SOC = ~1.050V for both CPU.

ii) if UEFI on default, thus 2133MHz, SOC measured on ProbeIt point for 1st = ~0.838V 2nd = ~0.893V
 
#7 ·
Quote:
Originally Posted by gupsterg View Post

I believe an "Auto rule" in UEFI is bumping SOC on RAM strap change. Not that UEFI "looks up a table" within CPU/SMU and say "hey set x for me".

I had 2x R7 1700, all same hardware :-

i) if UEFI on default and I changed RAM strap to 2400MHz SOC = ~1.050V for both CPU.

ii) if UEFI on default, thus 2133MHz, SOC measured on ProbeIt point for 1st = ~0.838V 2nd = ~0.893V
yeah i've noticed this as well with my 1800x. 2133mhz = ~0.8 - 0.9v's. 2400 = 1.0v. 2933 & 3200 1.15v. 2666mhz i've seen 1.13 - 1.15v. i'm assuming those auto's are perfectly safe for both motherboard and cpu. i doubt asus wants bugs again that will cause more frying of parts after the embed controller fiasco.
 
#8 ·
No idea.

I measure default SOC. Set SOC manually as required, so on remeasure they match stock. Then I up RAM strap and increase SOC as required.

1st R7 1700 2933MHz 14-14-14-14-34-1T VBOOT/VDIMM 1.35V, SOC: ~0.900V needed, could not attain 3200MHz, even with ~1.050V SOC and VCORE increase with offset of +181mV.

2nd R7 1700 3200MHz 14-14-14-34-1T VBOOT/VDIMM 1.35V, SOC: ~0.975V needed.

This was UEFI 1002 or 0902, all same HW except CPU. 1st CPU disposed of, 2nd still not reaching any higher yet. Both could use BCLK of 134MHz with lower RAM strap, with pretty much 0 tweaks to 3.8GHz / BCLK 100MHz profile. Each again attained same 2933MHz/3200MHz.
 
#9 ·
Quote:
Originally Posted by orlfman View Post

If the crosshair is autoing 1.15v for the soc with 2933 and 3200 ratios shouldn't it be safe? i don't see a reason to modify it unless 1.15v's isn't enough. why run lower than the auto soc voltage?

also isn't the greater than 1.2v for the soc crosshair exclusive? since originally asus had a bug that caused soc voltages higher than 1.0v to fry the embed controller on the crosshair. they patched it in 0902. elmor did say in testing up to 1.25v's is fine. anything higher can bring back the motherboard bricking bug of frying the embed controller on the crosshair. he advised 1.2v limit to leave some headroom as 1.25v is the max. so gigabyte might be correct at least for their boards since they might not have the possibility of frying their embedded controllers. i can't recall if amd has released any info publicly about max soc voltages for ryzen.
I don't believe it is exclusive, more a safe limit for the platform if sympathetic and also due to known failures using excessive voltage. What other vendors are saying is up to them, but I'm leaving the recommendation in this thread that 1.2v should not be exceeded, 1.25v maximum.
 
#10 ·
gupsterg--1700@3.8---3200Mhz-C14-14-14-34-1T---1.35v---SOC 0.975v---BIOS 0082---HCI---400%

W10C, CPU Batch: UA 1709PGT Country: Malaysia.




Prior to above W7, HCI MemTest ~6hrs/1000%, 7x 2048MB on 0079 but ProcODT as 53.3Ω so is same as 0082.

 
#12 ·
Quote:
Originally Posted by Secret Dragoon View Post

I will have to end up trying the Linux Application. Windows doesn't seem to "like" the memtest program too much. Killed my display driver.
EopmPDp.jpg
.
Keep in mind that can be caused by memory instability, but make sure applications such as Afterburner are not open.

Also please can results be submitted in the format noted in the op, thank you
 
#19 ·
Quote:
Originally Posted by Silent Scone View Post

I don't believe it is exclusive, more a safe limit for the platform if sympathetic and also due to known failures using excessive voltage. What other vendors are saying is up to them, but I'm leaving the recommendation in this thread that 1.2v should not be exceeded, 1.25v maximum.
do you have evidence of higher than 1.25v's frying other motherboard embedded controllers though? that's thing because so far its been 100% crosshair only. not even asus prime suffered frying of the emended controller. elmor admitted they didn't see this issue on them. as elmor only stated the 1.2 / 1.25v limit because of it frying the crosshairs embedded controller, not because of it being safe for the "platform" or the processor. i doubt gigabyte is not only stating, but autoing 1.35v's for 3200mhz ratio if it frys their controllers.

don't misunderstand me, i'm skeptical of voltages above the 1.2v, not because of asus and frying the crosshairs controller, but because of how steep of a raise that is from the default 0.8-0.9v's on the soc. the only thing i wish if amd themselves came out stating safe soc voltages for their processors for we can at least know from amd themselves and not this misinformation coming from the manufacturers. like gigabytes 1.35v and asus 1.2v. at least crosshair is concerned, its because you can fry the embedded controller asus uses on it.
 
#20 ·
Quote:
Originally Posted by orlfman View Post

do you have evidence of higher than 1.25v's frying other motherboard embedded controllers though? that's thing because so far its been 100% crosshair only. not even asus prime suffered frying of the emended controller. elmor admitted they didn't see this issue on them. as elmor only stated the 1.2 / 1.25v limit because of it frying the crosshairs embedded controller, not because of it being safe for the "platform" or the processor. i doubt gigabyte is not only stating, but autoing 1.35v's for 3200mhz ratio if it frys their controllers.

don't misunderstand me, i'm skeptical of voltages above the 1.2v, not because of asus and frying the crosshairs controller, but because of how steep of a raise that is from the default 0.8-0.9v's on the soc. the only thing i wish if amd themselves came out stating safe soc voltages for their processors for we can at least know from amd themselves and not this misinformation coming from the manufacturers. like gigabytes 1.35v and asus 1.2v. at least crosshair is concerned, its because you can fry the embedded controller asus uses on it.
Are you talking about the DRAM voltage or the Northbridge as it's still called on the MSI boards. Most of the high speed memory seems to be all 1.35v, stock for the NB seems to be floating around 1v.
 
Top