AMD Releases AM5 AGESA 1.0.0.3, Reintroduces C-State Boost Limiter with >4 Cores Loaded

[btarunr]

AMD released the latest version of the AGESA microcode for Socket AM5 platform. The new version 1.0.0.3 most notably reintroduces a Precision Boost C-state limiter that [accidentally?] got removed with version 1.0.0.2. This limiter prevents the CPU cores from boosting above 5.50 GHz when more than 4 cores are active (i.e. experiencing heavy workload). SkatterBencher demonstrated how this affects performance on Ryzen 7000-series desktop processors.

NopBench, a utility developed by ElmorLabs, lets you figure out the maximum boost frequency obtainable as workload scales across available CPU cores (i.e. starting from 1-thread, to n-thread). NopBench invokes the NOP instruction, and measures the number of NOP instructions can be processed per second. To make the NOP throughput comparable among processors of different microarchitectures, an architecture-specific factor is used, which for "Raphael" is 2.5x. By comparing the NOP throughput of a Ryzen 9 7950X processor tested with AGESA 1.0.0.2 to 1.0.0.3 (ASUS ROG Crosshair X670E Extreme BIOS versions 0611 vs. 0705); SkatterBencher was able to confirm that that the boost limiter is back in place, and limits Precision Boost frequency to 5.50 GHz when the NopBench load exceeds 4 cores.



View at TechPowerUp Main Site | Source

 

[izy]

Where can i find NopBench ?

 

[AusWolf]

What's the purpose of this limiter? Can it be disabled?

 

[farmertrue]

I've noticed this issue with my ASUS X670E Hero mobo and 7950X ever since updating to BIOS 0705 a couple weeks ago.

Do I just update the 0705 bios that I currently have and added weeks ago, to the 0705 bios that is now on their website? Or does the AGESA automatically update in the BIOS itself somehow?

 

[Chry]

I've noticed this issue with my ASUS X670E Hero mobo and 7950X ever since updating to BIOS 0705 a couple weeks ago.

Do I just update the 0705 bios that I currently have and added weeks ago, to the 0705 bios that is now on their website? Or does the AGESA automatically update in the BIOS itself somehow?

AGESA is updated automatically with a BIOS update.

 

[Deleted member 223428]

The question is why did AMD provide an AGESA with limits removed to reviewers and then quietly add the limits back in for release. Doesn't pass the smell test.

 

[cvaldes]

The question is why did AMD provide an AGESA with limits removed to reviewers and then quietly add the limits back in for release.

For better benchmarks at launch. Unfortunately this is a well-worn practice dating back decades.

Benchmarking is executed before release and the publications' reviews are under embargo until a certain date.

Sleazy? Yes. Uncommon? No. They have all done this at one time or another.

Some reviewers who value integrity/transparency mention that they used pre-release review code for their benchmarking. Others do not.

 

[Oberon]

Performance is actually better with 1003A, so there's nothing to get your torches and pitchforks out about...

 

[Makaveli]

I've noticed this issue with my ASUS X670E Hero mobo and 7950X ever since updating to BIOS 0705 a couple weeks ago.

Do I just update the 0705 bios that I currently have and added weeks ago, to the 0705 bios that is now on their website? Or does the AGESA automatically update in the BIOS itself somehow?

This bios you are using is already on 1.0.0.3 so you shouldn't need to do anything.

 

[Deleted member 223428]

For better benchmarks at launch. Unfortunately this is a well-worn practice dating back decades.

Benchmarking is executed before release and the publications' reviews are under embargo until a certain date.

Sleazy? Yes. Uncommon? No. They have all done this at one time or another.

Yes, I know. My question was rhetorical.

Some reviewers who value integrity/transparency mention that they used pre-release review code for their benchmarking. Others do not.

Technically, 1.0.0.2 was release code. My MB vendor had a beta release of '1.0.0.3 Patch A' on release day, but it's still there as the latest release, as beta.

Performance is actually better with 1003A, so there's nothing to get your torches and pitchforks out about...

They're still unlit and in the tool shed. I read the article as well, and yes, overall the performance is better in multi-thread. It's the lower thread count loads that saw a small regression in that chart. Results that people reading single thread performance benchmarks might see.

 

[Oberon]

They're still unlit and in the tool shed. I read the article as well, and yes, overall the performance is better in multi-thread. It's the lower thread count loads that saw a small regression in that chart. Results that people reading single thread performance benchmarks might see.

I don't think you know how to read charts.

 

[Deleted member 223428]

I don't think you know how to read charts.

Very possible.

Is the 2 thread performance of 1.0.0.2 not higher than 1.0.0.3A default?

 

[cvaldes]

Yes, I know. My question was rhetorical.

Okay. I can't tell how much any given person here knows. I read a lot online and while some handles and avatars seem familiar I just can't remember who most people are, not just here at TPU but pretty much everywhere online.

Maybe that's why some people throw in an emoji, the /s tag, or actually explain where their comment is coming from in situations like this one. Also there are non-native English speakers here as well as newcomers every day.

I certainly don't expect any of those people (or anybody else for that matter) to remember what I previously wrote.

Anyhow companies provide benchmark optimized code to juice performance results for launch day reviews. I don't run beta software anywhere these days so I don't really see these performance fluctuations in my daily usage.

 

[Oberon]

Very possible.

Is the 2 thread performance of 1.0.0.2 not higher than 1.0.0.3A default?

View attachment 267345

You mean by less than half of one percent in a scenario where the C-state limiter doesn't affect anything? It's convenient that you cropped out the 1 thread data point since the discrepancy would be even larger in favor of the new AGESA. So it's either that you can't read charts, that you don't understand what constitutes an actual performance difference, or that you're being intentionally disingenuous. None of them is a great look, honestly.

 

