Overclock.net - An Overclocking Community

Overclock.net - An Overclocking Community (https://www.overclock.net/forum/)
-   AMD CPUs (https://www.overclock.net/forum/10-amd-cpus/)
-   -   Ryzen Essential Info with link to owners info DB (https://www.overclock.net/forum/10-amd-cpus/1625015-ryzen-essential-info-link-owners-info-db.html)

gupsterg 03-08-2017 03:23 AM

Asus Crosshair VI Hero owners, "brick fix" ROM is 0902 and newer, available in OP of Elmor's CH6 OC thread linked below.

Also if using UEFI PState 0 OC with offset mode voltage for VCORE, disable Core Performance Boost, see this post
plus spoiler below.

Core Performance Boost (Click to show)

If you OC as soon as CPU go out of base clock multiplier OC mode kick in and PB/XFR is disabled.

So on a multiplier of:-

i) R7 1700 = 30.25
ii) 1700X = 34.25
iii) 1800X = 36.25

Will = OC mode.

I have a C6H, currently if a memory OC fails training :-

i) AMD CBS pages is reset.
ii) Extreme Tweaker is not reset.
iii) CPU Core Voltage Offset mode.
iv) CPB is [Auto/Enabled] on Extreme Tweaker.

CPU will get excessive voltage.

This is down to how CPU can use PB/XFR (even at boot/in UEFI) as CPB is on and as the CPU Core Voltage Offset did not reset on Extreme Tweaker = ~1.5V to CPU .

So my advice if you OC DISABLE CPB manually in UEFI.

Last update: 23/12/17

- Ryzen Timings Checker v1.02 link added.

Important info regarding temps on R7 1700/1700X/1800X in HWiNFO (Click to show)
Originally Posted by Mumak View Post

No, that offset is available since build 3125 as a secondary sensor called "CPU (Tdie)", which is available only for CPUs that have the Tctl_offset (1700X, 1800X).

What is shown as CPU Sensor under Asus Crosshair VI Hero is the Super IO Chip reading tCTL and displaying it. The Super IO chip CPU senor reading is used for cooling profile on C6H. The Super IO chip is ITE IT8655E.

This thread's OP will just have essential Ryzen info which I have collected for my own purposes of "meddling" biggrin.gif .

The Ryzen data I have collected so far from owners, if you would like to be included please state IHS stamp info. As it will be interesting to see if newer batches improve on OC'ability or not.

Essential Viewing

Delidding Ryzen: Is AMD Ryzen 7 soldered or not? by der8auer

AMD Ryzen Direct Die Cooling - Improvements? by der8auer

Essential Reading

Ryzen: Strictly technical by The Stilt

The PDF in ROG Crosshair VI overclocking thread by Elmor

Official AMD Ryzen DDR4 24/7 Memory Stability Thread

Ryzen Memory IC Collection Thread

Community Update #4: Let's Talk DRAM!

Memory OC Showdown: Frequency vs. Memory Timings (Also view section in OP Is RAM MHz king?)

Useful links

Windows 7 update unblocker

AMD Ryzen Master Utility - APP/PDF

AMD AM4 Chipset driver - Supports Windows 10/8.1/7 (64​-bit)

RyMem - the easiest way to see if your RAM will work with AM4

Elmor's tinkering tools for C6H

Elmor's SPD Tool, which allows checking of SPD data for corruption and restoring if you have file.

Ryzen Timings Checker v1.02 by The Stilt

UEFI 1403-SP42M by The Stilt for C6H

UEFI 9920-SP42M by The Stilt for C6H

Now the basics I have been gathering

RAM Info / Data Fabric (DFICLK) / Memory Stability testing
Warning: Spoiler! (Click to show)
Official RAM Info (Click to show)

Above is the official info on Ryzen 7 DDR4 support, any other config would be considered unofficial/OC. As the platform is so new currently, ROMs of mobos need to mature, so your achievable speeds will differ with higher spec DDR4 plus what #dimms/rank used/size GB.

Next on the C6H is an option DRAM VBoot Voltage, why is this handy?
Originally Posted by elmor View Post

This option is available because AMD is running their PSP and applying DRAM Ratio/timings before our BIOS code is able to execute. This means we can only apply higher voltage at that stage. If you boot from a fully powered off stage you'll get the default 1.2V until then. VBoot will tell our EC to apply higher voltage immediately at power on.

Next AMD will be releasing an update in May, which will improve RAM options.
Finally, as part of AMDs ongoing development of the new AM4 platform, AMD will increase support for overclocked memory configurations with higher memory multipliers. We intend to issue updates to motherboard partners in May that will enable them, on whatever products they choose, to support speeds higher than the current DDR4-3200 limit without refclk adjustments. AMD Ryzen™ processors already deliver great performance in prosumer, workstation, and gaming workloads, and this update will permit even more value and performance for enthusiasts who chose to run overclocked memory.

Quote extract link.
Data Fabric (Click to show)
The data fabric

The northbridge of Zeppelin is officially called as the data fabric (DF). The DF frequency is always linked to the operating frequency of the memory controller with a ratio of 1:2 (e.g. DDR4-2667 MEMCLK = 1333MHz DFICLK). This means that the memory speed will directly affect the data fabric performance as well. In some cases, it may appear that the performance of Zeppelin scales extremely well with the increased memory speed, however that is necessarily not the case.

In many of these cases the abnormally good scaling is caused by the higher data fabric clock (DFICLK) resulting from the higher memory speed, rather than the increased performance of the memory itself.

Quote from link.

I do not know the validity of this screen shot, it is on MSI AM4 mobo pages:-

C6H UEFI 0079 onwards ProcODT plus other settings to aid gaining RAM Speed (Click to show)
Originally Posted by elmor View Post

Extreme Tweaker/DRAM Timings will overwrite CBS menu items.
ProcODT/Fail_CNT (Click to show)
ProcODT = Processor On Die Termination
Originally Posted by elmor View Post

There are two new settings under AMD CBS\UMC Common Options\DDR4 Common Options\ you might want to take a look at, Fail_CNT and ProcODT.

Fail_CNT decides how many times to retry when DRAM training fails (F9 -> 0d), default is now 1.

ProcODT can help improve your DRAM overclocking, 0079 relies on whatever Auto value AMD deems is best, 0081 has default value as 53.3 ohm. There's a setting available also on previous BIOSes under AMD CBS\UMC Common Options\DRAM Memory Mapping named BankGroupSwap. If you have 2x Single-Rank modules you can try setting this to Disabled and you might see some performance boost in certain applications.
Originally Posted by pantsoftime View Post

For anyone unfamiliar with ODT, it's a termination setting for signal integrity purposes. It's not going to affect performance (directly) or degrade your chip but it will affect your ability to run at higher clock speeds. Both DRAM and DRAM controllers (IMCs) have ODT (on-die termination) resistors that are configurable to a few different settings. Nominal ODT values are often set based on trace impedances, but other factors often come into play. I can imagine things like: number of DIMMs installed, DIMM PCB design, VDIMM and VTT voltages, etc all having an effect on which ODT setting works best. I would shy away from very high settings because the signal will overshoot/ring a lot and potentially cause problems.

Suggested ProcODT values from Elmor/The Stilt.

