+5v at 6.24v and VCCIO at 2.028 Peaks

adobepro

Member
Hi,

Could anyone let me know if what HWInfo could be an issue with the sensors?

I got on my +5v, +6.24v at one point and then for my VCCIO 2.028v as max values. I wasn't logging at the time, so I can't correlate what was happening during that recorded spike. If this is accurate, do you know what parts it may have damaged (CPU/Memory controller, etc...) This voltage increase, if it wasn't a sensor issue, would be PSU related, meaning, the MB wouldn't ask for more than +5v, it was a transient spike from the PSU to the MB?

I've started logging now, but I didn't see any spike on the +5v and the VCCIO remains at ~.948

My specs are:

X99-UDP3
6800K, default clock 3.4, Turbo at 3.7 ( I kept everything auto, except LLC, which I set to 1/Standard.)
750 PSU G3 EVGA
32 GB Crucial 2400

Any help would be greatly appreciated.

[attachment=2398]
 

Attachments

  • 900x900px-LL-7d13a8b7_vccio.png
    900x900px-LL-7d13a8b7_vccio.png
    333.9 KB · Views: 19
This looks to me like an invalid readout from the sensor, not a system failure. This can happen sometimes, especially if you're running multiple monitoring tools in parallel. Is this the case perhaps ?
 
