TR Forums

computerbase.de revisits Ryzen gaming performance using Windows 10 with various power profiles and HPET On/Off versus Windows 7. Apparently with the High Performance profile enabled in Power Settings it bridges the gap with the 7700K:

http://imgur.com/a/TRaUM

Source: https://www.computerbase.de/2017-03/ryz ... e-parking/

Hopefully this will put to rest the idea that Ryzen "sucks for gaming."

Ryzen sucks for gaming.

OK:
1. Why didn't they turn on the "high performance" profile for the Intel processors?
2. Why is deactivating HPET... which is an important even timer that was actually originally developed by AMD in conjunction with Microsoft... so important for magical RyZen performance? If the HPET is so evil, why didn't AMD just tell the motherboard makers to make sure it's not even put on the board in the first place?
3. Did they turn HPET off on the Intel boards too?

chuckula wrote:

OK:
1. Why didn't they turn on the "high performance" profile for the Intel processors?
2. Why is deactivating HPET... which is an important even timer that was actually originally developed by AMD in conjunction with Microsoft... so important for magical RyZen performance? If the HPET is so evil, why didn't AMD just tell the motherboard makers to make sure it's not even put on the board in the first place?
3. Did they turn HPET off on the Intel boards too?

It says to me that there must still be some bugs in the system, They could still just be because of immature BIOS, or things that could be fixed with a Microcode update, but you shouldn't have to do things like this to get best performance. Unless there are hardware bugs, but that could still be worked arond in Microcode.

Ryzen doens't suck for gaming (and never did), but still caviat, caviat, caviat.

Is the HPET even doing anything on Ryzen?

I thought modern processors used an Invariant TSC instead?

Ryu Connor wrote:

Is the HPET even doing anything on Ryzen?

I thought modern processors used an Invariant TSC instead?

Both exist on modern processors and there are plusses/minuses to both.
The TL;DR version is that HPET tends to be more precise at the expense of additional overhead while TSC is faster but is often less precise.

srg86 wrote:

It says to me that there must still be some bugs in the system, They could still just be because of immature BIOS, or things that could be fixed with a Microcode update, but you shouldn't have to do things like this to get best performance. Unless there are hardware bugs, but that could still be worked arond in Microcode.

Ryzen doens't suck for gaming (and never did), but still caviat, caviat, caviat.

People actually use Windows' Balanced profile? Ever since Windows 8 I've noticed a lot less stuttering by switching to High Performance. I could see using Balanced for laptops and HTPCs but for a desktop workstation/gaming PC I don't see the point.

Up until last week, I never messed with Windows power profiles. I never needed to. I'm interested in the fix AMD mentioned coming later this spring.

I'm starting to feel like a beta tester.

I was essentially a beta tester for Windows Server 2K3, Windows 8/8.1, Geforce GTX 4xx, Radeon HD 58xx / 78xx / RX 4xx series and Skylake/Z170. All had their pit falls at first before tweaks and patches/BIOS fixes as I recall.