Samsung B (SR) 2x8GB 53.3Ω / 60.0Ω
Samsung B (DR) 2x16GB 80Ω / 96Ω
Samsung B (DR) 4x16GB 43.6Ω
Hynix A (DR) 2x8GB 53.3Ω
Hynix A (DR) 4x8GB 40Ω
My take on ProcODT with [email protected] post links (Click to show)
Case 1

i) User sets ProcODT 80Ω, saves and mobo repost.
ii) On repost if ProcODT is "wrong", training fail, AMD code detect this and revert to stock (ie [Auto]).
iii) Mobo repost successfully, user views ProcODT and it is [Auto].

Case 2

i) User sets ProcODT 60Ω, saves and mobo repost.
ii) On repost if ProcODT is "right", training does not fail.
iii) User views ProcODT and it is [60Ω].

A table of my testing of ProcODT

All settings were same except ProcODT and "one off" test of increased SOC: 1.05V. So too low/high a setting of ProcODT = boot issue straight away. A setting within "optimal" range will "train" on post of mobo. User needs to do further stress testing for setting.

Further testing of ProcODT

User tests "setup" with HCI Memtest, there are errors. Users needs to retweak ProcODT. Reference link 1, link 2, link 3.


i) What is ProcODT? link 1, link 2.

ii) What is ProcODT value at [Auto]? UEFI prior to 0079 is what AMD code/training decide, after UEFI 0081 is 53.3Ω from reading Elmor's posts/build up of UEFI. UEFI 9943/9945 is what AMD code/training decide.

ii) Why can I only select predefined ProcODT? link.

iii) Why do I need to do these steps, can I not just measure the value for ProcODT with a DMM? link

iv) I'm still having issues once tuned ProcODT and passed HCI Memtest? link. Only my opinion, the caveat for this is still "we" have immaturity on platform in regard to firmware. So even if "voltages" are correct and ProcODT, "we" may still face some issues. Variables like RAM kit, IMC, etc. So for some easy "tuning" others not.
CLDO_VDDP/Geardown (Click to show)
What is CLDO_VDDP?
Originally Posted by elmor View Post

Supply voltage for the memory PHY.
Originally Posted by elmor View Post

The VRM still works, but the CPU now uses an internally generated voltage instead of the external VRM on the MB. So you can change the value, but it won't affect anything inside the CPU. Only the CLDO_VDDP value works.
Originally Posted by elmor View Post

The setting is saved, but you need to power off once first before it actually applies. For example set the value and save + reboot. Go into BIOS again and power off your system, then power on again and the value should be applied.
Originally Posted by elmor View Post

