Personal computing discussed

Moderators: renee, Flying Fox, Ryu Connor

 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Win10 / R7 1700 frequency control problem

Fri Aug 17, 2018 7:39 pm

When I tell Windows to always run the CPU at 100% speed, Planetside gains ~30% to minimum framerates (finally bringing it in line with everyone else's numbers). This also fixes the problem with that memory latency bench where Windows is slower (~130 ns) than Linux or Wine (both ~114 ns). I spend little enough time in Windows (and enough of it is for gaming) that running the CPU full-speed when in Windows isn't a huge problem, but I'm still curious what's going wrong here.

When this problem is occurring, all frequency readouts appear normal except that it isn't boosting. A tweaked version of the memory bench (a long-running single-threaded workload) looks like it brings one core to full speed and stays there, and doesn't jump around between cores much, but 130 ns is as if that core were only clocked at 2.35~2.4 GHz (locking it to 2.7 results in 123 ns, locking to 3.0 results in 116-117 ns).

This CPU only has three speeds for the OS to choose between: 1.55, 2.7, and 3.0 (which is actually 3.2+). The minimum makes about as much difference to the memory bench as the maximum does, almost like half the time it isn't running the thread on the same core the frequency logic thinks it is. The 130 ns results are very consistent, though (130 and 131 are all I've seen from it).

At one point I disabled Cool 'n' Quiet (in the BIOS), got 116 ns, re-enabled it, got 114 ns, opened HWiNFO to see what that looked like in terms of clocks, and it went back to (and stayed at) 130 ns.

It does seem like lately it's been reluctant to boost in both Linux and Windows. Back when I started building that bench, I saw a lot of results more like 110/111 ns, which would be in line for 3.7-ish GHz. Those don't happen now on either OS, and even 1T Prime95 sticks at 3.2. 16T Prime95 blend locked to full speed doesn't go over 55C, so it isn't a thermal problem.

After a CMOS clear, it was boosting properly, but ceased doing so after a couple of bench runs (~20 seconds of load). After turning the RAM back up to the proper speed, I got one but only one 106 ns run, started HWiNFO, and now am getting 122-124 ns repeatably. Locking it to full speed in-OS results in 110 ns. It doesn't appear to be boosting, but is being very liberal with voltage up to 1.2V (usually it uses 1.16V for 3.75 and 0.96V for 3.2).

Disabling global C-state control (necessary to prevent the idle crash bug without excessive SoC voltage) slowed it down a bit more to the old 130/114 numbers. This also keeps it from going over a volt, though doesn't appear to change frequencies at all.

Has anyone got any theories?
 
TwistedKestrel
Gerbil Elite
Posts: 686
Joined: Mon Jan 06, 2003 4:29 pm

Re: Win10 / R7 1700 frequency control problem

Fri Aug 17, 2018 8:26 pm

Idle crash bug?
 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Re: Win10 / R7 1700 frequency control problem

Fri Aug 17, 2018 8:33 pm

The lesser-known early Zen bug. In the absence of a fix, my system randomly reboots every week or so. The more common fix is just to crank VSOC way up (as happens automatically when running DDR4-2800 or higher).
 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 1:02 pm

That deserves a bit more explanation; global C-state control is supposed to be strictly uncore, leaving core C-states working normally. It doesn't affect idle power consumption much.
 
qmacpoint
Gerbil Team Leader
Posts: 270
Joined: Wed Mar 14, 2018 12:56 pm

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 1:20 pm

I used to have the random reboot problem in my Desktop PC as I was an early Ryzen adopter, but I got fed up and RMA'ed that thing - now I don't get any issues in regards to the processor... not sure if you would be in the same boat though
 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 1:56 pm

Nah. I got a replacement under warranty for the compile bug, and the idle crash bug isn't very onerous to fix either way (base VSoC at 2666 is only 0.912V for this chip). Remember the buggy behavior going on now actually appears worse with global C-state control enabled than disabled, and it has been working 100% correctly with it disabled in the past.
 
qmacpoint
Gerbil Team Leader
Posts: 270
Joined: Wed Mar 14, 2018 12:56 pm

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 5:49 pm

synthtel2 wrote:
Nah. I got a replacement under warranty for the compile bug, and the idle crash bug isn't very onerous to fix either way (base VSoC at 2666 is only 0.912V for this chip). Remember the buggy behavior going on now actually appears worse with global C-state control enabled than disabled, and it has been working 100% correctly with it disabled in the past.

Interesting. I run everything at stock and haven't seen any problems - I would really have to try Planetside to see what's going on. Could it be the latest Windows release? or the Spectre/Meltdown CPU patch?
 
DancinJack
Maximum Gerbil
Posts: 4494
Joined: Sat Nov 25, 2006 3:21 pm
Location: Kansas

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 6:51 pm

I mean this in no offensive way to the people in here or the people that have purchased Ryzen, but these kind of issues are one of the reasons I still have an Intel chipset and CPU in my desktop. I, personally, just don't have these kind of issues with modern Intel CPUs and motherboards.

Having said that, I hope AMD and ASMedia can get their stuff worked out sooner rather than later.
i7 6700K - Z170 - 16GiB DDR4 - GTX 1080 - 512GB SSD - 256GB SSD - 500GB SSD - 3TB HDD- 27" IPS G-sync - Win10 Pro x64 - Ubuntu/Mint x64 :: 2015 13" rMBP Sierra :: Canon EOS 80D/Sony RX100
 
