Jump to content

DerBauer hardware survey highlights issues with max boost clock on Ryzen 3000 "It's worse than I thought"

Necrotic
1 minute ago, leadeater said:

1.0.0.3ABB addressed idle voltages and idle clock reporting, it wasn't made to address any boost clock problems, along with Destiny 2 and WHEA-Logger warnings. Power state voltages and clocks weren't changed.

It still addressed voltage and clock problems, as I said if you fix the brakes you need to test them at all speeds not just at walking pace because that's the only time they made a noise.

1 minute ago, leadeater said:

As for reviewers, the official reviewer guide instructed them to use AGESA 1.0.0.2 which would have been a terrible idea, Anandtech did so go look at that situation/mess. Gamers Nexus was one of the few that conducted the review using 1.0.0.3AB and that still had the boost clock reduction issue. It was impossible to do the reviews using 1.0.0.3ABB anyway since ti did not exist at that time.

So the whole thing was a mess and AMD couldn't even help reviewers test with a version that gave them the best results?

 

 

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

5 minutes ago, mr moose said:

It still addressed voltage and clock problems, as I said if you fix the brakes you need to test them at all speeds not just at walking pace because that's the only time they made a noise.

Unlike brakes why would you check boost clocks when you made zero changes to the voltages at those power states? Nothing was changed. There's no need to test the brakes when you adjusted only the park brake, you test the park brake works because that's what you actually changed/modified.

 

7 minutes ago, mr moose said:

So the whole thing was a mess and AMD couldn't even help reviewers test with a version that gave them the best results?

And there in lies the problem with the assumption that because 3rd party vendor boards had issues that AMD's engineering board also had the same problems. Is it not more likely that AMD carried out testing on equipment and it works but the problems only surfaced on 3rd party boards with customised BIOS and different power delivery designs. AGESA only does so much, vendors do the rest and are able to apply their own voltage curves and power profiles.

 

AMD would have tested 1.0.0.2 and thus is why they recommended to use it, had they known that it was so bad on vendor boards you think they would have recommended it? I think not.

 

If everything was working fine on AMD engineering equipment and vendors weren't testing properly how is AMD to know? Not that I think this was the situation over hasty bug fixes and release to vendors to meet release date windows. That is why I said the root of the problem lies with not giving reviewers product samples soon enough because that would have given them thousands of real data and feedback otherwise impossible.

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, leadeater said:

Unlike brakes why would you check boost clocks when you made zero changes to the voltages at those power states? Nothing was changed. There's no need to test the brakes when you adjusted only the park brake, you test the park brake works because that's what you actually changed/modified.

But clearly something changed.  but in this case the park brake is tied to the foot brake and a lot more complex than a single cable on a pivot. 

 

2 minutes ago, leadeater said:

And there in lies the problem with the assumption that because 3rd party vendor boards had issues that AMD's engineering board also had the same problems. Is it not more likely that AMD carried out testing on equipment and it works but the problems only surfaced on 3rd party boards with customised BIOS and different power delivery designs. AGESA only does so much, vendors do the rest and are able to apply their own voltage curves and power profiles.

So who's problem is that that they only test on certain hardware and for certain things?  I am not buying it.

 

2 minutes ago, leadeater said:

AMD would have tested 1.0.0.2 and thus is why they recommended to use it, had they known that it was so bad on vendor boards you think they would have recommended it? I think not.

 

If everything was working fine on AMD engineering equipment and vendors weren't testing properly how is AMD to know? Not that I think this was the situation over hasty bug fixes and release to vendors to meet release date windows. That is why I said the root of the problem lies with not giving reviewers product samples soon enough because that would have given them thousands of real data and feedback otherwise impossible.

Fine, we'll blame the vendor boards for it not working, why are AMD bothering to fix an issue that doesn't exist in their engineering testing ?.

 

I think we can agree on the bit in bold.

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

16 minutes ago, mr moose said:

Fine, we'll blame the vendor boards for it not working, why are AMD bothering to fix an issue that doesn't exist in their engineering testing ?.

I'm not saying AMD isn't at fault, or that vendors are more at fault. This is what happens when you want to meet a deadline and wish to do so more than iron out bugs that you perceive as non critical etc. Really the only part that I objected to what you said was about AMD knowingly advertising a product that couldn't meet the spec, product spec is validated way in advance. Later AGESA revisions don't have anything to do with product specs that are already announced publicly, let alone the product is already on sale.

 

