• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Ryzen: Strictly technical

Page 43 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Status
Not open for further replies.
Anyone seen this?
https://www.reddit.com/r/Amd/comments/60g5cj/windows_10_update_on_16_mar_have_partially_solved/

Reportedly Windows 10 update on 16 Mar has partially solved scheduler issue
Before:
Ug4J2Xi.png

After:
AdR9eqL.png


Can Anyone with Ryzen confirm?
 
Excuse me but this is implicitely displayed and can be computed this way, say in the 2.1-3.3GHz range.

Frequency ratio is 33/21 = 1.57

Squared voltage ratio is (1010/710)^2 = 2.023

The product of those two values is the ratio of powers from 2.1 to 3.3GHz and is equal to 3.177.

Hence the degree of the polynomial is :

Ln(3.177)/Ln(1.57) = 2.56
😵
You're trying to calculate a polynomial fit for a curve that doesn't exist in the first place? And what you're doing here is subsuming voltage-dependency of power consumption to show it as a polynomial function of frequency.

And FYI taking logarithms of ratios and dividing them is NOT how you do polynomial regression.

Intel process has a value that is close to the theorical optimum of 2, so their power scaling is significantly better..
The mathematical jugglery you do to claim this requires the ratio of the increase in voltage to be the square root of the ratio of the corresponding increase in frequency, in the linear range of the voltage-frequency curve. Show me this data for Intel CPUs and I'll believe you.
CB scale linearly with frequency and core count, that s why despite being ICC compiled it s a very valuable bench to test a uarch evolution..
From your own source, B&C,

frequency vs CB scores
3.0->1338
3.2->1393
3.7->1593
3.9->1690

it is obvious that scaling isn't perfectly linear.
 
😵
You're trying to calculate a polynomial fit for a curve that doesn't exist in the first place? And what you're doing here is subsuming voltage-dependency of power consumption to show it as a polynomial function of frequency.

My calculation is accurate, in the considered range for 10% higher frequency power increase by (1.1)^2.56...

You can easily deduce the respective contribution of frequency and voltage for Ryzen..

And FYI taking logarithms of ratios and dividing them is NOT how you do polynomial regression.

Here it works because the considered segment is a straight line, this mean that the exponent is constant in this range.

The mathematical jugglery you do to claim this requires the ratio of the increase in voltage to be the square root of the ratio of the corresponding increase in frequency, in the linear range of the voltage-frequency curve. Show me this data for Intel CPUs and I'll believe you.

This can be easily checked with the multiple CPUZ captures here and there, do your homework like i did, because i m not throwing random datas on this point but verified numbers..


From your own source, B&C,

frequency vs CB scores
3.0->1338
3.2->1393
3.7->1593
3.9->1690

it is obvious that scaling isn't perfectly linear.

It should be quasi linear, if it s not then the test wasnt perfectly done such that the conditions were strictly the same;
 
Anyone seen this?
Can Anyone with Ryzen confirm?

I am getting 15061 as we speak (finally!) so I can do some testing, but before/after will be impossible because I'm patching out before as we speak.

edit: looks like the update is failing, not sure why. Grr.
 
Last edited:
Speaking of Baghdad Bob, any proof of this supposed miracle patch, like a KB article or something? Or did it just materialize out of thin air?
 
Last edited:
Anyone seen this?
https://www.reddit.com/r/Amd/comments/60g5cj/windows_10_update_on_16_mar_have_partially_solved/

Reportedly Windows 10 update on 16 Mar has partially solved scheduler issue
Before:
Ug4J2Xi.png

After:
AdR9eqL.png


Can Anyone with Ryzen confirm?

This seems to be fake, probably pinned manually. If I create 8 threads on my Ryzen, it still distributes them over all logical cores. It only looks like it is trying to avoid SMT core, but the spikes are all over the place.

Edit: This is what it looks like with 8 Prime95 threads for me:

XXjwGF6.png
 
This seems to be fake, probably pinned manually. If I create 8 threads on my Ryzen, it still distributes them over all logical cores. It only looks like it is trying to avoid SMT core, but the spikes are all over the place.