just brew it!
Administrator
Posts: 54500
Joined: Tue Aug 20, 2002 10:51 pm
Location: Somewhere, having a beer

Re: Win10 / R7 1700 frequency control problem

Sat Aug 18, 2018 10:36 pm

DancinJack wrote:
I mean this in no offensive way to the people in here or the people that have purchased Ryzen, but these kind of issues are one of the reasons I still have an Intel chipset and CPU in my desktop. I, personally, just don't have these kind of issues with modern Intel CPUs and motherboards.

The high price of DDR4 has had the silver lining of forcing me to avoid the Ryzen early adopter issues. My FX-8350 is still rock-solid stable, for what it's worth. :lol:

I did have to use a 3rd party USB 3 card to work around the ASMedia issues though...
Nostalgia isn't what it used to be.
 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Re: Win10 / R7 1700 frequency control problem

Sun Aug 19, 2018 2:29 am

qmacpoint wrote:
Interesting. I run everything at stock and haven't seen any problems - I would really have to try Planetside to see what's going on. Could it be the latest Windows release? or the Spectre/Meltdown CPU patch?

Stock doesn't fix it, it isn't specific to Planetside, and it's probably been broken for the better part of a year (or I would have noticed bigger swings in Planetside's performance). Planetside is mainly just a good example of how big a problem it really is (and is by far the most CPU-sensitive realistic workload I'm running in Windows).

The more recent boost problems could be OS updates for some security issue, but being cross-OS it'd be fairly weird. I don't really care about the lack of boost except as a curiosity and in case it's related to other problems (present or future).

DancinJack wrote:
I mean this in no offensive way to the people in here or the people that have purchased Ryzen, but these kind of issues are one of the reasons I still have an Intel chipset and CPU in my desktop. I, personally, just don't have these kind of issues with modern Intel CPUs and motherboards.

Having said that, I hope AMD and ASMedia can get their stuff worked out sooner rather than later.

I think the motherboard (ASRock) is a more likely culprit for the issue at hand than the CPU, if not by a huge margin. It wouldn't be the board's first problem, and I could envision certain VRM problems causing this.

The idle hang bug was AFAIK specific to early Zeppelin dies and I mentally file it under early-adopter issues rather than Intel vs AMD. It is disappointing that this warranty replacement for the other early Zeppelin issue still has it, though.
 
synthtel2
Gerbil Elite
Topic Author
Posts: 956
Joined: Mon Nov 16, 2015 10:30 am

Re: Win10 / R7 1700 frequency control problem

Tue Aug 21, 2018 11:31 pm

Here's some more data (generated by the code at the bottom of this post, output via stb_image_write). Sorry about the odd presentation. I didn't put much work into it (obviously), and stbi_write_png() can't seem to handle more output pixels than that.

As far as I can tell, it makes not a shred of sense. Basically, if I let it clock below 2.7, it spends most of its time performing as 2.3~2.4 (if 3.2 max) or even worse if 2.7 max. It's very consistent, except that it occasionally decides to go full speed for a few dozen milliseconds. There are some other hints at power delivery or thermal problems, but all scenarios with those I can think of should start it out full speed.

While not themselves the problem, these slowdown blips don't seem likely to be normal. Interference from other software shouldn't have smooth ramps like that. That looks like something's convincing power management that it needs to slow down for a moment. I lean towards it being power delivery, since thermals are by all appearances so completely under control.

The results of finer sampling than that don't seem too interesting. Here's ITERS_PER_SAMPLE 12 and OUTPUT_SCALE_DIV 32.

#define WORKING_SET 1024*1024*1024
#define IMG_X 4096
#define IMG_Y 256
#define ITERS_PER_SAMPLE 2000
#define OUTPUT_SCALE_DIV 4096

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <intrin.h>

#define STB_IMAGE_WRITE_IMPLEMENTATION
#include "stb_image_write.h"

// xorshift64* constants from Vigna [2016]
uint64_t zs_prng(uint64_t* state)
{
   *state ^= *state << 17;
   *state ^= *state >> 31;
   *state ^= *state << 8;
   return *state * 1181783497276652981ull;
}

int main(int argc, char** argv)
{
   uint64_t* data = malloc(WORKING_SET);
   data[0] = 1;
   for(uint64_t i = 1; i < WORKING_SET / 8; i++) data[i] = zs_prng(&data[0]);
   
   uint8_t* output = malloc(IMG_X*IMG_Y);
   for(uint32_t i = 0; i < IMG_X*IMG_Y; i++) output[i] = 0;
   
   uint64_t acc = 0;
   
   for(uint32_t i = 0; i < IMG_X; i++) {
      uint64_t timer = __rdtsc();
      
      for(uint64_t j = 0; j < ITERS_PER_SAMPLE; j++) acc ^= data[zs_prng(&acc) & (WORKING_SET / 8 - 1)];
      
      timer = (__rdtsc() - timer) / OUTPUT_SCALE_DIV;
      if(timer > IMG_Y-1) timer = IMG_Y-1;
      timer = (IMG_Y-1) - timer;
      output[i + timer*IMG_X] = 255;
   }
   
   stbi_write_png("perf.png", IMG_X, IMG_Y, 1, output, IMG_X);
   
   // keeps the compiler from doing things it ought not
   printf("\nhash of run: %llu\n", acc);
   
   free(data);
   free(output);
}

Who is online

Users browsing this forum: No registered users and 1 guest
GZIP: On