Thanks for the reply. Good question. I may have launched HWMon and possibly coretemp too during this time. I noticed the +6.24 after 135 hours of monitoring, but I'm not sure when that happened and when I opened coretemp/hwmon (they were closed at the time I noticed this in HWInfo) I've closed them both down and I'm only using HWInfo now logged to file. I'm going to do the same workflow I did last week this week and see if I can reproduce it, but if not, maybe (hopefully) it was just that. I was getting worried because I've heard some really bad things about the X99 platform and just got it because I got a really good deal on it (replacing a SB 2600) and hoped those issues were ironed out since it's been over a few years since launch (like usb issues/vrm's overheating) I just bought a backup system with another X99 board (same board and same PSU, but this time, the 6850K for $299 at the Microcenter -- the 6850K was cheaper than the 6800K! I paid $320 for the 6800K)

Thanks again for your reply, I'll update this thread by this Sunday whether or not this happens again.

Just one quick question, for the VRIN value, should that be .6 above the highest individual vcore? As each core looks like it's getting a very specific voltage, all six cores vary, but none above 1.247. But while I get a avg VRIN of 1.847, it sometimes goes to 1.903 -- is that LLC kicking in? And does that mean, the most voltage hungry core is getting ~1.3 volts or is the extra voltage being using for cache memory or something else? Thanks again!
 
Martin said:
This looks to me like an invalid readout from the sensor, not a system failure. This can happen sometimes, especially if you're running multiple monitoring tools in parallel. Is this the case perhaps ?

Actually, it happened again, but this time, I got a new low for the 5v:

I opened the log in Excel and excluded the normal range of 5.01-5.04 and got this:

+5V [V]    PCH Core [V]    VCCIO [V]
0    1.056    0.948
6.24    1.056    2.028
3.84    1.056    0.948

Could the sensor be bad? That 6.24v is the exact peak voltage from last time, but 0 and 3.84 seem odd too.
 
VRIN is a different voltage. It's the only voltage supplied to CPUs with FIVR (Fully Integrated Voltage Regulator) and it's always ~1.8 V. I believe it has also a relatively high range.
This VRIN voltage is then converted to individual Vcore by the FIVR based on the actual need.
 
adobepro said:
Martin said:
This looks to me like an invalid readout from the sensor, not a system failure. This can happen sometimes, especially if you're running multiple monitoring tools in parallel. Is this the case perhaps ?

Actually, it happened again, but this time, I got a new low for the 5v:

I opened the log in Excel and excluded the normal range of 5.01-5.04 and got this:

+5V [V]    PCH Core [V]    VCCIO [V]
0    1.056    0.948
6.24    1.056    2.028
3.84    1.056    0.948

Could the sensor be bad? That 6.24v is the exact peak voltage from last time, but 0 and 3.84 seem odd too.

There seem to be multiple invalid readouts, also the 2.028 on VCCIO looks wrong. If you were not running other monitoring tools, it could be a sensor malfunction, or problem of readout.
 
adobepro said:
Martin said:
This looks to me like an invalid readout from the sensor, not a system failure. This can happen sometimes, especially if you're running multiple monitoring tools in parallel. Is this the case perhaps ?

Actually, it happened again, but this time, I got a new low for the 5v:

I opened the log in Excel and excluded the normal range of 5.01-5.04 and got this:

+5V [V]    PCH Core [V]    VCCIO [V]
0    1.056    0.948
6.24    1.056    2.028
3.84    1.056    0.948

Could the sensor be bad? That 6.24v is the exact peak voltage from last time, but 0 and 3.84 seem odd too.

Also, sorry to bug you, but is this similar to +5[V]

VR VIN (ATX +5V) [V]

For that sensor, I only have two values: 4.969 and 5.
 
Martin said:
VRIN is a different voltage. It's the only voltage supplied to CPUs with FIVR (Fully Integrated Voltage Regulator) and it's always ~1.8 V. I believe it has also a relatively high range.
This VRIN voltage is then converted to individual Vcore by the FIVR based on the actual need.

Thanks, I'll see if I can manually set the VRIN in the BIOS to 1.85 (it gets as high as 1.903) Gigabyte monitor tools by default sets the max at 1.9 so the alarm keeps going off. I thought it was my eyes, but it's not, the GB App Center shows "WARMING" on the alert but should be "WARNING"
 
Note that the GIGABYTE application might also be interfering with HWiNFO monitoring.
 
Martin said:
adobepro said:
Martin said:
This looks to me like an invalid readout from the sensor, not a system failure. This can happen sometimes, especially if you're running multiple monitoring tools in parallel. Is this the case perhaps ?

Actually, it happened again, but this time, I got a new low for the 5v:

I opened the log in Excel and excluded the normal range of 5.01-5.04 and got this:

+5V [V]    PCH Core [V]    VCCIO [V]
0    1.056    0.948
6.24    1.056    2.028
3.84    1.056    0.948

Could the sensor be bad? That 6.24v is the exact peak voltage from last time, but 0 and 3.84 seem odd too.

There seem to be multiple invalid readouts, also the 2.028 on VCCIO looks wrong. If you were not running other monitoring tools, it could be a sensor malfunction, or problem of readout.

Gotcha, no other sensors tools running and if it was a PSU issue, then I would expect to see a lot more +5 6.24 / fluctuations in the log? And possibly system instability? I'm not sure if the BIOS checks on that too and will shut down the machine on a spike like that -- it may have to last for a few seconds I guess rather than instant poll which could be inaccurate at any given poll. Sorry, just wondering if I should exchange the PSU with Amazon directly while I still can rather than submit and RMA to EVGA.
 
Martin said:
Note that the GIGABYTE application might also be interfering with HWiNFO monitoring.

UGH! Forgot about that! I started that last night and didn't close it. Thanks! I'll close that when I get home and will do a fresh log after that.
 
Hi Martin,

After turning off the GB app, for about 12 hours, the +5 and VCCIO look correct, thanks so much for your help!

Just one quick question for you, concerning vcore, I don't see an explicit vcore reading. I know it's different with FIVR, and VID is just a request from the CPU asking for a specific voltage, but is there a property in the HWiFNO sensor listings that let's us know what the actual voltage being given to the cores are (if it's even possible) or should we just deduct .6 from VRIN? Is it VIN0?
 
Only certain mainboards can monitor Vcore on CPUs with FIVR. And even in these cases the reported Vcore might not be reliable, especially in low-power states.
So lots of mainboard manufacturers report VID instead of Vcore on such systems (or later have moved from monitored Vcore to VID).
The problem is, that Vcore is buried inside the CPU and they don't have direct access to it as on systems without FIVR, where the mainboard supplies Vcore to CPU and thus this rail can be directly monitored.
 
