Microsoft Windows Bug Is Holding Back AMD Ryzen

Yes I read it. And I also know that, even not stated in the documentation, Windows 10 behaviour is the same as Windows 8.1.
I perfectly know QPC/QPF is the safest way to timing on Windows real time application, such games and it could use different real time clocks....

So, if the Windows scheduler does not use the kernel versions of QPC/QPF, what's real time clock does it use? I really doubt it will directly read the TSC register value.

EDIT:

This is a good analysis.

So, what I thought as a possible small optimization is not needed since it is already here...

The only issue here appear to be SMT related to me. With SMT on, the second logical thread of the same physical core is underused. Which is a wrong behaviour, especially with a pipeline length between 14 and 20 steps (I did not find the correct number but it should be a little more then Intel and a little less then Bulldozer).
Now all what is needed is to find where is the issue: in the hardware architecture (I hope that's a big NO!), in the firmware of the MBs (They are currently @the state of cràp, but they should not interfere with this kind of issue), or with the OS just not ready for the AMD SMT implementation in this kind of new architecture (which is NOT related to any kind of hardware clock).

 

Then why you ask such strange questions?

QPC is used to measure time span elapsed between two takes. See two calls of QPC in the code above - difference between two time stamps gives the time span. That`s the usage of QPC. And kernel variant of QPC
is KeQueryPerformanceCounter - OS scheduler can use it to measure time spans. This is about Difference Clocks. Either HPET or TSC is considered as counter which changes (increments or decrements) constantly with given frequency. HPET actually has capability to trigger sort of alarm in a future but this capability is not used in QPC. QPC just reads current state of counter (HPET or TSC or whatever) and returns it to caller.

And this is about Absolute (aka Real time) clocks which are used as Windows system clock:

nvm

 

I think you are not getting my point and me yours. Doesn't matter.
Anyway this has nothing to do with Ryzen performance on Windows.
Bye.

 

^ Point is very simple - don`t use phrases "system clock", "default system clock" (even simple "clock") when you are talking about HPET, TSC, QPC because they are not related to each other.

 

Thanks for posting. I'm waiting for the ITX Mobo's in the 2ndH of the year. As a 5820k ITX users, I laugh at these benchmarks. The 7700 fast CPUs beat the dust off my 5820k too, but it's eats their lunch at general computing and as for gaming, I game @1440p, 70hz, with a GTX 1070 and Gears 4, Rise ott Raider, and everything else is more than fast enough, i.e., I don't feel like there's anything to be gained my more benchmark FPS'. Nothing feels slow, stutter, or dropping frames.

The Ryzen is the only upgrade path for me, a 5820k user, that presents any meaningful performance for $$$ value.

Intel won the first round with the FUD campaign, but they're simply not going to be able to hold off AMD this time. Intel is a giant, they won't come close to being destroyed, but competition is back and the winner is users, particularly those with workstation class CPUs. The only chance Intel has to keep me as a customer in this area is to drop the 6900 or 5960X to $499 and we all know that's not going to happen.

Without AMD, I'd have not sub $1000 upgrade path, and NVIDIAS top end GPU, 1080ti now, would still cost $1000+. AMD should be every PC enthusiasts best friend right now and deserves to be rewarded. They've got my money, they just need to deliver the X300 chipset for ITX Mobos and Vega.

 

allegedly, AMD agrees with pcper.

tldr:

"I have been told from high knowledge individuals inside the company that even AMD does not believe the Windows 10 scheduler has anything at all to do with the problems they are investigating on gaming performance."

 

Do you remember what I said on the review of 1800x ?
I was 100% accurate with the fact that Ryzen R7 should be seen as a dual socket system , or dual quad core , instead of octa core processor, because of AMD CCX and fabric interconnect.

I was right again , that win 10 scheduler is OK. In fact is almost ok, one minor modification should be made, the L3 cache size 8Mb , instead of 16 Mb.

 

I'm also very sorry that Hilbert just took the false info from other sites and spread it here, without any further investigation.

 

I also see most of people doesn't really know what is in fact SMT/Hyperthreading .
Even people very good informed , with blogs and different IT sites are talking about physical thread and logical thread .
When SMT is enabled , only exist the physical core itself and 2 LOGICAL Threads. Both threads are equal from core perspective, there is no thread that is physical and other is logical . You can favor one thread or the other only by software and scheduler.
With SMT disabled, then thread and physical core is the same thing.

 

To make clear what SMT/HT is doing and to understand that with SMT/HT enabled only exist the physical core and 2 LOGICAL threads .
I run CPUz integrated benchmark on logical core 6 then logical core 7 and then on logical cores 6+7 (to see actual HT gain). Logical cores 6 and 7 both belong to physical core 3 .

Logical core 6 :

http://picpaste.com/cpu-z-core-6-kBlc0aCA.jpg



Logical core 7:

http://picpaste.com/cpu-z-core-7-oB9aJNTP.jpg


Logical cores 6+7:

http://picpaste.com/cpu-z-core-6_7-87y9SNd1.jpg


As you can see, logical core 6 is not more physical or more logical than core 7. Both are logical and are tied to physical core 3 . Both have the same performance also

In the 3rd pic we can see how much gain we can obtain turning on HT. According to CPUZ internal benchmark the gain is only 10%. Olso from first 2 pics we can see that trying to run multiple threads on only one logical core will negatively impact performance by 7%

 

Seems like everybody is misunderstanding the conclusions of the PCPer article. They dispelled rumors of the issue being related to core enumeration by the windows scheduler (essentially people claimed that windows scheduler was swapping running threads between physical cores).

The windows scheduler has nothing to do with this issue, and it's on AMD to alter the cpuid through bios updates to have the system recognized as effectively a dual CPU system that can be run in NUMA mode by windows.

Aka, microsoft has nothing to do with it, and it's odd that this was posted on G3d frontpage

 

Is there some particular reason you need to stick with Windows 7

 

G3D does great HW reviews. Material Hilbert actually writes typically is great. But for a long time now he has the habit of copy-pasting crap false click-bait 'news' articles.
For example, the "Intel CPU price cut" when it was really just a specific store, Microcenter, doing a sale.

 

What about how the scheduler splits threads between CCX's? Isn't that the actually important part? Even Microsoft on Twitter admitted that Windows need patching for Ryzen. If you mess a bit with Linux schedulers you'll see how crucial they are (same for CPU drivers). I would like to see a repeat review for Ryzen at around May, personally.

 

Microsoft said there are patches to be made, they said nothing about the scheduler. AMD themselves said the scheduler has nothing to do with it, read the PCPER article.

The problem isn't the windows scheduler, the problem is that the CPUID leads to it being recognized as a single CPU system (no NUMA mode) for compatibility reasons.

it's in AMD's hands to change this, not microsoft

 

I told you, scheduler is Ok. The only thing is to modify l3 chache from 16 Mb to 8mb. If is set to 8 Mb, cores from one CCX will not be forced to search data in L3 lcache of the other CCX. All other things are just fine with actual scheduler of win 10

 

For gaming, Ryzen need patches to actually see an R7 being a dual processor, that is all, but will never compete with i7 octa core in gaming, but will take out some serious issues that is stopping R7 to have better result

 

Maybe the modify of scheduler regarding L3 cache will be enough and r7 will not need games patches. The future will tell us

 

Déjà vu.... Bulldozer was poor at gaming performance as well, so the same story was made up as an excuse. MS released a patch later, the performance gain was none, marginal or even detrimental per a case.

Regardless this nice tale, you got your reason why AMD weren't hyping Ryzen cpus via gaming benchmarks at all, but used Blender etc..

Because they have been well aware of the issue and no solution found yet, nor they are being aware of the cause. So gg's.

 

Ryzen doesn't have "poor" gaming performance. I don't know what your definition of "poor" really is, to be honest. The games it's back aren't that many, and in most of the games it's actually close to the 6900k, which is exactly what was expected.

Keep in mind that none of them are compiled against Ryzen at this point, not even Windows CPU drivers.

How do you know what the "issue" is, and what the "solution" was? :infinity: As for Windows patches being detrimental for Bulldozer, it was the exact opposite.

http://www.guru3d.com/articles_pages/watch_dog_2_pc_graphics_performance_benchmark_review,8.html

http://www.guru3d.com/articles_pages/dishonored_2_pc_graphics_performance_benchmark_review,8.html

http://www.guru3d.com/articles_page...e_warfare_pc_graphics_benchmark_review,8.html

http://www.guru3d.com/articles_pages/battlefield_1_pc_graphics_benchmark_review,9.html

http://www.guru3d.com/articles_page..._graphics_performance_benchmark_review,8.html

Not that I would recommend a Bulldozer, but its performance has gone up with the times. Bulldozer was also slower than Sandy in everything, this is not the case with Ryzen. It in fact has better IPC than Kaby in some tests.