Edit: This is what it looks like with 8 Prime95 threads for me:

XXjwGF6.png


It's app specific, Fritz wasn't behaving properly before,maybe now it does.
Are you testing with or without the Win update?
 
Edit: This is what it looks like with 8 Prime95 threads for me:
Looks normal to me, basically load being spread on 1 physical core per thread. I would say it is painfully obvious even.

You can't and won't get rid of thread migration in Windows without manual affinity setting, so forget it.

This can be easily checked with the multiple CPUZ captures here and there, do your homework like i did, because i m not throwing random datas on this point but verified numbers..
The provide them. It was bad enough when you ignored silicon lottery in it's entirety comparing BC and Stilt's numbers.

Here it works because the considered segment is a straight line, this mean that the exponent is constant in this range.
Considered segment being straight line means exponent for freq/v is around 1, not whatever you made up, because it is linear. For power/freq it follows it is about 3. Gets trickier considering that linear scaling has it's offsets, but whatever.
 
Last edited:
With respect to the upcoming 1600 , 1500 and 1400 ryze models.

What got me wondering, with a ccx being a quad core and having 8 MB L3 cache, that cache is partitioned to at least 2MB for each core. Otherwise, hypothetically one core would use up all the L3 and the others would have none and the L2 tags needs storage as well. It got me wondering that when AMD has a 2 + 2 configuration or 3 + 3, the usable size of L3 for each core must increase as well. For only 2 cores per ccx, that seems easy.
4MB for each core. But with 3 cores for each ccx, 2 2/3. Which is not a binary number. I wonder how the cache is setup in these cases. Would it be rounded off to the first binary number ?

I mean, hypothetically a flexible format where one core could use all of L3 (with exception of storage for L2 tags for the other cores) when other cores need none, (An ideal situation that would never happen) and then suddenly other cores need the L3 victim cache as well, then there would need to be a policy of what is still left in the L3. I assume after L1 , L2 is checked and then L3, If not present, go to dram. That would cause weird timings in threads that run.
 
It's app specific, Fritz wasn't behaving properly before,maybe now it does.
Are you testing with or without the Win update?

I have the latest standard updates for Windows 10 (whatever Microsoft thinks I should have). But it doesn't look like they changed anything on the scheduler, if anything someone changed something on Fritz Chess ...
 
I have the latest standard updates for Windows 10 (whatever Microsoft thinks I should have). But it doesn't look like they changed anything on the scheduler, if anything someone changed something on Fritz Chess ...

Bits and Chips got a large gain in UT3 so it's looking llikely that something changed.
 
I have the latest standard updates for Windows 10 (whatever Microsoft thinks I should have). But it doesn't look like they changed anything on the scheduler, if anything someone changed something on Fritz Chess ...

The last update is the one that behave correctly, so it's normal what you have seen. You should have performed same screenshot before the update...
 
The last update is the one that behave correctly, so it's normal what you have seen. You should have performed same screenshot before the update...

Some are saying the update is only part of the latest Fast Ring Windows Insider Build. I'm calling BS on this since there's no documentation anywhere about any changes to the scheduler. Just a forum post on some Chinese forum.

KB4015438 is the latest regular Windows update, and it just replaces KB4013429.

This update includes quality improvements. No new operating system features are being introduced in this update. Key changes include:

Addressed a known issue with KB4013429 that caused Windows DVD Player (and 3rd party apps that use Microsoft MPEG-2 handling libraries) to crash.
Addressed a known issue with KB4013429, that some customers using Windows Server 2016 and Windows 10 1607 Client with Switch Embedded Teaming (SET) enabled might experience a deadlock or when changing the physical adapter’s link speed property. This issue is most commonly seen as a DPC_WATCHDOG_VIOLATION or when verifier is enabled a VRF_STACKPTR_ERROR is seen in the Memory dump.

Changing the scheduler to work better with Ryzen would be a "key change", no?
 
Status
Not open for further replies.
Back
Top