Overclock.net - An Overclocking Community - Reply to Topic

Thread: ASUS ROG X570 Crosshair VIII Overclocking & Discussion Thread Reply to Thread
Title:
Message:

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


  Additional Options
Miscellaneous Options

  Topic Review (Newest First)
10-19-2019 03:06 PM
The Stilt
Quote: Originally Posted by pantsoftime View Post
Has anyone heard when we might see a C8F beta BIOS for 1.0.0.4? Shamino went dark over on the Asus forums and he was the one providing the beta 1.0.0.3ABBA BIOSes previously.
Here is a manually updated 1001 bios with AGESA 1.0.0.4RC stack.
Again, its not complete build since the new control is not available in the existing CBS.
The CBS itself can be updated, but that would result in issues with recovery and Hii database in general, and because of that it is not done.

I've used it couple weeks now without any issues, but then again at least in my case there is no difference in behavior compared to 1.0.0.3ABBA builds either.

Note that this is an unofficial, modified bios.
It can be updated with either Flashback or Flashrom (with header stripped).

Crosshair VIII Formula - 1001MFS
10-19-2019 12:50 PM
pantsoftime Has anyone heard when we might see a C8F beta BIOS for 1.0.0.4? Shamino went dark over on the Asus forums and he was the one providing the beta 1.0.0.3ABBA BIOSes previously.
10-19-2019 11:54 AM
The Stilt

Here is the upper part of the V/F on the best core (2) of the 3700X I used.

I recorded the peak voltage command driven by the CPU during single threaded test, run with manual affinity.
The command was read from the VRM controller (ASP1405I) side, so there is no question if the software reported values are correct or not.
No offsets (controller side) were used and the CPU operated at the stock parameters (88W PPT, 60A TDC, 90A EDC, 95°C TjMax, 100% PBO scalar).

While all of the cores within this CPUs are able to hit the advertised 4.400GHz frequency, none of them are able to sustain it.
The average frequency for the best core (2) is 4385.965MHz in the workload I used.

At stock, three of the cores (1, 5, 6) hit the Vmax limit (LUVL) of 1.50000V in an effort trying to hit the default boost frequency.
The best core (2) requires 1.48125V to do that, leaving just 18.75mV to be "spent" for Auto OC purposes, which considering the V/F curve you can now extrapolate won't be sufficient even for 4425MHz.
In fact, if you look at the 4350 - 4400MHz point, you can already see that the V/F doesn't look right since it deviates from the trend. Coincidentally, 4375MHz is the highest set frequency (due to 25MHz granularity) that the core can sustain.