AMD can't pull an Apple and say you're using it wrong, particularly when you have a measurable metric to tell them "no you". It's still AMD's responsibility to make sure their product functions as advertised and address issues, whether that be a change on their end or working with vendors or both, it's still on them to do it.

 

16 minutes ago, mr moose said:

But clearly something changed.  but in this case the park brake is tied to the foot brake and a lot more complex than a single cable on a pivot. 

Well no, not for 1.0.0.3ABB because the problem existed before that revision. Your still applying it as if that created the problem, the issue was missed before 1.0.0.3ABB. Yes it would have been great if they had picked it up while testing 1.0.0.3ABB but it didn't create the problem and I doubt any boost behavior was tested at all since this revision didn't change nor adjust anything for that.

 

Clearly based on existing evidence it was already an issue before 1.0.0.3ABB so there is no point trying to pin it on that particular revision or it's testing, the problem had already gone unnoticed and just continued to be so, or was known but chosen to not be fixed in that revision or was not ready for that revision. You're already getting customer complaints about not being able to play Destiny 2, better to fix something that you can than wait.

Link to comment
Share on other sites

Link to post
Share on other sites

11 hours ago, leadeater said:

I'm not saying AMD isn't at fault, or that vendors are more at fault. This is what happens when you want to meet a deadline and wish to do so more than iron out bugs that you perceive as non critical etc. Really the only part that I objected to what you said was about AMD knowingly advertising a product that couldn't meet the spec, product spec is validated way in advance. Later AGESA revisions don't have anything to do with product specs that are already announced publicly, let alone the product is already on sale.

 

AMD can't pull an Apple and say you're using it wrong, particularly when you have a measurable metric to tell them "no you". It's still AMD's responsibility to make sure their product functions as advertised and address issues, whether that be a change on their end or working with vendors or both, it's still on them to do it.

 

Well no, not for 1.0.0.3ABB because the problem existed before that revision. Your still applying it as if that created the problem, the issue was missed before 1.0.0.3ABB. Yes it would have been great if they had picked it up while testing 1.0.0.3ABB but it didn't create the problem and I doubt any boost behavior was tested at all since this revision didn't change nor adjust anything for that.

 

Clearly based on existing evidence it was already an issue before 1.0.0.3ABB so there is no point trying to pin it on that particular revision or it's testing, the problem had already gone unnoticed and just continued to be so, or was known but chosen to not be fixed in that revision or was not ready for that revision. You're already getting customer complaints about not being able to play Destiny 2, better to fix something that you can than wait.

I am not applying it as if it created the issue, I am responding to the claims that there is no need for AMD to test boost clocks and CPU loading because they were not touched in the update. What I am saying is  that whilst the issue may not have been specifically boost clocks, the issue was with load monitoring and adjusting voltage and clock speed.  If they are going to update the software that reports or controls voltage and clocks then the rational approach is to check to make sure anything they did does not also effect boost clocks and voltage. 

 

Even if 1003abb wasn't updating issues with clock and voltage control/monitoring then 1003a in the earlier link was,  so the question then becomes was there an Agesa update that didn't address clock speed or voltage issues?  if so was it right after 1002 and also why would they not test core loading and boost clocks after the two updates that did effect them?  That is my point, there is no logic behind claiming they can't/won't check everything because it is not logical to avoid checking core loading and clock speed when the update specifically effects a major component of that.

 

 

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

32 minutes ago, mr moose said:

I am not applying it as if it created the issue, I am responding to the claims that there is no need for AMD to test boost clocks and CPU loading because they were not touched in the update. What I am saying is  that whilst the issue may not have been specifically boost clocks, the issue was with load monitoring and adjusting voltage and clock speed.  If they are going to update the software that reports or controls voltage and clocks then the rational approach is to check to make sure anything they did does not also effect boost clocks and voltage. 

 

Even if 1003abb wasn't updating issues with clock and voltage control/monitoring then 1003a in the earlier link was,  so the question then becomes was there an Agesa update that didn't address clock speed or voltage issues?  if so was it right after 1002 and also why would they not test core loading and boost clocks after the two updates that did effect them?  That is my point, there is no logic behind claiming they can't/won't check everything because it is not logical to avoid checking core loading and clock speed when the update specifically effects a major component of that.

 

 

to be fair if i was the engineer and i noticed that it made the cpu only 25mhz slower i might not worry too much about it and say we'll fix it later. especially if that patch has a security fix or something that probably will matter more 

 

just like if i made a program and noticed that it consumes 0.6% more cpu power than i expected i probably wouldnt delay release because of that

Link to comment
Share on other sites

Link to post
Share on other sites

2 minutes ago, spartaman64 said:

