[News] Microsoft Windows Bug Is Holding Back AMD Ryzen

[Ket]

Gigabyte are selling the AX370 Gaming 5 in the UK for a rather premium price, SCAN are selling it for 206, 211 with shipping. For that money there is nothing "mainstream" about the Gaming 5, not in the slightest. If Gigabyte really think the Gaming 5 is "mainstream" they better reduce it's price by 50-60, and that still doesn't make them exempt from bug fixing the UEFI. Manufacturers speccing B350 boards for 3200MHz memory isn't anything to complain about it just shows they are willing to stand behind and improve their product. Overclock3d are also echoing my, and others sentiments regarding the UEFI on the Gaming 5 and some other issues as well, to quote a few snippets from their conclusion;

We're also slightly concerned about the placement of the M.2 slot, particularly given their propensity to slow down when they get extra toasty. We'd also like a little more performance from it at stock settings, especially when so many people still use the "plug in and go" method of system building, we pray to the silicone gods that the Gigabyte engineers dont ruin these boards with half arsed 'fixes'. We have had enough of it keep happening and having to guide end users around their incompetencies to do basics tasks like set an acceptable stock Vcore. Chinese new year is over now boys, get back to doing some proper work. The Gaming 5 is great, lets see if you can make it better not worse.

With any luck, I'll be taking a look at a few more X370 boards in the near future then picking and choosing which I want to review, if any take my fancy that is. If not I'll be doing a article on the Zen 1700.

[chew*]

I agree price is at the top end of mainstream of course you need to question if retailers are cashing in with current supply and demand.

That aside like i have been saying there is so much functionality broken across vendors that looks is and should be the least of anyones concerns right now.

I will give an example. Currently a setting of 13 Cas latency is not applying nor is 15. Odd numbers across platforms....

2 totally different boards. 2 totally different vendors.

Next example.

Wprime gigabyte win 10 fast win 7 horrible

Asus (b350)wprime win 10 fast win 7 fast

Asus (b350)32m pi decent w10 slow w7

Gigabyte 32m pi faster in both but still slow...

These problems are far more of a concern and as such take priority over what I would consider trivial $hit at this point in time.

Im trying to get stuff fixed just so i can do a damn 3d comparison across systems and OS.

Currently reliable testing is out of the question..so my focus is simple in what i report. Function now. Fluff later.

[El Mano]

Wait, I'm probably wrong on this one but as far as I know the OS does not handle the CPU's cache.
Cache is hardware driven and the OS has nothing to do about it.
Can anybody clarify this?

[chew*]

Vendor tuning will impact OS performance.

scheduling can be worked around by OS swap

If the OS thinks that each thread is a core it can assume it has cache and therefore try to use it.

[vario]

Wait, I'm probably wrong on this one but as far as I know the OS does not handle the CPU's cache.
Cache is hardware driven and the OS has nothing to do about it.
Can anybody clarify this?

There are people who know a lot more and can probably give you a lot better answer.
but simple truth is, no matter if windows directly manages cache. It manages cores, and as there are 2 different L3 caches for different cpu 4 core blocks, you see that it can be a problem.
If windows shuffles workload from a core 1 on ccx 1 to a core 5 on ccx 2 , the data it needs is not in the cache assigned to it, so it must get it from ram or across infinity fabric or whatever its called from another L3.At least thats the main problem i see. And thats the simplest problem i see, there are probably a ton more that can be handled differently considering how bios and windows operates.

[StyM]

[Sparky]

Didn't this sort of thing sort of happen with Kentsfield? I know with my Q6600 for example certain workloads would make the thing slow way down, as any cross communication between the two dual core parts had to cram through FSB.

[iddqd]

Not quite that bad, as they have a dedicated fabric for inter-CU communication, but yeah - workloads where you have to keep memory coherent across all 16 threads won't perform as well as they could have if the L3 cache was a monolithic design.
Still, enabling NUMA support in Windows for the 8- and 6-core Ryzens should help out a lot. This could be done relatively quickly, as Windows already has this feature; it was originally designed for multi-socket boards to avoid jobs migrating from one socket to another needlessly.

[Sparky]

Well right, Kentsfield was shoving stuff through the FSB, to the NB, and back again. Terrible. This isn't that bad, no.

But as they pointed out, that would open another can of worms as now you're basically preventing a whole bunch of software from utilizing all available cores because so much software is not NUMA aware. This might help in some cases, but hurt in others.

[MattiasNYC]

The other thing I've heard about NUMA is that if you tell the OS to look at the CPU that way it might also try to partition RAM and get into trouble trying that. This would be because other NUMA designs would have dual-socket boards where each socket has dedicated RAM which is not the case here.