I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments. (At least I stick to Ubuntu LTS and Debian Stable now, so I'm not an alpha tester any more... )

ultima_trev wrote:

People actually use Windows' Balanced profile?

Maybe not most of us, but a lot of people are probably using it just because it's the default.

just brew it! wrote:

I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments.

Hey, me too! What are the odds of that?

just brew it! wrote:

I use Linux as my primary OS, so I am effectively a beta tester for Linux desktop environments. (At least I stick to Ubuntu LTS and Debian Stable now, so I'm not an alpha tester any more... )

Last time I used a Linux distro on a desktop was 2011 ish with Ubuntu / Fedora. Considering I couldn't get drivers for my WLAN (a 2008 Dell Inspiron) in Fedora and the fact that they recently switched from Metacity to Unity (which I hated with a fiery passion) I called it quits then and there.

ultima_trev wrote:

People actually use Windows' Balanced profile?

Yes, the vast majority of people. Not only is it the default, it just works.

There are no objective tests that show the balanced profile as a problem.

Just mythical/subjective/anecdotal talk of stuttering and how "core parking" is breaking things.

Ryzen has a new power management design, one that doesn't desire OS controlled power management. So it's not surprising there are some issues.

Lest I forget, the Ryzen sucks for gaming.

Ryu Connor wrote:

Lest I forget, the Ryzen sucks for gaming.

So do the 7700K or 5960X, apparently. That being said, Intel should just sell i3s and i5s, i7s and Xeons are of no use to anyone!

Ryu Connor wrote:

Yes, the vast majority of people. Not only is it the default, it just works.

There are no objective tests that show the balanced profile as a problem.

Just mythical/subjective/anecdotal talk of stuttering and how "core parking" is breaking things.

Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.

My understanding is that newer CPUs and Win10 support a faster means of frequency switching (in the microsecond range instead of milliseconds), so as long as your CPU and motherboard can do it, then you'd be fine staying in the balanced profile. My 4.2 GHz Skylake box does okay running on balanced, but my 3-year-old laptop definitely doesn't, so it runs at 2.4 GHz all the time when I've got my music profile loaded.

caconym wrote:

Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.

Thanks for the anecdote.

derFunkenstein wrote:

Up until last week, I never messed with Windows power profiles. I never needed to. I'm interested in the fix AMD mentioned coming later this spring.

I'm starting to feel like a beta tester.

Ironically, all my computers are running better with High Performance on. How did I never even consider this before? (I did put Sleep settings back on otherwise, though.)

Ryu Connor wrote:

caconym wrote:

Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.

Thanks for the anecdote.

In that case, one could probably up the minimum processor state % to higher in order to take advantage of the Balanced Profile with SpeedStep (the older clock switching feature). I do the reverse on my laptop, where I step down the maximum a notch to 95% when unplugged, to make sure when the CPU is loaded (tons of Win10 background processes can hog up the CPU), it does not go too crazy and burn the battery faster than I would like. It seems to have improved my battery life materially while not being too slow.

Ryu Connor wrote:

Thanks for the anecdote.

No need for sass, dogg.

Sure, it's an anecdote, but there's no room for subjective interpretation of the results on my end. It's an A/B test with one variable.

I did test with min-proc-states lower than 100%, and my heaviest tracks did fine starting at about 60, but if I'm working on music I'm probably plugged-in, so I leave it at 100% to give myself some headroom (especially with my desktop being so much quicker; I like to make sure my songs work on both machines).

Ryu Connor wrote:

Thanks for the anecdote.

Core parking might very well work for your use cases but it was causing visible and distracting stutter with Windows 8 in the Unigine and Metro 2033 benchmarks with my CPU at the time, an i7 870. Switching to High Performance and setting the minimum processor state to 100 is what eliminated the stuttering.

Just because you haven't experienced core parking performance degradation doesn't mean it doesn't exist.

Ryu Connor wrote:

caconym wrote:

Running in balanced mode can definitely result in stuttering in music production applications. I have numerous synth-heavy tracks that are unplayable if I let Windows keep the minimum processor state at the default 5%. Nothing subtle or subjective about it.

Thanks for the anecdote.

Way to be a jerk.

It's not just an anecdote. Avid (and Digidesign as its forebear) has long recommended this and lots of other tweaks to get the best and most performance out of Pro Tools. And lest ye think this is some AMD-specific crap, the system requirements are quite clear: go Intel or go home.

For the majority of people "it just works" (har) but those that need more know how to do it.

derFunkenstein wrote:

Way to be a jerk.

It's not just an anecdote. Avid (and Digidesign as its forebear) has long recommended this and lots of other tweaks to get the best and most performance out of Pro Tools. And lest ye think this is some AMD-specific crap, the system requirements are quite clear: go Intel or go home.

For the majority of people "it just works" (har) but those that need more know how to do it.

Looks like they're quite a bit stricter than even "go Intel or go home" if you want support from them. For Windows, the only configurations they've officially qualified are specific HP Z-series systems and Dell Precision laptops.

derFunkenstein wrote:

It's not just an anecdote. Avid (and Digidesign as its forebear) has long recommended this and lots of other tweaks

Like how Samsung and others presented "tweaks" like disabling prefetching and indexing on SSDs?

There's lot of bad advice out there.

I'd note all TR reviews are done with the balanced power profile.

It stands to reason if the stuttering we're real, we'd have seen it in the frame time results by now.

So, yes, I appreciate his anecdote instead of empirical data.

Just because you haven't experienced core parking performance degradation doesn't mean it doesn't exist.

It doesn't exist and his anecdote wasn't even about parking(C6), but apparently his music app doesn't make Speedstep realize it needs to speed up. I thought those issues got sorted out during the Conroe days, personally. There's a lot of crap software out there though.

What's super funny is core parking only impacts HT cores, which the i5 doesn't even have.

Ryu Connor wrote:

It doesn't exist and his anecdote wasn't even about parking(C6), but apparently his music app doesn't make Speedstep realize it needs to speed up. I thought those issues got sorted out during the Conroe days, personally. There's a lot of crap software out there though.

The application code should not need to do anything special to let the system know it needs more CPU power. If the system's power management can't respond quickly enough due to either OS or hardware limitations, then disabling said power management is a reasonable workaround.

just brew it! wrote:

The application code should not need to do anything special to let the system know it needs more CPU power. If the system's power management can't respond quickly enough due to either OS or hardware limitations, then disabling said power management is a reasonable workaround.

http://www.intel.com/content/dam/www/.. ... manual.pdf

From what I can see, Intel agrees with you. The ideal outcome is if the OS handles all things gracefully.

Of course they also note you're not completely helpless if the OS can't do it.

Thread affinity management — A multi-threaded application can enumerate processor topology and
assign processor affinity to application threads to prevent thread migration. This can work around the
issue of OS lacking multicore aware P-state coordination policy.

So, yes, sounds like the developers of this application could deal with it.

I guess if you consider it a bad application that it doesn't, is up to the eye of the beholder.

It's not clear to me that the Pro Tools issue is even related to thread affinity. If the application has very "bursty" CPU demands this could be causing cores to jump between P-states even if the threads are staying put. I could easily imagine a DAW application having highly variable CPU demands as tracks and effects are switched in and out; and if the CPU scheduler doesn't deal with that gracefully in real-time it will cause an audible glitch.

Bottom line is, Windows was not designed to be a "hard" real-time OS, and power management only makes that worse. In an audio production application you can only tolerate so much end-to-end latency so you can't hide the issue by increasing the depth of the buffers; you're kind of stuck between a rock and a hard place.

just brew it! wrote:

It's not clear to me that the Pro Tools issue is even related to thread affinity. If the application has very "bursty" CPU demands this could be causing cores to jump between P-states even if the threads are staying put.

Maybe. We'd need to take a closer look at what his application is doing. I just found a possible reason why his P-States might be stuck at low speed.

I just wanted an example. I don't need the example. Nor are we really here to fix his application or change his OS.

Isn't there someone in this forum to tell him about the virtues of Linux?

Interaction of OS scheduling and multicore unaware power management policy may create some situations
of performance anomaly for multi-threaded applications. The problem can arise for multithreading
application that allow threads to migrate freely.
13-11
POWER OPTIMIZATION FOR MOBILE USAGES
When one full-speed thread is migrated from one core to another core that has idled for a period of time,
an OS without a multicore-aware P-state coordination policy may mistakenly decide that each core
demands only 50% of processor resources (based on idle history). The processor frequency may be
reduced by such multicore unaware P-state coordination, resulting in a performance anomaly. See
Figure 13-5.

Bottom line is, Windows was not designed to be a "hard" real-time OS,

Is there even a modern operating system that is designed to be that? (rhetorical)

FreeDOS? (humor)

Ryu Connor wrote:

Bottom line is, Windows was not designed to be a "hard" real-time OS,

Is there even a modern operating system that is designed to be that?

Sure there are. None of them are designed for desktop use though. You're talking specialized OSes for high-reliability embedded applications. Think critical real-time platforms like aircraft fly-by-wire systems.

One example that is widely used in the avionics/defense industry: http://www.ghs.com/products/rtos/integrity.html

But OSes like that cost real money. (Stupid big money if you want the special version that can pass FAA/DoD certifications.) So these days most developers of non-critical embedded applications just throw an embedded Linux distro on their device without really understanding what they're doing, and call it a day. (And the recent wave of IoT botnets is the predictable result...)

Windows and Linux both have real-time priority classes for threads/processes, but this is only a partial solution at best, since the overall environment is fundamentally not designed with real-time in mind.

Ryu Connor wrote:

FreeDOS?

Heh. Well, at least it is simple enough that the response times are fairly predictable, for the most part. As long as you're not doing any I/O.

Things like pro audio apps may be spending a lot of time waiting for the audio to come in. When waiting for I/O, the OS is basically idle so the CPU may choose to go to deeper sleep states (under the Balanced profile). You can't really have the app keep hogging the CPU just to keep it awake either, because that is just an ineffective use of CPU power (the reverse problem). In this case, the wakeup time just seems to be not fast enough for this particular use case, and the app would be forced to catch up, causing stutters.

Re: RTOS - is QNX considered a real one? That's another big name that came to mind.