You can try changing the CLDO_VDDP setting (in AMD CBS, don't remember exactly which submenu), it's the replacement for VDDP found under Tweaker's paradise. Our setting is not affecting anything anymore, AMD changed the internal LDO setting. It can help stabalize things and even help with the memory frequency hole. Recommended values are around 900-1000mV, default is 950mV.
Originally Posted by The Stilt View Post

Few suggestions regarding the controls allowed by the new (AGESA bioses:

- In case you run into a MEMCLK hole, adjust the CLDO_VDDP voltage. The VDDP adjustment window is rather narrow, usually < 100mV. Also the window is neither static or linear. Because of that the setting which is optimal for frequency x might not be optimal for frequency y. Also since the window is not linear, but more of a wave form e.g. VDDP at 975mV might work perfectly fine whereas 980mV won't be able to train the memory. The MEMCLK hole is both CPU and DRAM specific, but so far I haven't seen any evidence it being motherboard specimen specific. This means that swapping either the CPU or the memory (to another CPU or modules) might either introduce or the get rid of the MEMCLK hole. Personally I have 100% success rate in clearing the MEMCLK hole with CLDO_VDDP adjustment (1x R7 1700, 1x R7 1800X and 2x R7 1700X). All of the MEMCLK holes on these CPUs have been cleared using 937 - 1000mV setting. Do note that when you change the CLDO_VDDP voltage, saving the bios settings will not put the new CLDO_VDDP voltage into effect, since the CLDOs can only be programmed during a cold reset or a cold boot. Because of that I suggest that you save the new CLDO_VDDP value and press the reset button before the system has booted up again. Also CLDO_VDDP must be at least 100mV lower than the DRAM voltage at all times. Regardless it is not recommended to exceed 1050mV.

- For Samsung B-die dual rank modules I suggest that 96Ohm ProcODT is used.
Originally Posted by The Stilt View Post

The memory controller FW used in still has room for improvements.
If the CLDO_VDDP is out of whack then it will fail memory training all together. I've yet to see any kind of improvement in stability from VDDP adjustment.

I'm not sure what the programming rules for tCWL are in this specific version, but make sure it is in sync with tCL on dual rank modules. Also if you're running high VDDCR_SoC voltages, try lowering it a bit (< 1.100V). Other than that there is not much you can do about it.
Originally Posted by The Stilt View Post

CLDO (dLDO) regulators don't use any of the external interfaces as the regulators are built into the die. They have granularity of 1LSB = 1mV, meaning you don't have to follow SVI/2 step size (6.25mV - 12.5mV).

Setting up 2T/Odd CAS.
Originally Posted by elmor View Post

If setting Command Rate or Geardown, please note Geardown = Enable is only possible with Command Rate = 1T (default at 2666+). Additionally CAS Latency is required to be an even number when Geardown is Enabled, some of you might have noticed.
Originally Posted by elmor View Post

Command Rate sets how many clock edges to wait after setting up addressing (how long to wait before reading or writing data), while Geardown is lowering the frequency of the commands sent to the DRAM (data speed is still the same).[/qoute]
BankGroupSwap and BankGroupSwapAlt (Click to show)
Originally Posted by The Stilt View Post

The default configuration is BankGroupSwap = Enabled, BankGroupSwapAlternative = Disabled.

These two options are mutually exclusive, meaning they can both be disabled but they cannot be enabled simultaneously.

Disabling BankGroupSwap will improve the real world performance (by couple percent), however the reported bandwidth (e.g. AIDA) decreases by < 6%.

Enabling BankGroupSwapAlternative has nearly the same positive effect on the real world performance, while the reported bandwidth remains at the same level with BankGroupSwap = Enabled.

Neither of the BankGroupSwap options should be touched, unless 1 DPC SR modules are used.
Originally Posted by The Stilt View Post

If you are using dual rank or 2 DPC single rank modules, you don't touch these options at all. This results in BankGroupSwap = Enabled and BankGroupSwapAlternative = Disabled (the configuration I was using).

With 1 DPC single rank configuration you should either disable both of them, or set BankGroupSwapAlternative = Enabled.

Enabling BankGroupSwapAlternative has the same positive effect on the real world performance as disabling BankGroupSwap does, however it doesn't have it's down sides (i.e. the lower reported bandwidth figures).

So basically:-

For 2 dimm per channel dual rank leave as is, ie UEFI defaults.
For 1 dimm per channel dual rank leave as is, ie UEFI defaults.
For 2 dimm per channel single rank leave as is, ie UEFI defaults.

Only for 1 dimm per channel single rank set as Disabled for both or have BGSA Enabled.
CAD Bus Configuration (Click to show)
Originally Posted by The Stilt View Post

Those who are able to train the memory at high speeds (>=3466MHz), but are unable to stabilize it due to signaling issues, I suggest that you try decreasing the "Command & Address" related drive currents (increasing the resistance).

AMD CBS > UMC Common Options > DDR4 Common Options > CAD Bus Configuration > CAD Bus Drive Strength User Controls:

Clock Drive Strength = 30.0Ohm
Address / Command Drive Strength = 30.0Ohm
CS / ODT Drive Strength = 30.0Ohm
CKE Drive Strength = 30.0Ohm

24.0Ohm is the default value for all of them, at >=2666MHz MEMCLK (regardless of the DRAM configuration).

These values are not very sensitive so anything up to 60Ohms should allow you to train the memory.

At default settings (24.0Ohms) anything above 3466MHz was unstable due to signaling issues (only B2 DIMM slot was able to run 3600MHz stable).
Memory Stability testing (Click to show)
In the past I have used HCI Memtest, then we have Google stressapp test, link to thread.
Batch file for multiple instances of HCI Memtest (Click to show)

Below is example of what is needed in a batch file to open 16 instances of HCI using 850MB to test ~13,600MB on a 16GB rig. Remove lines for lower thread count CPU and edit value after /t to change RAM amount an instance uses.
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850
start memTestPro.exe /t850

In the OP of Official AMD Ryzen DDR4 24/7 Memory Stability Thread, there info on using these applications. Another thread that has some good posts to ref/search in is *Official* DDR4 Z170 Z270 and X99 24/7 Memory Stability Thread.
The Stilt's DDR4 Timings (Click to show)

This post contains his DDR4 timings setup on F4-3600C15-8TZ @ 3466MHz which I believe to be F4-3600C15D-16GTZ (Samsung B-Die).

C6H UEFI DRAM Timings setup as The Stilt's settings (Click to show)
DRAM CAS# Latency [14]
DRAM RAS# to CAS# Read Delay [14]
DRAM RAS# to CAS# Write Delay [14]
DRAM RAS# PRE Time [14]
DRAM RAS# ACT Time [28]
Trc_SM [54]
TrrdS_SM [6]
TrrdL_SM [9]
Tfaw_SM [36]
TwtrS_SM [4]
TwtrL_SM [12]
Twr_SM [12]
Trcpage_SM [Auto]
TrdrdScl_SM [2]
TwrwrScl_SM [2]
Trfc_SM [333]
Trfc2_SM [Auto]
Trfc4_SM [Auto]
Tcwl_SM [14]
Trtp_SM [8]
Trdwr_SM [6]
Twrrd_SM [3]
TwrwrSc_SM [1]
TwrwrSd_SM [7]
TwrwrDd_SM [7]
TrdrdSc_SM [1]
TrdrdSd_SM [5]
TrdrdDd_SM [5]
Tcke_SM [6]
ProcODT_SM [60 ohm]
Cmd2T [1T]
Gear Down Mode [Disabled]

AMD CBS > UMC Common Options > DDR Memory Mapping > BankGroupSwap [Disabled] (Note: As kit was 1 DPC SR)


His timings give a very nice boost smile.gif .

Past tweaking results

Some members have reported issues with them, so all RAM/CPUs may not accommodate them. For me his timings at 3333MHz eclipse 3466MHz C16 2T which is best I can attain with my CPU for that RAM MHz by keeping to SOC: 1.1V DDR: 1.375V.

More timings have also been shared for 3200MHz and 3333MHz in this post.

Hynix AFR / MFR 1 DPC SR timings in this post.

Above was post-flame-small.gif The Stilt's post-flame-small.gif 3333MHz Fast setup, my F4-3200C14D-16GTZ did need 1.375V set in UEFI, so some may find 1.35V isn't enough.

Also see spoiler labeled BankGroupSwap and BankGroupSwapAlt, as BGSA Enabled with timings above is an option to use.

Is RAM MHz king?
Warning: Spoiler! (Click to show)
Originally Posted by The Stilt View Post

Half of the 3DMark Sky Diver Combined Test score comes from the physics score. The physics engine used in 3DMark is Bullet, which is extremely sensitive to latency.

3200MHz 14-14-14-75-350ns-BGSE = 116.85fps
3200MHz 14-14-14-75-350ns-BGSD = 119.51fps
3520MHz 14-14-14-56-177ns-BGSD = 125.07fps
3200MHz 12-12-12-54-140ns-BGSD = 127.07fps

These are with R7 clocked at 3.575GHz.

Those are five run averages, since the score varies slightly between the runs.
3DMark SD CT isn't the best benchmark to evaluate the real world memory performance, however it is quite decent and can be run very quickly.
Originally Posted by The Stilt View Post

Higher DFICLK itself doesn't improve the performance. Increasing the DFICLK (by increasing the MEMCLK) only helps if the DFI is the bottle neck.

1600MHz DFICLK (i.e. 3200MHz MEMCLK) is sufficient for > R7 1800X and the returns from higher speeds are diminishing. At higher CPU speeds (which are unachievable on current gen. Ryzen CPUs) the required DFICLK for optimal performance will increase as well.
Hitman DX12 FPS scaling (Click to show)

Latency is king >= 3200MHz.

Timings used for 3200LL & 3466LL in above chart are below, 3200LL needed ~≥1.45V, RAM kit used by The Stilt F4-3600C15D-16GTZ.
Originally Posted by The Stilt View Post

3200MHz = 12-12-12-28-54-140ns-9-8-12-2-2-GDME-1T (tCL-tRCDR/W-tRP-tRAS-tRC-tRFC-tCWL-tRTP-tWR-tWRWRSCL-tRDRDSCL)
3466MHz = 14-14-14-28-54-192ns-14-8-12-2-2-GDMD-1T (tCL-tRCDR/W-tRP-tRAS-tRC-tRFC-tCWL-tRTP-tWR-tWRWRSCL-tRDRDSCL)

140ns @ 3200MHz = 224 CLK
192ns @ 3466MHz = 333 CLK
Originally Posted by The Stilt View Post

Sure, on 1401 I can stabilize them at 3600MHz but the performance is worse than at < 3066MHz.

The new PMU used in 1401 bios is no longer able to handle tight tRDRDSC, tRDRDSCL / tWRWRSCL or 1T command mode with GearDownMode disabled at high speeds (>= 3466MHz). With older PMUs it handled them just fine, however I wasn't able to stabilize 3600MHz in dual channel due to signaling issues (CAD options weren't available).

For example at 3466MHz setting just tRDRDSC from 1 to 5 CLKs will result in lower performance in HITMAN than 2933MHz with tRDRDSC at 1 CLK.

This is by no means ASUS's fault, it's just the characteristics of the new PMU firmware.

Precision Boost and XFR info
Warning: Spoiler! (Click to show)
R7 1700

In a heavily-multithreaded “all cores boost” scenario, this user-focused performance tuning permits the 1700 to ramp peak power draw up to its fused package power limit of approximately 90W electrical (note: AM4 reference power limit is 128W). Precision Boost and/or XFR will level off at 72.3tCase°C or ~90W of electrical power (whichever comes first).

R7 1700X/1800X

In a heavily-multithreaded “all cores boost” scenario, this user-focused performance tuning permits the 1700X/1800X to ramp peak power draw up to the AMD Socket AM4 reference limit of 128W. Precision Boost and/or XFR will level off at 60tCase°C or 128W of electrical power (whichever comes first).

Notes: above is for "out of box" setup, when we up multipler of CPU past x point CPU goes into OC mode, so "headroom" limitations are removed.

Regarding tCase°C :-
tCaseMax is the actual maximum package temperature, measured from surface center of the IHS. This figure is significantly lower (IIRC 71-56°C), as it is an external temperature (a major delta is to be expect).

Quote extract link.

For the 1700 SKU the clock configuration is following:

- 3.0GHz all core frequency (MACF)
- 3.2GHz maximum all core XFR ceiling (ACXFRC)
- 3.7GHz single core frequency (MSCF)
- 3.75GHz maximum single core XFR ceiling (SCXFRC)

For the 1700X SKU the clock configuration is following:

- 3.4GHz all core frequency (MACF)
- 3.5GHz maximum all core XFR ceiling (ACXFRC)
- 3.8GHz single core frequency (MSCF)
- 3.9GHz maximum single core XFR ceiling (SCXFRC).

For the 1800X SKU the clock configuration is following:

- 3.6GHz all core frequency (MACF)
- 3.7GHz maximum all core XFR ceiling (ACXFRC)
- 4.0GHz single core frequency (MSCF)
- 4.1GHz maximum single core XFR ceiling (SCXFRC)

In above slide PState 0 is 3600MHz on the 1800X, that is the base frequency of Precision Boost; then we have the other boost frequencies dependent on other factors of headroom/XFR.

XFR is on non X CPU but half that of a X CPU.

The base-clock (BCLK)
Warning: Spoiler! (Click to show)
General info (Click to show)
Firstly this is covered in The Stilt's OP of Anandtech thread. Next is info on say Crosshair VI Hero where it does this:-

For example an M.2 drive running at Gen 2 x4 with 140 RECLK will give you 2800MB/s of bandwidth.

Quote extract from link.

Other info:-
SATA is not affected, at least the ones which are located in Promontory (external FCH). I'm not certain if Taishan's (internal FCH) SATAs are affected by the BCLK, but there is a chance they are.

Quote extract from, but do also take Elmor's findings into account, so YMMV depending on setup, etc.

Now let's say we keep stock multipler and adjust BCLK, will PB/XFR function? link. I would also think as CPU has not entered "OC mode" due to keeping stock multipler the limitations for "headroom" will apply as per info in section "Precision Boost and XFR info".

Currently the only motherboards with BCLK adjustment are:-

Asrock X370 Taichi
Asrock Fatal1ty X370 Professional Gaming
Asus Crosshair VI Hero
Gigabyte GA-AX370-Gaming K7
Readings of BCLK in monitoring SW (Click to show)
Originally Posted by elmor View Post

There is no such fluctuation, it's 100% a readout problem. Reference clock is not directly measured, but calculated using a suitable counter and prone to errors. The only platform which has hardware counters for reference clock is Skylake/Kaby Lake. Do you have any details on accuracy @Mumak?
Originally Posted by Mumak View Post

That's right - only very few CPUs allow true hardware measuring of BCLK (i.e. Skylake). For the rest we need to perform certain (often indirect) measurements to determine the BCLK and this can of course show slight fluctuations, especially under heavy system load.
HWiNFO has an option to disable BCLK "Periodic polling", so it will sample BCLK only once and don't perform periodic measurements and thus show fluctuations. I'm sorry, but there's no other way around this, as long as manufacturers don't offer a true measuring like in Skylake.

Warning: Spoiler! (Click to show)
Below is Official info from AMD on 1700/1700X/1800X is:-
AMD Ryzen processors do not use pre-programmed VID tables.
1. Therefore, there is no fixed Vcore when the CPU runs in its out-of-box condition.
2. Default Vcore will vary depending on workload and will range from 1.2-1.3625V.
3. Overclocking an AMD Ryzen processor will snap the voltage to 1.3625V, but this value can be changed.

As a general guideline: a CPU voltage of 1.35V is acceptable for driving everyday overclocks of the AMD Ryzen processor. Core voltages up to 1.45V are also sustainable, but our models suggest that processor longevity may be affected. Regardless of your voltage, make sure you’re using capable cooling to keep temperatures as low as possible.

While there are never guarantees with overclocking, the majority of users should find that an 8C16T AMD Ryzen processor will achieve 4.2 GHz @ 1.45V of CPU voltage. Advanced and accomplished overclockers trying to push record frequencies may find more headroom by disabling cores and disabling SMT on motherboards that offer the option in the BIOS.

Just to prove above is official info, please use the link in this post, see page 34.

Next info from The Stilt, link.

Due to how Ryzen is, owners will see variable voltage and high peaks when PB/XFR occurs.

It is confirmed now that using AMD CBS section places CPU in "OC mode" like by just a multiplier change say in another part of mobo UEFI, the post by The Stilt.

C6H ProbeIt VCORE point vs measuring at socket
Warning: Spoiler! (Click to show)

The ProbeIt read points are on page 32 of user manual, when I have an image of measuring points for socket, it will be placed here.
Originally Posted by elmor View Post

Using DMM to measure voltage will be accurate only in idle. During load you will read higher than what the CPU is actually getting because of power plane droop being accounted for when the VRM outputs voltage.

The VRM uses on-die sense outputs to read accurate voltage at the "destination". It will thus output a higher voltage during load because there will be significant voltage drop across the CPU and ground power plane. To get a more accurate reading you need to measure at the MLCCs at the back of the CPU socket, and be sure to also get your ground point from there.
Warning: Spoiler! (Click to show)
Originally Posted by ProTekkFZS View Post

Never mind, I learned how to Google biggrin.gif

Measured under load with LLC 3:

Probelt VCore: 1.469

Measured per Elmor's recommendation: 1.450

Quite a bit of droop, definitely reads better to me there
Originally Posted by ProTekkFZS View Post

Voltage information overload inbound:

Picture of back of motherboard shamelessly ripped from TweakTown: http://www.tweaktown.com/reviews/8097/asus-rog-crosshair-vi-hero-amd-x370-motherboard-review/index2.html

With that out of the way, on to the data:

All values measured by DMM under full load.

In the picture attached:
Green = VSOC

BIOS Settings -
VCORE 1.425, LLC 4
VSOC 1.1, No LLC

Starting with the VCORE measurements at the VRM caps: Top right to bottom right


VSOC measurements at the VRM caps: Left to right


VCORE measurements at the socket:
1.425V swinging to 1.426V

VSOC at socket:

Now, onto the voltages everyone has been brownpantsing themselves about, ProbeIt:

VCORE: 1.522V
SOC: 1.114V
DRAM: 1.375V
VDDP: 0.903V
1.8 PLL: 1.903V
SB: 1.074V
C6H PCB back (Click to show)
Originally Posted by ProTekkFZS View Post

Moar info, I individually probed all MLCC's:

Green: VSOC
Blue: IMC/DRAM? Read 1.35V
Yellow: PLL? Read 1.8xxV
Purple: VDDP? Read 0.892V
Light Blue: Couldn't definitively figure out

Any that I didn't cover in this picture, I didn't have the balls to try to get my probes in there to get a measurement.

Originally Posted by ProTekkFZS View Post

"CPU Core Voltage (SVI2 TFN)" could possibly be the "real" voltage because that's using telemetry from the actual CPU which could possibly account for further losses inside the socket and CPU itself. I can't confirm this nor suggest you or anyone use that value as gospel. I'm merely an enthusiast with a cheapo multimeter, not an engineer smile.gif

LLC settings on C6H
Warning: Spoiler! (Click to show)
To read further context to quotes shared within spoilers below, click the green arrow right within quote.

The Stilt's share (Click to show)
Originally Posted by The Stilt View Post

Just keep the voltages at sane levels (< 1.45V for VDDCR_CPU, < 1.10V for VDDCR_SoC) and don't tamper with the load-line settings, unless you actually MEASURE significant amounts of droop, under load (which is not likely on C6H). Voltage overshoot hurts just as bad as undershoot, when it comes to stability. If you need to increase the load-line setting (i.e. introduce overshoot) to maintain stability, then your voltages are not set correctly to begin with.

The load-line options in bios translate to:

Auto = ±0% (1.425mOhm)
Level 1 = -40% (0.855mOhm)
Level 2 = -50% (0.7125mOhm)
Level 3 = -75% (0.35625mOhm)
Level 4 = -85% (0.21375mOhm)
Level 5 = -100% (0.0000mOhm)

I personally recommend to keep the load-line settings at "Auto" at all times, unless you are doing LN2 runs.

The main difference between the different Ryzen 7-series SKUs (aside of the clocks) is the leakage. The 1700 SKUs have low leakage characteristics, while both 1700X & 1800X are high(er) leaking silicon. Because of that 1700 requires even less load-line biasing than the other two (due the currents being lower).
Originally Posted by The Stilt View Post

Because these chips have already been pushed so far at stock, that we're already hitting the voltage limits (rather than the usual thermal or clock limits). Silicon with higher SIDD generally requires less voltage at ISO frequency and has at least somewhat better voltage scaling. They draw more current and run hotter than the silicon with lower leakage, but in case the silicon isn't thermally limited that's not a disadvantage but an advantage.

There is a reason why they are binned this way at the factory as well wink.gif Same was done with Vishera 9k-series CPUs. Using high leakage silicon is most likely the only way to produce 1800X models with their 4.1GHz MSCXFC, without breaching the reliability thresholds for VDDCR_CPU.
Originally Posted by The Stilt View Post

The significantly tighter droop specification applies only in cases where the dLDO is used. dLDOs are not used for B1 stepping consumer parts, so the load-line specification does not apply. Infact the AM4 load-line specification is looser than it was for AM3+ for example (1.425mOhm vs. 1.3mOhm).

Only other thing to add to above is the dLDOs are used by minor domains of Ryzen, this is stated by The Stilt in his Ryzen: Strictly technical thread on Anandtech.
Despite the presence of the dLDOs, the consumers can ignore them completely. This is because in the consumer parts most of the dLDOs (all except some of the minor domains) are permanently placed in a by-pass mode. This means that actual regulators are disabled and all of the voltage regulation takes place on the motherboard, just like on the previous generation CPUs and APUs.

Other posts to ref of The Stilt, link to post showing how to calculate VDROOP, link to how to calculate overshoot from LLC change, LL tool, ITE granularity, leakage aspect touched on in this post.

[email protected]'s share (Click to show)
Originally Posted by [email protected] View Post

Just something a bit more objective to help scotch some of the eternal LLC debates. LLC 1 works quite well for everyday use. Just a stock capture here. That said, the CPUs don't pull much current at all, so I don't expect big changes. Small FFT Prime load hitting the VRM.

Blue trace = Vcore
Yellow trace = current (peak is around 130W)

1.40 VID set in UEFI gives around 1.38V "idle", dipping no more than 20mv when hit with load.
Originally Posted by [email protected] View Post

There's no need to go through all of them. Not from my perspective, anyway.

If you're wondering what happens at level 5, here's a very crude (non-ideal) capture:

With an LLC of 5, if VID is set to 1.40V in UEFI (manual), you'll see load voltages in the ballpark of 1.45V. When releasing the load, the voltage will momentarily peak around 1.47V, before it returns to idle state. The overshoot duration is sub 50uS, but the CPU frequently sees 50~70mv more than what you've set. With "Voffset removed" the VRM has to substantially ramp the voltage when the load hits (will vary somewhat depending upon current), which puts more strain on the FETs. It's just more strenuous on the system to have to ramp voltage by ~50mv while dealing with a transient. How that may impact things down the road is always up in the air. You're playing with percentages/potential for failure, and what that means to you. Whether or not it will happen is difficult to quantify.

If you have sympathy for electronics, you'd likely opt for LLC 1 or 2. At those levels, peak overshoot is constrained 10-20mV over the user-applied VID at durations that likely fall within the tolerance guidelines. Those levels are complimentary to the associated devices. From levels 3 and above, the actual voltage is ramped above the user-defined value, and we start seeing excursions of 30mV+ past the user-set value.
Originally Posted by [email protected] View Post

This is where elementary understanding of LLC helps. You just need to set the correct VID to get the required load voltage. Nothing else to it, really.

Which PState to edit?
Warning: Spoiler! (Click to show)
See this post and this earlier one in thread is also good to note.

PState 0 in AMD CBS from what I have experienced and others, the VID must remain default. On a R7 1700 this is 1.1875V (VID: 3A), for 1700X/1800X it's 1.35V (VID: 20). So to gain voltage you require for an OC manual or offset mode CPU voltage is needed.

On a R7 1700 what I noted. Stock CPU, idle ~1.4GHz, PState 2 is default 1550MHz

Next I change only PState 0 to attain a higher ACB clock and do not modify PState 2 (default 1550MHz), the higher I go for MHz in PState 0 the closer idle clock gets to PState 2 (MHz value).

So lets' say I go for PState 0 as 3.7GHz I'll be idling at ~1.5GHz , next I set PState 0 as 3.8GHz I'll be idling at ~1.55GHz, so basically the value in PState 2 is acting as "ceiling" clock for that state and based on how far you OC PState 0 you attain a higher PState 2 clock.

If you lower Pstate 2 you get lower idle, I was able to go all the way down to 1125MHz, 1100MHz I'd get random freezes in OS, I had not edited VID in PState 2 for this set of test.

Next I edit VID in PState 2, I could use 575mV compared with default 875mV, this approximately changed the idle voltage "range" by ~100mV on DMM readings for VCORE. This meant my idle VCORE range was very close to stock CPU idle VCORE.

Temp info
Warning: Spoiler! (Click to show)
HWiNFO shows tCTL, this matches AMD Master OC SW, similar to CPU Package MAX temp on Intel. The information on tCTL is contained in this post by The Stilt (Zeppelin=Ryzen).
tCTL should no longer be on linearized scale on Zeppelin. AFAIK it is the ROS (alternating, highest sensor reading within the CCXs) in °C scale, similar to AMD K10 cores or GPUs.
In my experience the temperatures reported are quite realistic.

I'm not fully certain about the retail parts, however the tCTLMax should be 95°C on all SKUs. Zeppelin supports cHTC so the ODMs might be configuring the limit to a lower figure if they want, however the default is 95°C.

tCaseMax is the actual maximum package temperature, measured from surface center of the IHS.
This figure is significantly lower (IIRC 71-56°C), as it is an external temperature (a major delta is to be expect).

Here is also a post by Elmor (do read his job title in his CH6 OC thread wink.gif ). Below image is from his PDF.

Then there is this info from AMD, link :-

Now it is still unclear what is going on with temps, from seeing some of owners posts in the Ryzen club, some members find the need to adjust say tCTL offset in HWiNFO to make it match with AMD Master, others don't. HWiNFO by default has no offset present to tCTL, so this variation must be concluded as down to how mobo UEFI is setup, but I can not say for sure.

Sense MI Skew on C6H - To disable or not?
Warning: Spoiler! (Click to show)
Originally Posted by gupsterg View Post

Does PLL have abnormal affect on temperature sensors?

tl;dr No, not with my HW and OC profile.

Who am I?

I am a PC enthusiast with no PC HW/SW qualification and no association with a company in this context.

Test case

CPU: R7 1700 UA 1709PGT
RAM: F4-3200C14D-16GTZ
MOBO: C6H rev.1.03
HSF: ThermalRight Archon IB-E X2 with 2x TY143

Case has side panel on for testing, as that is how normally rig is used. Room ambient ~25°C, internal setup as shown below.

UEFI settings were my usual 3.8/3333 Fast setup.

UA1709PGT_3.8_3333_Fast.zip 7k .zip file

Only PLL was changed from 1.8V to 1.75V and then 1.85V.

Test data

RAW data zip with screenies / HWINFO CSV log

1.8V PLL

1.75V PLL

1.85V PLL


i) Where do I get the stress test? it is linked in OP of my thread in my signature.

ii) Was Sense MI Skew disabled? yes, as I have always done that on all UEFIs as gave me "realistic" temps as I have a R7 1700 with no temp offset.

iii) Do you think the temperature data is correct? IMO yes from past experience with HW/SW.

iv) What was polling rate in HWiNFO? 1000ms.

v) Why is your BCLK 100MHz? I have it manually set as that in UEFI and HWINFO is set to only take a one time reading at launch, so there will be no fluctuation for BCLK.

vi) Why is 1.8V PLL test screenie showing a lower min CPU socket temp compared with others? the rig had been powered off for some time prior to testing. I had powered it on and let it idle before testing. I can only assume the variation between that test and later ones is down to case ambient / socket changed slightly via from usage. Between each test the rig was allowed to idle so temperatures at start of 1.75V & 1.85V testing should be relatively "idle" situation.

vii) Why test this? there has been much discussion on PLL changes affecting temperature readings. As I had relied on others data in past I thought it was time to test for myself and have another facet testing to compare with a R7 1800X which I will have later this week.

viii) Will you be doing testing on R7 1800X? yes.

ix) Do I adjust PLL? nope not needed to so far.

x) Why adjust it? some have gained stability with it, so I would say a owner needs to decide what they do.

xi) What is a safe voltage to use? really no idea, Elmor has touched on it's case usage in the OC PDF in OP, there is a table within his PDF with guidance.
Originally Posted by majestynl View Post