When the Fmax is increased through the Auto OC offset (doesn't matter if its set to 25 or to 200MHz), the core will hit 4425MHz and 1.50000V VID request, which happens to be the Vmax (LUVL) limit as well.
Extrapolating based on the last two datapoints (4350 & 4400) the voltage required for 4425MHz would be 1.496875V, which due to the 6.25mV VID granularity is 1.50000V. And since the two last datapoints are lower than they should be (due to 4.4GHz not being sustained), and because the V/F keeps deteriorating even further with the increasing frequency, the actual requirement to sustain 4425MHz would be even higher than 1.50000V, hence out of reach.

Regarding the FIT:

Here's the behavior in Cinebench R20 NT, with 128W PPT, 100A TDC and 140A EDC limits:

100% = 5012 (score) - 1.381V Vmax (LUVL), 110.516W package power, limit reason: silicon fitness (reliability)
200% = 5034 (score) - 1.401V Vmax (LUVL), 115.825W package power, limit reason: silicon fitness (reliability)
300% = 5051 (score) - 1.413V Vmax (LUVL), 119.166W package power, limit reason: silicon fitness (reliability)

Despite I used custom tools for this, you can record the peak requested voltages with HWInfo as well, nothing wrong with that.
But if you want to see the accurate peaks the CPU is commanding, you need to use =< 250ms sample rate.
At the stock sample rate (2000ms) I saw up to 75mV lower peaks compared to the readings recorded from the VRM controller itself, at high speeds.

This is obviously just the behavior of a single CPU core of a single CPU specimen however, the theory applies to each and every Ryzen 3000-series CPU.
10-19-2019 08:47 AM
The Stilt
Quote: Originally Posted by rv8000 View Post
Makes sense, though it’s rather hard to see why certain bios settings don’t work in practice when there is no concrete way to see all limitations.

I ran several cinebench tests with 2x, 4x, 6x, 8x, and 10x, and all resulted in the same peak VID reading of 1.438, and same peak vcore of 1.425v read in hwinfo. (Peak clock of 4425)

So while I understand what you’re saying, either something is being misreported, I’m being limited by something I can’t tangibly record, or something isn’t working properly.
Did you test in multithreading workloads?
You should see significant increases from PBO scalar, when not limited by PPT/TDC/EDC.

Also, you are looking at HWInfo to determine the maximum voltage?
10-18-2019 08:57 PM
Bold Eagle subbed for the content.............
10-18-2019 08:50 PM
rv8000
Quote: Originally Posted by The Stilt View Post
Quote: Originally Posted by rv8000 View Post
Thanks for the explanations.

Concerning the Scalar, at least by ASUS's definition, the only description they really offer within the bios is that altering the scalar level only allows the vcore/VID to sustain longer durations at it's defined level. They don't really mention anything about frequency, though in turn higher/longer sustained voltage does result in longer periods at a higher frequency. Would one have to increase the VID from auto to +10mV, in theory, to start to see higher frequency jumps even though the Auto OC is set to +200mhz? For instance: if I increased the VID value in the bios/PBO would I see larger than a 25mhz increase when to the best of my knowledge I'm not hitting any of the PBO limits?
Increasing the scalar only helps, if FIT causes a voltage limit that is below the "global Vmax" (LUVL), which is 1.5000V (unless manually set to a lower value, through the control introduced in AGESA 1.0.0.4).

This is rarely the case in ST workloads, but very common in MT scenarios, especially on 3700X and 3800X SKUs. That being said, I've seen it happening in ST scenarios as well.
For example, if you increase the PPT to say 128W, TDC to 100A and EDC to 140A you should see somewhat higher clocks and significantly higher voltages during e.g. Cinebench R20 MT test when you raise PBO scalar from 1x to e.g. 3x.
Thats because in MT scenario the voltage is limited by the stock reliability (FIT) and increasing the scalar (hence reducing the reliability) will allow the use of higher voltages.

Offsetting the voltages won't technically make any difference, since the CPU will follow its AVFS decisions when it operates in non-OC (i.e. manual) mode. Offsetting can get you around the PPT/TDC/EDC limits, but obviously it won't change what the CPU
expects and wants to receive, in terms of the voltage.

Let's say that you have a 3700X CPU with following V/F for Core 1: 4100MHz = 1.3250V, 4200MHz = 1.36250V, 4300MHz = 1.4125V, 4400MHz = 1.4625V.
When you increase the Fmax through Auto OC, the CPU will calculate the V/F for this range as well (most likely through extrapolation, similar to Intel). If it determines that the Core 1 will require
1.4750V for 4425MHz, 1.49375V for 4450MHz and 1.51250V for 4475MHz, then =< 4450MHz is the maximum you will see no matter what you do (due to 1.5000V hard LUVL / Vmax limit). You can offset the effective voltage, but not what the CPU needs and wants to see.

There is room for improvement in the way the AVFS currently behaves however, these improvements will not result in higher peak frequencies (only avg) even if they all would materialize.
There are two ways for the frequencies to improve on 3000-series CPUs: Either the Vmax (LUVL) is allowed to be increased (not going to happen frankly) or the manufacturing process improves from its current state.
AMD has themselves stated in their slides that the Fmax on 3000-series CPUs is being limited by the maximum voltage they can feed to the silicon.
Makes sense, though it’s rather hard to see why certain bios settings don’t work in practice when there is no concrete way to see all limitations.

I ran several cinebench tests with 2x, 4x, 6x, 8x, and 10x, and all resulted in the same peak VID reading of 1.438, and same peak vcore of 1.425v read in hwinfo. (Peak clock of 4425)

So while I understand what you’re saying, either something is being misreported, I’m being limited by something I can’t tangibly record, or something isn’t working properly.
10-18-2019 11:54 AM
Lupo91
Quote: Originally Posted by SeeGee View Post
Your results are better than mine to be honest. Can you run Atto Disk Benchmark and post your results? It has better granularity than CDM. I'll post my results when I get home and you'll see what I mean.




In my opinion the problem is in the bios of the motherboard, because it is not possible that both Nvme (Corsair MP 600/Aorus Gen 4) have poor performance in 4K
10-18-2019 11:44 AM
The Stilt
Quote: Originally Posted by rv8000 View Post
Thanks for the explanations.

Concerning the Scalar, at least by ASUS's definition, the only description they really offer within the bios is that altering the scalar level only allows the vcore/VID to sustain longer durations at it's defined level. They don't really mention anything about frequency, though in turn higher/longer sustained voltage does result in longer periods at a higher frequency. Would one have to increase the VID from auto to +10mV, in theory, to start to see higher frequency jumps even though the Auto OC is set to +200mhz? For instance: if I increased the VID value in the bios/PBO would I see larger than a 25mhz increase when to the best of my knowledge I'm not hitting any of the PBO limits?
Increasing the scalar only helps, if FIT causes a voltage limit that is below the "global Vmax" (LUVL), which is 1.5000V (unless manually set to a lower value, through the control introduced in AGESA 1.0.0.4).

This is rarely the case in ST workloads, but very common in MT scenarios, especially on 3700X and 3800X SKUs. That being said, I've seen it happening in ST scenarios as well.
For example, if you increase the PPT to say 128W, TDC to 100A and EDC to 140A you should see somewhat higher clocks and significantly higher voltages during e.g. Cinebench R20 MT test when you raise PBO scalar from 1x to e.g. 3x.
Thats because in MT scenario the voltage is limited by the stock reliability (FIT) and increasing the scalar (hence reducing the reliability) will allow the use of higher voltages.

Offsetting the voltages won't technically make any difference, since the CPU will follow its AVFS decisions when it operates in non-OC (i.e. manual) mode. Offsetting can get you around the PPT/TDC/EDC limits, but obviously it won't change what the CPU
expects and wants to receive, in terms of the voltage.

Let's say that you have a 3700X CPU with following V/F for Core 1: 4100MHz = 1.3250V, 4200MHz = 1.36250V, 4300MHz = 1.4125V, 4400MHz = 1.4625V.
When you increase the Fmax through Auto OC, the CPU will calculate the V/F for this range as well (most likely through extrapolation, similar to Intel). If it determines that the Core 1 will require
1.4750V for 4425MHz, 1.49375V for 4450MHz and 1.51250V for 4475MHz, then =< 4450MHz is the maximum you will see no matter what you do (due to 1.5000V hard LUVL / Vmax limit). You can offset the effective voltage, but not what the CPU needs and wants to see.

There is room for improvement in the way the AVFS currently behaves however, these improvements will not result in higher peak frequencies (only avg) even if they all would materialize.
There are two ways for the frequencies to improve on 3000-series CPUs: Either the Vmax (LUVL) is allowed to be increased (not going to happen frankly) or the manufacturing process improves from its current state.
AMD has themselves stated in their slides that the Fmax on 3000-series CPUs is being limited by the maximum voltage they can feed to the silicon.
10-18-2019 09:25 AM
rv8000
Quote: Originally Posted by The Stilt View Post
The thing is that you cannot tell if Vmax is being hit or not, since there is no "flag" to indicate that.
Same goes for FIT, but with FIT you can at least ensure that its not the limit (by using PBO Scalar).

Frankly I do not know what exactly causes the Vmax to be lower on certain cores, or in certain workloads, but I'd assume it has something to do with SIDD (leakage).

I'll see if I can find a way to provide more data on this and the general behavior.
Thanks for the explanations.

Concerning the Scalar, at least by ASUS's definition, the only description they really offer within the bios is that altering the scalar level only allows the vcore/VID to sustain longer durations at it's defined level. They don't really mention anything about frequency, though in turn higher/longer sustained voltage does result in longer periods at a higher frequency. Would one have to increase the VID from auto to +10mV, in theory, to start to see higher frequency jumps even though the Auto OC is set to +200mhz? For instance: if I increased the VID value in the bios/PBO would I see larger than a 25mhz increase when to the best of my knowledge I'm not hitting any of the PBO limits?
10-18-2019 09:12 AM
SpeedyIV
Quote: Originally Posted by Lupo91 View Post
I also have the Corsair MP-600 1Tb, performance is poor in 4K, and I don't understand why.

I also tried the Aorus Gen4 1Tb, but more or less the same

Both have poor performance in 4K
You might find this interesting to read.

https://www.reddit.com/r/Amd/comment...ie_gen_4_slow/
This thread has more than 10 replies. Click here to review the whole thread.

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