[Psychoholic]

The "workaround" for this is enable "Medium Load Boostit" from PBO menu.. May not be on ALL boards though.

 

[AusWolf]

The "workaround" for this is enable "Medium Load Boostit" from PBO menu.. May not be on ALL boards though.

Does this mean that you need PBO to see the 7950X's max boost clock of 5.7 GHz?

 

[Oberon]

Does this mean that you need PBO to see the 7950X's max boost clock of 5.7 GHz?

Literally read the article...

 

[phanbuey]

this seems like a downgrade.

 

[AusWolf]

Literally read the article...

Well, there's a "default" and a "C-state dis" result for both AGESA versions, so I assume there is a switch somewhere in the BIOS. I just don't want to assume - knowing for sure is better.

 

[Oberon]

Well, there's a "default" and a "C-state dis" result for both AGESA versions, so I assume there is a switch somewhere in the BIOS. I just don't want to assume - knowing for sure is better.

It only affects the clock limit when four or more cores are loaded.

 

[AusWolf]

It only affects the clock limit when four or more cores are loaded.

I know that, but can it be disabled? There's no reason to limit yourself to 5.5 GHz if your cooling could allow for more.

 

[Dr. Dro]

Where's the fix for the PBO EDC bug on AM4?

 

[Kelutrel]

I built in golang something similar to the NopBench mentioned in the initial post, as I was not able to find and download anything similar from the internet.

For anyone curious, instead of directly accessing the smu hardware registers to get the current frequency of each core, that would have required creating a signed driver, I just used the HwINFO feedback produced by adding each core clock to the gadget reporting feature and then monitoring each core frequency, from the reporting hwinfo registry keys in the windows registry, while running a floating-point intensive load on an increasing amount of threads locked on each core in CPPC order. This reduced the code complexity tenfolds (and this is why I am posting this here).

The results for my 5950X (B2), are:
01 cores got 5099mhz
02 cores got 5097mhz
03 cores got 5090mhz
04 cores got 5072mhz
05 cores got 5036mhz
06 cores got 4991mhz
07 cores got 4973mhz
08 cores got 4961mhz
09 cores got 4930mhz
10 cores got 4908mhz
11 cores got 4874mhz
12 cores got 4853mhz
13 cores got 4824mhz
14 cores got 4806mhz
15 cores got 4794mhz
16 cores got 4785mhz

 

[Dr. Dro]

I built in golang something similar to the NopBench mentioned in the initial post, as I was not able to find and download anything similar from the internet.

For anyone curious, instead of directly accessing the smu hardware registers to get the current frequency of each core, that would have required creating a signed driver, I just used the HwINFO feedback produced by adding each core clock to the gadget reporting feature and then monitoring each core frequency, from the reporting hwinfo registry keys in the windows registry, while running a floating-point intensive load on an increasing amount of threads locked on each core in CPPC order. This reduced the code complexity tenfolds (and this is why I am posting this here).

The results for my 5950X (B2), are:
01 cores got 5099mhz
02 cores got 5097mhz
03 cores got 5090mhz
04 cores got 5072mhz
05 cores got 5036mhz
06 cores got 4991mhz
07 cores got 4973mhz
08 cores got 4961mhz
09 cores got 4930mhz
10 cores got 4908mhz
11 cores got 4874mhz
12 cores got 4853mhz
13 cores got 4824mhz
14 cores got 4806mhz
15 cores got 4794mhz
16 cores got 4785mhz
View attachment 267708

What AGESA are you running? My 5950X (B0 stepping) can't come close to those frequencies on all-core even with simple instructions with AGESA 1.2.0.7 thanks to the EDC bug. It's like 4900 > 4600 with simple instructions, around 4450 MHz with AVX code on 1.2.0.3 C, 4150 at best with AVX on 1.2.0.7, it throttles for the hell of it.

That and it is not very adjustable, I really can't get it stable with more than -2 all-core curve optimizer. So far I'm in a VERY annoying position, I have to choose between my processor performing as intended and my computer starting on the first try because memory training is broken in AGESA earlier than 1.2.0.5, and anything later than 1.2.0.3 C has the EDC bug in it. Man, AMD things. I'll keep this in mind when my next (Intel) processor comes by.

 

[Kelutrel]

What AGESA are you running? My 5950X (B0 stepping) can't come close to those frequencies on all-core even with simple instructions with AGESA 1.2.0.7 thanks to the EDC bug. It's like 4900 > 4600 with simple instructions, around 4450 MHz with AVX code on 1.2.0.3 C, 4150 at best with AVX on 1.2.0.7, it throttles for the hell of it.

That and it is not very adjustable, I really can't get it stable with more than -2 all-core curve optimizer. So far I'm in a VERY annoying position, I have to choose between my processor performing as intended and my computer starting on the first try because memory training is broken in AGESA earlier than 1.2.0.5, and anything later than 1.2.0.3 C has the EDC bug in it. Man, AMD things. I'll keep this in mind when my next (Intel) processor comes by.

I am on Agesa 1.2.0.7 on a Crosshair VIII Formula, and I am pretty happy on Amd Zen3, it may depend from a lucky bin too.
For comparison, you can consider that when running CBR20 MT all my cores run at roughly 4330MHz in HwINFO.
Anyway I use PPT:180W, TDC:125A, EDC:140A (to avoid the undervolt with EDC>140), Boost +50MHz (and obviously the PBO curves).
Consider that I am using a simple floating-point load on those cores. If I used the AVX or SSE2 instruction sets, or a CBR20 benchmark load, the peak frequency would have been a bit lower.
The NopBench used by SkatterBencher used the NOP instruction, that is probably slightly better to top up the peak frequency of each core, but I couldn't simulate it in golang without it being optimised and removed, so I used floating-point operations instead.