@Ramad @bluej511 @gupsterg

What a coincidence Gup biggrin.gif, was doing same test on my 1800x. I DO see big difference on Temp readings. No effect on ram voltage readings so far. Did a bench with Cinebench. All same scores.

PLL = Auto 37,9c - 70c
Warning: Spoiler! (Click to show)

PLL = 1.8v 37,8 - 70,3c
Warning: Spoiler! (Click to show)

PLL = 1.86v 44,8 - 78c
Warning: Spoiler! (Click to show)

PLL = 1.74v 22,6 - 48,6c
Warning: Spoiler! (Click to show)

Testrig: Ryzen 1800x (see signature)
Max Temp reach: Cinebench
Using PLL: allways set on 1.8v since begin
Bios: 1403
Sense MI Skew: Auto
Ram: 3466 (fast timings by myself)
Originally Posted by gupsterg View Post


+rep thumb.gif .

tCTL is getting skewed in your testing, as it did before in several other X CPU owners when this discussion happened before.

As tDIE is just tCTL with -20°C and not a real sensor it is also getting skewed.

As CPU sensor under heading Asus Crosshair VI Hero is Super IO chip (ITE IT8655E) reading tCTL from CPU it is also skewed.

But what your testing shows is what I hypothesized before biggrin.gif . CPU socket sensor has no skewing smile.gif .