to be fair if i was the engineer and i noticed that it made the cpu only 25mhz slower i might not worry too much about it and say we'll fix it later. especially if that patch has a security fix or something that probably will matter more 

 

just like if i made a program and noticed that it consumes 0.6% more cpu power than i expected i probably wouldnt delay release because of that

 

what if you had already promised 25Hz more though?  They are selling to the petulance of the tech enthusiast crowd. the same crowd that thinks intel are intentional lazy, that nvidia duped them of 0.5G and that a $400 HP desktop is shit because it doesn't play crysis and uses tamper screws.

 

 

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, mr moose said:

 

what if you had already promised 25Hz more though?  They are selling to the petulance of the tech enthusiast crowd. the same crowd that thinks intel are intentional lazy, that nvidia duped them of 0.5G and that a $400 HP desktop is shit because it doesn't play crysis and uses tamper screws.

 

 

idk what was in the update. if its like changing the font in the bios and it made the cpu 25mhz slower yes ill be a bit angry but once again if it was a security fix or some great feature got added i wouldnt be angry

Link to comment
Share on other sites

Link to post
Share on other sites

4 minutes ago, mr moose said:

 

what if you had already promised 25Hz more though?  They are selling to the petulance of the tech enthusiast crowd. the same crowd that thinks intel are intentional lazy, that nvidia duped them of 0.5G and that a $400 HP desktop is shit because it doesn't play crysis and uses tamper screws.

 

 

Well I find it weird that people are fine with it being 25Mhz slower,then praise AMD for giving them that performance later, rather than when they paid for it but I guess you could take it either way. I doubt most tech enthusiasts would take it the same way with Intel or Nvidia, like the TDP ratings even with explanation and how irrelevant TDP is to an enthusiast using a large air or water cooler they still insist Intel lied to them.

Link to comment
Share on other sites

Link to post
Share on other sites

6 minutes ago, Blademaster91 said:

Well I find it weird that people are fine with it being 25Mhz slower,then praise AMD for giving them that performance later, rather than when they paid for it but I guess you could take it either way. I doubt the tech enthusiasts would take it the same way with Intel or Nvidia, like the TDP ratings even with explanation and how irrelevant TDP is to an enthusiast using a large air or water cooler they still insist Intel lied to them.

ive never heard of people praising amd for giving it back in fact theres plenty of people in this thread bashing them for it to an unnecessary degree imo i myself is indifferent/slightly annoyed by it or shitting on intel for their tdp ratings but idk maybe we hang around different people

Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, mr moose said:

the issue was with load monitoring and adjusting voltage and clock speed.

At idle. The problem was existing monitoring software when querying the CPU information would cause the CPU to come out of idle causing a spike in vcore voltage, that's why everyone was complaining about 1.5V vcore because all the software was causing the same behavior. I you didn't check the voltage or used Ryzen Master it wasn't a problem.

Link to comment
Share on other sites

Link to post
Share on other sites

9 minutes ago, spartaman64 said:

ive never heard of people praising amd for giving it back in fact theres plenty of people in this thread bashing them for it to an unnecessary degree imo i myself is indifferent/slightly annoyed by it or shitting on intel for their tdp ratings but idk maybe we hang around different people

Their twitter post announcing the clock fix was full of praise, it was quite weird to see.

Link to comment
Share on other sites

Link to post
Share on other sites

10 minutes ago, spartaman64 said:

ive never heard of people praising amd for giving it back in fact theres plenty of people in this thread bashing them for it to an unnecessary degree imo i myself is indifferent/slightly annoyed by it or shitting on intel for their tdp ratings but idk maybe we hang around different people

Yeah I can't criticize them too much for 25Mhz, although it should run to the specs on the box imo. Although some people were praising them for it and having the opinion of no one should should have even brought it up to be fixed, the TDP analogy was pretty bad but i'm just saying the reaction wouldn't be the same with Intel if their CPU's weren't hitting the advertised boost clocks. I get not everything can be caught in testing but boost clocks should've been something more obvious, unless there wasn't any testing available at the time with retail motherboards.

Link to comment
Share on other sites

Link to post
Share on other sites

20 minutes ago, leadeater said:

Their twitter post announcing the clock fix was full of praise, it was quite weird to see.

thats twitter though, its echo chambers everywhere 

Link to comment
Share on other sites

Link to post
Share on other sites

8 minutes ago, Blademaster91 said:

