Read more.And the Windows 10 thread scheduler is "operating properly for Zen," says AMD.
Read more.And the Windows 10 thread scheduler is "operating properly for Zen," says AMD.
What?
So they've set a 20 deg C arbitrary buffer onto measured temps to get fans to work overtime, for reasons only they know. Thread scheduling is "fine" even though the CPU performs noticeably better on an older operating system that likely doesn't support all of Ryzen's features, PLUS no explanation as to why this is.
Balanced power plan still hasn't received any Ryzen related modifications (though this is likely all Microsoft) and AMD refuse to accept that negative SMT scaling is in any way systematic or meaningful, despite the community saying otherwise, and believes "simple" changes are all that is required. So simple that they haven't arrived anywhere for anyone yet.
Why did they bother?
Edit: though to be fair Intel has had a very long time to get HT working properly on their side and while negative scaling isn't as bad, they have far from alleviated it, so maybe it's just the fundamental concept of increasing threads for lower single thread throughput that causes it. It could therefore be that Ryzen suffers more on single thread IPC when it deploys SMT threads to systemwide processes during gameplay. I don't know, someone with a bigger brain can explain it.
Last edited by Ozaron; 14-03-2017 at 11:27 AM.
Problems, what problems?
Well, the 20°C offset only seems to apply to 'X' models.
And the 'X' models are meant to feature a more aggressive XFR boosting depending on temps. So is a faster fan meant to allow a higher boost? Or if the CPU relies on this erroneous offset does this mean the boost is actually lower?
I remember watching Tiny Ton Logans review of the 1800x and he said that there was something amiss as there was nowhere near enough heat being displaced from the case to account for the temperature reading of the cpu.
Bit half bakes I guess but haven't AMD cpu's always been funny with how they report temperatures?
Very odd. It's almost like they want to keep efficiency high by having the fans work harder than normal. Worst case would be that they can only cope with a lower tjMax, but I don't see why they wouldn't just lower it in that case - perhaps they thought about it and concluded it didn't fit well with existing fan profiles :/
For PWM CPU coolers the fan speeds are usually set by reference to a software-defined target temperature. Reporting a higher-than-actual temperature will force the fans to work harder, as they're actually trying to keep the CPU 20oC lower than the target. That means a cooler CPU, allowing for higher boosts. The CPU itself knows the real temperature then adjusts the figure it reports to the OS to force improved cooling.
This would be my guess - they looked at existing fan profiles and decided that they didn't ramp up the speed fast enough to make best use of the dynamic frequency adjustment and XFR boost headroom that the CPUs had, so they came up with a simple hack to force better cooling.
And of course we now know what the X stands for - Xtra-loud....
The temperature reporting seems hardwired in to the CPU, so turning XFR off will do nothing.
Besides, my comment above might be a little too cynical - I've just posted this in another thread:
which fits better with the comments made on AMD's blog anyway....
EDIT
Another thought has just occurred to me, based on CAT's speculation that the 1700 is binned for lower leakage and the 1700X/1800X are binned for higher leakage ... silicon leakage gets worse with higher temps, which in turn increases the voltage required for stable operation and therefore the power required to sustain the performance (which itself also causes an increase in temperatures, which increases the required voltage ... etc.). If CAT's right, forcing higher fan speeds on the X-versions of the chips to keep them cooler than reported would improve their leakage characteristics under normal use, thereby reducing the voltage and power requirements to keep them stable...
Last edited by scaryjim; 14-03-2017 at 01:07 PM.
Still think a much-needed feature in modern OSes is a "disable SMT for this program" option to have the OS report an 8C8T processor to the software and have the scheduler lock the affinity of that software to primary cores only. Even with perfect SMT there is plenty of software that is disadvantaged by it, but it is a bit extreme to disable it globally.
Perhaps software should have a thread profile for task schedulers to read and better assign threads as well, e.g. to assign heavy single threaded software to a core whilst keeping the associated SMT core clear of tasks.
Last edited by CAPTAIN_ALLCAPS; 14-03-2017 at 01:18 PM. Reason: clarity
CAPS LOCK IS NOT A BUTTON IT IS A WAY OF LIFE.
I agree, XFR seems to be a constant source of trouble for minimal gains. Maybe it will improve in future versions less limited by a ~4GHz ceiling, but I honestly think they should have tried a BIOS selectable TDP instead - e.g. for the 1800X 3.6/4.0GHz @ 95W, 3.8/4.1GHz @ 140W, something else @ 65W.
If it could be switched using a physical button like the old Turbo button on the front of the computer that would be great. Cool and quiet when browsing the internet - where the only serious load is some badly scripted ad chewing up 100% of a core - and full power when it is actually needed.
Last edited by CAPTAIN_ALLCAPS; 14-03-2017 at 01:23 PM.
CAPS LOCK IS NOT A BUTTON IT IS A WAY OF LIFE.
This relies on starting the program with Run though, doesn't it? At least I haven't encountered a way to do this for executables started by another program. This is a problem in a lot of the software I used to use, which was usually lots of small independent executables tied together by a separate overarching GUI. It is also a problem for software like Steam games as they must be started through the Steam client (another reason to use GoG).
Plus I would expect modern software to spawn threads according to the number of detected cores (certainly a couple of scientific programs I used do, though in those cases you can manually change the figure to prevent performance loss due to hyperthreading) so reporting 8C8T would be helpful if possible.
Edit - if memory serves, doesn't running a program in Win98/WinXp compatibility mode lock the affinity to single threaded? So it is hardly novel or unknown, it just isn't done.
Last edited by CAPTAIN_ALLCAPS; 14-03-2017 at 01:51 PM.
CAPS LOCK IS NOT A BUTTON IT IS A WAY OF LIFE.
Here's a tip for AMD... Stop trying to to obfuscate real speed numbers, real core numbers, how hot the CPU actually is, how much power it actually uses, etc...
Why hasn't AMD realized that this convoluted smoke screen they've been trying to build between their CPUs and consumers to hide their shortcomings just isn't working? Stop trying to scam the modern computer user. Just build normal multi-purpose CPUs like Intel makes you'll be successful in the market.
There are currently 1 users browsing this thread. (0 members and 1 guests)