Note through out your testing it is similar.

AUTO: current 31, min 27, max 37, aver. 30, counter on HWINFO 1min 55sec

1.8V: current 34, min 27, max 37, aver. 29, counter on HWINFO 1min 59sec

1.86V: current 33, min 27, max 37, aver. 28, counter on HWINFO 3min 34sec

1.74V: current 35, min 29, max 38, aver. 32, counter on HWINFO 1min 00sec

So the reality is as Ramad posted to Hotstock, the CPU sensors have reading skewed in SW, but actual temperature has not changed with change of PLL. This was also the conclusion in the past reached.

Try Sense MI Skew: Disabled when you have time.
Originally Posted by bluej511 View Post

Pretty sure socket temp is no where near as reliable as tctl, at least in my case. It either reads too high as a min or too low as a high. At idle it reads too high, at low it reads too low lol.
Originally Posted by gupsterg View Post

For this test case it is useful.

For me it can be too high at idle vs tCTL, rationale?

a) heat getting trapped in socket, no airflow, etc.

b) no cooling solution on that side of CPU so theoretically hotter.

Then what about the difference at load between socket and tCTL? well the rationale would be same as TcaseMAX, see section Precision Boost/XFR info in OP of my thread.

So to me the behavior of CPU socket sensor makes perfect sense.
Originally Posted by majestynl View Post

Quick test again before i go to eat biggrin.gif

Same test as: My post before, but now with Sense MI Skew: Disabled:

PLL = Auto 46,6c - 81,3c
Warning: Spoiler! (Click to show)

PLL = 1.8v 46,5 - 80,5c
Warning: Spoiler! (Click to show)

PLL = 1.86v 46,5 - 80,8c
Warning: Spoiler! (Click to show)

PLL = 1.74v 46,5 - 81,5c
Warning: Spoiler! (Click to show)

I'm going to eat! very hungry here, will investigate later! be right back thumb.gif
Originally Posted by gupsterg View Post

From this testing I conclude again on X CPU members should use Sense MI Skew: Disabled on UEFI 1401 / 1403 as stated before smile.gif .

+rep for testing thumb.gif .

Temperature skewing from PLL change is not occurring.

CPU socket sensor again is not skewing as in previous testing by yourself.

tCTL has the 20°C as AMD state X CPU has.

tDIE is correct as it has the offset removed.

CPU sensor under Asus Crosshair VI Hero is correct as it has 20°C removed. As this temperature is used for cooling profile, when setting fan profile in UEFI it will be relevant.

Min/max tCTL all cases ~46°C / ~80-81°C.

Min/max tDIE and CPU sensor all cases ~26°C / 60-61°C. If we use motherboard sensor of ~26°C logically these values are correct, a reflection of ambient temp, IMO down to how majestnl cooling/case setup is.

