CPU Core Voltage (SVI2 TFN) or Core x VID or what?

[GLoBaLReBeL]

System . . .

AMD Ryzen 3700X
MSi Unify x570 Mobo
Cosair 3600 32GB Ram (2x16GB)
650 SeaSonic Titanium rated PS
other odds and ends

I've read through at least the last 8 recent pages in the forum and couldn't find anything on this so hoping someone can assist.

I am in the process of OC'n my 3700X and want to be sure that I am paying attention to the correct voltage readings in HWiNFo for the ACTUAL voltage the CPU is getting. In my BIOS I can set it to an all core clock OC, and set the VCore to the (AMD) recommend max voltage of 1.325. Once in windows I launch HWiNFo and start benching to see what Vdroop I get when pushing the system to the max. I want to know what reading should I be looking at to determine the actual voltage that the CPU is getting?

If I look at 'SVI2 TFN', it pretty much stays at 1.325, but if I focus on the 'Core x VID' I see the voltage drop to 1.2xx during all core workloads. If I want to get the most out of my all core OC, then I need to use LLC to help with Vdroop but I don't know which reading to base my choice off of. If I base it off of 'Core x VID', then I know I should start increasing my LLC modes up until I get it to stay stable at 1.325 under all core load in my 'Core x VID'. If I base it off the SVI2 TFN then I don't want to use LLC as it doesn't really drop below 1.325.

