X370 Killer SLI/AC Voltage jumping all over

Check monitoring with ONLY one app clears this up.

The chip providing the data does NOT like to be addressed by more than one monitoring app at a time. Been this way since I began computing, decades ago.

last version cpu-z is bugged.. use hwinfo.

nycalex wrote: Well, first of all my board has NO LLC option unless i downgrade to bios 2.3. 2.4 (what it came with) and 2.5 both delete LLC option. so instead i have something called vcore OFFSET. i have it currently set at + 60mv (i don't even know how much voltage that is in plain english). cpu has been oc to 3.9 Core voltage set at 1.325 Vcore offset set at +60mv (this is the lowest setting available) now on to benchmarking: Prime95 = rock solid stable ran it 3 hours. peak temperature was 62 degrees measured with ryzen master and hwmonitor. the issue i'm having is that cpi-z, hwmonitor and ryzen master are all showing me a DIFFERENT voltage. HWmonitor showing voltages ranging from 1.8 to 2.7 cpu-z showing 1.28 to 1.36 ryzen master showing the exact voltage i set in bios: 1.325 now, since i don't have LLC............how do i maintain 1.325 volts at all times?

Have you tried using the Fixed Voltage setting, instead of Offset?

Did you notice with the UEFI version that gives you the LLC option, that is sets LLC to 1 by default? That is the greatest LLC correction, providing the least voltage droop. Did you notice any difference between the VCore variation between having the LLC option, and without it?

Is the Ryzen Master voltage reading constant at 1.325V?

Monitoring programs do not read the VCore continuously, like an analog volt meter. They take a reading, a sample voltage at whatever polling rate programed into the software. For example, HWiNFO64's Polling Frequency is 2000ms, which is 2 seconds. So it reads the VCore and all other readings every two seconds. The polling rate can be set to a different frequency by the user. You can find that setting in the Config window, General tab.

Next, the polling rate of each monitoring program is not guaranteed to be the same. Even if it is the same, there is no guarantee that each program is reading the VCore at the same time. If they do try to read the VCore at the same time, that is when problems happen, and the readings are bad. There is an instruction that can be used by monitoring programs (IF they use it) to wait to take a reading if another program is currently reading data. But with all these variables and unknowns, and the simultaneous read problem, that is why using multiple monitoring programs at the same time does not work.

Another question is what is the monitoring program reading for the "VCore"? Is it the VCore VID or the true VCore, which can be two different things. VID is what the processor cores request using their internal programmed tables. The true VCore is what is actually used by the processor. The two may be identical, but the VID will always be the higher of the two readings. They could be equal but the true VCore is usually at least a bit lower than the VID. Programs like Intel's Extreme Tuning Utility show the VID, which I know from experience using it. Ryzen Master also looks like it shows the VID, but I don't have as much experience with it.

Any non-VID VCore reading is not a voltage reading that is simply translated from binary to decimal. It is data in a certain format that must be translated into the VCore value. This data is not necessarily the same for every processor generation/architecture. That's why we sometimes see crazy high VCore values like the 2.7V you saw from HWMonitor. Guess what your 1.325V VCore setting is multiplied by two and rounded up to one decimal place? It's 2.7V. HWMonitor is applying the wrong translation to the VCore data. CPU-Z version 1.79 made the same mistake. Version 1.79.1 fixed it.

Do you have all the CPU power saving options disabled in the UEFI/BIOS? Are you using the Windows High Performance Power Plan, or configured whatever power plan you use to have the Minimum Processor State set to 100%? If all of those things are not set that way, the VCore can change. Processors are designed to try to shift into a lower power usage state, and all these options enable them to do that. Lower power usage normally includes a lower VCore.

We assume the VCore reading is exact, but it isn't. The difference between 1.28V and 1.36V is 0.08V, 8/100 of a volt. Do we even know if the entire VCore monitoring chain, from monitoring chip to the software dealing with it, has that degree of accuracy? We like to believe it is, but that is faith. Ever see any specs about that? Just making the point.

Checking our VCore is more complex and difficult than we want to believe, and in reality is rarely exact at any time. That's why Intel uses the VID, and most likely Ryzen Master too. Ryzen's VID is most likely closer to the true VCore than Intel's VID, given what I have seen.

So what is the difference between the voltage below the frequency value (in the Bios) and the lower one in the external cpu voltage?

on hwinfo
Voltage 1: vcore
Voltage 2 (external voltage): CPU core voltage (SVI2 TFN)


Edited by Denroth - 25 Jun 2017 at 2:02am

parsec wrote: Have you tried using the Fixed Voltage setting, instead of Offset?

yes, i set it at 1.325.

however, i only have 2 options for vcore offset, it's either auto (then voltages really jump high) or a set number starting with +60mv. this is the reason i went with +60mv.

parsec wrote: Did you notice with the UEFI version that gives you the LLC option, that is sets LLC to 1 by default? That is the greatest LLC correction, providing the least voltage droop. Did you notice any difference between the VCore variation between having the LLC option, and without it?

no, since i did not go into windows with bios 2.3. i wanted to update to agesa 1.0.0.6.

parsec wrote: Is the Ryzen Master voltage reading constant at 1.325V?

yes sir

parsec wrote: Monitoring programs do not read the VCore continuously, like an analog volt meter. They take a reading, a sample voltage at whatever polling rate programed into the software. For example, HWiNFO64's Polling Frequency is 2000ms, which is 2 seconds. So it reads the VCore and all other readings every two seconds. The polling rate can be set to a different frequency by the user. You can find that setting in the Config window, General tab. Next, the polling rate of each monitoring program is not guaranteed to be the same. Even if it is the same, there is no guarantee that each program is reading the VCore at the same time. If they do try to read the VCore at the same time, that is when problems happen, and the readings are bad. There is an instruction that can be used by monitoring programs (IF they use it) to wait to take a reading if another program is currently reading data. But with all these variables and unknowns, and the simultaneous read problem, that is why using multiple monitoring programs at the same time does not work. Another question is what is the monitoring program reading for the "VCore"? Is it the VCore VID or the true VCore, which can be two different things. VID is what the processor cores request using their internal programmed tables. The true VCore is what is actually used by the processor. The two may be identical, but the VID will always be the higher of the two readings. They could be equal but the true VCore is usually at least a bit lower than the VID. Programs like Intel's Extreme Tuning Utility show the VID, which I know from experience using it. Ryzen Master also looks like it shows the VID, but I don't have as much experience with it. Any non-VID VCore reading is not a voltage reading that is simply translated from binary to decimal. It is data in a certain format that must be translated into the VCore value. This data is not necessarily the same for every processor generation/architecture. That's why we sometimes see crazy high VCore values like the 2.7V you saw from HWMonitor. Guess what your 1.325V VCore setting is multiplied by two and rounded up to one decimal place? It's 2.7V. HWMonitor is applying the wrong translation to the VCore data. CPU-Z version 1.79 made the same mistake. Version 1.79.1 fixed it.

very informative, thank you for the detailed explanation.

parsec wrote: Do you have all the CPU power saving options disabled in the UEFI/BIOS? Are you using the Windows High Performance Power Plan, or configured whatever power plan you use to have the Minimum Processor State set to 100%? If all of those things are not set that way, the VCore can change. Processors are designed to try to shift into a lower power usage state, and all these options enable them to do that. Lower power usage normally includes a lower VCore.

all cpu power saving ooptions are off on bios and i did set high performance in windows. i want constant 3.9ghz on cpu to test stability. once i determine my desired overclock and voltage, i torture test the system for a couple of hours to make sure it is stable.

parsec wrote: We assume the VCore reading is exact, but it isn't. The difference between 1.28V and 1.36V is 0.08V, 8/100 of a volt. Do we even know if the entire VCore monitoring chain, from monitoring chip to the software dealing with it, has that degree of accuracy? We like to believe it is, but that is faith. Ever see any specs about that? Just making the point. Checking our VCore is more complex and difficult than we want to believe, and in reality is rarely exact at any time. That's why Intel uses the VID, and most likely Ryzen Master too. Ryzen's VID is most likely closer to the true VCore than Intel's VID, given what I have seen.

thank you for the explanation.

phew, that took a while to read and understand throughly.

i appreciate the effort you took into answering my concerns.

now, i have been gaming heavily on this system for the past couple of days. so far i don't see any crazy jumps in cpu temperature, but i still do see jumps in voltages.

i'm going to give hwinfo64 a try as was suggested by some members here.

i'll report back with results.