Yeah I can't criticize them too much for 25Mhz, although it should run to the specs on the box imo. Although some people were praising them for it and having the opinion of no one should should have even brought it up to be fixed, the TDP analogy was pretty bad but i'm just saying the reaction wouldn't be the same with Intel if their CPU's weren't hitting the advertised boost clocks. I get not everything can be caught in testing but boost clocks should've been something more obvious, unless there wasn't any testing available at the time with retail motherboards.

this issue seems to happen on some boards and not others, so it could very well be that amd during internal testing with their boards did not see the problem until motherboard guys started to chip them their motherboards which looking at how there were news about them having little time to get the boards ready could be the reason amd also didn't have enough time to catch the bug before release, they need to start to involve the motherboard manufacturers sooner 

Link to comment
Share on other sites

Link to post
Share on other sites

46 minutes ago, cj09beira said:

this issue seems to happen on some boards and not others, so it could very well be that amd during internal testing with their boards did not see the problem until motherboard guys started to chip them their motherboards which looking at how there were news about them having little time to get the boards ready could be the reason amd also didn't have enough time to catch the bug before release, they need to start to involve the motherboard manufacturers sooner 

Companies need to stop worrying about information leaking to competitors, by that point in time it's really not going to matter and the product is as good as it's going to be and at the end of the day once released will compete as it is so needs to be as good as possible from the start. Some of these short time windows are intentional but really just cause more issues than it's worth.

 

Just get ES/QS samples out soon as you can, even if you have to send multiple different revisions of these. Also send QS samples to reviewers, they have NDAs anyway, then later send retail samples to them for the published reviews. It's really going to make no difference at all if a reviewer breaks NDA to AMD/Intel 1 or 2 months before launch, advanced notice for having to price drop is all that's going to result from that and these companies would already be well aware of the situation anyway.

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, spartaman64 said:

idk what was in the update. if its like changing the font in the bios and it made the cpu 25mhz slower yes ill be a bit angry but once again if it was a security fix or some great feature got added i wouldnt be angry

There was a problem with monitoring software querying the CPU which caused the CPU to think it was being asked for more performance so it upped the voltage and clocks.  not a security fix but an issue with the CPU determining when it needed to up the voltage and clock  and when it was just being monitored.

2 hours ago, leadeater said:

At idle. The problem was existing monitoring software when querying the CPU information would cause the CPU to come out of idle causing a spike in vcore voltage, that's why everyone was complaining about 1.5V vcore because all the software was causing the same behavior. I you didn't check the voltage or used Ryzen Master it wasn't a problem.

that's still a modification to the software that tells the CPU when to increase the voltage and clocks.  Even if it is simple and not expected to interfere with any other part of its operation I am still not buying that they wouldn't at least check for it.

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, mr moose said:

that's still a modification to the software that tells the CPU when to increase the voltage and clocks.  Even if it is simple and not expected to interfere with any other part of its operation I am still not buying that they wouldn't at least check for it.

All they did was delay when the boost happens, instead of wait say 1ms it's now set to wait 10ms (not real numbers). It's a mitigation against existing software that doesn't use the new APIs (which didn't exist till now btw) that don't cause the problem.

 

And I still think it's far more likely the engineering equipment was reaching the correct boost clocks for AMD the whole time so the issue went unnoticed until customer/reviewer feedback.

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, leadeater said:

All they did was delay when the boost happens, instead of wait say 1ms it's now set to wait 10ms (not real numbers). It's a mitigation against existing software that doesn't use the new APIs (which didn't exist till now btw) that don't cause the problem.

 

And I still think it's far more likely the engineering equipment was reaching the correct boost clocks for AMD the whole time so the issue went unnoticed until customer/reviewer feedback.

hence:

6 hours ago, mr moose said:

 Even if it is simple and not expected to interfere with any other part of its operation I am still not buying that they wouldn't at least check for it.

 

Grammar and spelling is not indicative of intelligence/knowledge.  Not having the same opinion does not always mean lack of understanding.  

Link to comment
Share on other sites

Link to post
Share on other sites

New article up at Anandtech going into Turbo, Intel style, AMD style, and more. 

 

https://www.anandtech.com/show/14873/reaching-for-turbo-aligning-perception-with-amds-frequency-metrics-

 

Not finished reading it myself yet.

Main system: i9-7980XE, Asus X299 TUF mark 2, Noctua D15, Corsair Vengeance Pro 3200 3x 16GB 2R, RTX 3070, NZXT E850, GameMax Abyss, Samsung 980 Pro 2TB, Acer Predator XB241YU 24" 1440p 144Hz G-Sync + HP LP2475w 24" 1200p 60Hz wide gamut
Gaming laptop: Lenovo Legion 5, 5800H, RTX 3070, Kingston DDR4 3200C22 2x16GB 2Rx8, Kingston Fury Renegade 1TB + Crucial P1 1TB SSD, 165 Hz IPS 1080p G-Sync Compatible

