Core i7 (Kaby Lake) core clocks

[RobertR]

I have been watching the Sensor Status>Core #n Clock display on and off for a while now, and re-check it when a new version of HWiNFO comes out.

Prior to the latest version (5.47-3115) - and possibly one or two BETA releases before, I would see the full range of my CPU (i7-7700) "turbo" clocks: 3.6 GHz (normal) up to 4.2 GHz (occasionally)... and very occasionally, I would see nonsensical readings of 6-7 GHz.

I don't know how much of what is displayed for these values is just being directly read from H/W, vs how much of this has to be computed from multiple inputs.

BUT, with this newest version of HWiNFO, I never see anything above 4.0 GHz - is it possible that you are now artificially "clamping" these values, and chose the [incorrect] 4.0 GHz value as the max allowed here?  If so, you might check the Intel docs for this CPU, which really can go to 4.2 - if not, ?

While we are on the subject of observed values, the "Bus Clock" reading appears to show a range of readings that may not be "possible" (46.4 MHz - 105.8 MHz)?  I thought it was a fixed value - 100 MHz in my case - but I may have this wrong?

Details: Z270-based mobo, NO overclocking, XMP-3200 memory, Win10 x64.

 

[Martin]

Values like 6-7 GHz should not be displayed, it would be great if you could post a screenshot of such situation and capture it in the HWiNFO Debug File that I could analyze.
HWiNFO doesn't perform any clock clamping, so it must be due to some other limits in the system (power, temperature ?).
Bus Clock on Kaby Lake is measured by the CPU and it should not fluctuate so much (should be very close to 100 MHz unless changed by user). Again, would be great if you could post a HWiNFO Debug File that captures such situation and I will analyze it.

 

[RobertR]

Well, I said it had quit showing the "normal" highest turbo clocks of 3.6-4.2, and that it had quit showing the "nonsensical" values too... it looks like it needed more time.  

BUT, I still seems to not show the "normal" high values, topping out at 4 GHz - unfortunately, the crazy ones are still possible it seems.

Note that both pics (the first is from whatever BETA was current on March 7, the second is from the latest BETA 5.47-3115) I am posting show the funny Bus Clock values.

Finally, since it takes some time to get enough samples to see the obviously bad ones, the debug files are huge - anything I can do about that, and any instructions on posting these large files?

[attachment=2231]

[attachment=2232]

 

[Martin]

Those BCLK fluctuations are really huge, haven't seen such extreme values yet. These have direct impact on the clocks measured as clock = ratio * BCLK.
I will definitively need the Debug Files to analyze this. If those files are too large then please compress them first using ZIP or RAR or 7Zip (best). If such compressed files are still too large to be attached here, then you might try to upload them to some public storage websites, or send them directly to me via e-mail (you can find it in HWiNFO or at the bottom of homepage).

 

[RobertR]

Got some debug traces for you, Martin - a small one with just a bad bus clock, and a larger one with the bad core clocks - let's see if I can upload these [7Zip-compressed] files.

[attachment=2236]

No, I am not allowed to add the larger attachment - it is 2.3 MB (compressed) - and even with the "unlimited" quota for attachments, when I try to actually "add" it, I see no error, but it just re-displays the message without the new file.

Perhaps the smaller one with the funny bus clock will help.

 

[Martin]

Thanks for the data.
The problem is because you have disabled the "Bus Clock-based" option in main settings - Safety - "CPU Clock Measurement". If you enable this setting, all should be well.
You can also enable the "Periodic polling" option, which will constantly watch the BCLK during runtime.

 

[RobertR]

Thanks, Martin - I had been looking for the "magic" combination of HWiNFO settings that gives the best compromise between CPU utilization and accurate/meaningful values displayed, and it looks like I may have turned off one too many options.

Interestingly, this took care of the "wild" variations - as you said it would - but my highest clock seen per core was still only 4 GHz... so, a bit of digging, and I decided to update my BIOS (this shouldn't have been necessary, as both Gigabyte and the BIOS companies should have had Kaby Lake samples to work with, but...) - and that took care of things!

Now, Windows 10 understands the CPU properly, and I see the high end of the adjusted clocks going to 4.2 GHz, and also see an "extended" lower end of 800 MHz (instead of the previous 1.6 GHz)... I wouldn't be surprised if Windows was doing the best it could, and interpreting the CPU as a "Skylake" part - but now it sees it as the "Kaby Lake" part it really is.

Finally, I also notice that what HWiNFO displays as "Vcore" from the "GIGABYTE Z270X-UD5-CF (ITE IT8686E)" device now also has a much expanded low range, displaying values anywhere from 0 to 1.15, but usually sitting around 0.75.

I expect that this is a "synthesized" number from the "ITE IT8686E", so how to interpret it isn't completely obvious... in the Intel doc "7th-gen-core-family-desktop-s-processor-lines-datasheet-vol-1", there are a pair of figures (4.1 and 4.2) that go into the processor, package, and core power and "C" states, but it is a little tough to understand fully.

Thanks again for putting me on the right track, and the rest of this should serve as a warning to all to keep those BIOSes updated!

 

[Martin]

You're welcome, I'm glad that everything is OK now.