My thought process is...
(Turn off PBO, cool'N'quiet,C-States, etc as I am just doing all core OC and don't need any of this as I want it to act the exact same way at all times during use)
1. Set multiplier for CPU
2. Set Vcore to value (for me 1.325)
3. Launch Windows and HWiNFo
4. Start bench and look at numbers
5. If numbers drop below 1.325, then increase multiplier until unstable and once unstable increase LLC mode in BIOS and retest
Step 5 is where I need to know what voltage value/reading I should be looking at in order to ID the voltage flucuation change from the LLC mode change.

I apologize if this has been coverd, but I wasn't able to find it anywhere.

 

[Martin]

You should always rely on the "CPU Core Voltage (SVI2 TFN)", this is the most accurate voltage. VID values are only what the CPU requests from VRM.

 

[GLoBaLReBeL]

Wonderful! Thank you soo much for that clarification. Hopefully it helps some others as well!

 

[19arek93]

Hi Martin,
At first thank You for this great program.

I'm writing because I need little help understanding readings too.
For 3 days I'm fighting with my Gigabyte B450 Aorus Elite - newest BIOS and Ryzen 1600 AF (12nm).
Long story short - My PC wasn't dropping voltage at CPU in idle after OC using Pstates. Right now with clean, updated Windows 10 it is doing so, I think.
The problem i have is that Core #0-6 VID is fluctuating in range of ~0.4-1.35v(Pstate manually set), Vcore reading from Motherboard is acting same way, but SVI2 TFN it is not.

At this point I have no idea at what reading I'm supposed to look. I would be really grateful if You could clarify this for me.

Greetings!

 

[alxns]

@19arek93 Some BIOS auto settings will set the correct power saving options for low current idle (namely C-States, AMD cool'n'quiet and Power Supply Idle Current) but it depends on the board, how you set the manual Vcore, and which Windows power plan you use.

I wanted to open a new thread exactly regarding the SVI2 TFN sensor not dropping voltage at idle currents (regardless of the polling rate), because I've been wondering that myself. But I think this is just the right thread
If your motherboard Vcore reading shows this low voltage idle state, it is really happening. Measuring Vcore from the back of the socket with a multimeter reflects that.
The sampling interval from the SVI2 TFN sensor probably does not register the short idling voltage dips (or there's some capacitive magic), and the same way, the motherboard sensor probably does not show short bursts up to the requested voltage.

HWinfo motherboard Vcore and SVI2 TFN Vcore idling (for reference, polling rate is 2000 ms to have the low current idle state, and voltage is set at 1.200V in BIOS)


DMM back of socket idling. Note the short bursts close to 1.20V


Either way, idle power states voltage changes are happening too fast for both DMM and software readings. So an oscilloscope would help!

 

[VictorVG]

alxns

Colleague! Because the sensors of the motherboard control circuits use averaging due to integrating circuits with an unknown time constant, then they can miss short amplitude bursts, and the device you use is not a RMS voltmeter, but the time constant of the integrating circuit in its circuit is hardly shorter than 0,25 - 0,5 sec. usually digital voltmeters are built according to the double integration scheme because it provides a sufficiently small measurement error, but it also has a long cycle of a single measurement, so I would use a peak sensor from a Schottky input diode and a capacitor with a capacity of 5 - 10 nF - anyway, with most digital voltmeters at the input there is a source follower with a MOS transistor providing the input impedance of the circuit several tens of megohms, and to observe the presence of pulses I would use an oscilloscope with a passband of at least 100 MHz.

 

[alxns]

Oh natürlich! Thanks for the thorough explanation. That's why I'm saying, either way DMM or software don't show the reality. But the point is, if the software superIO Vcore reading fluctuates low, it's safe to say that the idle power state is working, even if the SVI2 TFN sensor's voltage doesn't appear so. The lower PPT reading is also a good indicator of working idle state (and low SMU core power)

 

[VictorVG]

As a developer, I can name the upper limits in which the deviation of the supply voltage is allowed - up to 2.5V <= ±1%, 2.5V - 5V ±5%, 5V - 12V - ±7%, 12V and above ±10% in the entire range of declared operating temperatures, currents and operating frequencies. When going beyond them, the operability and serviceability of the circuit is not guaranteed. This is primarily due to the technological variation in the parameters of semiconductor devices capable of reaching ±30% - ±40% within a single production batch, and this directly affects the percentage of production defects and the cost of finished products.

 

[craxton]

i noticed something VERY strange, VID voltage in hwinfo says 1.55v with Virtualization on with hyperV on (was trying to show a kid across the wires how to use bluestacks) but ive never noticed this before, after turning SVM back off in bios its went away and is now regulating again like it should. i will state never did the vcore or SVI2 voltage use or get near that voltage range. but its kinda strange as alot of readings just vanished in hwinfo, is this a bug. or known issue? didnt get screenshots but am going to retry this and see if the same thing happens again. once hyperv was turned on and virt. in windows features and the pc restarted nothing came up on my desktop like it didnt have nearly enough voltage. (r 5 5600x msi mpg gaming edge wifi) limiting pbo values 200 100 110 as thats about what my cpu likes for some odd reason any less on ppt and it hard crashes. anyhow ill edit this reply with some screenshots of before and after once im done.

as stated came back and shared the pics, i may have taken more than needed to illustrate what my claim is to what im seeing to show. and this is probably normal, although the biggest things being VID1.5? and that all 6 cores have disappeared entirely.

 

[Martin]

This is a known limitation of Hyper-V, the Hypervisor decides what parts of hardware are masked and virtualized or not. Applications cannot influence this.
As an alternative you might try the new Snapshot polling mode that should not be influenced by Hyper-V: https://www.hwinfo.com/forum/threads/hwinfo-v6-35-4310-beta-released.6847/post-27573

 

[craxton]

This is a known limitation of Hyper-V, the Hypervisor decides what parts of hardware are masked and virtualized or not. Applications cannot influence this.
As an alternative you might try the new Snapshot polling mode that should not be influenced by Hyper-V: https://www.hwinfo.com/forum/threads/hwinfo-v6-35-4310-beta-released.6847/post-27573

well, considering when i turned on hypervisor it instantly started causing issues like when your overclocking and trying to undervolt the cpu my pc started doing stuff like that, or when your ram overclock isnt the least bit stable. checked my boot drive windows found no errors, and the only thing i changed was hypervisor. I thank you for the link, but no thank you until amd fixes this agesa code. cant say for sure its AMD or windows directly but something for certain was wrong. thought i had some real serious issue as i could NOT get my desktop to load. i could login but the desktop main screen just kept being blank with my background like the entire file explorer system was crashing?

needless to say i finally got it to allow me to turn off hyperV or i assume it did as it said "installing updates" when i finally got it to restart and boot back up. unless, hypervisor hits HARD on fclk being 2000? idk, thats the only issue ive had (tested my ram oc extensively with y-cruncher, occt, TM5 anta777 100% cycle x5 loops, and HCI overnight.) anyhow thanks but for now that wont be needed.