Wednesday, October 26th 2022

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

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.
Source: SkatterBencher
Add your own comment

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

#1
izy
Where can i find NopBench ?
Posted on Reply
#2
AusWolf
What's the purpose of this limiter? Can it be disabled?
Posted on Reply
#3
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?
Posted on Reply
#4
Chry
farmertrueI'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.
Posted on Reply
#5
Super Firm Tofu
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.
Posted on Reply
#6
cvaldes
Super Firm TofuThe 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.
Posted on Reply
#7
Oberon
Performance is actually better with 1003A, so there's nothing to get your torches and pitchforks out about...
Posted on Reply
#8
Makaveli
farmertrueI'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.

Posted on Reply
#9
Super Firm Tofu
cvaldesFor 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.
cvaldesSome 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.
OberonPerformance 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.
Posted on Reply
#10
Oberon
Super Firm TofuThey'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.
Posted on Reply
#11
Super Firm Tofu
OberonI 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?

Posted on Reply
#12
cvaldes
Super Firm TofuYes, 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.
Posted on Reply
#13
Oberon
Super Firm TofuVery possible.

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

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.
Posted on Reply
#14
Psychoholic
The "workaround" for this is enable "Medium Load Boostit" from PBO menu.. May not be on ALL boards though.
Posted on Reply
#15
AusWolf
PsychoholicThe "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?
Posted on Reply
#16
Oberon
AusWolfDoes this mean that you need PBO to see the 7950X's max boost clock of 5.7 GHz?
Literally read the article...
Posted on Reply
#17
phanbuey
this seems like a downgrade.
Posted on Reply
#18
AusWolf
OberonLiterally 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.
Posted on Reply
#19
Oberon
AusWolfWell, 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.
Posted on Reply
#20
AusWolf
OberonIt 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.
Posted on Reply
#21
Dr. Dro
Where's the fix for the PBO EDC bug on AM4?
Posted on Reply
#22
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
Posted on Reply
#23
Dr. Dro
KelutrelI 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
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.
Posted on Reply
#24
Kelutrel
Dr. DroWhat 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.
Posted on Reply
#25
AlderaaN
Hello @btarunr

Could you please advise where can the aforementioned NopBench or something equivalent to its capability can be downloaded from?

Regards,
Posted on Reply
Add your own comment
Nov 22nd, 2024 17:08 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts