[Official] AMD Ryzen DDR4 24/7 Memory Stability Thread - Overclock.net - An Overclocking Community

Forum Jump: 

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

Reply
 
Thread Tools
post #1 of 2267 (permalink) Old 04-23-2017, 03:04 PM - Thread Starter
@ASUS
 
Silent Scone's Avatar
 
Join Date: Nov 2013
Posts: 11,353
Rep: 402 (Unique: 225)
[Official] AMD Ryzen DDR4 24/7 Memory Stability Thread

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/mciue9..._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/com.../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 [email protected] 1.2v---BIOS 0902---Stressapptest---1 Hour--F4-3200C14-8GTZ
Or
Silent [email protected] 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!

Last edited by Silent Scone; 03-04-2019 at 03:26 AM.
Silent Scone is offline  
Sponsored Links
Advertisement
 
post #2 of 2267 (permalink) Old 04-23-2017, 04:27 PM
Linux Lobbyist
 
Join Date: Sep 2010
Location: Missouri, USA
Posts: 2,655
Rep: 266 (Unique: 139)
Praz is offline  
post #3 of 2267 (permalink) Old 04-23-2017, 07:52 PM
Kraust
 
Secret Dragoon's Avatar
 
Join Date: Mar 2011
Posts: 257
Rep: 9 (Unique: 7)
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.

hwbot - currently not active.
Secret Dragoon is offline  
Sponsored Links
Advertisement
 
post #4 of 2267 (permalink) Old 04-23-2017, 08:40 PM - Thread Starter
@ASUS
 
Silent Scone's Avatar
 
Join Date: Nov 2013
Posts: 11,353
Rep: 402 (Unique: 225)
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.
Silent Scone is offline  
post #5 of 2267 (permalink) Old 04-24-2017, 12:35 AM
New to Overclock.net
 
orlfman's Avatar
 
Join Date: Jul 2008
Location: arizona
Posts: 714
Rep: 67 (Unique: 54)
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.

orlfman is offline  
post #6 of 2267 (permalink) Old 04-24-2017, 12:42 AM
Meddling user
 
gupsterg's Avatar
 
Join Date: Jan 2015
Location: Lurking over a keyboard
Posts: 6,733
Rep: 728 (Unique: 341)
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
gupsterg is offline  
post #7 of 2267 (permalink) Old 04-24-2017, 12:46 AM
New to Overclock.net
 
orlfman's Avatar
 
Join Date: Jul 2008
Location: arizona
Posts: 714
Rep: 67 (Unique: 54)
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.

orlfman is offline  
post #8 of 2267 (permalink) Old 04-24-2017, 01:47 AM
Meddling user
 
gupsterg's Avatar
 
Join Date: Jan 2015
Location: Lurking over a keyboard
Posts: 6,733
Rep: 728 (Unique: 341)
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.
gupsterg is offline  
post #9 of 2267 (permalink) Old 04-24-2017, 02:13 AM - Thread Starter
@ASUS
 
Silent Scone's Avatar
 
Join Date: Nov 2013
Posts: 11,353
Rep: 402 (Unique: 225)
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.
Silent Scone is offline  
post #10 of 2267 (permalink) Old 04-24-2017, 03:33 AM
Meddling user
 
gupsterg's Avatar
 
Join Date: Jan 2015
Location: Lurking over a keyboard
Posts: 6,733
Rep: 728 (Unique: 341)
gupsterg is offline  
Reply

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 3 (0 members and 3 guests)
 


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off