In the 1.86V PLL screenie you have WHEA error chap, "CPU Cache L0 Errors" redface.gif .

Uncore/Cache Info
Warning: Spoiler! (Click to show)
The Stilt's post.
In your example (CPU-Z), the CPU + L1/L2/L3 operated at ~4055MHz, while the actual data fabric operated at 1800MHz.

L1/L2/L3 = CPU frequency.
Data fabric, memory controller = MEMCLK (effective) / 2.

Then this.
There is no "uncore" in Ryzen. CCX essentially operates at it's own (core speed) and the fabrics and the memory controller at half the effective MEMCLK speed.
Uncore is just the term used by CPU-Z for data fabric (DFICLK).

Stability testing
Warning: Spoiler! (Click to show)

Y-Cruncher, this for me runs ~5 warmer than x264, this also is more stressful than RealBench IMO. I do Y-Cruncer 1st, without FFT as temps don't increase much for that so I reckon no use on Ryzen. 2nd x264, 3rd RealBench Stress mode and then [email protected] is also a productive stress test IMO.

x264 on my sample of Ryzen needs more VCORE to be stable than RealBench Stress mode. OC also falls over quicker than RealBench. For example RB ST 2hrs pass on 3.7GHz @ 1.1875V but x264 it didn't even pass 1 loop, needed 1.206V. x264/x265 download in this post by JackCY.

RealBench, stated by 8 Pack, used by Silicon Lottery for binning. This page right at the top is latest version, v2.54.

Prime 95 with Ryzen support - BETA

IBT AVX found in OP of Vishera Owners thread.

Windows 7 on Ryzen
Warning: Spoiler! (Click to show)

Ryzen_USB_W7_x64.zip 879k .zip file

1. USB driver link/DISM guide by The Stilt.

2. Guide on using NTLite to integrate drivers at Fernando's Win-RAID Forum.

3. Video of me using NTLite to integrate USB driver to Win 7 Pro x64.

Anyone installing Win 7 this is how it went on my C6H:-

i) Win 7 Pro x64 ISO, this did not have "to date" updates integrated but only the USB drivers.
ii) After OS install, I installed the AM4 chipset drivers from AMD site.
iii) WiFi card's driver, GC-WB867D-I, I use Intel driver from Intel site and not Gigabyte.
vi) Crimson driver for Fury X, then ICC profile for monitor.

And no "unknown" devices in device manager biggrin.gif .

I have onboard LAN disabled as don't use it, that does require driver. Onboard sound was picked up, but that will be disabled later as use the GPU's audio output over DP to monitor, then plug my headphones in to it.

So far very smooth install of OS and a few less drivers than my i5/Z97 setup smile.gif . Like how the AMD AM4 driver had SMBus, etc as "all in one" package smile.gif . Keeping "bloatware" at bay so far wink.gif .

Power Plan editing in Windows
Warning: Spoiler! (Click to show)
The registry edit in this post by JackCY has info on enabling editable core parking in Win 10. This thread has information on doing the same on Win 7.

I have been using Win 7 Pro with High Performance Power Plan setup with disabled core parking and below CPU settings:-

Above setup with an OC via AMD CBS (PState 0) is down volting / clocking for me.

How to Add "Choose Power Plan" to Desktop Context Menu in Windows 7 and Windows 8.

Windows 10: 'Choose Power Plan' context menu - Add in Windows 10

My results on Windows 7 Power Plan tweaking

For me High Performance power plan with Core Parking off (ie 100%) on Win 7 Pro x64 gives best performance on 3DM FS, here are 3 runs of each.

Balanced Core Parking default 10% (ie enabled).


Balanced Core Parking 50% (ie disabledish)


High Performance Core Parking 100% (ie disabled)



Using Flashback on C6H (Click to show)
My procedure.

i) UEFI filename as C6H.CAP, copy to USB stick.
ii) Load UEFI defaults prior to doing flashback and let mobo repost and shutdown.
iii) Make sure USB stick is in Flashback port (marked in red box below image)

iv) Press and hold the Flashback button (blue box, above image) ~5secs. Blue LED on the button will flash slow for a few seconds and quicken as it starts update process. At the end of process it will extinguish, you are ready to boot up. If the blue LED stays constant the UEFI file was not found on USB stick, so check USB stick is correct format and filename is correct.


Setting up PState 0 OC on C6H (Click to show)
When using UEFI PState 0 OC with offset mode voltage for VCORE, disable Core Performance Boost on Extreme Tweaker page, there is no need to set the one in AMD CBS menu as that will reset on a memory training fail boot (Q-Code: F9), resulting in possible over volting of CPU, see info at top of OP.


i) Use Global C-States Control: [Enabled] located in Advanced page > AMD CBS > Zen Common Options.

ii) CPU Core Ratio all sections on Extreme Tweaker page keep as [Auto]

Saving C6H UEFI settings as txt file (Click to show)
1. ASUS Overclocking Profile (Click to show)
2. Load/Save Profile from/to USB Drive (Click to show)
3. Ctrl F2 save the current BIOS setting (Click to show)
4. Enter filename for settings save (Click to show)
5. Confirmation of save (Click to show)

When I did testing for saving UEFI settings:-

- Did not matter which USB port I used, I just picked random one on rear IO, USB stick FAT32 (same stick I use for USB Flashback).
- After you press CTRL + F2 the entry box for filename is already highlighted, denoted by turquoise / light blue green highlight around it.
- Pressing tab / arrow keys / using mouse, entry box can be selected if it is not.
- Whatever filename you enter it will have _setting.txt added to it on save.
- txt will be saved in root of USB stick.

Note: AMD CBS sections are not recorded in settings save txt, I use F12 to grab UEFI screenshots.

save_setting.txt 17k .txt file

C6H CPU Socket temperature sensor location (Click to show)

C6H Motherboard temperature sensor location (Click to show)

Super IO Chip (ITE IT8665E) voltage read back granularity on C6H (Click to show)
Originally Posted by The Stilt View Post

When looking at the software reported voltage figures sourced from the ITE8665 LPC/IO, keep in mind that the granularity (ADC LSB) isn't very good either. ITE8665E supports 10.9mV granularity (i.e. minimum change, LSB) however because ASUS uses 1:2 voltage divider for VIN1 input (VDDCR_CPU) the actual granularity is twice of the nominal (21.8mV).

Installing Ryzen Power Plan manually (Click to show)

1. Unpack Ryzen_Balanced_Plan.ppkg with 7zip and open an admin command prompt then change the filepath. Actual .pow file is located in Ryzen_Balanced_Plan\DataAsset\2Ryzen_Balanced.pow_2a73e\Ryzen_Balanced.pow

2. In the command prompt type "powercfg /import ""

Disabling HPET on C6H (Click to show)
So far none of the UEFIs have had an option, so use bcdedit in OS from command prompt/powershell.

bcdedit /set useplatformclock false to disable
bcdedit /set useplatformclock true to enable

Do I need to use both EPS12V 8 pin and ATX12V 4 pin connectors for power on C6H? link.