Link to comment
Share on other sites

Link to post
Share on other sites

Was looking up CPUs on AMD's site a moment ago and noticed a tooltip for boost. Has this always been there? Or did they add this recently? I don't remember seeing it before, but I never really looked either until recent events kicked off.

 

amdboost.png.07628ca0a90dc9833960adf5fcc7bccd.png

Main system: i9-7980XE, Asus X299 TUF mark 2, Noctua D15, Corsair Vengeance Pro 3200 3x 16GB 2R, RTX 3070, NZXT E850, GameMax Abyss, Samsung 980 Pro 2TB, Acer Predator XB241YU 24" 1440p 144Hz G-Sync + HP LP2475w 24" 1200p 60Hz wide gamut
Gaming laptop: Lenovo Legion 5, 5800H, RTX 3070, Kingston DDR4 3200C22 2x16GB 2Rx8, Kingston Fury Renegade 1TB + Crucial P1 1TB SSD, 165 Hz IPS 1080p G-Sync Compatible

Link to comment
Share on other sites

Link to post
Share on other sites

Haven't watched it myself yet, but apparently Paul (and Kyle?) covered the Anandtech article. May be alternative if you don't like reading.

 

 

Main system: i9-7980XE, Asus X299 TUF mark 2, Noctua D15, Corsair Vengeance Pro 3200 3x 16GB 2R, RTX 3070, NZXT E850, GameMax Abyss, Samsung 980 Pro 2TB, Acer Predator XB241YU 24" 1440p 144Hz G-Sync + HP LP2475w 24" 1200p 60Hz wide gamut
Gaming laptop: Lenovo Legion 5, 5800H, RTX 3070, Kingston DDR4 3200C22 2x16GB 2Rx8, Kingston Fury Renegade 1TB + Crucial P1 1TB SSD, 165 Hz IPS 1080p G-Sync Compatible

Link to comment
Share on other sites

Link to post
Share on other sites

That Anandtech article is basically explaining how AMD Turbo works, and is trying to cover AMD's bottom from false advertising.
If you bought a AMD Ryzen 3700X and that box says Max Turbo 4.4GHz, and you never reach that speed. Then you read this Anandtech article, explaining how AMD Turbo works, are you going to accept their explanation. I don't think so.

Intel Xeon E5 1650 v3 @ 3.5GHz 6C:12T / CM212 Evo / Asus X99 Deluxe / 16GB (4x4GB) DDR4 3000 Trident-Z / Samsung 850 Pro 256GB / Intel 335 240GB / WD Red 2 & 3TB / Antec 850w / RTX 2070 / Win10 Pro x64

HP Envy X360 15: Intel Core i5 8250U @ 1.6GHz 4C:8T / 8GB DDR4 / Intel UHD620 + Nvidia GeForce MX150 4GB / Intel 120GB SSD / Win10 Pro x64

 

HP Envy x360 BP series Intel 8th gen

AMD ThreadRipper 2!

5820K & 6800K 3-way SLI mobo support list

 

Link to comment
Share on other sites

Link to post
Share on other sites

4 hours ago, NumLock21 said:

That Anandtech article is basically explaining how AMD Turbo works, and is trying to cover AMD's bottom from false advertising.
If you bought a AMD Ryzen 3700X and that box says Max Turbo 4.4GHz, and you never reach that speed. Then you read this Anandtech article, explaining how AMD Turbo works, are you going to accept their explanation. I don't think so.

I thought the Ryzen 2000 way of advertising specs was the most clear and covered the single core boost variability. For that generation they have a boost figure, which anything could do (PB2), then gave an additional XFR2 note that performance could increase based on cooling and power etc but gave no number.

Link to comment
Share on other sites

Link to post
Share on other sites

16 hours ago, NumLock21 said:

That Anandtech article is basically explaining how AMD Turbo works, and is trying to cover AMD's bottom from false advertising.
If you bought a AMD Ryzen 3700X and that box says Max Turbo 4.4GHz, and you never reach that speed. Then you read this Anandtech article, explaining how AMD Turbo works, are you going to accept their explanation. I don't think so.

Nothing of the sort. Both Intel and AMD have a pamphlet with explanation to what turbo on that system is and how it behaves. Nobody is responsible for people not reading and assuming Dreamland is real

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×