Martin said:
Only certain mainboards can monitor Vcore on CPUs with FIVR. And even in these cases the reported Vcore might not be reliable, especially in low-power states.
So lots of mainboard manufacturers report VID instead of Vcore on such systems (or later have moved from monitored Vcore to VID).
The problem is, that Vcore is buried inside the CPU and they don't have direct access to it as on systems without FIVR, where the mainboard supplies Vcore to CPU and thus this rail can be directly monitored.

Hi Martin, thanks for the detailed reply, fully understand now, thank you!
 
Martin said:
Only certain mainboards can monitor Vcore on CPUs with FIVR. And even in these cases the reported Vcore might not be reliable, especially in low-power states.
So lots of mainboard manufacturers report VID instead of Vcore on such systems (or later have moved from monitored Vcore to VID).
The problem is, that Vcore is buried inside the CPU and they don't have direct access to it as on systems without FIVR, where the mainboard supplies Vcore to CPU and thus this rail can be directly monitored.

Hi Martin,

Hate to bug you again, but one last quick question -- concerning Broadwell-E (and Haswell since they both use fiVR), I read your reply in another post: "On Haswell and later, the CPU features a Fully Integrated Voltage Regulator (FIVR), which is supplied a constant voltage of ~1.8V only and then the FIVR manages the requested voltages to all rails inside the CPU" My questions are:

1 If you supply 1.82 VRIN (hard value, not "Auto") and set "Auto" for CPU Core Voltage, does the CPU determine from the given 1.82 VRIN what voltage to use for each core, based on the core's VID value (or VID curve, not sure how the curve works yet)?

2. If you set "Auto" for CPU Voltage, does the motherboard use the CPU VID values (based on a given clock frequency) or do some motherboards decide on their own what voltage to use based on frequency AND load?

3. If I don't use CPU Core Voltage "Auto", should I use the highest core VID as the CPU Core Voltage or should I use an average of all core as the vcore, e.g.
Reported VID 6850K:
#1 1.238
#2 1.227
#3 1.234
#4 1.243
#5 1.242
#6 1.236

Use 1.236 vcore?

4. Lastly, if I use the highest reported VID for vcore, in my case, 1.243, will fiVR use 1.243 for all cores or is fiVR smart enough to give each core it's requested VID if the voltage allowed is high enough, e.g., if you set 1.238 for vcore, the fiVR can't give 1.243 to core #4 so it will give it the max it can, which is 1.238, but it could give less to core #2, which has a VID of 1.227?

Thanks!!
 
The CPU's FIVR always decides what core voltage to use based on the request and it should not depend on exact value of VRIN.
For the other questions you might find better answers on some forums like www.overclock.net
 
Martin said:
The CPU's FIVR always decides what core voltage to use based on the request and it should not depend on exact value of VRIN.
For the other questions you might find better answers on some forums like www.overclock.net

Thanks for your help again Martin; ok, I'll try there and I'll call Intel directly, I'm not going to bother with calling Gigabyte, they are useless with support.
 
adobepro said:
Martin said:
The CPU's FIVR always decides what core voltage to use based on the request and it should not depend on exact value of VRIN.
For the other questions you might find better answers on some forums like www.overclock.net

Thanks for your help again Martin; ok, I'll try there and I'll call Intel directly, I'm not going to bother with calling Gigabyte, they are useless with support.

Just a quick update...Intel support is as about as helpful and useful as a hole in your head. The quoted the maximum safe voltage for the 6850K as 1.52. I  had the same issue with Intel a few years ago with the Intel 730 SSD when they said it had no cap to prevent data corruption in case of power loss. It did, went through a whole ordeal with Hardware Canuks to get their support staff corrected. The sad thing is, Intel still hasn't updated their ARK page, and it's been over 2 years as it still shows "Enhanced Power Loss Data Protection" as No.

http://ark.intel.com/products/81039/Intel-SSD-730-Series-480GB-2_5in-SATA-6Gbs-20nm-MLC

So sad that these people just don't care. Just in it for a paycheck.

Also, after a few days, my voltages are not spiking like they were being reported due to having other monitoring software running. I did get one random spike, but I figured out why, even though I closed the GB app, I forgot I set an alert, so the app was still polling in the background. After uninstalling the app, HWiNFO is running perfectly. Thanks again!
 
Back
Top