Will XMP work on AM4 board? X370 ASRock Gaming K4 Fatal1ty Review - Good Price Performer?, has option not functioning currently, perhaps in a later release. On Asus mobo D.O.C.P, that video is from 2012 . Gigabyte X370 Gaming 5 has XMP option. Don't know how many/which AMD AM4 mobos have XMP translation feature though.

Will mobo's without BCLK clock gen chip support adjustment? link and also link.

What about Ryzen's gaming performance issue? link to post.

Does HWiNFO report CPU power correctly? to be verified by The Stilt, do read this linked post.

Which cores are SMT (HT) in windows? odd, link to post.

For VDDP, this, this, this

FCLK, UCLK, link to post, another post on UCLK.

Does AMD Master OC SW work with all mobos? will not work on mobos with chipset that lack OC support, see table in this THG article.

Gaining RAM IC information, view video.

If having issues with AIDA64 memory bench set tRDRD_Sc = 1

My Benches Collection

3DM13 (Click to show)
3x 3DM FS 3200MHz from several days ago. 3x 3DM FS 2133MHz run today. i5 4690K from 250+ Fury X 3DM benches thread, will get R7/X370 on Win 10 soon and use same driver as that thread wink.gif .

Rerun of 3x 3DM FS 3200MHz . Saves files for 3200MHz below.

3DM_FS_3200MHz.zip 347k .zip file

All I do is change RAM strap in UEFI, RAM timings are manually set so the same used (14-14-14-14-34-1T), Asus MG279Q has FreeSync disabled in OSD, using 144Hz.

3x 3DM FS 2133MHz rerun, save files below.

3DM_FS_2133MHz.zip 353k .zip file

So out of 6 results of 2133MHz, total score for run worst vs best.

So out of 6 results of 3200MHz, total score for run worst vs best.

Then worst 2133MHz vs worst 3200MHz. Then best 2133MHz vs best 3200MHz.

CB15 Performance bias enabled in UEFI.

3200MHz without CB15 PB 6x runs from above. 3200MHz with CB15 PB 6x runs. So worst of each compared, best of each compared.

Save files.

3DM_FS_3200MHz_CB15PB.zip 715k .zip file

3DM13 - TimeSpy (Click to show)

3.8GHz 3200MHz C14 1T, seems more consistent results than 3DM13, but am using v17.4.3 WHQL drivers vs v16.12.2 WHQL, may repeat testing with older driver and other RAM clocks.

R7/X370 vs i5/Z97, similar ~3% difference on R7 vs i5 as 3DM13 FSE results for Graphics test elements.

CINEBENCH R15.038_RC184115 (Click to show)
3.8GHz W7 (Click to show)
Win 7 Pro x64, all updates to date, ISO/install as in section Windows 7 on Ryzen, Power Plan as highlighted in OP relevant section. UEFI is set pretty much manually, so when I was lowering straps only what I can't control has changed.

3200MHz C14 with CB15 Performance Bias enabled in C6H UEFI

3200MHz C14

2933MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2933MHz C14

2666MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2666MHz C14

2400MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2400MHz C14

2133MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2133MHz C14

3.9GHz W10C (Click to show)
Win 10 Pro x64 Creators Edition, clean ISO install, all updates to date. UEFI is set pretty much manually, so when I was lowering straps only what I can't control has changed. Power Plan is default Balanced with Core Parking 50%, this has been used as it seemed most "Optimal" for 3DM FS/TS. Then also the 3.8GHz OC I run for 24/7 use, when compared with W7 High Performance Core Parking 100& (ie disabled) vs W10C for CB R15 was ~3 points within each other. The 1703 result for CB15 in screenies is a saved result on W7 with no PB in UEFI with 3200MHz C14 1T.

3200MHz C14 with CB15 Performance Bias enabled in C6H UEFI

3200MHz C14

2933MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2933MHz C14

2666MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2666MHz C14

2400MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2400MHz C14

2133MHz C14 with CB15 Performance Bias enabled in C6H UEFI

2133MHz C14

SuperPosition (Click to show)
More RAM clocks to added soon, so check back.

3.8GHz 3200MHz (Click to show)
Stock Fury X, Power Efficiency: On

Fury X GPU: 1100MHz HBM: 545MHz, Power Efficiency: On

Fury X GPU: 1145MHz HBM: 545MHz, Power Efficiency: On

3.8GHz 2133MHz (Click to show)
Stock Fury X, Power Efficiency: On

Fury X GPU: 1100MHz HBM: 545MHz, Power Efficiency: On

Fury X GPU: 1145MHz HBM: 545MHz, Power Efficiency: On

Arne Saknussemm 03-08-2017 12:52 PM

Nice one gupsterg thumb.gif

You got this in there? http://support.amd.com/TechDocs/AMD%20Ryzen%20Processor%20and%20AMD%20Ryzen%20Master%20Overclocking%20Users%20Guide.pdf

gupsterg 03-08-2017 10:56 PM

OMG Arne! that mainstream system has got you on a mainstream forum! tongue.gifbiggrin.gif

Yep will add that to OP smile.gif , also got a few other tweaks to do to OP today wink.gif .

Sgt Bilko 03-09-2017 12:55 AM

Subba Dubbed Dub biggrin.gif

Also + Rep thumb.gif

Arne Saknussemm 03-09-2017 01:52 AM

Originally Posted by gupsterg View Post

OMG Arne! that mainstream system has got you on a mainstream forum! tongue.gifbiggrin.gif

Heh...actually I already got rid of that mainstream system...didn't quite cut it for me...thinking of trying Ryzen out...so appreciate the thread!

gupsterg 03-09-2017 05:18 AM

@Sgt Bilko @Arne Saknussemm

Nice to have you guys onboard thumb.gif .

@Arne Saknussemm

Storage capability is lacking on X370 vs say X99 from what I have seen others state. As X370 has enough for what I need I've not looked too much into it. Got some images which later I will place in OP.

Yeah OC headroom is sucking on Ryzen. Platform is immature and pretty much all are having "teething" issues. So it will be a rough ride for some time, but I do believe it will be OK as time goes on.

Seems like major "bang for $" though vs an Intel 8C setup TBH, that's what made me jump.

This was an interesting watch posted by a member in owners club. Hoping to ask someone who has more knowledge (aka The Stilt if the video is on the ball and will add to OP).

Ashura 03-09-2017 05:19 AM

Nice Thread gupsterg thumb.gif

Let me know if I can be of any help. smile.gif

gupsterg 03-09-2017 05:36 AM


Cheers mate smile.gif , more the merrier wink.gif .

Gonna add this link to OIP soon and perhaps guide of me updating a Win 7 ISO wink.gif .

*** edit ***

Created Win 7 x64 SP1 ISO with Ryzen USB/chipset drivers today, integrated using nLite v1.3 following Win RAID guide. Hopefully my CH6 be here tomorrow and once installed and verified can share my screenies of ISO creation.

Undervolter 03-09-2017 12:43 PM

This may interest you:

Mr Splash 03-09-2017 02:26 PM

Thanks for the info thread gupsterg, not an owner yet but will be. I'll appreciate all this when I do.. So thanks & Peace, Splash

All times are GMT -7. The time now is 12:06 PM.

Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.

User Alert System provided by Advanced User Tagging (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
vBulletin Security provided by vBSecurity (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.

vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.