I'm not so sure what the solution is, but it's beginning to look to me like this might have to get done on a software level.

For pro audio some people need very low latency, and there's a specific circumstance where this becomes an issue (with CCX). So for us there's a need to get the software to park tasks in a specific CCX. If the OS does it for us it might not help because how does the OS know if the thread needs to go in one CCX or the other?

[chew*]

The other thing I've heard about NUMA is that if you tell the OS to look at the CPU that way it might also try to partition RAM and get into trouble trying that. This would be because other NUMA designs would have dual-socket boards where each socket has dedicated RAM which is not the case here.

I'm not so sure what the solution is, but it's beginning to look to me like this might have to get done on a software level.

For pro audio some people need very low latency, and there's a specific circumstance where this becomes an issue (with CCX). So for us there's a need to get the software to park tasks in a specific CCX. If the OS does it for us it might not help because how does the OS know if the thread needs to go in one CCX or the other?

That's actually a very good question and also causes more questions like if AMD could implement quad channel on either side of the chip would it be even faster.

Was it designed with the ability/flexibility to do this. It raises a ton of questions and or possibilities.

A CPU is only as fast as the platform it resides in.

I've actually found some very interesting results on b350, looking deeper into it now.

[MattiasNYC]

Chew,

thanks a million for sharing btw, it's greatly appreciated by all I'm sure.

[chew*]

Chew,

thanks a million for sharing btw, it's greatly appreciated by all I'm sure.

Np I share what I can when I can and if I can.

Some things I may know and can not discuss but if I see someone way off course I will attempt to redirect them...unfortunately some people are stubborn

[JPQY]

The chess engine i sent you is Numa-aware..i have tested on a Dual Xeon E5-2699 V4 system where it uses all cores/threads @100 in less then 1sec.!

[AbortRetryFail?]

It's been awhile since my 2P builds but if I recall correctly, you could tell if 'NUMA-Hell' was dogging you if your page-faults took off.

If the program could not find what it was looking for on the Socket1 DIMM bank, it would 'thrash' (what I called it) and go looking in the Socket2 DIMM bank. it seemed to me you ended up in this dopey loop of writes/reads/misses.

Is this what folks are contemplating? Latency in certain workloads is being driven by 'L3 hopping' or thrashing?

[chew*]

The chess engine i sent you is Numa-aware..i have tested on a Dual Xeon E5-2699 V4 system where it uses all cores/threads @100 in less then 1sec.!

Si senor but im on a rather lower end board after a failure of another board so milking it until i can get something that i can stress without worries.

Dainty pwm is the term i would use atm.

[vario]

Shouldnt this be a simple thing ? At least the CCX L3 problem.
I fired up cinebech and run single core bench.Hwinfo shows me core usage.
The thread bounces between 4 cores constantly , sometimes miliseconds, sometimes a second or two staying on the same core.
The fix should be easy to implement, in case ryzen is in the system, windows enumarates cores for CCX1 and CCX2, when thread starts at a core in specific CCX, it bounces it only in the CCX it started. No L3 cache misses. Or am i not understanding something ?
Of course SMT problem can be something more, but im guessing its also partially resolved by this.

[BenchZowner]

Scheduler bug confirmed to be... not real officially by AMD themselves.
It is working fine.

L3 Cache issue ? No comments on it, but I wouldn't count on being a size detection bug.

https://community.amd.com/community/...mmunity-update

[vario]

AMD HQ

[kromosto]

This is not looking good for AMD.

[AliG]

Is anyone really surprised though?

AMD has a fraction of the headcount and budget of Intel, and still managed to produce a CPU that pulls big wins in raw compute power. They clearly need to both improve the instruction set robustness and refine the manufacturing process - but Ryzen for the price is rather impressive. I actually think the fact the 1700X does beat the 6900k in certain tests gives people a skewed perspective, as if AMD either botched the design (which clearly the memory controller needs work) or there are secret huge software gains out there.

They reality is they'll take a big chunk out of the midrange professional market and use that money to better optimize Zen+ (and so on).

[kromosto]

This is not a surprise for me actually but what is surprise is AMD used 4 core ccx to compete with intel. If it was 8 core it will be more future proof but with this architecture they even cant compete with Intel next year. Unless they made a design that can be upgraded to 8 core... I hope so.

[AliG]

Why is that a disappointment? I thought Kentsfield pretty much put to bed the benefits of monolithic cores.

Having a quadcore based architecture allows them to easily scale from midrange to high end server applications. They just need to improve the way the scheduler and L3 cache help cores interact.

[kromosto]

You are right. Maybe I had high expectations. Either way if AMD can solve this no problem.