# [OFFICIAL] HWiNFO/32/64 Thread



## fommof

Hi Martin, i LOVE your work man, i am a totally monitoring/logging freak and right now your apps (both the 32 and 64 version) are #1 in my list (i also have a dozen monitoring/log apps, some of them are not free of charge).









Great work!!!

The only thing that makes me still use other similar apps at the time being is just the format of the logs. Personally, it would make my life easier if the units (C, V, %, W etc) got written only at the titles. Most of the times i use these logs to create graphs using excel. The way it is right now i have first to replace all the units to empty space first, then create and process the graphs otherwise they get recognized as text.

So first thing i have to do is take this for instance:

Code:



Code:


Physical Memory Available    Physical Memory Load    Core #0 VID     Core #1 VID     Core #0 Clock   Core #1 Clock   Core #0 Usage
2174 MB 29.0 %  0.981 V 0.981 V 1596.4 MHz      1596.4 MHz      0.0 %
2172 MB 29.0 %  0.976 V 0.981 V 1596.3 MHz      1596.3 MHz      3.8 %
2172 MB 29.0 %  0.981 V 0.976 V 1596.4 MHz      1596.4 MHz      2.8 %
2172 MB 29.0 %  0.966 V 1.241 V 1596.4 MHz      2394.5 MHz      6.8 %
2172 MB 29.0 %  0.966 V 0.966 V 1596.5 MHz      1596.5 MHz      4.8 %

and make it look like this:

Code:



Code:


Physical Memory Available MB Physical Memory Load %  Core #0 VID V Core #1 VID V   Core #0 Clock Mhz Core #1 Clock Mhz       Core #0 Usage %
2174    29.0    0.981   0.981   1596.4  1596.4  0.0
2172    29.0    0.976   0.981   1596.3  1596.3  3.8
2172    29.0    0.981   0.976   1596.4  1596.4  2.8
2172    29.0    0.966   1.241   1596.4  2394.5  6.8
2172    29.0    0.966   0.966   1596.5  1596.5  4.8

Also it would be great if the app could figure out the localization to use the "right" symbols according to the regional settings. For instance, here in Greece, the decimal symbol is the comma ",". In the logs the decimal symbol is the dot ".". Excel doesn't recognize for instance that 1.12V is a number because according to my regional settings the decimal symbol should be the comma. So in order to make the charts i have to do another "replace all " otherwise all the numbers with a dot decimal symbol are being considered by excel as text...

So after this replace it would now look like this:

Code:



Code:


Physical Memory Available MB Physical Memory Load %  Core #0 VID V Core #1 VID V   Core #0 Clock Mhz Core #1 Clock Mhz       Core #0 Usage %
2174    29,0    0,981   0,981   1596,4  1596.4  0,0
2172    29,0    0,976   0,981   1596,3  1596.3  3,8
2172    29,0    0,981   0,976   1596,4  1596.4  2,8
2172    29,0    0,966   1,241   1596,4  2394.5  6,8
2172    29,0    0,966   0,966   1596,5  1596.5  4,8

...and at this point all the figures that have the decimal symbol are being recognized by excel as numbers (and not text) and it's ready to get transformed to a chart/graph...

Since you log to comma delimited format it can't be done with this delimiter (your delimiter conflicts with my decimal symbol) so maybe a more generic delimiter (like the tab) or an option to choose which ever you want would be the resolution.

Still, no worries, even if you don't do any of these it would still be my #1 monitoring prog, great stuff and thank you very much for your time and effort and the fact that you provide it for free.


----------



## Mumak

I like both ideas, so I'll try to implement them.
The units written only at the 1st line (header) shoud be easy, regional settings might be a bit more tricky, but I'll see what I can do.
Quote:


> Originally Posted by *fommof*
> 
> Hi Martin, i LOVE your work man, i am a totally monitoring/logging freak and right now your apps (both the 32 and 64 version) are #1 in my list (i also have a dozen monitoring/log apps, some of them are not free of charge).
> 
> 
> 
> 
> 
> 
> 
> 
> Great work!!!
> The only thing that makes me still use other similar apps at the time being is just the format of the logs. Personally, it would make my life easier if the units (C, V, %, W etc) got written only at the titles. Most of the times i use these logs to create graphs using excel. The way it is right now i have first to replace all the units to empty space first, then create and process the graphs otherwise they get recognized as text.
> So first thing i have to do is take this for instance:
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> Physical Memory Available    Physical Memory Load    Core #0 VID     Core #1 VID     Core #0 Clock   Core #1 Clock   Core #0 Usage
> 2174 MB 29.0 %  0.981 V 0.981 V 1596.4 MHz      1596.4 MHz      0.0 %
> 2172 MB 29.0 %  0.976 V 0.981 V 1596.3 MHz      1596.3 MHz      3.8 %
> 2172 MB 29.0 %  0.981 V 0.976 V 1596.4 MHz      1596.4 MHz      2.8 %
> 2172 MB 29.0 %  0.966 V 1.241 V 1596.4 MHz      2394.5 MHz      6.8 %
> 2172 MB 29.0 %  0.966 V 0.966 V 1596.5 MHz      1596.5 MHz      4.8 %
> 
> and make it look like this:
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> Physical Memory Available MB Physical Memory Load %  Core #0 VID V Core #1 VID V   Core #0 Clock Mhz Core #1 Clock Mhz       Core #0 Usage %
> 2174    29.0    0.981   0.981   1596.4  1596.4  0.0
> 2172    29.0    0.976   0.981   1596.3  1596.3  3.8
> 2172    29.0    0.981   0.976   1596.4  1596.4  2.8
> 2172    29.0    0.966   1.241   1596.4  2394.5  6.8
> 2172    29.0    0.966   0.966   1596.5  1596.5  4.8
> 
> Also it would be great if the app could figure out the localization to use the "right" symbols according to the regional settings. For instance, here in Greece, the decimal symbol is the comma ",". In the logs the decimal symbol is the dot ".". Excel doesn't recognize for instance that 1.12V is a number because according to my regional settings the decimal symbol should be the comma. So in order to make the charts i have to do another "replace all " otherwise all the numbers with a dot decimal symbol are being considered by excel as text...
> So after this replace it would now look like this:
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> Physical Memory Available MB Physical Memory Load %  Core #0 VID V Core #1 VID V   Core #0 Clock Mhz Core #1 Clock Mhz       Core #0 Usage %
> 2174    29,0    0,981   0,981   1596,4  1596.4  0,0
> 2172    29,0    0,976   0,981   1596,3  1596.3  3,8
> 2172    29,0    0,981   0,976   1596,4  1596.4  2,8
> 2172    29,0    0,966   1,241   1596,4  2394.5  6,8
> 2172    29,0    0,966   0,966   1596,5  1596.5  4,8
> 
> ...and at this point all the figures that have the decimal symbol are being recognized by excel as numbers (and not text) and it's ready to get transformed to a chart/graph...
> Since you log to comma delimited format it can't be done with this delimiter (your delimiter conflicts with my decimal symbol) so maybe a more generic delimiter (like the tab) or an option to choose which ever you want would be the resolution.
> Still, no worries, even if you don't do any of these it would still be my #1 monitoring prog, great stuff and thank you very much for your time and effort and the fact that you provide it for free.


----------



## fommof

Thank you sir, +infinite rep!


----------



## Mumak

I have just released v3.94-1560 which (besides other improvements like enhanced support of GTX 680, EVGA and ASUS 7-series mobos) logs sensor values without the units for better import.
The decimal separator based on regional settings might be implemented later, because this requires a bit more work.


----------



## Arni90

I have noticed some stuttering in games when running HWiNFO64, but it fixed itself when I disabled a lot of measuring values I'm not interested in knowing the value of. I'm not really sure what value it is, but a lot of people have this problem so I think it would be a good idea to look into it. I have a hunch it may be GPU usage, but I couldn't get it to trigger on my system.

Otherwise it's a great program!


----------



## fommof

Downloaded it, tested it, GREAT stuff, thank you very much sir!









Now i only have to do one replace ("." to ",") and i am ready to go!!!


----------



## Mumak

Yes, this can happen and depends on mainboard used - more precisely sensors. Some of them require quite much time/resources to read a value from them. Especially "EC" or SMART sensors seem to exhibit such issue. Unfortunately this is because of how the sensors were designed, so the best workaround is as you mention - disable monitoring of these sensors. I have decided to keep them despite this fact, because I think it's better to read more values and if there are issues, it can be 'fixed'. Let's hope the vendors will become aware of this problem and some day they make a better design.
You might also check this thread on HWiNFO forum for more known issues and workarounds:
http://www.hwinfo.com/forum/Thread-IMPORTANT-Known-Issues
Quote:


> Originally Posted by *Arni90*
> 
> I have noticed some stuttering in games when running HWiNFO64, but it fixed itself when I disabled a lot of measuring values I'm not interested in knowing the value of. I'm not really sure what value it is, but a lot of people have this problem so I think it would be a good idea to look into it. I have a hunch it may be GPU usage, but I couldn't get it to trigger on my system.
> Otherwise it's a great program!


----------



## Arni90

On my sig rig it was SMART monitoring, thanks for letting me know so I don't have to configure the program without knowing what to disable


----------



## Mumak

In case of SMART causing such lag, this is a problem of the storage driver. Some versions of Intel RST drivers are know to cause such (and some other) issues. Intel is aware of this, but IDK when they will fix this.
Quote:


> Originally Posted by *Arni90*
> 
> On my sig rig it was SMART monitoring, thanks for letting me know so I don't have to configure the program without knowing what to disable


----------



## K62-RIG

HWinfo is absolutely brilliant. Best monitoring tool I have come across.


----------



## Mumak

Thanks


----------



## ACHILEE5

Quote:


> Originally Posted by *Mumak*
> 
> Thanks


Can this be used with the LCD display on a G15 keyboard


----------



## Mumak

Yes. Just make sure you have the LG LCD software running, then open Sensors -> Configure and select which values to show on LCD and their positions.
Alternatively you can use LCDHost (later versions have support of HWiNFO) for an even better experience.
Quote:


> Originally Posted by *ACHILEE5*
> 
> Can this be used with the LCD display on a G15 keyboard


----------



## ACHILEE5

Quote:


> Originally Posted by *Mumak*
> 
> Yes. Just make sure you have the LG LCD software running, then open Sensors -> Configure and select which values to show on LCD and their positions.
> Alternatively you can use LCDHost (later versions have support of HWiNFO) for an even better experience.


Nice one








I'll look into it


----------



## Stu-Crossfire

Great to have you here mate, I use your monitor every day of my life and really love it.


----------



## FromUndaChz

+Rep buddy, love this program!

This feature rules:


----------



## Derp

The max clock speed of my CPU is all over the place in HWiNFO after playing a game. The highest the clock speed should ever get is 3507 MHz (167 x 21) which is my Prime95 blend/IBT/HCI stable overclock. As you can see HWiNFO shows that some of the cores are clocking higher, one of them at 4271 MHz.











Tmonitor shows the processor's correct idle and load clock speeds without the spikes that HWiNFO displayed.


----------



## Mumak

I'm aware of this issue happening sometimes on certain CPUs. Which CPU do you have, is that the Core i7 920 ?
Quote:


> Originally Posted by *Derp*
> 
> The max clock speed of my CPU is all over the place in HWiNFO after playing a game. The highest the clock speed should ever get is 3507 MHz (167 x 21) which is my Prime95 blend/IBT/HCI stable overclock. As you can see HWiNFO shows that some of the cores are clocking higher, one of them at 4271 MHz.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Tmonitor shows the processor's correct idle and load clock speeds without the spikes that HWiNFO displayed.


----------



## Derp

Quote:


> Originally Posted by *Mumak*
> 
> I'm aware of this issue happening sometimes on certain CPUs. Which CPU do you have, is that the Core i7 920 ?


Yes, i7 920 C0.


----------



## Mumak

I have this issue in my to-do list..


----------



## spinejam

Thanks! Use it every day!


----------



## John-117

Like the program a lot. But can someone help me with something I can't understand. In sensor mode, one of the first things listed is:
Core #0 VID ... Core #3 VID. This value goes from 1.001V to 1.401V, depending on the clock speed and voltage. But it does not really match the Vcore set at the bios.
If I enable LLC, idle Vcore stays for example at 1.344V, but Core VID drops to 1.004V on all cores.
With LLC disabled and voltage offset enabled, idle Vcore is 0.960V, Core VID is 1.004V.
Same thing happens with another system with an AMD processor.

So, what is core vid, and should I care more about this value when overclocking?
With my 2600K, under load, I can see the Vcore at 1.32V and core VID at 1.365V.


----------



## peterbazooka

Love this program and have been using for awhile now. Thought you might be interested to know that anandtech mentions using it to log cpu and gpu speeds recently and since anandtech are god (IMHO) in testing I would take that as high praise









http://www.anandtech.com/show/5878/mobile-ivy-bridge-hd-4000-investigation-realtime-igpu-clocks-on-ulv-vs-quadcore

Keep up the good work!


----------



## Mumak

The VID value reported is the voltage level which the CPU requests from Voltage Regulator (VR). Vcore on the other hand is the real measured CPU voltage, so you should more care about the Vcore value. If your mainboard features a Digital PWM VR, then HWiNFO should be able to report value measured/reported straight by the VR too.
Quote:


> Originally Posted by *John-117*
> 
> Like the program a lot. But can someone help me with something I can't understand. In sensor mode, one of the first things listed is:
> Core #0 VID ... Core #3 VID. This value goes from 1.001V to 1.401V, depending on the clock speed and voltage. But it does not really match the Vcore set at the bios.
> If I enable LLC, idle Vcore stays for example at 1.344V, but Core VID drops to 1.004V on all cores.
> With LLC disabled and voltage offset enabled, idle Vcore is 0.960V, Core VID is 1.004V.
> Same thing happens with another system with an AMD processor.
> So, what is core vid, and should I care more about this value when overclocking?
> With my 2600K, under load, I can see the Vcore at 1.32V and core VID at 1.365V.


----------



## Mumak

No, I didn't know that








Thanks for the info. I'm working hard to improve HWiNFO every day








Quote:


> Originally Posted by *peterbazooka*
> 
> Love this program and have been using for awhile now. Thought you might be interested to know that anandtech mentions using it to log cpu and gpu speeds recently and since anandtech are god (IMHO) in testing I would take that as high praise
> 
> 
> 
> 
> 
> 
> 
> 
> http://www.anandtech.com/show/5878/mobile-ivy-bridge-hd-4000-investigation-realtime-igpu-clocks-on-ulv-vs-quadcore
> Keep up the good work!


----------



## dafour

Nice to find this thread,i'm also a big fan of your software.
I do have the slowdown bug in the RAGE engine,i noticed it in GTA IV and now Max Payne 3 too.


----------



## Mumak

Try to disable sensors (right-click and Disable Monitoring). Some of them might cause a higher load or latency, especially the EC and SMART ones. More info here: http://www.hwinfo.com/forum/Thread-IMPORTANT-Known-Issues
Quote:


> Originally Posted by *dafour*
> 
> Nice to find this thread,i'm also a big fan of your software.
> I do have the slowdown bug in the RAGE engine,i noticed it in GTA IV and now Max Payne 3 too.


----------



## Mumak

*HWiNFOMonitor v1.0 released !*

HWiNFOMonitor is an advanced Sidebar Gadget which allows to display and monitor any HWiNFO sensor data.
It's fully customizable and can display values in text, graphs or bars. SideShow is supported as well.










Download HERE


----------



## fommof

Thanks man!

I'll try it when i get back home!


----------



## Warrax22

I've been using HWiNFO since the DOS days! it's a great utility to have and thanks for keeping it up after all these years!


----------



## psyside

Can anyone tell me do i got this right? is the enabled readouts for the actual physical cores and not threads?


----------



## Mumak

Thread #1 is the Hyperthreading logical unit, and it shares the resources with Thread #0 of the same core.


----------



## psyside

I'm not sure if i understand you right, your saying the cores with 0 in the name are the physical right?

Can you change this to threads/cores in the future release so it can be easy to tell apart? thanks









For example.

Core 1
Core 1 thread
core 2
core 2 thread etc









Also what is On Demand clock modulation?

Thanks again


----------



## Mumak

Both Thread #0 and Thread #1 under a particular core # share the same core's resources, so they together represent the core. The Thread #1 is usually called a "Hyperthreading Unit".
On Demand Clock Modulation is a method to reduce performance by inserting duty cycles between CPU clocks. This method is used on some systems (certain notebook manufacturers use this practice) to reduce performance/power when the CPU is overheating.


----------



## freemason

Hey guys, i recently downloaded this program to check my CPU usage when i am gaming. However, i am experiencing difficulty working this program. I have MSI afterburner and the Riva tuner statistics server installed. However, when i go to HWiNFO64 and press configure and i go under RIVA tuner OSD, i cannot click the options. The boxes "Show" and "Label" are shaded grey. I re installed MSI afterburner and HWiNFO but nothing worked. Please help


----------



## Mumak

Please make sure to use the latest HWiNFO version, because there have been updates to this recently.
Also if it doesn't work, try to start the OSD Server prior to launching HWiNFO (this order shouldn't be required with latest HWiNFO versions though).
Quote:


> Originally Posted by *freemason*
> 
> Hey guys, i recently downloaded this program to check my CPU usage when i am gaming. However, i am experiencing difficulty working this program. I have MSI afterburner and the Riva tuner statistics server installed. However, when i go to HWiNFO64 and press configure and i go under RIVA tuner OSD, i cannot click the options. The boxes "Show" and "Label" are shaded grey. I re installed MSI afterburner and HWiNFO but nothing worked. Please help


----------



## freemason

Hey thanks for the reply, i had already the updated version. I updated it to the beta but that still didnt work. I also tried running the OSD server before turning on HWiNFO but it still wouldnt let me change the options.


----------



## Mumak

And have you chosen (selected) a sensor entry from the above list before trying to assign it to RTSS ? Just to make sure...
Please attach a screenshot so I can see it exactly.
Quote:


> Originally Posted by *freemason*
> 
> Hey thanks for the reply, i had already the updated version. I updated it to the beta but that still didnt work. I also tried running the OSD server before turning on HWiNFO but it still wouldnt let me change the options.


----------



## freemason

My good sir, i am a complete idiot. I did not select the sensor entry once i was in the configure window. Thank you!!!


----------



## Mumak

No problem







I guess I should make the interface more intuitive


----------



## Belial

Great utility!

However, I have a request -

Please, make it so you can reset the graph. I'm often changing settings on many things, tweaking this thing and that thing, so it's a bit of a pain when I have to close out the many graphs I may have pulled up, and then open them back up again.

It'd also be nice if the time settings could be tweaked around. I can't exactly tell how much time has passed or what I'm looking at unless I can tell a certain spike/dip occurred at a certain time.

and it'd be neat if i could pull up a graph, and it already has the last X minutes or whatever, already loaded up on it. Maybe I could scroll, and look back further in time, or et cetera. This would be in the times I maybe didnt have the foresight to pull the graphs up, but if, say, something happened (like my driver crashed), I could maybe look at the graph to see usage stats or something. I dont know if this is possible but just saying... i mean with logging on wouldnt it then be at least possible?

and custom graph profiles. Like I just hit "CPU Graph Set 1" and my core 0, 1, 2, 3, total, vcore, graphs all showed up, or "Gaming set up 1" and core 0, 1, gpu bus load, gpu memory usage, and gpu temp showed up. Instead of having to click every graph :X

Finally, fps is not listed. I really, really, really, really wish I could pull up a graph of FPS stats like I could with everything else. This is the one reason why this program, for me, does not replace ... fraps or something that i dont have but am looking for. The thread about 'OSD using RTSS+HWinfo' is why I looked into this and got it (at the moment, what I'm doing to look at fps use is watching my saved stream videos and just looking at how the numbers change for fps, for most stats I'm just looking at min/max, but fps isnt like that).

Thanks though. cool program, with the OSD.


----------



## Mumak

I'll note your suggestions for Graph improvements and put them into my to-do list (which is BTW already quite large ;-))
There are currently some addons for HWiNFO available (like Gadgets) which offer more customizable and fancy output. If there would be others interested in interfacing with HWiNFO for any kinds of extensions, I'll gladly assist them.
As for the FPS, I'm sorry, but there is currently no plan for adding this feature. It's available in the RTSS and can be combined with any HWiNFO outputs.


----------



## Mumak

Check the new Beta build released recently for a few updates to the graphs


----------



## mark_thaddeus

I just saw the 409_1815 Beta but the direct link from your site is very slow.

My download is saying that it will take 30 minutes to download a 2.3MB file.









Is there another link or mirror that is faster? I download in all the other sites and I never have a problem with downloading anything, even tried speedtest to confirm my side isn't at fault.

Can you help? Thanks in advance!


----------



## Mumak

I have checked the download and don't see a problem there. You might check again if it persists, or try alternative mirrors which are listed in the same download table - Softpedia has a working mirror here: http://www.softpedia.com/progDownload/HWiNFO64-Download-189486.html and http://www.softpedia.com/progDownload/HWiNFO-Download-5006.html
Computerbase is also mirroring the latest beta builds here: http://www.computerbase.de/downloads/system/hwinfo/
Quote:


> Originally Posted by *mark_thaddeus*
> 
> I just saw the 409_1815 Beta but the direct link from your site is very slow.
> My download is saying that it will take 30 minutes to download a 2.3MB file.
> 
> 
> 
> 
> 
> 
> 
> 
> Is there another link or mirror that is faster? I download in all the other sites and I never have a problem with downloading anything, even tried speedtest to confirm my side isn't at fault.
> Can you help? Thanks in advance!


----------



## mark_thaddeus

+ Rep - I used the softpedia link and got it there, thanks!


----------



## Belial

I have been using your program religiously for a while now. I loved that you added the feature where, when you pull up graphs and put them somewhere, and then save&exit, it'll save them there and so when you start up, those graphs will always pop up, in the right spots (this has been on for a few months, just saying thanks now).

So far I've been able to get rid of a bunch of programs because yours is so inclusive. However, I still have to use coretemp. Could you please include the following feature when you get a chance:

- Turn Off/Sleep/Hibernate/Execute Program like CoreTemp on X Temp (but you could make it do X anything for X value on X value! Shutdown on NB temp if you have bad nb cooling! Shutdown screen if GPU gets too hot!)

I'm also still interested in the graph's being able to display time. You've added a lot of stuff to the graphs, very cool, but I still can't exactly tell how much time they represent.


----------



## Mumak

HWiNFO currently supports Alarms which allow you to execute any application (and specify arguments for it) when any of the measured values reach a threshold defined. This way you should be able to perform the above mentioned actions. For example using the "shutdown.exe" tool in Windows with "-s" switch for a shutdown action.
I'll put the time scale + Y-axis info into the TODO list.


----------



## Belial

I'm not sure I follow exactly how to do that.

In CMD I can type in -shutdown -s and it'll say "windows will shut down in a minute". If I type in "-shutdown -s -t 0" it'll shut down immediately. I'm not sure how to make that an application to be run by hwinfo.

I feel like an idiot asking this. I searched, i'm not really sure what i'm searching for though. how to shutdown through command, doesnt say how to list it as a program :X If I type 'shutdown.exe' in searchm, i find i get a pop-up saying "RTShutdown" and then I hit it, it says "Realtemp alarm window" something and it shuts down but not immediately, takes a second.


----------



## Mumak

No problem







Open the Configure screen of HWiNFO / Sensors. Then select the sensor value you want to watch and on which you want to base the alert. Enable alerting for this value, choose the threshold and enable "Run a Program". Then choose the program you want to run - in your case it's the "shutdown.exe" which can be located in the "C:\WINDOWS\system32\" folder. Then put the argument (in your case "-s -t 0") into the Program Arguments field. That should be it








Quote:


> Originally Posted by *Belial*
> 
> I'm not sure I follow exactly how to do that.
> 
> In CMD I can type in -shutdown -s and it'll say "windows will shut down in a minute". If I type in "-shutdown -s -t 0" it'll shut down immediately. I'm not sure how to make that an application to be run by hwinfo.
> 
> I feel like an idiot asking this. I searched, i'm not really sure what i'm searching for though. how to shutdown through command, doesnt say how to list it as a program :X If I type 'shutdown.exe' in searchm, i find i get a pop-up saying "RTShutdown" and then I hit it, it says "Realtemp alarm window" something and it shuts down but not immediately, takes a second.


----------



## sKratch

Is there a way to get it to show my VRAM temps? They won't show up in any program..


----------



## Mumak

This is only possible if the GPU has a sensor measuring this. Since you say no program displays such values, I believe your GPU doesn't have such sensor.
Quote:


> Originally Posted by *sKratch*
> 
> Is there a way to get it to show my VRAM temps? They won't show up in any program..


----------



## sKratch

Quote:


> Originally Posted by *Mumak*
> 
> This is only possible if the GPU has a sensor measuring this. Since you say no program displays such values, I believe your GPU doesn't have such sensor.


So it's true, only som 7970's have a VRAM thermal node.


----------



## Mumak

Not just 7970, some others too, but mostly the high-end models.
Quote:


> Originally Posted by *sKratch*
> 
> So it's true, only som 7970's have a VRAM thermal node.


----------



## fommof

Hi Mumak, still using your prog, still love it!!!

One little thing...my GTX580 gone south and for the time being i use a Sapphire HD5450. The problem is that when i start HWInfo it scans 40 or so sensors of the HD5450 and it takes a lot of time to open eventually (i always set your prog start automatically at windows boot, the only exception is now with the bloody HD5450).

Is there any way to make HWInfo not to bother with the HD5450? I have already disabled monitoring of the HD5450 but that didn't take care of my prob.

Thanks in advance!


----------



## Mumak

Indeed, the long startup time is because HWiNFO is scanning the GPU I2C bus to check if there are any additional I2C sensors. However, only certain (mostly high-end) GPUs have such sensors (like ADT, MAX, CHL, UPI, etc). So in your case I suggest to disable the entire "*GPU I2C Support"* in HWiNFO / Configure / SMBus/I2C tab. That will considerably speed-up the starting time









For those whose GPUs might have such additional I2C sensors and want to improve the start-up time, they might use the "*GPU I2C Bus Exclusion*" boxes to disable certain GPU I2C buses. Since it's not possible to make a general recommendation on which buses to disable, I suggest to try possible combination and disable those which don't cause loosing those additional GPU sensors.

Note, that selecting all boxes in "*GPU I2C Bus Exclusion*" is same to disabling the entire GPU I2C Support.

I hope this is not too complicated, just let me know if you have any questions








Quote:


> Originally Posted by *fommof*
> 
> Hi Mumak, still using your prog, still love it!!!
> 
> One little thing...my GTX580 gone south and for the time being i use a Sapphire HD5450. The problem is that when i start HWInfo it scans 40 or so sensors of the HD5450 and it takes a lot of time to open eventually (i always set your prog start automatically at windows boot, the only exception is now with the bloody HD5450).
> 
> Is there any way to make HWInfo not to bother with the HD5450? I have already disabled monitoring of the HD5450 but that didn't take care of my prob.
> 
> Thanks in advance!


----------



## fommof

Thank you very much sir!


----------



## fommof

Mister Mumak, just downloaded the latest non-beta version...GREAT stuff!!! I love the addition of the "Average" column at the Sensors panel.









Maybe at some future version you could add a Runtime field that would show for how many days/hours/minutes/seconds the HWinfo is running? (CoreTemp style, lol)

By having a way to show the runtime of the HWinfo, the average values becomes even more meaningful and it's handy when you screen-capture the HWinfo...









EXCELLENT work as always!!!


----------



## fommof

Quote:


> Originally Posted by *fommof*
> 
> Maybe at some future version you could add a Runtime field that would show for how many days/hours/minutes/seconds the HWinfo is running? (CoreTemp style, lol)


For instance, 3 possible locations...


----------



## Mumak

This is a good idea.. When you press Reset Values, should this counter be reset too ?


----------



## fommof

Quote:


> Originally Posted by *Mumak*
> 
> This is a good idea.. When you press Reset Values, should this counter be reset too ?


Good question actually...

IMHO, the Uptime/Runtime value should be reset as well, otherwise the average values won't say the whole truth...

So again, imho and the way i see it, the Uptime/Runtime value will get initialized everytime the prog starts from scratch or when pressing the "Reset Values".

PS: even if the Uptime/Runtime don't get reset i personally wouldn't have a prob to close/re-open HWinfo to reset it and start gathering min, max and average data for a new session, so either way the Uptime/Runtime opion would be very useful to me (and not ony to me i hope)...


----------



## Mumak

OK, will be added in the next build (below the Reset Min/Max button)


----------



## fommof

Quote:


> Originally Posted by *Mumak*
> 
> OK, will be added in the next build (below the Reset Min/Max button)


Thanks a lot Martin!!!


----------



## Belial

Why is it that the graph of Physical Ram load is always on the bottom? I can't get it to stick on top of other graphcs (primarly, the core utilization graphs). I save it, save and close, it won't stay on top. And now the 'autostart' option isnt saving either.


----------



## Belial

When I set graphs, I noticed that the further down the list ones go on top, instead of staying in the top/bottom orientation as saved


----------



## Mumak

I need more details to check this. Could you please attach a screenshot explaining the problem? I also might need the registry content of HKEY_CURRENT_USER\Software\HWiNFO32/64.
Do you have the option "Remember preferences" enabled in Configure ?


----------



## fommof

Just installed the last version, thanks for the "timer" Martin!!!


----------



## Belial

Yes, remember preferences is saved.



http://imgur.com/1tEy8Dn


I noticed actually, that a graph will always stack on top of another graph if it's lower on the list. So for example, RAM Load will ALWAYS be below Core usage or GPU usage. That big graph on the bottom was virtual load, you can see it lays on the bottom of everything (i had saved it as to be on top).

I didn't realize this at first, because as you can see by how I set up my graphs with the cores... all of them fit neatly, except RAm load. But as you can see, 0:0 is below 0:1 is below 1:0 is below cores 1:0 which is below 1:1 etc etc... and physical ram is the only one in my set-up that isn't lower down the list.

Anyways, I had a question. What exactly is CPU Package Power and IA Cores power? What's the difference? Is my CPU wattage, or power consumption, Package + IA cores? So is my CPU consuming at most 85+79=164w? Or is it just 85, or 79? And what about on the IRF reading, all those powers... what is VR VOUT, VR VIN, Current, Power POUT and Power Input? I'm assuming power input is the power being requested by the vrm and then power POUT is how much the cpu is actually consuming? I'm a bit confused, what is the figure people always talk about? Or is my cpu basically requesting powerinput = 182w at max load?

Just a bit confused. Like VR Vout is 1.506, then I have a vcore of 1.5v at most, and my DMM says I use at most 1.5v, so what is vr vout?

Thanks.

as for the regedit readings... which one? There's quite a few of them, I'm not sure which registry you want of the multiple hwinfo registries and how i"d even convey the information to you. If you want I can type it out, it'd take a bit though but whatever you need.


----------



## Mumak

The graphs are displayed in the order as seen in the Sensors window, so when you're overlapping them, you need to place them in the right order. So the next one is placed on top of the previous one.

The CPU Package Power is the total power consumed by the entire chip, so it should be equal to CPU Cores + GT Cores + System Agent powers.

The IRF IR3567 is the digital PWM VR controller, so all those values determine the VR state. On some mainboards there can be multiple such chips, on yours it seems to control the CPU core voltage. So the VR VOUT is the voltage sent to CPU (Vcore). Input values like VIN (+12V), Power Input are on the input side of the VR, output is what goes to the CPU.


----------



## Belial

Thanks for taking the time to respond, but I'm not totally getting it yet.

So you say CPU Package Power is CPU power consumption, that's the big figure we all are interested in. So my CPU is basically consuming 85w? That is all the power consumption of my [email protected] CPU? I mean that seems too low, ivy bridge i7-3770k consumes more like just shy of 150w I thought ( source: http://forums.tweaktown.com/gigabyte/48359-ivy-bridge-overclocking-guide-extreme-ln2-section-guide-included.html), if not more with extreme overclocks (like mine).

So then what is IA Cores Power? As I understand, IA is a sensor placed in the cores (source: http://forums.anandtech.com/showthread.php?t=2247324). Or is the IA Cores just a different sensor, placed somewhere differently, reading the same thing? So basically, one of these sensors is 'more accurate' about my true wattage, or power consumption? So my true power consumption is not 85w, and it may not be 79w, but it's somewhere around there, something I can understand based on these two readings?

I actually hid quite a few values on my board, but there's IRF IR3567 (as pictured), IRF 3567 (IGPU), IRF 3570 (VDIMM), and IRF IR3570 (CPU VCCIO/VTT) with the same readings but for the igpu, vdimm, and vtt respectively (with vr vout, vr vin, current, pout, input as the one pictured).

But so why is there such a huge discrepancy between the wattage being sent to my CPU (Power (POUT)) as being 165w, and CPU Package Power? CPU Package Power + IA Cores seems more close to that number. Actually it's almost exactly the same number (both are 165, just the addition of both is 165.362).

So when people, or whatever, or sites, say how much power their CPU is consuming, I'm assuming they are referring to Power (Input) because that would be like the number change you would see if you used a Kill-O-Watt at the wall. Because even though my CPU is only pulling 165w, or 85w or whatever, the VRM is pulling 182w. So from the wall, the user would see on the Kill-O-Watt, a power consumption of 182w + power consumption of other stuff on the computer.


----------



## fishhawk

Love your Work, I use HWinfo64 all the time, will have a couple of questions tomarrow for ya afteri read completely through this thread.


----------



## Mumak

Quote:


> Originally Posted by *Belial*
> 
> Thanks for taking the time to respond, but I'm not totally getting it yet.
> 
> So you say CPU Package Power is CPU power consumption, that's the big figure we all are interested in. So my CPU is basically consuming 85w? That is all the power consumption of my [email protected] CPU? I mean that seems too low, ivy bridge i7-3770k consumes more like just shy of 150w I thought ( source: http://forums.tweaktown.com/gigabyte/48359-ivy-bridge-overclocking-guide-extreme-ln2-section-guide-included.html), if not more with extreme overclocks (like mine).
> 
> So then what is IA Cores Power? As I understand, IA is a sensor placed in the cores (source: http://forums.anandtech.com/showthread.php?t=2247324). Or is the IA Cores just a different sensor, placed somewhere differently, reading the same thing? So basically, one of these sensors is 'more accurate' about my true wattage, or power consumption? So my true power consumption is not 85w, and it may not be 79w, but it's somewhere around there, something I can understand based on these two readings?
> 
> I actually hid quite a few values on my board, but there's IRF IR3567 (as pictured), IRF 3567 (IGPU), IRF 3570 (VDIMM), and IRF IR3570 (CPU VCCIO/VTT) with the same readings but for the igpu, vdimm, and vtt respectively (with vr vout, vr vin, current, pout, input as the one pictured).
> 
> But so why is there such a huge discrepancy between the wattage being sent to my CPU (Power (POUT)) as being 165w, and CPU Package Power? CPU Package Power + IA Cores seems more close to that number. Actually it's almost exactly the same number (both are 165, just the addition of both is 165.362).
> 
> So when people, or whatever, or sites, say how much power their CPU is consuming, I'm assuming they are referring to Power (Input) because that would be like the number change you would see if you used a Kill-O-Watt at the wall. Because even though my CPU is only pulling 165w, or 85w or whatever, the VRM is pulling 182w. So from the wall, the user would see on the Kill-O-Watt, a power consumption of 182w + power consumption of other stuff on the computer.


Your observation is absolutely right and I'm wondering about the same. Somehow the CPU energy/power counters seem not to return proper data. Anyway, according to definition:
The "CPU Package Power" = Power of the entire processor including IA Core, Integrated Graphics and the System Agent
The "IA Cores Power" concerns IA Cores portion of the CPU package only.
So that's the definition and how it should be, but it seems the reality (at least on your machine is different). I'd expect the sum of the POUT of all VRs for CPU to be equal to the "CPU Package Power" value. I've seen many systems, where this value seemed to provide correct results. I'm sorry, but I don't know what advice I could make to you to find the truth. Maybe try to watch these values under various load conditions if there's maybe a situation where it seems to provide correct values. I doubt this is a bug in HWiNFO's algorithm for power measurement, rather a problem in the CPU Power Control Unit reporting. I've seen a similar bug acknowledged by Intel on certain CPUs - it caused the power meter to under report power values by as much as 50%, but I'm not sure if your CPU could be affected by this. Maybe try a BIOS update ?


----------



## Oranuro

Rep+

Thanks for this tool.

I kid you not this tool and cpu-z are the first things that get installed after a new or refreshed build, even before drivers.


----------



## Belial

Quote:


> Originally Posted by *Oranuro*
> 
> Rep+
> 
> Thanks for this tool.
> 
> I kid you not this tool and cpu-z are the first things that get installed after a new or refreshed build, even before drivers.


Why would you bother installing CPU-Z if you have hwinfo?

Seriously though, Mumak, could you please allow for resizing of the summary page? The only reason I still use CPU-Z is because the summary page for HWinfo is actually very large, a lot of space in there I think could be shortened. I had to use CPU-Z to fit everything in my screen:


Spoiler: Warning: Spoiler!



 vs




Also, customizable/cool looking skins for hwinfo. And I hope one day you incorporate benches into your program. I have a vision for you Mumak, that one day overclockers will only need to download your one program, and that is all there is to it. Maybe one day it will install the drivers for you, automatically overclock your system (and do a good job!), run a 5 minutes stress test that is more stressful and comprehensive than 35 hours of prime95 custom blend...
Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Belial*
> 
> Thanks for taking the time to respond, but I'm not totally getting it yet.
> 
> So you say CPU Package Power is CPU power consumption, that's the big figure we all are interested in. So my CPU is basically consuming 85w? That is all the power consumption of my [email protected] CPU? I mean that seems too low, ivy bridge i7-3770k consumes more like just shy of 150w I thought ( source: http://forums.tweaktown.com/gigabyte/48359-ivy-bridge-overclocking-guide-extreme-ln2-section-guide-included.html), if not more with extreme overclocks (like mine).
> 
> So then what is IA Cores Power? As I understand, IA is a sensor placed in the cores (source: http://forums.anandtech.com/showthread.php?t=2247324). Or is the IA Cores just a different sensor, placed somewhere differently, reading the same thing? So basically, one of these sensors is 'more accurate' about my true wattage, or power consumption? So my true power consumption is not 85w, and it may not be 79w, but it's somewhere around there, something I can understand based on these two readings?
> 
> I actually hid quite a few values on my board, but there's IRF IR3567 (as pictured), IRF 3567 (IGPU), IRF 3570 (VDIMM), and IRF IR3570 (CPU VCCIO/VTT) with the same readings but for the igpu, vdimm, and vtt respectively (with vr vout, vr vin, current, pout, input as the one pictured).
> 
> But so why is there such a huge discrepancy between the wattage being sent to my CPU (Power (POUT)) as being 165w, and CPU Package Power? CPU Package Power + IA Cores seems more close to that number. Actually it's almost exactly the same number (both are 165, just the addition of both is 165.362).
> 
> So when people, or whatever, or sites, say how much power their CPU is consuming, I'm assuming they are referring to Power (Input) because that would be like the number change you would see if you used a Kill-O-Watt at the wall. Because even though my CPU is only pulling 165w, or 85w or whatever, the VRM is pulling 182w. So from the wall, the user would see on the Kill-O-Watt, a power consumption of 182w + power consumption of other stuff on the computer.
> 
> 
> 
> Your observation is absolutely right and I'm wondering about the same. Somehow the CPU energy/power counters seem not to return proper data. Anyway, according to definition:
> The "CPU Package Power" = Power of the entire processor including IA Core, Integrated Graphics and the System Agent
> The "IA Cores Power" concerns IA Cores portion of the CPU package only.
> So that's the definition and how it should be, but it seems the reality (at least on your machine is different). I'd expect the sum of the POUT of all VRs for CPU to be equal to the "CPU Package Power" value. I've seen many systems, where this value seemed to provide correct results. I'm sorry, but I don't know what advice I could make to you to find the truth. Maybe try to watch these values under various load conditions if there's maybe a situation where it seems to provide correct values. I doubt this is a bug in HWiNFO's algorithm for power measurement, rather a problem in the CPU Power Control Unit reporting. I've seen a similar bug acknowledged by Intel on certain CPUs - it caused the power meter to under report power values by as much as 50%, but I'm not sure if your CPU could be affected by this. Maybe try a BIOS update ?
Click to expand...

Oh okay, so basically my cpu package power reading is the only one that is wacky, and it appears to just be the difference of true package and IA cores. I mean it sounds about right (package + IA, the VR powers on CPU), almost 200w for an [email protected] i7-3770k. All seems pretty accurate.

I've gone through a few BIOS revisions, always been the same like this (although this is a beta bios and maybe just last stable bios was bugged too). Thanks, I will just hide the package power info and look at it via VRM info if i need to!


----------



## Belial

and i hope one day we can pull graphs of sensor values that we've hidden on the sensors tab (ie i'd like to hide all my thread usages on sensor tab but have graphs of them all.


----------



## Mumak

I'm not sure if resizing of the Summary window would help, since there are too many items in the window. It's hard to fit all those information into a single screen...
I have some ideas about GUI redesign for long ago and I understand that this should be done. However I still haven't found the right one...


----------



## Belial

What does Current mean? It has amperage figures by it. If you multiply it by, say, cpu current (iout) of 114 x 12 = 1368w and that's way more than im using or is reported on wattage... there's current figures for everything, I dont know what they refer to.

And my sapphire dual-x 7950, there is a VRM (POUT) value that maxes at 58 on [email protected] (stock on this gpu). Is that just an off value?


----------



## Mumak

Quote:


> Originally Posted by *Belial*
> 
> What does Current mean? It has amperage figures by it. If you multiply it by, say, cpu current (iout) of 114 x 12 = 1368w and that's way more than im using or is reported on wattage... there's current figures for everything, I dont know what they refer to.
> 
> And my sapphire dual-x 7950, there is a VRM (POUT) value that maxes at 58 on [email protected] (stock on this gpu). Is that just an off value?


I'm not sure which exact values you mean. Can you please post a screenshot? The VRM (POUT) values should be quite precise and determine the power consumption - however they might not cover the entire power consumption of the whole component, but only the parts they power. i.e. some CPUs/GPUs have multiple VRs (for core, memory, etc).


----------



## Belial

Thanks for the clarification!


----------



## Mumak

If you mean the IRF IR3567 for example, the current should be multiplied by voltage rail OUTPUT it controls (not +12V) to give power. I assume you have hidden the respective VOUT value (which most probably is the VR output = Vcore), so if you enable it, that should be the missing part of your equation.


----------



## bustacap22

.


----------



## Tomlintm

i got a question

after i installed my new AMD FX-4300 Vishera 3.8GHz 95w cpu a while back this new cpu power started to show up and im wondering is it accuate b/c it stays between 20-30w so can you explain how it works unless its bugs


----------



## Mumak

Quote:


> Originally Posted by *Tomlintm*
> 
> i got a question
> 
> after i installed my new AMD FX-4300 Vishera 3.8GHz 95w cpu a while back this new cpu power started to show up and im wondering is it accuate b/c it stays between 20-30w so can you explain how it works unless its bugs


HWiNFO follows instructions by AMD on how to measure CPU power usage. But I cannot give you a guarantee that this really works reliably. It would be no wonder if it wouldn't, just the fact how recent AMD CPU thermal sensors work - they are extremely unreliable especially at lower temperatures. Maybe a BIOS update might help to get better results...


----------



## Tomlintm

and my bios is up today for my asrock 990fx extreme 3 mobo so pretty much the reading are not worth looking at then


----------



## Dhsidh46434




----------



## Mumak

Quote:


> Originally Posted by *benigngerm*
> 
> Why is hwinfo displaying variable minimum and maximum clocks? I have C1E, C2E, EIST and Thermal Monitoring 2 disabled in the BIOS. What concerns me is my CPU ostensibly reaching 5GHz sometimes...


What CPU is that? If you attach the HWiNFO Debug File, I can check what's going on there...


----------



## Dhsidh46434




----------



## Mumak

On some older CPU families the measurement of CPU clock is not precise and it might happen, that occasionally HWiNFO measures an invalid clock. This can happen more often if there are some high load tasks running in background.


----------



## Baghi

Nothing technical but I'd like to congratulate and thank you for developing such a great product for free of charge. It does better than many paid ones even. I'm a big fan of open-source and free-to-use software.


----------



## Dhsidh46434




----------



## Mumak

Thanks guys. Developing own OSD would be too much effort, which I rather spend on improving support of various hardware components and technologies.


----------



## go4life

I love your work Martin!









Keep it up, we need more like this!

EDIT: Found this while using it, my specs are in signature if you need them, and I will be happy to provide more information if needed.


----------



## Belial

^ It's because CPU-Z is junk and we shouldn't be using it anymore.

HWInfo, in that screen, is showing you your chip's VID. I just checked on my i7-3770k


----------



## Mumak

What CPU-Z shows is the Vcore and what you seen in the HWiNFO window is the CPU VID. These can be different depending on board design and configuration. Generally, the VID is the voltage requested by CPU to VR and Vcore is the really measured voltage (by a sensor). If there's a voltage offset applied or adjusted VR, those can be different.

If you open the sensors window in HWiNFO, you'll get both values monitored - the VID and Vcore.


----------



## go4life

Ah ok, my bad then


----------



## Belial

Is there a way to tell hwinfo to turn _off_ a program when X reaches a certain value?

Ie, at 85*C GPU temp, hwinfo shuts down a particular 24/7 compute workload program like folding.

Thanks.


----------



## Mumak

Yes, it's possible - you need to define a HWiNFO alarm triggered according to your criteria. This would be then configured to either run a custom batch file (.bat or .cmd) which would then terminate the application, or straight run the required application with a command line switch to terminate it (or stop). However I'm not sure about [email protected], if/how it's possible to terminate it in a way that you don't loose the work. I have only experience with BOINC, there I think it might be possible to launch "boinccmd --quit" or "boinccmd --project URL suspend".
Quote:


> Originally Posted by *Belial*
> 
> Is there a way to tell hwinfo to turn _off_ a program when X reaches a certain value?
> 
> Ie, at 85*C GPU temp, hwinfo shuts down a particular 24/7 compute workload program like folding.
> 
> Thanks.


----------



## DirkDaring

For my cpu temps I have one being reported under CPU amd fx-8120 and one under a different sensor.... ITE IT8720F. The one under the cpu is lower by almost 10 degrees. Are these measures of cores and cpu package? I'm guessing the lower one would be the measure of cores....


----------



## Mumak

Yes, the value under your CPU sensor is from the internal diode. However recent AMD CPUs have a flawed diode which doesn't provide precise results, the more imprecise the lower the temperature is. So below a certain value, the sensor doesn't provide valid data. It tends to give reasonable results only at temperatures closer to critical point. This has been acknowledged by AMD, but no fix was provided.


----------



## DirkDaring

Thank you sir.


----------



## SSDdrivei7

Ha! Mumak! And a hearty--LOL!!!!!







Yes! I was just getting ready to post a new thread concerning HWINFO64 and how absolutely sublime this semi-mandatory program truly is! I especially love the Sensor Status window with its ability to link almost any current hardware stat to the tray! To actually pin and observe my computer's dimms @ will to- and via the taskbar's tray is tricked! And any hardware sensor can simply be right-clicked to show a real-time Graph on the desktop! Tracking computer essentials on this computer during gaming has never been more accurate or easier!







Hat's off, mann!


----------



## Belial

PLEASE INCORPORATE FAN CONTROL INTO HWINFO LIKE THIS:

http://www.almico.com/sfarticle.php?id=5


----------



## killerhz

Quote:


> Originally Posted by *Mumak*
> 
> Hi all,
> 
> I'm the author of HWiNFO/32/64 tools, which I noticed are quite successfully used here.
> I decided to create a thread on this forum to provide support for these tools, listen to your feedback, opinions and ideas.
> Feel free to ask/request/share thoughts about HWiNFO/32/64 here and I hope you enjoy using these tools.
> 
> Martin


pretty sick app. thanks for this. didn't know about it at all but really like it a lot..

+ 1 for the good work


----------



## Belial

anyone still using cpu-z or hwmonitor is stuck in the stone age.


----------



## par

there is a alert log in hwinfo? for example like probe ii?



i don't find it.. if there isn't, it's possible to will add it a day in future?

PS

rep+ Mumak!


----------



## Mumak

Quote:


> Originally Posted by *par*
> 
> there is a alert log in hwinfo? for example like probe ii?


It's not possible to view the alert log, but there is possibility to set custom alerts and log all values.


----------



## par

Quote:


> Originally Posted by *Mumak*
> 
> *there is possibility to set custom alerts* and log all values.


yes, i know.. it's wonderful








Quote:


> It's not possible to view the alert log,


there are possibilities for a future integration?


----------



## Mumak

It might be a useful feature, so I'll put this into my to-do list


----------



## par

great!

anyway your sw is already magnific , my congratulations


----------



## Mumak

Thank you


----------



## Baghi

Can we use in-game OSD without relying on MSI AB and RivaTuner? I use ASUS GPU Tweak as my overclocking utility. Thanks.


----------



## Mumak

You need to have the OSD Server of MSI AB or RivaTuner or EVGA PrecisionX running, since only this can render the sensor values from HWiNFO into games (or other D3D apps).
Quote:


> Originally Posted by *Baghi*
> 
> Can we use in-game OSD without relying on MSI AB and RivaTuner? I use ASUS GPU Tweak as my overclocking utility. Thanks.


----------



## par

maybe it's possible to extrapolate RTSS OSD from rivatuner/afterburner/precision ?


----------



## Baghi

Quote:


> Originally Posted by *Mumak*
> 
> You need to have the OSD Server of MSI AB or RivaTuner or EVGA PrecisionX running, since only this can render the sensor values from HWiNFO into games (or other D3D apps).


So right now it's not possible without the help of RTSS? Can I install RTSS separately?


----------



## Germanian

im actually doing a powerpoint presentation for this program in my CS/IS 101 class on wednesday









Show a program that other people might not know about it and this program is amazing. Thank you for your hardwork.


----------



## Mumak

Yep, the RTSS OSD server seems now to be available separately too. Check here:
http://www.guru3d.com/files_details/rtss_rivatuner_statistics_server_download.html


----------



## Baghi

Quote:


> Originally Posted by *Mumak*
> 
> Yep, the RTSS OSD server seems now to be available separately too. Check here:
> http://www.guru3d.com/files_details/rtss_rivatuner_statistics_server_download.html


AWESOME! Never bothered to Google this thing but still. Thanks a lot. +REP


----------



## 636cc of fury

Any way to get vdimm displaying on the Asrock Z87 OC Formula?


----------



## Mumak

This (and almost all ASRock) boards are not able to measure actual DRAM voltage.

Quote:


> Originally Posted by *636cc of fury*
> 
> Any way to get vdimm displaying on the Asrock Z87 OC Formula?


----------



## par

I have a little question, about RTSS OSD..

with old HWiNFO version I can chose a different and personal label for all the lines..

for example, before i can do this:










now it isn't possible ?

EDIT

sorry, i discovery that I can do an OSD like in the image also with new HWiNFO version...

but..

before, label of OSD was separated to label of main window of software..

now, label of main window of software, and label of OSD, are united..

so..

before, i can have a OSD like in the pic, and i can also have the default label in the main window of software..

now, i can have a OSD like in the pic, but i can't have also default label in the main windows of software.. and i am forced to use for example a label of main window like this:










it's right?

THNXXX


----------



## Mumak

The labels have always been the same in both the sensors window and OSD, the only thing that changed is the way how sensor values are grouped together on a single line.
If there's a real demand for a custom label for each line in OSD ,I can have a look at implementing this feature.


----------



## par

ok.. i remembered that with an old old version i can chose a personal label for OSD but without changing also the label of main window.. but evidently i don't remember correctly









custom labels for OSD, separated to main window labels, will be great..

don't forget the alert log!









THNXXX


----------



## Mumak

I've got an alternate idea - what if the label displayed in OSD would be a combination of all labels you select for the given line ? Let me try that...


----------



## par

Quote:


> Originally Posted by *Mumak*
> 
> I've got an alternate idea - what if the label displayed in OSD would be a combination of all labels you select for the given line ? Let me try that...


I did not understand very well. but I trust you


----------



## Mumak

Those items which have the "Show Label in OSD" option enabled will also get the respective label combined based on labels in the sensors window (custom).
Check the new build just released (v4.23-1993) and see


----------



## mark_thaddeus

Quote:


> Originally Posted by *Mumak*
> 
> Those items which have the "Show Label in OSD" option enabled will also get the respective label combined based on labels in the sensors window (custom).
> Check the new build just released (v4.23-1993) and see


That's awesome! Keep up the great work!


----------



## par

Quote:


> Originally Posted by *Mumak*
> 
> Those items which have the "Show Label in OSD" option enabled will also get the respective label combined based on labels in the sensors window (custom).
> Check the new build just released (v4.23-1993) and see


i tried and I understand..

SWEET


----------



## par

my new OSD


----------



## mark_thaddeus

I just wanted to give feedback regarding your website Mumak. Specifically the download section, if you could make it in such a way that the actual download links are closer to the description it would be less confusing. It took a minute for me to realize that it was a drop down box and all the links were in the bottom. I was trying to hit the graphic up top initially and figured things out but having a very user friendly site willl definitely help.



You would think looking at that page that the links are all up top but you have to click on the green download installer for a drop down menu to appear. It also seems the links down below are just a tad confusing when you see the "download latest beta" with it.


----------



## Mumak

I know what you mean and so far there have been only few complaints about this layout. I understand that this might be confusing for some users, but I think for most of them the site design is clean and easy to understand. Position of those ads is intentional and in the end makes a huge difference in income. These ads are what allows me to keep HWiNFO completely freeware (it was shareware few years ago, btw). I have received tons of requests to bundle HWiNFO with stuff like installers, ad services, etc, but I refuse them all. I want to have things clean, but I also need to make a compromise to cover my effort (which btw is ~20 years in total) and expenses. If you look at lots of other software, it uses ads too (even software which is not free), or is bundled with crap. Some other sites use even more aggressive ads and it's really though to find the right content there. So I still think that the HWiNFO site is much cleaner than many others are. Just look at this page, how many ads are there - I counted 8 banners








Honestly, personally I don't like ads either (sometimes it makes me angry) and I wish I could find a better way to cover my costs, however I haven't found another solution yet. I hope that one day this will change.


----------



## mark_thaddeus

That's cool Mumak, completely understandable! It would be cool though if you could add a line up top that says all download links are at the bottom. Cheers!


----------



## Belial

Hey, how do I display HWInfo stuff on an LCD? I would assume using lcd smartie, which is what everyone else uses these days: http://lcdsmartie.sourceforge.net/

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *Belial*
> 
> Hey, how do I display HWInfo stuff on an LCD? I would assume using lcd smartie, which is what everyone else uses these days: http://lcdsmartie.sourceforge.net/
> 
> Thanks.


AFAIK, there's no LCD Smartie plugin-in for HWiNFO (yet). You might check their forums if they would like to support it.


----------



## Belial

I don't see it ;/

I dont really see any way to show info well. Coretemp plugin requires you to run coretemp, system monitor wont pick up my cpu's temps (haswell) and doesnt report max core temp.


----------



## 331149

I've got a question and it might be a bit strange, I sure can't figure this one out.
Using hwinfo, CPU power does not show up. However when I put the pc to sleep and wake it up, CPU power is there. Hwinfo also reports an increase in vcore and mhz (by a whopping 500mhz).

I have turbocore disabled and all that useless junk so this is quite puzzling..

Specs
FX-8320 currently at stock with turbocore off
Radeon R9 270X
Asus M5A99X Evo R2.0 with latest bios
Windows 7 ultimate and up-to-date

Take a look. Left window is before sleep, right window is after sleep. Super strange!


Original: http://cdn.overclock.net/0/00/00e779c1_hwinfohuh.jpeg


----------



## Mumak

You're right, this is very strange. I don't have an exact answer for this, but my guess is that this is a BIOS issue. It seems that the BIOS enables some settings (or doesn't properly restore actual ones) after resume from S3. It could be that it doesn't properly preserve (disable) Core Power Boost (CPB) after resume and maybe some other settings as well.
You might try the following:
- Enable (CPB) in BIOS and watch how it behaves
- Perform a BIOS update


----------



## asxx

very useful, thanks.


----------



## par

Hi Mumak!

if i can ask you one thing...

why you changed the previous 'config system' about custom OSD ? ..this:

http://imageshack.us/a/img341/8352/howtoconfighwinfotoshow.jpg

i think it was very better!

anyway no problem with the new 'config system'


----------



## Belial

http://forums.lcdsmartie.org/viewtopic.php?f=8&t=3493&p=19393#p19393

HWINFO LCD Smartie plug in finsihed!!!?!111! Holy cow!

$20 LCD (rgb negative from adafruit imo best looking), MCU for $20, and you got an lcd to display hwinfo stuff! yahoo! wowowo!

AWESOMEMEMEMEM!!!!asdfasdfasdfa


----------



## Mumak

Quote:


> Originally Posted by *par*
> 
> Hi Mumak!
> 
> if i can ask you one thing...
> 
> why you changed the previous 'config system' about custom OSD ? ..this:
> 
> http://imageshack.us/a/img341/8352/howtoconfighwinfotoshow.jpg
> 
> i think it was very better!
> 
> anyway no problem with the new 'config system'


Because I had to add more items into that config screen, which wouldn't fit there anymore (like reordering of items, etc).

Quote:


> Originally Posted by *Belial*
> 
> http://forums.lcdsmartie.org/viewtopic.php?f=8&t=3493&p=19393#p19393
> 
> HWINFO LCD Smartie plug in finsihed!!!?!111! Holy cow!
> 
> $20 LCD (rgb negative from adafruit imo best looking), MCU for $20, and you got an lcd to display hwinfo stuff! yahoo! wowowo!
> 
> AWESOMEMEMEMEM!!!!asdfasdfasdfa


Yep, it's in Beta phase and should be released soon


----------



## Belial

unfortunately i've been having some refresh/buffer issues with my LCD+MCU (micro, ide 1.5.4). It's like if I have a lot of dynamic stuff displayed or something the first 2 lines funk out... really sucks.

https://forum.sparkfun.com/viewtopic.php?f=42&t=36671&p=166019#p166019

but man, that plugin seems really smooth, seems as customizable as hwinfo itself. no problem as far as the lcd smartie emulation and when the lcd isnt funking out.


----------



## par

other question..

when i format and copy hwinfo exe and the hwinfo ini file, i lost all my settings about the layout and the osd.. where is the file that have these settings?

thnx Mumak


----------



## Mumak

Quote:


> Originally Posted by *par*
> 
> other question..
> 
> when i format and copy hwinfo exe and the hwinfo ini file, i lost all my settings about the layout and the osd.. where is the file that have these settings?
> 
> thnx Mumak


It's stored in the registry under:
For HWiNFO32: HKEY_CURRENT_USER\Software\HWiNFO32\Sensors
For HWiNFO64: HKEY_CURRENT_USER\Software\HWiNFO64\Sensors


----------



## par

nad how i can backup and restore it ?


----------



## Mumak

You can export the entire key using the "regedit" tool in Windows. To import the saved data, just click the .reg file.


----------



## taem

First of all, I love this app, huge thanks to the creator. I always have it up on the secondary monitor, and I send it's values to RTSS for in game osd.

I have a bunch of questions about the various sensors but the priority one is this: the SMART sensor for hard drive warning says "yes". Uhh... This is a brand new 960gb ssd!! Please tell me this means the sensor is active and not that the drive is failing. No warning has popped up in Windows 8.1. If it does mean drive is failing, what is my next step?


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> First of all, I love this app, huge thanks to the creator. I always have it up on the secondary monitor, and I send it's values to RTSS for in game osd.
> 
> I have a bunch of questions about the various sensors but the priority one is this: the SMART sensor for hard drive warning says "yes". Uhh... This is a brand new 960gb ssd!! Please tell me this means the sensor is active and not that the drive is failing. No warning has popped up in Windows 8.1. If it does mean drive is failing, what is my next step?


Please show me the exact S.M.A.R.T. statistics that is shown in the main HWiNFO window / Drives. You can copy/paste the S.M.A.R.T. section from that window here.
Have you maybe checked with CrystalDiskInfo what does that say ?


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> Please show me the exact S.M.A.R.T. statistics that is shown in the main HWiNFO window / Drives. You can copy/paste the S.M.A.R.T. section from that window here.
> Have you maybe checked with CrystalDiskInfo what does that say ?


Here it is:


----------



## Mumak

I meant all SMART parameters from the main HWiNFO window (not Sensors window). You might disable the Sensors-only mode to get that window.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> I meant all SMART parameters from the main HWiNFO window (not Sensors window). You might disable the Sensors-only mode to get that window.


I'm not sure what you mean by SMART parameters, here is the window to the right when I select the ssd. There is one entry showing a yellow triangle with an exclamation point, screen of that first:



And the rest of it:

General Information
Drive Controller: Serial ATA 6Gb/s @ 6Gb/s
Drive Model: Crucial_CT960M500SSD1
Drive Revision: MU03
Drive Serial Number: 133209499002
World Wide Name: 500A7519499002
Drive Capacity: 915,715 MBytes (960 GB)
Media Rotation Rate: SSD Drive (Non-rotating)
Nominal Form Factor: 2.5"

Drive Geometry
Number of Cylinders: 16383
Number of Heads: 16
Sectors Per Track: 63
Number of Sectors: 16514064
Total 32-bit LBA Sectors: 268435455
Total 48-bit LBA Sectors: 1875385008
Cache Buffer Size: N/A

Transfer Modes
Sectors Per Interrupt: Total: 16, Active: 16
Max. PIO Transfer Mode: 4
Multiword DMA Mode: Total: 2, Active: -
Singleword DMA Mode: Total: -, Active: -
Ultra-DMA Mode: Total: 6 (ATA-133), Active: 5 (ATA-100)
Max. Multiword DMA Transfer Rate: 16.7 MBytes/s
Max. PIO with IORDY Transfer Rate: 16.7 MBytes/s
Max. PIO w/o IORDY Transfer Rate: 16.7 MBytes/s
Transfer Width: Unknown
Native Command Queuing: Supported, Max. Depth: 32
TRIM Command: Supported (Deterministic Read After TRIM, Words = 0)

Device flags
Fixed Drive: Present
Removable Drive: Not Present
Magnetic Storage: Present
LBA Mode: Supported
DMA Mode: Supported
IORDY: Supported
IORDY Disableable: Supported

Features
Write Cache: Present, Active
S.M.A.R.T. Feature: Present, Active
Security Feature: Not Present, Inactive
Removable Media Feature: Not Present, Disabled
Power Management: Present, Active
Advanced Power Management: Present, Active
Packet Interface: Not Present, Disabled
Look-Ahead Buffer: Present, Active
Host Protected Area: Present, Enabled
Power-Up In Standby: Not Suppported, Inactive
Automatic Acoustic Management: Not Suppported, Inactive
48-bit LBA: Supported, Active
Host-Initiated Link Power Management: Supported
Device-Initiated Link Power Management: Supported, Disabled
In-Order Data Delivery: Not Supported
Hardware Feature Control: Supported, Disabled
Software Settings Preservation: Supported, Enabled
NCQ Autosense: Not Supported
Link Power State Device Sleep: Supported, Disabled
Hybrid Information Feature: Not Supported
All Write Cache Non-Volatile: Not Supported
Extended Number of User Addressable Sectors: Not Supported
Device Encrypts All User Data: Supported
CFast Specification: Not Supported
NCQ Priority Information: Supported
Host Automatic Partial to Slumber Transitions: Supported
Device Automatic Partial to Slumber Transitions: Supported
NCQ Streaming: Not Supported
NCQ Queue Management Command: Not Supported
DEVSLP to Reduced Power State: Supported
Extended Power Conditions Feature: Not Supported
Sense Data Reporting Feature: Not Supported
Free-Fall Control Feature: Not Supported

Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.)
[01] Raw Read Error Rate: 100/Always OK, Worst: 100 (Data = 2712)
[05] Reallocated Sector Count: 100/Always OK, Worst: 100 (Data = 2)
[09] Power-On Hours/Cycle Count: 100/Always OK, Worst: 100 (Data = 101)
[0C] Power Cycle Count: 100/Always OK, Worst: 100 (Data = 144)
[AB] Program Fail Count 100/Always OK, Worst: 100
[AC] Erase Fail Count: 100/Always OK, Worst: 100
[AD] Wear Leveling Count/Erase Count: 100/Always OK, Worst: 100
[AE] Unexpected Power Loss Count: 100/Always OK, Worst: 100 (Data = 47)
[B4] Unused Reserved Block Count (Total): 0/Always OK, Worst: 0 (Data = 16521)
[B7] Runtime Bad Block (Total)/SATA Downshift Count: 100/Always OK, Worst: 100
[B8] Initial Bad Block Count/Reported I/O Error Detection Code Errors 100/Always OK, Worst: 100
[BB] Uncorrectable Error Count/Total Erase Count: 100/Always OK, Worst: 100
[C2] Temperature 71/Always OK, Worst: 64 (Data = 29.0 °C)
[C4] Erase Failure Block Count/Reallocation Event Count 100/Always OK, Worst: 100 (Data = 18)
[C5] Read Failure Block Count/Current Pending Sector Count 100/Always OK, Worst: 100
[C6] Off-Line Uncorrectable Error Count/Total Count of Read Sectors 100/Always OK, Worst: 100
[C7] CRC Error Count/Total Count of Write Sectors 100/Always OK, Worst: 100
[CA] Percentage Of The Rated Lifetime Used/CRC Error Count: 100/Always OK, Worst: 100
[CE] Minimum Erase Count / Write Error Rate 100/Always OK, Worst: 100
[D2] SATA CRC Error Count/Successful RAIN Recovery Count 100/Always OK, Worst: 100 (Data = 7)
[F6] Total Host Sector Writes 100/Always OK, Worst: 100 (Data = 2056250159)
[F7] Host Program Page Count 100/Always OK, Worst: 100 (Data = 64373124)
[F8] Unknown 100/Always OK, Worst: 100 (Data = 9368652)


----------



## Mumak

This is a false warning, that should not be displayed on SSD drives, so please ignore it.
I'll fix it in the next build.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> This is a false warning, that should not be displayed on SSD drives, so please ignore it.
> I'll fix it in the next build.


Thanx tons, you put my mind at ease.


----------



## 331149

Quote:


> Originally Posted by *TheBDK*
> 
> I've got a question and it might be a bit strange, I sure can't figure this one out.
> Using hwinfo, CPU power does not show up. However when I put the pc to sleep and wake it up, CPU power is there. Hwinfo also reports an increase in vcore and mhz (by a whopping 500mhz).
> 
> I have turbocore disabled and all that useless junk so this is quite puzzling..
> 
> Specs
> FX-8320 currently at stock with turbocore off
> Radeon R9 270X
> Asus M5A99X Evo R2.0 with latest bios
> Windows 7 ultimate and up-to-date
> 
> Take a look. Left window is before sleep, right window is after sleep. Super strange!
> 
> 
> Original: http://cdn.overclock.net/0/00/00e779c1_hwinfohuh.jpeg


finally figured out the cause. I disable turbocore right from the get go and after sleep wakeup, it's enabled again for reasons I cannot even begin to understand. No wonder Windows is crashing on so many people when it wakes up from sleep.


----------



## Mumak

Quote:


> Originally Posted by *TheBDK*
> 
> finally figured out the cause. I disable turbocore right from the get go and after sleep wakeup, it's enabled again for reasons I cannot even begin to understand. No wonder Windows is crashing on so many people when it wakes up from sleep.


I believe that's a BIOS bug in restoring registers after S3 resume. It might be fixed in a BIOS update. If it isn't you should notify ASUS about that problem.


----------



## fommof

Hey Martin, hope you are doing well man.

The HWInfo together with FRAPS is my way to go monitoring/logging progs the only ones i use for my reviews, measurements etc, once again excellent work! The fact that the HWInfo logs the FRAPS values as well solved a major issue to me, now i don't have to synchronize FRAPS and HWInfo data, it's all in one.









One thing i miss is a hotkey for enabling/disabling the logging whenever i need when i run an application. That would made my life even easier since i wouldn't have to syncronize or keep time when starting a game/bench, going to menu etc etc until the start of the actual measurements.

I wonder if the HWInfo can "steal" and log the frame time values of the FRAPS as well, that would be awsome.

Also, i still use the v4.16-1900 works like a charm. I had to deal with some problems when tried to use a newer version when monitoring an i3-3240 (Z77 mobo) running heavy applications like Linx AVX. The interface/screen of the HWInfo couldn't refresh per 1 sec like it should (i always set the interval to 1000ms, gives me all the data i need and never had any probs with it) , it was like there were strange interruptions. Has never happened to me with older versions running the same apps in different pcs. Bad thing is i don't have the i3 anymore and i can't remember which HWInfo version was so i guess not much of a real feedback here.

Keep up the good work Martin!


----------



## Mumak

A hotkey for logging is on my list








I don't understand which frame time values from FRAPS do you exactly mean..?
As for the lag during update with newer versions, you should try to disable sensors one by one to find which one is causing that (could be an EC or Disk sensor). But since you don't have that board anymore...


----------



## fommof

Quote:


> Originally Posted by *Mumak*
> 
> A hotkey for logging is on my list


Woooohooooo!!!








Quote:


> Originally Posted by *Mumak*
> 
> A hotkey for logging is on my list
> 
> 
> 
> 
> 
> 
> 
> 
> I don't understand which frame time values from FRAPS do you exactly mean..?




If you check "Frametimes" then you also ger the frame times which shows the latency and imho says way more than the FPS charts of what you are experiencing, for insance:

This is a fresh measurement of mine, comparison between Win 7 and Win 8.1 playing BF4 at the very same pc at certain settings etc:



(chart shows milliseconds, in real life at these settings in Win 7 the game is waaay too choppy)

Quote:


> Originally Posted by *Mumak*
> 
> As for the lag during update with newer versions, you should try to disable sensors one by one to find which one is causing that (could be an EC or Disk sensor). But since you don't have that board anymore...


I am afraid i tried it, i always disable everything i am not interested in monitoring. Shame i forgot to let you know at that time, we would troubleshoot....


----------



## Mumak

I'm afraid, it doesn't seem to be possible to retrieve frame times from FRAPS. It would also be problematic to synchronize the sampled data with HWiNFO update cycles.


----------



## fommof

No worries!









Thanks Martin!


----------



## 331149

Found another issue (don't hate me), but it's not possible to disable my NIC when HWiNFO is running. I've even disabled network monitoring but it doesn't seem to help.

It comes up with this error


----------



## mark_thaddeus

Quote:


> Originally Posted by *TheBDK*
> 
> Found another issue (don't hate me), but it's not possible to disable my NIC when HWiNFO is running. I've even disabled network monitoring but it doesn't seem to help.
> 
> It comes up with this error


Can you include what motherboard your using? Looking at your screen grab, it seems it's the Intel NIC right?

That should at least help the developer figure things out better.


----------



## fommof

Quote:


> Originally Posted by *TheBDK*
> 
> Found another issue (don't hate me), but it's not possible to disable my NIC when HWiNFO is running. I've even disabled network monitoring but it doesn't seem to help.
> 
> It comes up with this error


I am sure i have seen this behavior in my gaming pc (Z77, Intel NIC) but i am dealing with strange behavior when i want to enable/disable the network card even in my "every day" system (again, Z77 but Realtek NIC). Close HWInfo and i can disable/enable the card in a sec. With the HWInfo running the system won't enable/disable the card unless i reboot (mopst of the available sensors are disabled and hidden):



*That's the 4.3 version*. I have kept an older version just in case (v4.16-1900), it's fine with the older version (the card can be disabled/enabled instantly without having to restart or any other funny messages, that's in both my systems).

Full system specs:
*Intel Celeron G530 (Noctua D14 passive/fanless)
*Asus P8Z77-M (bios: 2105 official)
*G.Skill DDR3 1333MHz 9-9-9-24 1.5V (2x2Gb)
*OCZ Agility3 240Gb
*WD20EARX
*Asus DRW-24BSST
*Raidsonic Icybox Trayless Mobile Rack for 3.5" hdds
*Corsair AX760
*Cooler Master CM690 II Advanced (2x Noctua NF-S12 FLX)
*Samsung UE32F5000AW
*Win7 Ultimate 64bit










EDIT: i was wrong, the gaming pc (Z77, Intel NIC) doesn't have these issues right now (did a clean install a week ago), tested it a few minutes ago. Still, i have experienced what TheBDK mentioned, i just can't reproduce it right now.


Spoiler: Warning: Spoiler!





Full system specs:
*Intel 2600K (Corsair H100i,4x NF-F12 push/pull)
*Asus Maximus Gene V (bios: 1707 official/OROM 11.0.0.1339)
*Corsair Vengeance DDR3 1600Mhz 9-9-9-24 1.5V (2x4Gb)
*OCZ Vertex3 120Gb (x2 RAID0)
*Samsung 830 256GB
*Samsung SH-222AB
*Scythe Kaze Q12 12-Channel Fan Controller
*Raidsonic Icybox Trayless Mobile Rack for 3.5" hdds
*EVGA GTX Titan SC (Corsair H100i,4x NF-P12 push/pull)
*Focusrite Scarlett 18i8
*Corsair AX850
*Dimastech BenchTable Easy Dual V2.5
*LG W2361V
*Samsung UE32EH5000
*MS Keyboard Natural Ergonomic 4000
*Logitech K230/M235
*Win 7 Ultimate 64bit


----------



## Mumak

Thanks for reporting. I think I know why this happens. Will try to fix this in the next (Beta) build...


----------



## psyside

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for reporting. I think I know why this happens. Will try to fix this in the next (Beta) build...


What version is the best to use with R9 290, and what should i do before installing? clean install is impossible if you use portable version i think? what do you recommend? thanks.


----------



## Mumak

It's always best to use the latest version available, in most cases including the Beta pre-releases which are almost always stable.
There are no special requirements for the install procedure and portable versions can be used as well. If you have some version already installed, you can copy the portable over the current one.
All 'portable' settings are kept in the INI file, the rest of the settings (machine/user-specific) is kept in the registry. If you want to reset all the registry settings to default values, just press the "Reset settings" button in HWiNFO / Settings.

And here's a new build that should fix the problem with disabling the network adapter while HWiNFO is running:
www.hwinfo.com/beta/hw64_433_2105.zip
Please let me know if it's OK now...


----------



## psyside

On my friend pc, the latest version broke the mining, it made the crypt miner wont start, i argued that its not HWiNFO issue, we tried everything, after some time he uninstall it, and the mining started at once. So that's why i ask this, sorry.


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> On my friend pc, the latest version broke the mining, it made the crypt miner wont start, i argued that its not HWiNFO issue, we tried everything, after some time he uninstall it, and the mining started at once. So that's why i ask this, sorry.


It's hard to say what exactly happened there without further details. But when you don't have HWiNFO running and the issues persist, then I think it can NOT be caused by HWiNFO.

Sometimes there might be problems when monitoring additional sensors or VRs on AMD GPUs, so if you look for highest stability, then I suggest to disable the "GPU I2C Support" option in HWiNFO. On the other hand, if you disable it, you will no longer see GPU VR and additional sensors monitored.


----------



## psyside

Thanks, what i meant is we both use HWiNFO for monitoring gpu vrm/psu stability, and temps. So it was running when there was the issue, i will make clean install now and try the latest version, thanks for your help.


----------



## psyside

Also one more thing, why does HWiNFO start so slow? like 30 seconds, is this normal?


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> Also one more thing, why does HWiNFO start so slow? like 30 seconds, is this normal?


Where does it spend most of the time ?

Usually the slowest parts are those scanning the GPU I2C bus for VRs and additional sensors. You can try to reduce the scanning time by trying to disable GPU I2C buses, which don't contain those VRs: Settings - "SMBus / I2C" - "GPU I2C Bus Exclusion". From that list try to select boxes one by one until you don't see those VRs displayed. Then uncheck the box which seems to be the one showing those VRs. Unfortunately I can't tell you exactly which one is that, because this is GPU-specific. On some machines it's the bus #6, so for scanning time improvement you might end-up with all boxes checked except #6.
But the scan might consume some time on other parts, that depends...


----------



## psyside

I have all the sensors disabled expect PSU/GPU monitoring, pretty sure its the VR sensors, but i need them









Here is my config..



Everything that is not displayed, expect the PSU readings, is dsabled. It would be amazing, if you can make graphs dynamic, the ability to move PSU reading - graphs next to the GPU's instead of having to scroll and searching for them since they can not be seen in the default window size would be really great.

I can always re size, but then it takes to much space on my monitor, i multi-task most of the times.


----------



## Mumak

By disabling the other GPU I2C buses (as I described above), you should not loose the GPU VR values - you'd just disable buses which do not contain any devices and this might improve the startup (scan) time.

As for the sensor screen layout, you can either completely remove any sensor values from the screen or change their order how you like it. Check Configure Sensors / Layout...


----------



## psyside

Oh didn't know you can do that, thanks!

Also about the GPU12C, i don't see that option anywhere?


----------



## Mumak

Quote:


> Also about the GPU12C, i don't see that option anywhere?


It's not in Configure Sensors screen, but on the initial HWiNFO screen (before you launch the scan) click the Settings button.


----------



## psyside

No vrm sensors like this, only gpu temps/usage









Just tell me what to select


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> 
> 
> No vrm sensors like this, only gpu temps/usage


Yep - "GPU I2C Support"=OFF completely disables ALL buses. Enable "GPU I2C Support" back and then try to play with those Bus Exclusions as I describe earlier if you find a config that will not loose GPU VRMs and will improve startup time.


----------



## 331149

Quote:


> Originally Posted by *mark_thaddeus*
> 
> Can you include what motherboard your using? Looking at your screen grab, it seems it's the Intel NIC right?
> 
> That should at least help the developer figure things out better.


Yes of course, I always forget that simple thing







Full essential specs;

AMD FX-8320
AMD Radeon R9 270X with latest WHQL drivers
ASUS M5A99X Evo R2.0 with latest bios
16GB Kingston DDR3-1800
Windows 7 Ultimate 64bit

and of course the network card
Intel Pro/1000 GT < PCI but still quite amazing









I don't use onboard NIC especially when it's Realtek. Sowwy.


----------



## Mumak

Quote:


> Originally Posted by *TheBDK*
> 
> Yes of course, I always forget that simple thing
> 
> 
> 
> 
> 
> 
> 
> Full essential specs;
> 
> AMD FX-8320
> AMD Radeon R9 270X with latest WHQL drivers
> ASUS M5A99X Evo R2.0 with latest bios
> 16GB Kingston DDR3-1800
> Windows 7 Ultimate 64bit
> 
> and of course the network card
> Intel Pro/1000 GT < PCI but still quite amazing
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I don't use onboard NIC especially when it's Realtek. Sowwy.


Have you tried the new build I posted here? http://www.overclock.net/t/1235672/hwinfo-32-64-thread/160#post_21649042
It should fix that issue.


----------



## 331149

Quote:


> Originally Posted by *Mumak*
> 
> Have you tried the new build I posted here? http://www.overclock.net/t/1235672/hwinfo-32-64-thread/160#post_21649042
> It should fix that issue.


Just tried it, and it fixed it completely







Thanks.


----------



## fommof

Great job Mumak, once again...the version you posted earlier fixed the NIC issue, thanks again!


----------



## Mumak

Thanks for the feedback guys, I'm glad that this is solved now.


----------



## error-id10t

Just a random post to give rep, didn't even know you were here and been using this program.


----------



## psyside

Quote:


> Originally Posted by *Mumak*
> 
> Have you tried the new build I posted here? http://www.overclock.net/t/1235672/hwinfo-32-64-thread/160#post_21649042
> It should fix that issue.


It happen to me as well this morning, the version you posted its not direct link, can you tell me what version exactly should i use? thanks.


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> It happen to me as well this morning, the version you posted its not direct link, can you tell me what version exactly should i use? thanks.


I have removed that intermediate build, since there's a new official Beta build available, which includes this fix as well. So please get the latest Beta v4.33-2110 from the HWiNFO download page: http://www.hwinfo.com/download.php


----------



## psyside

Quote:


> Originally Posted by *Mumak*
> 
> I have removed that intermediate build, since there's a new official Beta build available, which includes this fix as well. So please get the latest Beta v4.33-2110 from the HWiNFO download page: http://www.hwinfo.com/download.php


Uh, so it happen on the new beta as well? i had the latest beta already









Might be some other issue, will report back if i'm able to reproduce it, thanks


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> Uh, so it happen on the new beta as well? i had the latest beta already
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Might be some other issue, will report back if i'm able to reproduce it, thanks


If you're sure that the network problem happened with the latest Beta (Build 2110) too, then please let me know.


----------



## psyside

I was sleeping, when i came back my system crashed due to mining, - black screen, and the adapter was disabled, now the question is does the system tried to restart but it didn't and it did disable the drivers - applications, you know like before it shuts down, or the network driver was disabled due to HWiNFO, i'm not sure but will report back.


----------



## os2wiz

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for reporting. I think I know why this happens. Will try to fix this in the next (Beta) build...


Martin, I guess this is frivolous, but can I download hwinfo64 somewhere where they do not include an installer that plants spyware on my computer??? I assume you have your own installation routine. I know I had downloaded it somewhere without one of these obnoxious installers, but I can't remember where. Thanks.


----------



## psyside

Quote:


> Originally Posted by *os2wiz*
> 
> Martin, I guess this is frivolous, but can I download hwinfo64 somewhere where they do not include an installer that plants spyware on my computer??? I assume you have your own installation routine. I know I had downloaded it somewhere without one of these obnoxious installers, but I can't remember where. Thanks.


http://www.fosshub.com/HWiNFO.html


----------



## Mumak

I'd definitively like to know where you found such installer. The official HWiNFO installer doesn't include any additional 'bonuses'.
The link provided by psyside is the primary mirror for HWiNFO. Thanks.


----------



## par

anyway it's also officially supported the portable version







(i love it







)


----------



## taem

Had to reinstall my system and now I cant get hwinfo to auto start. Here are how my settings look:



What am I doing wrong? I want the sensors screen to appear on my desktop when I boot up. Using the latest 64 bit beta portable


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Had to reinstall my system and now I cant get hwinfo to auto start. Here are how my settings look:
> 
> 
> 
> What am I doing wrong? I want the sensors screen to appear on my desktop when I boot up. Using the latest 64 bit beta portable


Disable the "Auto Start" option, click OK to save settings. Then open the settings again, enable it and OK.
That might work


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> Disable the "Auto Start" option, click OK to save settings. Then open the settings again, enable it and OK.
> That might work


Yup that worked, tyvm.


----------



## taem

Ok got a big issue. I'm using 433_2120 64 bit. Single R9 290.

It is slow as hell. Absurdly so. And I can't do anything on my system until it loads.

I googled it and you suggested turning off GPU 12C Support (there are three settings). But if I do that I lose vrm sensors.

I did not have this problem with either of my R9 280X cards, just started with this 290, tho this is a newer version of hwinfo.

Any way around this? What about the GPU 12C Bus Exclusion options? Maybe I should toy with it. But starting hwinfo is so painfully slow I dread the thought of doing it dozens of times trying to find out if a combination of those boxes might resolve this.


----------



## os2wiz

I am using the latest official release of hwinfo64. I noticed on my AMD A10-7850k apu that cpu temperatures fluctuate wildly from second to second. Is there a bug with hwinfo64 and the new Kaveri cpus?


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Ok got a big issue. I'm using 433_2120 64 bit. Single R9 290.
> 
> It is slow as hell. Absurdly so. And I can't do anything on my system until it loads.
> 
> I googled it and you suggested turning off GPU 12C Support (there are three settings). But if I do that I lose vrm sensors.
> 
> I did not have this problem with either of my R9 280X cards, just started with this 290, tho this is a newer version of hwinfo.
> 
> Any way around this? What about the GPU 12C Bus Exclusion options? Maybe I should toy with it. But starting hwinfo is so painfully slow I dread the thought of doing it dozens of times trying to find out if a combination of those boxes might resolve this.


You mean the startup is slow ? If yes, what is the exact "Detecting..." item where it stays too long ?
That might be improved by disabling some GPU I2C buses. Please attach the HWiNFO Debug File and I can analyze it to see what exactly to disable.


----------



## Mumak

Quote:


> Originally Posted by *os2wiz*
> 
> I am using the latest official release of hwinfo64. I noticed on my AMD A10-7850k apu that cpu temperatures fluctuate wildly from second to second. Is there a bug with hwinfo64 and the new Kaveri cpus?


I don't think there's a bug - the temperature sensors in later AMD generations are just too buggy, especially at lower temperatures.
Or have you maybe seen a different behaviour with earlier HWiNFO versions ?


----------



## os2wiz

Quote:


> Originally Posted by *Mumak*
> 
> I don't think there's a bug - the temperature sensors in later AMD generations are just too buggy, especially at lower temperatures.
> Or have you maybe seen a different behaviour with earlier HWiNFO versions ?


No.NO.NO! I am talking about wild gyrations 10 to 15 degree Celcius shifts from one moment to another. I have NEVER seen this in 2 years of using your program. I know all about inaccuracies at low temperatures, that is NOT what I have described.


----------



## Mumak

Quote:


> Originally Posted by *os2wiz*
> 
> No.NO.NO! I am talking about wild gyrations 1--15 degree Celcius shifts from one moment to anothert. I have NEVER seen this in 2 years of using your program. I know all about inaccuracies at low temperatures, that is NOT what I have described.


Which exact sensor is that, can you attach a screenshot ?


----------



## Phillychuck

I tried searching, but got a ton of hits on "h100i" :-(

Any reason hwinfo doesn't support the h100i sensors?

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *Phillychuck*
> 
> I tried searching, but got a ton of hits on "h100i" :-(
> 
> Any reason hwinfo doesn't support the h100i sensors?
> 
> Thanks.


Well, HWiNFO does have support for Corsair Link protocol, however it's disabled. The main reason for this is, that this protocol is not well designed and when the Corsair software is running, any other application trying to access it will case collisions and both utilities will not report correct values. You would have to disable the Corsair software in order to run other tools. Apparently, Corsair should come up with a new version of their software which will allow other tools to use its protocol sometimes in 2014.


----------



## Phillychuck

Quote:


> Originally Posted by *Mumak*
> 
> Well, HWiNFO does have support for Corsair Link protocol, however it's disabled. The main reason for this is, that this protocol is not well designed and when the Corsair software is running, any other application trying to access it will case collisions and both utilities will not report correct values. You would have to disable the Corsair software in order to run other tools. Apparently, Corsair should come up with a new version of their software which will allow other tools to use its protocol sometimes in 2014.


Thanks for the quick reply, Corsair Link seems really clunky to me, I know its needed to control the device but I've just been letting it control itself without the software running. I'll see if I can figure out how to enable it in hwinfo


----------



## Mumak

Quote:


> Originally Posted by *Phillychuck*
> 
> Thanks for the quick reply, Corsair Link seems really clunky to me, I know its needed to control the device but I've just been letting it control itself without the software running. I'll see if I can figure out how to enable it in hwinfo


You won't be able to activate it, because it's hard-disabled







I made such a decision to avoid potential problems users would get when launching it on a system via Corsair Software running.


----------



## Phillychuck

Quote:


> Originally Posted by *Mumak*
> 
> You won't be able to activate it, because it's hard-disabled
> 
> 
> 
> 
> 
> 
> 
> I made such a decision to avoid potential problems users would get when launching it on a system via Corsair Software running.


Gotcha! Thanks for your work on this great tool


----------



## Mumak

Quote:


> Originally Posted by *Phillychuck*
> 
> Gotcha! Thanks for your work on this great tool


I'm currently playing with the idea to enable this sensor with a warning to users, that they need to disable Corsair software, but I still believe that this might cause more problems than advantages...


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> You mean the startup is slow ? If yes, what is the exact "Detecting..." item where it stays too long ?
> That might be improved by disabling some GPU I2C buses. Please attach the HWiNFO Debug File and I can analyze it to see what exactly to disable.


Hangs at "analyzing PCI Bus" but that's fairly brief.

Where it really hangs for a long time is "ATI GPU #61", and #62 and #63.

Other than those 4 spots everything else goes by in a blur.

Not quite sure how to do a debugging file?


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Hangs at "analyzing PCI Bus" but that's fairly brief.
> 
> Where it really hangs for a long time is "ATI GPU #61", and #62 and #63.
> 
> Other than those 4 spots everything else goes by in a blur.
> 
> Not quite sure how to do a debugging file?


Try to disable GPU I2C bus #7 in Settings, if that improves the scan speed and you don't loose the GPU VRMs.
If that doesn't help, enable Debug Mode in Settings. Then let run the complete scan until Sensors appear (might take a bit longer), close HWiNFO and attach/send me the HWiNFO64.DBG file it produced.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> Try to disable GPU I2C bus #7 in Settings, if that improves the scan speed and you don't loose the GPU VRMs.
> If that doesn't help, enable Debug Mode in Settings. Then let run the complete scan until Sensors appear (might take a bit longer), close HWiNFO and attach/send me the HWiNFO64.DBG file it produced.


That worked! Now it's just a moderate hitch when scanning pci bus, before and after that it whizzes by. Thanx for not only making such a useful app but taking the time to help on all these questions.


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> That worked! Now it's just a moderate hitch when scanning pci bus, before and after that it whizzes by. Thanx for not only making such a useful app but taking the time to help on all these questions.


This is due to an attempt to wake GPU cards which might be disabled. I think you don't have such GPUs and can disable the "Wake disabled GPUs" option. That should bring another speed-up









BTW, I'm currently working on a GPU I2C caching option, that should improve launch time on such systems without having to disable GPU buses manually.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> This is due to an attempt to wake GPU cards which might be disabled. I think you don't have such GPUs and can disable the "Wake disabled GPUs" option. That should bring another speed-up


Yup, it's instantaneous load now







Tyvm!


----------



## taem

Two oddities I'm curious about, with how hwinfo64 reports my r9 290 gpu.

Memory clock is off by 1, it's set to 1500 and shows up as such on every other monitor, but hwinfo says 1499. This happens on every memory clock setting, it's always off by 1.

Pcie link speed is reported as 8gbps. The bus is 3.0 x16 and reported as such on other monitors. It's set to auto in bios. This sensor doesn't update anyway but I was curious why it says 8 and not 1 (idle) or 16 (active).


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Two oddities I'm curious about, with how hwinfo64 reports my r9 290 gpu.
> 
> Memory clock is off by 1, it's set to 1500 and shows up as such on every other monitor, but hwinfo says 1499. This happens on every memory clock setting, it's always off by 1.
> 
> Pcie link speed is reported as 8gbps. The bus is 3.0 x16 and reported as such on other monitors. It's set to auto in bios. This sensor doesn't update anyway but I was curious why it says 8 and not 1 (idle) or 16 (active).


I think the other tools just round-up the value of memory clock, whereas HWiNFO reports the exact value as calculated by the GPU logic. Is it displayed as 1499.0 ?

8 Gbps is the maximum transfer rate of the PCIe 3.0 interface. If you mean x1 / x16, this is the PCIe link width, which is a different parameter. I might add reporting this in sensors in the future, currently you should be able to see the actual value of this parameter in the System Summary screen.


----------



## taem

Quick question. Which readout in Sensors shows how much wattage the cpu is drawing?

Another quick q: Do the two VRM Power Out sensors show the total wattage consumed by the gpu? Or just by the two vrms and there is another power source the gpu is drawing on?


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Quick question. Which readout in Sensors shows how much wattage the cpu is drawing?
> 
> Another quick q: Do the two VRM Power Out sensors show the total wattage consumed by the gpu? Or just by the two vrms and there is another power source the gpu is drawing on?


1. That depends on the CPU. I'd need to see a screenshot of the entire sensors screen. Later Intel CPUs can measure their power consumption, some mainboards feature digital PWMs which too can measure particular rail power.

2. Again, I'd need to see a screenshot of the sensors screen. Though in most cases if there are 2 GPU VRMs reported, then the 1st one is for GPU core and the 2nd is GPU VRAM.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> 1. That depends on the CPU. I'd need to see a screenshot of the entire sensors screen. Later Intel CPUs can measure their power consumption, some mainboards feature digital PWMs which too can measure particular rail power.


This isn't the whole sensors screen but they are the only readouts measured in watts:


Is this then the total wattage being used by cpu? It's a 4670k.
Quote:


> 2. Again, I'd need to see a screenshot of the sensors screen. Though in most cases if there are 2 GPU VRMs reported, then the 1st one is for GPU core and the 2nd is GPU VRAM.


Again the only readouts measured in watts are GPU Vrm Power Out for the two VRMs:


It's an R9 290.

If I add these up it's roughly what my meter measures at the wall. I guess the difference comes from drives and fans.


----------



## Mumak

Yes, both should be the total wattage for CPU and GPU, though there still might be a small part of current consumed by other components. I can't tell how much, nor which, this depends on particular design.


----------



## taem

Ok one more question.

What is "GPU VRM Power In (PIN)" and what is "GPU VRM Power out (POut)"?


----------



## Mumak

It's the measured power (voltage * current) on the input and output side of the Voltage Regulator.


----------



## taem

Help! Hwinfo used to show 3 sections for each gpu, the first showing main info like thermal diode, clocks, fan, etc, and the other two showing temps and voltage/current/power for each vrm.

Now it's only showing one section for gpu #2, the main one with thermal diode etc. The vrm sections are missing for gpu #2. They are present for gpu #1.

This is the same crossfire setup I had previously when I did get all three sections for both gpus. I temporarily removed gpu #2 and put it back in, now info missing.

I'm using 4.35-2140. I have Wake Disabled GPUs enabled.


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Help! Hwinfo used to show 3 sections for each gpu, the first showing main info like thermal diode, clocks, fan, etc, and the other two showing temps and voltage/current/power for each vrm.
> 
> Now it's only showing one section for gpu #2, the main one with thermal diode etc. The vrm sections are missing for gpu #2. They are present for gpu #1.
> 
> This is the same crossfire setup I had previously when I did get all three sections for both gpus. I temporarily removed gpu #2 and put it back in, now info missing.
> 
> I'm using 4.35-2140. I have Wake Disabled GPUs enabled.


There can be more reasons why that happened:
- ULPS might be disabling your 2nd GPU when idle. Try to put some load on GPU, or disable ULPS.
- When using the last HWiNFO build, try to disable the "GPU I2C Caching" option. Then run HWiNFO with sensors and check if it's visible. If yes, you can enable that option back.

If nothing helps, please post the HWiNFO Debug File.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> There can be more reasons why that happened:
> - ULPS might be disabling your 2nd GPU when idle. Try to put some load on GPU, or disable ULPS.
> - When using the last HWiNFO build, try to disable the "GPU I2C Caching" option. Then run HWiNFO with sensors and check if it's visible. If yes, you can enable that option back.
> 
> If nothing helps, please post the HWiNFO Debug File.


ULPS was already disabled but unchecking GPU I2C Caching fixed it. Thanks you're awesome. Is GPU I2C Caching something I need/want btw or can I just leave it off?

Oh and one suggestion if I can be so cheeky and ungrateful, I like to move the info I look at the most to the top but right now it's a real pain changing the layout, because unless I'm missing something you have to select whatever you want to move and then click a billion times on the up arrow. And you have to do this for all the entries you want to move. Am I doing it wrong? If not, dude, making layout arrangement easier would be so awesome.


----------



## Mumak

GPU I2C Caching can be a useful option for considerably speeding-up start on some systems with AMD GPUs (maybe some NVIDIA too). It should eliminate certain scans which might take quite long time. In your case, when you took a GPU out and then placed it back it seems it didn't work properly. I'll have a look at that... I think you might enable it back to speed-up the start.

I know that changing the order of sensor items can be painful in some cases. I'm thinking about how to improve this, maybe adding the ability to select multiple items might help...


----------



## Barefooter

Quote:


> Originally Posted by *Mumak*
> 
> I know that changing the order of sensor items can be painful in some cases. I'm thinking about how to improve this, maybe adding the ability to select multiple items might help...


That would be great! That's one reason why I don't upgrade to the newer versions as often as they come out because it does take awhile to get everything I want up top where I like it.


----------



## Mumak

Quote:


> Originally Posted by *Barefooter*
> 
> That would be great! That's one reason why I don't upgrade to the newer versions as often as they come out because it does take awhile to get everything I want up top where I like it.


Upgrading to a new version doesn't reset the order of sensor items. These settings are kept.


----------



## Barefooter

I will try again. Every time I've upgraded I had to redo the order. I will report back.


----------



## M1kuTheAwesome

Sorry if this has been answered already but I have no time to read back. I wanted to stress test my CPU OC and as always, use HWiNFO64 for monitoring. However, when I ran it, I couldn't see the sensors window. It was open on taskbar, but on my 2 monitors there was nothing. The summary window opens alright.
I already reinstalled HWiNFO but that changed nothing. Is there a fix to this?


----------



## Mumak

Quote:


> Originally Posted by *M1kuTheAwesome*
> 
> Sorry if this has been answered already but I have no time to read back. I wanted to stress test my CPU OC and as always, use HWiNFO64 for monitoring. However, when I ran it, I couldn't see the sensors window. It was open on taskbar, but on my 2 monitors there was nothing. The summary window opens alright.
> I already reinstalled HWiNFO but that changed nothing. Is there a fix to this?


I'm not sure what exactly happened, I'd need more details to check that.
Before launching the scan click Settings and then "Reset Preferences". That should fix it.


----------



## Mumak

As a small (and quick) improvement to sensor reordering, in the next build I'll add buttons for moving items straight to the top or bottom of the list.
Multi-row selection will require more effort, but I'm currently busy with adding new features (e.g. AMD Carrizo support







), so this will come later...


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> As a small (and quick) improvement to sensor reordering, in the next build I'll add buttons for moving items straight to the top or bottom of the list.
> Multi-row selection will require more effort, but I'm currently busy with adding new features (e.g. AMD Carrizo support
> 
> 
> 
> 
> 
> 
> 
> ), so this will come later...


Straight to top would be brilliant. Multi selection not important, this isn't something you have to do more than once in a while.

And my settings are kept when I get a new version, even though I'm using portable. Don't know why that other guys setting didn't keep.


----------



## M1kuTheAwesome

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure what exactly happened, I'd need more details to check that.
> Before launching the scan click Settings and then "Reset Preferences". That should fix it.


It worked. Thank you, sir!


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Straight to top would be brilliant. Multi selection not important, this isn't something you have to do more than once in a while.
> 
> And my settings are kept when I get a new version, even though I'm using portable. Don't know why that other guys setting didn't keep.


Check the new version 4.36 - it adds buttons to move items to top or bottom.


----------



## os2wiz

Quote:


> Originally Posted by *taem*
> 
> Straight to top would be brilliant. Multi selection not important, this isn't something you have to do more than once in a while.
> 
> And my settings are kept when I get a new version, even though I'm using portable. Don't know why that other guys setting didn't keep.


Mumak, I strongly contend that your program through version 4.34 does NOT measure temperatures properly with Kaveri A10-7850k. I have much higher temperatures on this chip, both at idle and under load than I have on my AMD FX-8350, even though I run it a lower overclock. I do think you must pay more attention to this issue. The same thing happened with the competitor program hardware monitor and they are working on working out the problem with their next upgrade. You have never acknowledged the problem.


----------



## taem

Quote:


> Originally Posted by *Mumak*
> 
> Check the new version 4.36 - it adds buttons to move items to top or bottom.


Awesome! Off to download it now. Thanks for all your work.


----------



## Mumak

Quote:


> Originally Posted by *os2wiz*
> 
> Mumak, I strongly contend that your program through version 4.34 does NOT measure temperatures properly with Kaveri A10-7850k. I have much higher temperatures on this chip, both at idle and under load than I have on my AMD FX-8350, even though I run it a lower overclock. I do think you must pay more attention to this issue. The same thing happened with the competitor program hardware monitor and they are working on working out the problem with their next upgrade. You have never acknowledged the problem.


Oh, yes.. I have several times explained what's the issue - it's a problem of the on-die thermal sensor and has been acknowledged by AMD. It's providing erratic values in many cases, especially at lower temperatures.
Unfortunately, there's no fix for this possible - it's a hardware flaw.


----------



## os2wiz

Quote:


> Originally Posted by *Mumak*
> 
> Oh, yes.. I have several times explained what's the issue - it's a problem of the on-die thermal sensor and has been acknowledged by AMD. It's providing erratic values in many cases, especially at lower temperatures.
> Unfortunately, there's no fix for this possible - it's a hardware flaw.


So there is no way to know with any accuracy to know my cpu temp? Then will this cause unnecessary shutdowns and throttling to protect cpu against incorrectly perceived thermal danger?


----------



## Mumak

Quote:


> Originally Posted by *os2wiz*
> 
> So there is no way to know with any accuracy to know my cpu temp? Then will this cause unnecessary shutdowns and throttling to protect cpu against incorrectly perceived thermal danger?


There's not much details about this available from AMD, but I (and some others) believe, that the sensor works with better accuracy at higher temperatures / closer to maximum, or the internal firmware uses some correction factors. There shouldn't be problems with thermal protection.


----------



## psyside

Quote:


> Originally Posted by *Mumak*
> 
> Check the new version 4.36 - it adds buttons to move items to top or bottom.


Where are this buttons?


----------



## Mumak

Quote:


> Originally Posted by *psyside*
> 
> Where are this buttons?


Configure Sensors - Layout


----------



## paradoxum

Quote:


> Originally Posted by *Mumak*
> 
> Configure Sensors - Layout


Thanks for this. I remember trying to re-order my list before this. Is multi-select moving still planned?

Also, how do I get rid of this little popup window? I can't remember what I did to turn it on, and I reset my preferences and it comes back.

http://i.imgur.com/dUmpsQi.png

Thanks.

Also, stop releasing updates so often! (joking). every time I launch the program I get a notification there's an update!


----------



## Mumak

Quote:


> Originally Posted by *paradoxum*
> 
> Thanks for this. I remember trying to re-order my list before this. Is multi-select moving still planned?
> 
> Also, how do I get rid of this little popup window? I can't remember what I did to turn it on, and I reset my preferences and it comes back.
> 
> http://i.imgur.com/dUmpsQi.png
> 
> Thanks.
> 
> Also, stop releasing updates so often! (joking). every time I launch the program I get a notification there's an update!


Yes, the muti-row selection feature is still in plan, but I'm currently working on a lot of other features... i.e. Haswell-E, Broadwell, Skylake, new mainboards and GPUs, etc... So there will be a new update soon









You don't want that small window with clocks to open automatically? That's can't be disabled yet..


----------



## paradoxum

Quote:


> Originally Posted by *Mumak*
> 
> You don't want that small window with clocks to open automatically? That's can't be disabled yet..


No, I thought I turned an option on for it to show when I was adding things to the systray, didn't realize it was happening by it's own volition.

Thanks


----------



## Mumak

Quote:


> Originally Posted by *paradoxum*
> 
> No, I thought I turned an option on for it to show when I was adding things to the systray, didn't realize it was happening by it's own volition.
> 
> Thanks


That window with clock bars is a part of the System Summary window. So if you disable opening of the Summary, that one won't open either.


----------



## paradoxum

Quote:


> Originally Posted by *Mumak*
> 
> That window with clock bars is a part of the System Summary window. So if you disable opening of the Summary, that one won't open either.


Ah, I see the difference now. I remember those bars being a part of the summary window itself. Why did you separate them?

Personally, I would love to see the summary and sensor window integrated, and done away with the 'main' window, so I can launch it and it will just look something like this:

http://i.imgur.com/4DVw289.png


----------



## Mumak

Quote:


> Originally Posted by *paradoxum*
> 
> Ah, I see the difference now. I remember those bars being a part of the summary window itself. Why did you separate them?
> 
> Personally, I would love to see the summary and sensor window integrated, and done away with the 'main' window, so I can launch it and it will just look something like this:
> 
> http://i.imgur.com/4DVw289.png


I had to find another way how to display the clock bars for systems with more cores. The previous implementation allowed 8 clocks max (8 cores) and extending that layout for upcoming new CPUs (some with lots of cores) wouldn't look well.
I believe there are only few users preferring such an integration, most of them utilize sensors only. I'll give it a thought anyway...


----------



## paradoxum

Quote:


> Originally Posted by *Mumak*
> 
> I believe there are only few users preferring such an integration, most of them utilize sensors only. I'll give it a thought anyway...


It would just be an option, of course right? I wouldn't want to try and force changes on people that they don't want. Maybe that's what you mean by giving it a thought [as to making it an option]

Thanks again.


----------



## Mumak

Yes.. When time will allow that


----------



## Blue Dragon

Before I even ask a question I have to say Thank You!!!







I love this program and actually bought my G19 keyboard just for it. - http://www.overclock.net/t/1460118/logitech-g19-keyboard-lcd-hwinfo64-quick-guide

If I try to run any update over HW64_430 my second GPU turns and stays on even at idle. utilization steady 90% but temps lead me to believe this is false reading. haven't really had time to play with it, any tricks getting it to work with CF 7870's?


----------



## Jamaican Reaper

Thx for this program man,i use it everytime i game to monitor my hardware....


----------



## Mumak

Quote:


> Originally Posted by *Blue Dragon*
> 
> Before I even ask a question I have to say Thank You!!!
> 
> 
> 
> 
> 
> 
> 
> I love this program and actually bought my G19 keyboard just for it. - http://www.overclock.net/t/1460118/logitech-g19-keyboard-lcd-hwinfo64-quick-guide
> 
> If I try to run any update over HW64_430 my second GPU turns and stays on even at idle. utilization steady 90% but temps lead me to believe this is false reading. haven't really had time to play with it, any tricks getting it to work with CF 7870's?


I'll need more information to track this issue.
- Do you have ULPS enabled ?
- When does that GPU get enabled - during the HWiNFO scan and then stays on with 90% load until you close HWiNFO ?
- Have you tried to disable the "Wake disabled GPUs" option? It might be cause by a problem in OpenCL support of GPU drivers...


----------



## Blue Dragon

thank you sir! it was the wake disabled GPU option, I was just looking in the sensor options, not the main menu.


----------



## lawson67

Quote:


> Originally Posted by *Mumak*
> 
> I'll need more information to track this issue.
> - Do you have ULPS enabled ?
> - When does that GPU get enabled - during the HWiNFO scan and then stays on with 90% load until you close HWiNFO ?
> - Have you tried to disable the "Wake disabled GPUs" option? It might be cause by a problem in OpenCL support of GPU drivers...


Hi Mumak firstly thanks for your fantastic all in one sensor monitoring program that simply makes my other programs that i had to run such as real temp to name just one completely redundant!
However i have a problem and would like to know if you could help me find the solution?....I have 2 new R9 290 cards installed in crossfire and i have ULPS disabled!...The problem that i am having is unlike GPU 1 which HWiNFO can see and report my GPU D3D Memory Dedicated and GPU D3D Memory Dynamic and GPU Memory Utilization!...However On my second GPU HWiNFO simply fails to see these sensors?...and for GPU Memory Utilization it does show up but it reads only 0%?...do you know of any solution or workaround for this problem?

The picture below will show you the settings i am using and show you the missing values!...and once again thanks for your fantastic Program









Edit: Also you will see from the picture below that HWiNFO has the 6x6 SMbus exclusion checked!...this came checked at default in HWiNFO and i have left it checked incase it has been done for some reason that i do not know?...However i have unchecked and rechecked this box and shutdown and restarted HWiFO yet i see know change to the sensors that are displayed for my GPU,s from the GPU I2C bus 6 which my graphic cards appear to use!...I wondered why by default the 6X6 I2C bus was excluded?...However below are my settings....Thanks in advance for your help


----------



## Mumak

I'm aware of the issue, that on some multi-GPU configs the D3D memory usage is not displayed for secondary GPUs, but I don't know why that happens. This is based on undocumented functions, so unfortunately I don't have a solution for that. It's not the best way how to determine GPU memory usage, however currently it's the only way for AMD and Intel GPUs, since they don't seem to feature an interface to provide such information.

But it's not related to the GPU I2C Bus Exclusion. By default all checkboxes are disabled, meaning that all GPU I2C buses are scanned. If you have some checked, and you're sure you haven't done that, maybe you copied HWiNFO together with the INI file containing such settings.


----------



## lawson67

Quote:


> Originally Posted by *Mumak*
> 
> I'm aware of the issue, that on some multi-GPU configs the D3D memory usage is not displayed for secondary GPUs, but I don't know why that happens. This is based on undocumented functions, so unfortunately I don't have a solution for that. It's not the best way how to determine GPU memory usage, however currently it's the only way for AMD and Intel GPUs, since they don't seem to feature an interface to provide such information.
> 
> But it's not related to the GPU I2C Bus Exclusion. By default all checkboxes are disabled, meaning that all GPU I2C buses are scanned. If you have some checked, and you're sure you haven't done that, maybe you copied HWiNFO together with the INI file containing such settings.


Ok thanks for you answer and yes i must have checked that late one night by mistake and shall uncheck it now....thanks for confirming that to me...I also would like to point out that HWiNFO is also not the only program that can not read these sensors...Open hardware monitor could not read them along with playclaw and others!...hopefully in the future we will have documented functions of these sensor so that they can be read and surported!.....Also i have to say that excluding all of the other GPU IC2 bus addresses that my cards are clearly not using allows for HWiNFO to load all of my sensors in seconds!....what a great program you have made!...Thank you very much!


----------



## Mumak

Quote:


> Originally Posted by *lawson67*
> 
> Ok thanks for you answer and yes i must have checked that late one night by mistake and shall uncheck it now....thanks for confirming that to me...I also would like to point out that HWiNFO is also not the only program that can not read these sensors...Open hardware monitor could not read them along with playclaw and others!...hopefully in the future we will have documented functions of these sensor so that they can be read and surported!.....Also i have to say that excluding all of the other GPU IC2 bus addresses that my cards are clearly not using allows for HWiNFO to load all of my sensors in seconds!....what a great program you have made!...Thank you very much!


I really hope that AMD and Intel will someday offer functions for more precise monitoring. NVIDIA has such functions in their NVAPI and they work great.
Disabling all GPU I2C buses (or completely disabling GPU I2C support) can significantly reduce the scan time on some machines, however you will loose the GPU VRM or additional GPU sensors.
The recently added GPU I2C Caching option should also significantly reduce the scan time even if you have all GPU I2C buses enabled and you won't loose the additional sensors.


----------



## lawson67

Quote:


> Originally Posted by *Mumak*
> 
> I really hope that AMD and Intel will someday offer functions for more precise monitoring. NVIDIA has such functions in their NVAPI and they work great.
> Disabling all GPU I2C buses (or completely disabling GPU I2C support) can significantly reduce the scan time on some machines, however you will loose the GPU VRM or additional GPU sensors.
> The recently added GPU I2C Caching option should also significantly reduce the scan time even if you have all GPU I2C buses enabled and you won't loose the additional sensors.


Excluding all GPU IC2 bus addressees other than 6 HWiNFO can still see my VRM temps as conformed in the pictures i posted above!...Also the displayed values are correct and perfectly match GPU-Z









Also it loads all of my sensors in only 3 seconds!...outstanding!


----------



## djkomrad

so im running the sapphire 280x, and the hwinfo only shows the core sensors and voltage, no vrm info. anyway to fix this? i heard that ati may have removed these sensors, but that is unconfirmed


----------



## Mumak

Quote:


> Originally Posted by *djkomrad*
> 
> so im running the sapphire 280x, and the hwinfo only shows the core sensors and voltage, no vrm info. anyway to fix this? i heard that ati may have removed these sensors, but that is unconfirmed


That depends on particular model of the GPU. It's possible to monitor GPU VRM values only if the GPU features a Digital PWM VR circuit. Only some models have this, i.e. my Club 3D HD7950's RoyalKing have such, but a GIGABYTE R9 280X OC WF3 doesn't.


----------



## lawson67

Quote:


> Originally Posted by *Mumak*
> 
> I really hope that AMD and Intel will someday offer functions for more precise monitoring. NVIDIA has such functions in their NVAPI and they work great.
> Disabling all GPU I2C buses (or completely disabling GPU I2C support) can significantly reduce the scan time on some machines, however you will loose the GPU VRM or additional GPU sensors.
> The recently added GPU I2C Caching option should also significantly reduce the scan time even if you have all GPU I2C buses enabled and you won't loose the additional sensors.


Hi Mumak i would like to update HWINfO i am using the 64bit stand alone version however i would like to switch to the installed version but if thats to diffecult and to save settings then i dont mind downloading the new stand alone version again!...

Is it just a case of backing up the HWiNFO64.INI and over writing the one that comes with the updated version?...And can that also be done with the installed version?....Thanks for any help Mumak


----------



## Mumak

Quote:


> Originally Posted by *lawson67*
> 
> Hi Mumak i would like to update HWINfO i am using the 64bit stand alone version however i would like to switch to the installed version but if thats to diffecult and to save settings then i dont mind downloading the new stand alone version again!...
> 
> Is it just a case of backing up the HWiNFO64.INI and over writing the one that comes with the updated version?...And can that also be done with the installed version?....Thanks for any help Mumak


Yep, just replace the newly installed INI file with yours. The installation also asks you if you want to replace it. That's it - simple








Sensor-specific settings are kept in the registry, so they are retained after reinstalling.


----------



## lawson67

Quote:


> Originally Posted by *Mumak*
> 
> Yep, just replace the newly installed INI file with yours. The installation also asks you if you want to replace it. That's it - simple
> 
> 
> 
> 
> 
> 
> 
> 
> Sensor-specific settings are kept in the registry, so they are retained after reinstalling.


Thank you very much for your reply and your help Mumak and once again thank you for such a great piece of software that has become an essential component of my PC!...


----------



## Denca

The latest version is showing me HyperThreading usage while I have it disabled. I can confirm its disabled because I checked it in the resource monitor.


----------



## Mumak

Quote:


> Originally Posted by *Denca*
> 
> The latest version is showing me HyperThreading usage while I have it disabled. I can confirm its disabled because I checked it in the resource monitor.


Where is it showing this? Please post a screenshot.


----------



## Denca

Sure thing. The first screen is from the sensors only part of the HWiNFO64 and the other one is from resource manager to show you that my HT is off. If its on it shows on the resource manager it self.





I've been using *this great tool* for years now and as far as I remember is that if the HT was off it would not show on the sensor only tab.


----------



## 331149

I would really love an import/export of sensor settings. I just reinstalled Windows and had hwinfo + it's ini file backed up (I use the portable version) and all of my prev settings were gone. Now I have to rename, rearrange and hide stuff. Ugh.


----------



## Mumak

Quote:


> Originally Posted by *Denca*
> 
> Sure thing. The first screen is from the sensors only part of the HWiNFO64 and the other one is from resource manager to show you that my HT is off. If its on it shows on the resource manager it self.
> 
> 
> 
> 
> 
> I've been using *this great tool* for years now and as far as I remember is that if the HT was off it would not show on the sensor only tab.


What you see doesn't mean that HT is enabled at all. HWiNFO shows only one thread per core there and it doesn't show any HT units (which would be seen as Thread #1). So it's in sync with the Task Manager and I don't see any problems there.


----------



## Mumak

Quote:


> Originally Posted by *TheBDK*
> 
> I would really love an import/export of sensor settings. I just reinstalled Windows and had hwinfo + it's ini file backed up (I use the portable version) and all of my prev settings were gone. Now I have to rename, rearrange and hide stuff. Ugh.


I'll put that on my list. Currently exporting/importing sensor settings can be done using the "regedit" tool. Just locate the respective HKEY_CURRENT_USER\Software\HWiNFO64 key and export it. Then after reinstall just run the saved reg file and all settings will be restored.


----------



## Denca

Quote:


> Originally Posted by *Mumak*
> 
> What you see doesn't mean that HT is enabled at all. HWiNFO shows only one thread per core there and it doesn't show any HT units (which would be seen as Thread #1). So it's in sync with the Task Manager and I don't see any problems there.


Good to know. Thanks for a quick response and this great *( read essential )* tool Mumak


----------



## Dasboogieman

Hi might be a noob question

I have an Asus P8Z68 V Gen 3 motherboard with an AMD 290 GPU. I recently dropped in an i5-3570k replacement for the i5-2500k. Just in the Hwinfo tab about PCIE I saw it only reports 8Gbps. The GPU has the full 16 lanes allocated since I have nothing else plugged in except a soundcard on the PCIe x4 port (linked to the Southbridge). I was under the impression PCIE 3.0 x16 allows up to 16Gbps bandwith.

I would like to know if this is a hardware thing or if the Hwinfo is reporting the info wrong.

I also am fully aware the performance difference is neligible however, I would still like to know the reasoning for this report.

Thanks


----------



## Mumak

This is normal for later GPUs - when idle, they reduce the PCIe interface rate/width. Just put some load on the GPU and watch how it goes to maximum width.


----------



## Dasboogieman

Quote:


> Originally Posted by *Mumak*
> 
> This is normal for later GPUs - when idle, they reduce the PCIe interface rate/width. Just put some load on the GPU and watch how it goes to maximum width.


It idles at 2.5Gbps, I am aware of that.

However, at load it only reports 8Gbps but GPUz confirms that it is running at the full x16 PciE 3.0


----------



## Mumak

8 Gbps is the maximum transfer rate of PCIe 3.0. This is the transfer rate, link width (x16) is a different paramter.


----------



## 5orehead

Hi guys, i have ASUS SABERTOOTH MARK 1 motherboard and noticed strange thing. In HWINFO64 i have no real vcore value, only VID. I posted screenshot, is there a way to make it visible? Thanks

P.S. Asus utility Ai Suite III shows me vcore value, but it's very heavy and doesn't show proper CPU temp.


----------



## Dasboogieman

Quote:


> Originally Posted by *Mumak*
> 
> 8 Gbps is the maximum transfer rate of PCIe 3.0. This is the transfer rate, link width (x16) is a different paramter.


OOOOOOOOOOOOOOOH I get it now.
http://en.wikipedia.org/wiki/PCI_Express

Hwinfo is reporting 8 Gigabits per lane, which equals 128 Gigabits over 16 lanes. This equals roughly 16 Gigabytes per second.

I feel enlightened


----------



## Mumak

Quote:


> Originally Posted by *5orehead*
> 
> Hi guys, i have ASUS SABERTOOTH MARK 1 motherboard and noticed strange thing. In HWINFO64 i have no real vcore value, only VID. I posted screenshot, is there a way to make it visible? Thanks
> 
> P.S. Asus utility Ai Suite III shows me vcore value, but it's very heavy and doesn't show proper CPU temp.


Please download the latest HWiNFO Beta build - v4.39, Build 2220. This adds support of Z97 series mainboards.
Let me know if there are still any issues...


----------



## 5orehead

Quote:


> Originally Posted by *Mumak*
> 
> Please download the latest HWiNFO Beta build - v4.39, Build 2220. This adds support of Z97 series mainboards.
> Let me know if there are still any issues...


Thank you, it works. I'll keep an eye on it and post here, if there will be any issues.


----------



## Blue Dragon

my asus R9 290 is showing two different vrm temp sets-

I'm guessing the first set is correct due to reports of VRM1 getting hotter than VRM2 -

not a big deal or anything, just more curious to which is correct.
BTW- I did rename first set, they both have same exact names- I just shortened it for display on my G19 keyboard LCD.


----------



## Mumak

Usually (if available) there are 2 VRM sensors, where in most cases the 1st is the GPU Core VRM and 2nd is the GPU VRAM VRM.
The temperatures under those sensors is reported for 2 loops which is in most cases mirrored between these two sensors. So:
GPU VRM1 (Core) Temp2 = GPU VRM2 (Memory) Temp1
GPU VRM2 (Memory) Temp2 = GPU VRM1 (Core) Temp1
So basically you could ignore VRM1 and VRM2 Temp2 values which are just mirrored ones and Temp1 values are actual for the particular VRM.


----------



## Belial

edit


----------



## MrStrat007

Good afternoon, I have a question in regards to the CPU VCore monitoring. Hardware is a Gigabyte z87X-OC motherboard and a 4770k CPU. HWINFO reports 4 vcore sensors, three of which change with load and fluctuate up and down. The fourth one (VCore 3) stays at a constant 1.668 volts!! Is this just an error or do I have a serious hardware problem?

Thanks
-Strat



Spoiler: Screenshot







Edit: I think I derped majorly and that that doesn't in fact relate to the CPU as I thought it did. If this is so, my apologies!


----------



## TheCautiousOne

Quote:


> Originally Posted by *FromUndaChz*
> 
> +Rep buddy, love this program!
> 
> This feature rules:


how do you get it to display like that??


----------



## Mumak

Quote:


> Originally Posted by *MrStrat007*
> 
> Good afternoon, I have a question in regards to the CPU VCore monitoring. Hardware is a Gigabyte z87X-OC motherboard and a 4770k CPU. HWINFO reports 4 vcore sensors, three of which change with load and fluctuate up and down. The fourth one (VCore 3) stays at a constant 1.668 volts!! Is this just an error or do I have a serious hardware problem?
> 
> Thanks
> -Strat
> 
> 
> 
> Spoiler: Screenshot
> 
> 
> 
> 
> 
> 
> 
> Edit: I think I derped majorly and that that doesn't in fact relate to the CPU as I thought it did. If this is so, my apologies!


No, it seems HWiNFO is not properly reporting the Vcore3 value. I'll check this and fix eventually.


----------



## Mumak

Quote:


> Originally Posted by *TheCautiousOne*
> 
> how do you get it to display like that??


Check here: http://www.overclock.net/t/1229915/how-to-cpu-and-gpu-usage-along-with-fps-in-game


----------



## MrStrat007

Quote:


> Originally Posted by *Mumak*
> 
> No, it seems HWiNFO is not properly reporting the Vcore3 value. I'll check this and fix eventually.


Thank you for the quick reply. I checked today with a multimeter (forgot I had voltage read points for each core) and the Vcore is sitting around 0.75V at idle across all 4 cores, which is where it should be. Phew.

Wonderful program and I appreciate all the work you have and are putting into it!


----------



## Mumak

Quote:


> Originally Posted by *MrStrat007*
> 
> Thank you for the quick reply. I checked today with a multimeter (forgot I had voltage read points for each core) and the Vcore is sitting around 0.75V at idle across all 4 cores, which is where it should be. Phew.
> 
> Wonderful program and I appreciate all the work you have and are putting into it!


If you could run load on different cores, then measure the exact voltage per each core and compare with HWiNFO, I could adjust the CoreX values (maybe they are in the wrong order).


----------



## MrStrat007

Quote:


> Originally Posted by *Mumak*
> 
> If you could run load on different cores, then measure the exact voltage per each core and compare with HWiNFO, I could adjust the CoreX values (maybe they are in the wrong order).


As far as loading the cores go, Does it matter which program I use to do this? I can run IBT now and check voltages or have my brother game on my pc while I measure voltages and compare them to HWinfo's reported voltages. I can do this tonight when he gets home.

Is it necessary to load each core separately or should comparing DMM and HWInfo during a stress test yield the same results?


----------



## Mumak

It doesn't matter which method you use. It's just important that one core has a different voltage, so it can be easily identified which one it is.
When comparing with HWiNFO please check the current Vcore, Vcore0, Vcore1 and Vcore2 values.


----------



## fateswarm

When I read current/power/voltage outputs from an IR3563B controller, I read directly the chip's output and not something calculated by hwinfo, right?


----------



## Mumak

Quote:


> Originally Posted by *fateswarm*
> 
> When I read current/power/voltage outputs from an IR3563B controller, I read directly the chip's output and not something calculated by hwinfo, right?


Yes, all those values are measured by the IR3563.


----------



## fateswarm

Quote:


> Originally Posted by *Mumak*
> 
> Yes, all those values are measured by the IR3563.


Thanks very much!


----------



## MSuomi

Hello, all. With latest beta and the newest stable, my LCDHost started to crash (with latest beta). I went back to earlier version (which worked), but updated just to newest stable. No help, as soon as HWinfo starts, LCDHost crashes (using it with my G19). Latest LCDHost. Any idea, anyone?


----------



## Duality92

When adding/removing sensors from showing in the list, the list automatically goes back to top. With a lot of sensors being removed (I got like 110), I find myself scrolling down for each and every one. I think that if you would just leave the whole list there with check boxes and the ones selected would be in bold and the ones disabled from showing to be regular text/light gray highlight. It would be more visual too.

Also, as is, if you want to re-enable sensors and have a lot hidden, it's not easy to find it exactly because you can only see 4 rows at a time.

But overall. I simply won't/don't use any other monitoring program, because for me, it has everything I need!


----------



## Mumak

Quote:


> Originally Posted by *MSuomi*
> 
> Hello, all. With latest beta and the newest stable, my LCDHost started to crash (with latest beta). I went back to earlier version (which worked), but updated just to newest stable. No help, as soon as HWinfo starts, LCDHost crashes (using it with my G19). Latest LCDHost. Any idea, anyone?


I have reported this to the author of LCDHost plug-in. Will let you know if there's an update.


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> When adding/removing sensors from showing in the list, the list automatically goes back to top. With a lot of sensors being removed (I got like 110), I find myself scrolling down for each and every one. I think that if you would just leave the whole list there with check boxes and the ones selected would be in bold and the ones disabled from showing to be regular text/light gray highlight. It would be more visual too.
> 
> Also, as is, if you want to re-enable sensors and have a lot hidden, it's not easy to find it exactly because you can only see 4 rows at a time.
> 
> But overall. I simply won't/don't use any other monitoring program, because for me, it has everything I need!


Are you removing the items via the Settings/Layout or the main sensors screen?
I believe the way of removing sensors you suggest (checkboxes, etc) would not be acceptable for most users, since they really want some values to disappear.
I'll check how to improve the behavior when removing items.


----------



## Duality92

Quote:


> Originally Posted by *Mumak*
> 
> Maybe it would be simpler to remove sensors from the Settings/Layout screen. I believe the way of removing sensors you suggest (checkboxes, etc) would not be acceptable for most users, since they really want some values to disappear.
> I'll check how to improve the behavior in the main sensors window when removing items.


I really want some to disapear too, wait, I'll sketch up something in paint to show you.


----------



## Duality92

Like this







instead of the current method for hidding items.
Quote:


> Originally Posted by *Mumak*
> 
> Are you removing the items via the Settings/Layout or the main sensors screen?
> I believe the way of removing sensors you suggest (checkboxes, etc) would not be acceptable for most users, since they really want some values to disappear.
> I'll check how to improve the behavior when removing items.


I'm hiding items via this screen by unchecking the "show" box.


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> 
> 
> Like this
> 
> 
> 
> 
> 
> 
> 
> instead of the current method for hidding items.
> I'm hiding items via this screen by unchecking the "show" box.


Sorry, I misunderstood it first. I really like your idea, I'll will put that into my to-do list !








I'll try to slightly improve the behavior of the current design, later will do your idea, which will require more time for implementation.


----------



## Duality92

Quote:


> Originally Posted by *Mumak*
> 
> Sorry, I misunderstood it first. I really like your idea, I'll will put that into my to-do list !
> 
> 
> 
> 
> 
> 
> 
> 
> I'll try to slightly improve the behavior of the current design, later will do your idea, which will require more time for implementation.


Awesome


----------



## MSuomi

Quote:


> Originally Posted by *Mumak*
> 
> I have reported this to the author of LCDHost plug-in. Will let you know if there's an update.


Thanks, great. I went back to 4.40 and it doesn't crash now. Excellent work with HWinfo, everything I need in 1 package. Earlier I had to use at least 2 different programs to get the info for cpu and gpu. Keep up the good work


----------



## Mumak

Quote:


> Originally Posted by *MSuomi*
> 
> Thanks, great. I went back to 4.40 and it doesn't crash now. Excellent work with HWinfo, everything I need in 1 package. Earlier I had to use at least 2 different programs to get the info for cpu and gpu. Keep up the good work


The original author of the LCDHost plugin is no longer working on it. Best would be to report this issue over at LCDHost forums: http://forum.linkdata.se/lcdhost-plugins/release-lhmonitoring-v1.05-219.60.html


----------



## By-Tor

I have been using HWInfo64 along with HWMonitor for sometime and this combo is a lot of help in monitoring my system.

I have noticed some people posting there readings and I notice a sensor named CPU Power and it's reading in watts. I'm using the same version as this person that posted this in another thread and as you can see his shows this reading.

I can't find this sensor listed on my install of the same version.

Could this be that my motherboard does not allow this sensor to work or even show up in the list?

Thanks


----------



## Mumak

Presence of this sensor depends on two factors - CPU and BIOS.
Most modern CPUs have a capability to measure their own power - most Intel, some AMD. But I have seen some systems (especially AMD), where even if the CPU did support power monitoring, the power values were not available. I believe that was because the BIOS didn't properly initialize some features in the CPU. A BIOS update might help then...


----------



## By-Tor

I'm 4 Bios updates behind, so updating may help.

TY


----------



## By-Tor

I updated to the newest Bios and that did the trick and CPU Power was available until I restarted my computer then it was gone again...

Scrathing head....


----------



## Mumak

Quote:


> Originally Posted by *By-Tor*
> 
> I updated to the newest Bios and that did the trick and CPU Power was available until I restarted my computer then it was gone again...
> 
> Scrathing head....


Hmm, then you should contact the mainboard vendor.


----------



## By-Tor

Quote:


> Originally Posted by *Mumak*
> 
> Hmm, then you should contact the mainboard vendor.


Figured out why I was not getting the reading in the first place...

AMD Turbo Core has to be in Auto or Enabled for this feature (CPU Power) to work. I always have mine disabled when overclocking...

Strange....


----------



## fateswarm

There's a person in the devil's canyon or haswell's oc club latest replies that figured their board shows the vin and vcore with switched numbers by the way.


----------



## Mumak

Quote:


> Originally Posted by *fateswarm*
> 
> There's a person in the devil's canyon or haswell's oc club latest replies that figured their board shows the vin and vcore with switched numbers by the way.


Where exactly? Please supply more details, or a pointer to the particular post.


----------



## fateswarm

Scrap that. It was that other stupid software.







Unless it's a similar issue manifested on this.

http://www.overclock.net/t/1411077/haswell-overclocking-guide-with-statistics/15100_100#post_22787191


----------



## LostParticle

Hello









Congratulations for your amazing program! I use it all the time and I will also use it with the Aquasuite!

I have one question, though: - How come and your program does not show the DRAM voltage and the CPU/NB voltage, in real time? I mean, the actual values? And most importantly: can this be fixed in a future version? Should I use an older version, perhaps?

Also, in this latest version, CPU package temp has suddenly disappeared!

Here is a screenshot, and my system is shown in my signature. Thank you!









ps: I have the latest BIOS


----------



## Mumak

DRAM voltage and NB voltage should be displayed under the ASUS EC sensor. I see you have a lot of values hidden and probably have changed the order of sensors. Please first check at the bottom of the sensors list if you maybe see those and also check if those values are not hidden.
If you that didn't work, please attach the HWiNFO Debug File for analysis.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> DRAM voltage and NB voltage should be displayed under the ASUS EC sensor. I see you have a lot of values hidden and probably have changed the order of sensors. Please first check at the bottom of the sensors list if you maybe see those and also check if those values are not hidden.
> If you that didn't work, please attach the HWiNFO Debug File for analysis.


Thanks for the reply, I will answer more analytically in a bit. Where can I find the debug file, please?


----------



## Mumak

Check this on how to create a Debug File: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Check this on how to create a Debug File: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


I have created the debug file but since it is a .DBG file the site does not allow me to attach it or to send it via pm to you. How can I upload it here or send it to you?

Besides that, I have restored the order in the sensor's panel. Here is a screenshot of the program:


Spoiler: Warning: Spoiler!







Also, here is a screenshot from AIDA64 in which these values are represented correctly:


Spoiler: Warning: Spoiler!







Please help me make HWiNFO64 show these values, as well.

Thank you.


----------



## Mumak

Try to compress the DBG file using any tool like ZIP, RAR, 7zip and attach here. If that won't work, please send me that via e-mail - my address is in HWiNFO









EDIT - No need for that anymore.. I think I found the bug


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Try to compress the DBG file using any tool like ZIP, RAR, 7zip and attach here. If that won't work, please send me that via e-mail - my address is in HWiNFO


okay, done!









HWiNFO64.zip 35k .zip file


----------



## Mumak

Try this build, it should fix it







www.hwinfo.com/beta/hw64_445_2302.zip
Let me know...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Try this build, it should fix it
> 
> 
> 
> 
> 
> 
> 
> www.hwinfo.com/beta/hw64_445_2302.zip
> Let me know...


Thank you very much for the lightning fast reply!!

It seems that the DRAM voltage is shown correctly now but I was not able to see the CPU/NB voltage value anywhere...

I've loaded another overclocking profile of mine and ran a five mimutes Small FFTs Prime95 test. Here is the screenshot:


Spoiler: Warning: Spoiler!







To give you an idea, this profile has the following settings in the BIOS:

- CPU Manual voltage = 1,468750 V
- CPU/NB Manual voltage = 1,268750 V
- DRAM voltage = 1,635000 V (it seems that the motherboard regulates this one)

Thank you


----------



## Mumak

The CPU/NB voltage doesn't in fact come from a real sensor, it's rather a readout of a value that's set. So that's the reason why it's not reported in sensors.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The CPU/NB voltage doesn't in fact come from a real sensor, it's rather a readout of a value that's set. So that's the reason why it's not reported in sensors.


Okay, I see...

So, there's no way HWiNFO64 will show this value, as well? Like AIDA does?
The reason I am asking is that I wish to view all these values in Aquasuite's Overview pages, at least in one of them, that I am creating. I would be grateful if I could use just HWiNFO in cooperation with Aquasuite and not having to use both programs to represent what I want.

And...one last question/request: is it possible to make HWiNFO show the system's date and time, as well?







It would be awesome if you could do that! So that I could use those values, as well in Aquasuite. Any user who wouldn't like those can easily hide them/disable monitoring them. AIDA can show these on its sensor gadget but they cannot be passed to Aquasuite...

Oh, and one last question: in the new build that you have provided does NB represent the North Bridge Core voltage? And does NB HT represent the Hyper Transport voltage, as shown in AIDA, respectively? I'm asking because these values differ a bit but they are close.

Thank you very-very much


----------



## Mumak

I can add that value into sensors.
As for the system date/time I believe such an entry doesn't belong into the sensors. And anyway, if you want to see this information in Aquasuite, I believe it's a question to them.
Yes, the NB should represent NB Core voltage and NB HT the Hyper Transport voltage. These should be in sync with ASUS tools like AI Suite. The small difference could be because of rounding. Important is that it's close to AI Suite, so you might check that.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I can add that value into sensors.
> As for the system date/time I believe such an entry doesn't belong into the sensors. And anyway, if you want to see this information in Aquasuite, I believe it's a question to them.
> Yes, the NB should represent NB Core voltage and NB HT the Hyper Transport voltage. These should be in sync with ASUS tools like AI Suite. The small difference could be because of rounding. Important is that it's close to AI Suite, so you might check that.


Man, if you will do that you are simply awesome!!!
As you already know CPU/NB is an important value, used in overclocking and it would be amazing to have it there, when posting the results from the stress tests!

I hope I am not testing your patience here, and by the way forgive my language, I am not a native English speaker, but I will request from you also a few other useful readings and IF you can please (please, please...) put them in the sensor's panel as well:

- CPU/NB frequency exists already but HT Link Speed (in MHz) is missing... Can you put HT Link speed, as well?








- It would be really-really nice and useful if the CPU Ratio (the Multiplier), and the CPU Bus frequency could be shown, too!









I deeply appreciate your effort, I LOVE your program and I use it all the time!















I am just trying to avoid other programs and keep only yours in my system.

Thank you VERY much, looking forward to the new build!









ps: I do not have the AI Suite currenty installed, mainly because it was in conflict with AIDA64... If I will get rid of that, I might install it again

thaaaaank youuu!!!


----------



## Mumak

OK, I believe that such information is useful in sensors, so I have added it.
What about this: www.hwinfo.com/beta/hw64_445_2303.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I believe that such information is useful in sensors, so I have added it.
> What about this: www.hwinfo.com/beta/hw64_445_2303.zip


Thank you SO much, it works great!!!

There is one problem, however..
I have an O/C profile, called FSB + Turbo. In that one it does not show the correct value of HT Link Speed and also... Core 0 temp has disappeared (!) and CPU Power took its place! Also, CPU Package temp reading is long gone... [EDIT: they have reappeared after I restored the original order!]

Here is a screenshot:


Spoiler: Warning: Spoiler!







One last, and this will be the last, request: IF you can add HyperTransport & Northbridge Multipliers, as well, together maybe with the BUS Speed, it will be a miracle!

Thank you very much! I will express my enthusiasm fully when we will make it work !


----------



## Mumak

I can see Core0 temp on the screenshot. Anyway, I suggest not to count of those values. Check here for more information: http://www.hwinfo.com/forum/Thread-CPU-Core-Temperature-Measuring-Facts-Fictions
As for the other values like CPU Package Power and Package temp, these might depend on BIOS settings.
This should fix the HT clock: www.hwinfo.com/beta/hw64_445_2304.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I can see Core0 temp on the screenshot. Anyway, I suggest not to count of those values. Check here for more information: http://www.hwinfo.com/forum/Thread-CPU-Core-Temperature-Measuring-Facts-Fictions
> As for the other values like CPU Package Power and Package temp, these might depend on BIOS settings.
> This should fix the HT clock: www.hwinfo.com/beta/hw64_445_2304.zip


Where can you see the Core0 temp in my previous screenshot?! I cannot see it anywhere! No problem though because it has reappeared after I have restored the original order. I hope it will not disappear again because for sure I will hide some values and also I will rearrange the order. It's the way I work this fine software









When it comes to AMD FX temps, I am aware of the problem and I only trust them when they are above 50C tending to equalize with the CPU socket temp. CPU power, an AWESOME feature IF it would work all the time, seems to work only when Turbo Core is enabled. No problem









Unfortunately though HT clock was not corrected with this build either. Besides restoring the default order I have even reset the preferences! Losing all my re-naming...
It is still showing 2200MHz when the actual value is ~2571.something MHz. It looks like the program is reading a static value and not a real-time value. In CPU-Z the HT Link is changing a bit.


----------



## Mumak

Try this one for fix to HT clock: www.hwinfo.com/beta/hw64_445_2305.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Try this one for fix to HT clock: www.hwinfo.com/beta/hw64_445_2305.zip


YES!! Yeeeesssss!! It worked!!

















Spoiler: Warning: Spoiler!







Thank you VERY MUCH!









A few questions:

- Will hiding a few values, renaming a few others and reordering some of them, make things disappear or get inaccurate? (I don't think so, just asking)

- NB VID represents the voltage NB is asking? If so, from whom?

- Will you consider adding the Bus Speed & NB + HT multipliers, as well?









Thank you very much!!

In a few hours you made HWiNFO x 20 times more useful and functional than it was already!















I think that if you will add those asked above, as well, the people will have to show their DRAM timings only!

Bless you, Man!!


----------



## Mumak

Hiding/reordering of items should work fine.
I believe the NB VID is requested from the Voltage Regulator on mainboard.
Yes, I will consider adding those items. However too many items make the sensor screen too large and crowded. There are also some internal limits on certain amount of values, which I'll need to raise because of the recent additions. This is fine for HWiNFO, but will need to be validated with plug-in authors if they handle them properly.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Hiding/reordering of items should work fine.
> I believe the NB VID is requested from the Voltage Regulator on mainboard.
> Yes, I will consider adding those items. However too many items make the sensor screen too large and crowded. There are also some internal limits on certain amount of values, which I'll need to raise because of the recent additions. This is fine for HWiNFO, but will need to be validated with plug-in authors if they handle them properly.


Okay, Sir!

Thank you very much, you've done an amazing job on this program! I think it is the best in the world!
Thanks for clarifying it about the NB VID, it's the same as the Core#.. VID, I will rename them properly.

One idea/suggestion, if I may: it would be..."perfection" if HWiNFO was capable of splitting the values as the window would resize. I mean, when maximized (for example) the values to get next to the others, in two columns. Ouf, it's late now for me to think in English but perhaps you understand me. I don't know how easy is something like that, I just suggest it.







Personally, I don't mind because I am hiding everything related to my SSDs, besides the temps. Another suggestion/idea is to represent the CPU Multiplier with one value -like CPU-Z does- instead of eight. Again, personally I do not mind and I prefer it like this, with eight values









I don't understand the part with the plug-in authors, but nevermind









Think about making two or three columns possible, when the window is maximized







One time, when first dealing with the program, I was so fascinated from it that I had to turn one of my monitors in portrait mode just to have it open completely!









Anyway, thank you very much for this great upgrade!! Thank you!


----------



## Mumak

Indeed, the multi-column mode for sensors window is one of the ideas that I'm thinking about how to display more values. The amount of sensors has grown pretty large during the time. I never thought it will grow so large








I'll need to perform some internal changes too and this might cause that from the next builds you might need to reconfigure sensors (order, appearance) again, since some values will change their positions... I don't like this to happen, but unfortunately there's no other way.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Indeed, the multi-column mode for sensors window is one of the ideas that I'm thinking about how to display more values. The amount of sensors has grown pretty large during the time. I never thought it will grow so large
> 
> 
> 
> 
> 
> 
> 
> 
> I'll need to perform some internal changes too and this might cause that from the next builds you might need to reconfigure sensors (order, appearance) again, since some values will change their positions... I don't like this to happen, but unfortunately there's no other way.


Good morning!









Personally, I have NO problem in reordering - renaming my sensors. It IS a considerable amount of work - and at some point I should finish with it - but I have no problem! When comparing this amount of work with the (great) benefit of having all the indications I need in one single program, and in addition this program to be fully operable with the Aquasuite, well that is perfect for me!









Objectively speaking though, meaning for other users as well, isn't it great to be able to have everything you need in one place and not having to open CPU-Z and/or AIDA etc to watch and present the different values?

Multi-column interface (only) when the window will be maximized will be a very useful upgrade!

But consider also to represent the CPU Ratio (the multiplier) with one value, instead of eight. You can then introduce the Bus frequency, NB & HT multipliers and perhaps more and still use less sensors than now









Finally, one can just Hide/Disable monitoring in whatever he/she does not need. The most important thing, the extremely important thing, is the values to be there and to be accurate


----------



## Mumak

There will be CPUs which can run each core in a different P-State, so per-core multipliers are needed.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> There will be CPUs which can run each core in a different P-State, so per-core multipliers are needed.


Excellent, no problem at all!









One last suggestion about the interface : it would be great if you could make the SHIFT and CONTROL buttons to work







For example, let's say that I wish to hide 10 values. I'd like to be able to select all of them, with either SHIFT or CONTROL pressed, right click and select Hide and/or Disable Monitoring. The same would be great with reordering them! Instead of having to do one at a time, to be able to move up or down a set of values.

But IF these tasks are difficult to program or if they are a fuss, personally I do not mind not having them. The most important thing is to have the sensor I need and it to have an accurate value that I can trust. As accurate/trustworthy as they can be, that is.

Thank you very much, looking forward to your new build!









Have a very nice day!


----------



## LostParticle

Hi again









I have installed the AI Suite to check the new sensors of the program. I did not want to install it but I did it. Please, have a look in the following screenshot, and specifically at the NB and NB HT voltage values. Those were among the ones introduced yesterday. Why is this difference between HWiNFO and AI Suite / AIDA? AIDA is a bit closer to AI Suite..

I've loaded Optimized Defaults and not one of my o/c profiles


Spoiler: Warning: Spoiler!







Thank you.

ps: something tells me that I should not install that garbage on my computer because perhaps it does not show real time values







Perhaps AMD OverDrive does..


----------



## Mumak

The screenshot from AI Suite shows the values SET. Please attach the Monitor screenshot of AI Suite (or any other that shows the values monitored).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The screenshot from AI Suite shows the values SET. Please attach the Monitor screenshot of AI Suite (or any other that shows the values monitored).


The monitor of AI Suite II does not show any of these voltages. I have it open on my screen right now and it shows only the following voltage values:
VCore, +3.3V, +5V, +12V, +VDDA. And then it shows the temperatures.

I think that there is no monitor in AI Suite that shows these values. Maybe AMD overdrive does but then again should I install it or just trust AIDA?


----------



## Mumak

OK, here's another build: www.hwinfo.com/beta/hw64_445_2306.zip
This adds the HT and NB ratios. It should also report the EC voltages closer to the real values.
Note, that since I reshuffled some sensors internally, you might need to do the "Restore Original Order" again, or full Reset Preferences.


----------



## Mumak

OK, I think I have found another way how to adjust the EC voltages to be even more accurate. Will do that in the next build.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I think I have found another way how to adjust the EC voltages to be even more accurate. Will do that in the next build.


Sorry for the delayed reply - I had to go somewhere.

I performed a System Restore to get rid of the AI Suite and the AMD OverDrive. To me they are of NO use: AOD, even though representing these 2 voltage values, it always shows them with value of 0.0000V








AI Suite is showing just what's set - and not what's going on in real-time.

Your last build (hw64_445_2306) shows these two values exactly as they are set in the BIOS!







It's great but...they do not change at all. Now, I don't know if these values (NB and NB-HT voltage) are supposed to change a bit, but I will wholeheartedly WELCOME your new and most accurate build!









And IF you will manage to put in there the last important value = the BUS speed, as well, it will be awesome!









Thanks a lot!


----------



## Mumak

OK, will post a new build shortly.
The BUS speed for HT/NB is the same as the CPU bus clock anyway.


----------



## Mumak

Here is it: www.hwinfo.com/beta/hw64_445_2308.zip
That should improve the EC voltages a bit and they should change slightly now.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Here is it: www.hwinfo.com/beta/hw64_445_2308.zip
> That should improve the EC voltages a bit and they should change slightly now.


Perfect!!! It seems to work awesomely!










Spoiler: Warning: Spoiler!







Thank you VERY much!!
















Of course, I will test it with my o/c profiles, as well, this one was with Optimized Defaults, and I will also test it with manually set values! I'm sure it will go great though!









Regarding the Bus Speed, do you mean that the value shown here, next to Bus Speed = 200.67MHz, is already shown in HWiNFO? Because at that "Bus Speed" I was referring.


----------



## Mumak

Ah, sorry - you're right.. the Bus Speed should be already there but due to another bug it's not. I need to fix again


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Ah, sorry - you're right.. the Bus Speed should be already there but due to another bug it's not. I need to fix again


Ah, really sorry man! Well, I suppose it will be something simple







On the other hand, the GOOD you are doing to ALL of Sabertooth's owners is really-really-really great!!


----------



## Mumak

Another build: www.hwinfo.com/beta/hw64_445_2309.zip
Should show Bus Clock and even more improve EC voltages.

Now I need a short break


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Another build: www.hwinfo.com/beta/hw64_445_2309.zip
> Should show Bus Clock and even more improve EC voltages.
> 
> Now I need a short break


Hello again !









I came to confirm that this last build works perfectly on my system!























Optimized Defaults:


Spoiler: Warning: Spoiler!







An O/C profile:


Spoiler: Warning: Spoiler!







Another O/C profile:


Spoiler: Warning: Spoiler!







HWiNFO64 agrees with the BIOS and also with AIDA and CPU-Z. I was not expecting anything less of course, since it is the BEST monitoring tool in the world!!

The only hick-up it has presented on my system is that CPU Power measurement disappears when AMD Turbo Core is Disabled, and that the CPU Package temperatures have disappeared too, in my FSB O/C profile. Not even reseting the Preferences could bring them back. No worries though









I will test it with some manual settings, too, and also with a short-time Prime95 stress test. I won't post anything unless a problem will arise.

I would like to thank the Programmer very much for all this effort! He brought the program to a whole new Level! I still recall, couple of months ago when I first started overclocking, the surprise of the people in one of the largest tech forums of my country, when we discovered - after posting the results- that HWiNFO was not capable of showing fundamental values like the DRAM voltage and all the rest, recently added. [I'm talking about my M/B, ofc]

Now they will all know that it is THE BEST and the ONLY WAY, if you'd like to know what's really going on inside your system!

Thank you!!!


----------



## Mumak

The inability to read CPU Power values when AMD Turbo Core is Disabled is not just a limitation of your system, but AFAIK others as well. This seems to be a limitation of the CPU/BIOS and I believe all other tools are affected as well.
Thank you for so much testing and reporting







I sometimes wish there were more users like you, I cannot test all systems myself


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The inability to read CPU Power values when AMD Turbo Core is Disabled is not just a limitation of your system, but AFAIK others as well. This seems to be a limitation of the CPU/BIOS and I believe all other tools are affected as well.
> Thank you for so much testing and reporting
> 
> 
> 
> 
> 
> 
> 
> I sometimes wish there were more users like you, I cannot test all systems myself


You are right, about the cpu power, it disappears from AIDA, as well.

You are welcome and I thank you for your amazing program!









Well... I have reordered, I have renamed, a lot...







Here is the final "version", aka the way I use HWiNFO :


Spoiler: Warning: Spoiler!









I've hidden what refers to the SSDs besides the temperature, and also four arbitrary values that make no sense: Temp7 & Temp8 and also VIN4 & VIN6 which have the same values all the time - in all o/c profiles (1.584V & 0.036V, respectively).

Besides that, the software works superbly! All this hard work was done not just to present the best and most informative screenshots possible, but also because these names will get passed to Aquasuite, when I'll be preparing its Overview pages! Over-viewing via the Aquasuite on everyday usage and over-viewing via HWiNFO when overclocking









It would be really useful if a multicolumn interface together with the SHIFT and CTRL buttons' usage would get implemented









Thank you!









Take care


----------



## LostParticle

Hi Martin!









I have downloaded pre-release version hw64_445_2313 a few minutes ago and it seems to work fine!









What are the differences from version hw64_445_2309?

I have renamed and reordered quite a few things so I cannot see the differences. I wouldn't like to restore the original order since it's a lot of work reordering again...

Thank you, great job!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have downloaded pre-release version hw64_445_2313 a few minutes ago and it seems to work fine!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> What are the differences from version hw64_445_2309?
> 
> I have renamed and reordered quite a few things so I cannot see the differences. I wouldn't like to restore the original order since it's a lot of work reordering again...
> 
> Thank you, great job!


All the changes I did for you are included there (and will be carried forward).
There were some additional changes to solve issues with other boards, for example the PCH Thermal sensor is now disabled by default, since accessing it on a few boards could cause a hang. Also, some more minor additions, but I believe neither of them is of concern for you.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> All the changes I did for you are included there (and will be carried forward).
> There were some additional changes to solve issues with other boards, for example the PCH Thermal sensor is now disabled by default, since accessing it on a few boards could cause a hang. Also, some more minor additions, but I believe neither of them is of concern for you.


Thanks a lot!









These new builds will be extremely useful to me and the rest of the thousands of Sabertooth's owners, at least those who care about their system.

Keep up the good work and have a great day!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thanks a lot!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> These new builds will be extremely useful to me and the rest of the thousands of Sabertooth's owners, at least those who care about their system.
> 
> Keep up the good work and have a great day!


Thanks, you too!


----------



## LostParticle

Hi Martin









I would like to ask you about the VCore values in your latest beta.. Why HWiNFO64 cannot / does not show the minimum vcore like cpu-z and aida64 does, in the following screenshot?


Spoiler: Warning: Spoiler!







Thank you


----------



## Mumak

I don't know exactly, maybe the low Vcore lasted only for a short while, which was not captured by HWiNFO during its update cycle..


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I don't know exactly, maybe the low Vcore lasted only for a short while, which was not captured by HWiNFO during its update cycle..


Thanks for the quick reply!

I have set the "Scan Interval" to 500ms, saved and reopened the program but still it does not show the minimum correctly...

On the other hand, I have CPU-Z x64 open right now on my desktop and Core Voltage takes the value of 1.032V in approx. every second. It does not get this value one time, only. It fluctuates. In 2 seconds for example, it has taken this value around 4 times. It also gets another value: 1.368V. Neither this one is shown in HWiNFO64.

Right now, the minimum in HWiNFO is 1.536V, after 11 minutes of running


----------



## Mumak

Try to close the other tools, don't load the CPU for a while and see if then HWiNFO displays that voltage.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Try to close the other tools, don't load the CPU for a while and see if then HWiNFO displays that voltage.


I did it and it is still the same.

Specifically, I've rebooted and left HWiNFO64 running for about 8 minutes without doing anything else on my computer. The minimum VCore value that it is showing is 1.536V
I then closed it and opened CPU-Z x64 and the minimum I've seen was 1.032V

To be honest, Martin, I have observed this since I am using HWiNFO64 = since for ever, but I did not mind.


----------



## Mumak

Please try to disable the ASUS EC sensor (or entire EC Support) to see if that makes a difference.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Please try to disable the ASUS EC sensor (or entire EC Support) to see if that makes a difference.


Okay, I will do that but to do it, do I have to "reset preferences"? And most importantly, if so, will I lose my naming and my re-ordering then?!

Or perhaps you mean to simply Disable Monitoring for the EC Sensor?


----------



## Mumak

No, you don't need to reset preferences and names. Just either disable monitoring on the [ASUS EC] sensor entry, or disable EC Support in Settings.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, you don't need to reset preferences and names. Just either disable monitoring on the [ASUS EC] sensor entry, or disable EC Support in Settings.


Ah, yes!

The second I have disabled the monitoring of the ASUS EC sensor the low VCORE appeared immediately and in addition, the values change much-much faster now! [scan interval still at 500ms]
And I have seen the other voltage values, as well!


Spoiler: Warning: Spoiler!







Okay, so what can be done about this matter then? I really need to view the ASUS EC sensor's values! Can this get fixed, somehow?

In case it cannot, in case I'll have to live with it, is at least the MAX VCore represented correctly? Because MAX VCore is a REALLY important value!!

?


----------



## Mumak

I believe the reporting of the Vcore values is correct. The problem is that reading from the EC sensor takes a bit of resources, especially CPU cycles. That means, while reading values from the EC the CPU raises its operating point for a short while (reading the EC values and CPU Vcore happens close together), which affects the current Vcore value. Unfortunately this is how the EC sensor is implemented - it's by design (which I personally don't like).
I can try to change the order in which sensors are read during each cycle, maybe this will reduce this effect.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I believe the reporting of the Vcore values is correct. The problem is that reading from the EC sensor takes a bit of resources, especially CPU cycles. That means, while reading values from the EC the CPU raises its operating point for a short while (reading the EC values and CPU Vcore happens close together), which affects the current Vcore value. Unfortunately this is how the EC sensor is implemented - it's by design (which I personally don't like).
> I can try to change the order in which sensors are read during each cycle, maybe this will reduce this effect.


I would suggest to give it a try, if it's not too much trouble, and I am here to test it!

I don't know if it's of any help, but let me say two things: 1) AIDA64 does collect that low voltage value, 2) no matter how many hours I will leave HWiNFO64 running - and usually I let it go all day long- it never "catches" that low value of the VCore!

Or at least I think so...

Anyway, please give it a try as long as these crucial values will be represented correctly!

Thank you very much!
















ps_1: I cannot understand how it can show the correct MAX vcore (and it does!) and fail in showing the correct MIN vcore...

ps_2: after disabling the EC, vcore was read from "somewhere else" and shown correctly!







Can you not read just the vcore from "that other place", like when the EC is disabled?


----------



## Mumak

OK let me explain how it works in HWiNFO. Every cycle (configurable) it's like:
- Read System values
- Read....
- Read EC values (this raises the CPU operating point (OP) - clock, Vcore, etc. - because it takes some resources
- Read ITE values including Vcore - this reads a higher Vcore since EC above caused it to rise for a short while
- Read....
- Cycle delay (500 ms in your case)

Now if I exchange the EC / ITE readout, reading EC values will still raise the OP, but there will be sufficient time to drop to current (low level in case there's no other CPU load) before reading the Vcore from ITE.
You'll then also see a different order of sensor in the list.


----------



## Mumak

OK, I changed it, so please try this build: www.hwinfo.com/beta/hw64_445_2317.zip
and let me know the result.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I changed it, so please try this build: www.hwinfo.com/beta/hw64_445_2317.zip
> and let me know the result.


YES! It works! Thank you very much!!
I can now see 1.032V as MIN VCore value in HWiNFO64, exactly as CPU-Z is showing me!
















Thank you for the explanation, as well! One last question: why in CPU-Z the values can change so rapidly and in HWiNFO not? Does it have to do with the scan interval? Should I set it even lower? If not, in which value do you suggest I should set it?

Thank YOU!

ps: I have not observed any difference in my ordering or naming scheme. Do I have to reset the program for this new beta to work properly or is it OK to leave it like this?


----------



## Mumak

I'm not sure, but I think CPU-Z uses a lower interval. Since HWiNFO reads the EC sensor as well (which CPU-Z doesn't) and that takes some additional time I don't advise to set it too low.
You don't need to reset the preferences as long as you don't notice any oddities.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure, but I think CPU-Z uses a lower interval. Since HWiNFO reads the EC sensor as well (which CPU-Z doesn't) and that takes some additional time I don't advise to set it too low.
> You don't need to reset the preferences as long as you don't notice any oddities.


Okay, thank you









I forgot to set it at 500ms in the latest beta you've sent me but now that I did, it almost follows CPU-Z, and of course, they agree in their readings!








I hope 500ms is not too low.

Once again, I'd like to thank you very much for your support to the users and for the instant solutions you offer in whatever problem might arise. ALL the latest improvements/additions you've implemented in HWiNFO are vital to the Sabertooth user, unless he/she doesn't care at all about his system!

Have a very nice day/evening!









Thank you


----------



## Mumak

You're welcome


----------



## LostParticle

Hi again, Martin!









I have recently changed platform and now I am using an ASRock Z97 Extreme6 motherboard together with an Intel Core i7-4790K









I think that the latest beta of HWiNFO64 does not monitor my system correctly. Here are three screenshots which show all of the software's readings:


Spoiler: Warning: Spoiler!









I have no hidden values neither have I renamed or changed anything.

First of all, HWiNFO64 does not monitor and show the CPU_Fan 2. Then, I think that a certain value is repeated twice: the "CPU Digital IO" value.
Finally, do you happen to know which temperature value is the TCase value?

Thank you!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi again, Martin!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have recently changed platform and now I am using an ASRock Z97 Extreme6 motherboard together with an Intel Core i7-4790K
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I think that the latest beta of HWiNFO64 does not monitor my system correctly. Here are three screenshots which show all of the software's readings:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have no hidden values neither have I renamed or changed anything.
> 
> First of all, HWiNFO64 does not monitor and show the CPU_Fan 2. Then, I think that a certain value is repeated twice: the "CPU Digital IO" value.
> Finally, do you happen to know which temperature value is the TCase value?
> 
> Thank you!


Please attach the HWiNFO Debug File, so I can check the CPU Fan2.
Tcase - if you mean the temperature measured in the socket, I'm not sure if this board has such a sensor. The CPU (PECI) value is read from the core sensors and seems to be identical to the "CPU" as well.


----------



## LostParticle

Okay, thanks, here is the file

HWiNFO64.zip 60k .zip file


You are right, Tcase is probably not measured.

Thank you


----------



## Mumak

Thanks. I'll fix that fan in the next Beta build.
Let me know if you need it sooner, otherwise a new public Beta will be released in a few days.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I'll fix that fan in the next Beta build.
> Let me know if you need it sooner, otherwise a new public Beta will be released in a few days.


Thank you, Martin!

If it will be released in no more than a week, I am okay with it.
Will you also fix the "CPU Digital IO" which is repeated twice?

Also, do you happen to know what VIN6, VIN12 and VIN14 represent?
Is the DRAM voltage shown, somewhere?

Thanks!


----------



## Mumak

I think VIN6, VIN12 and VIN14 are not used voltage monitoring pins.
I haven't seen an ASRock board being able to monitor DRAM voltage yet.


----------



## King PWNinater

How do I get CPU wattage information in the sensor?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think VIN6, VIN12 and VIN14 are not used voltage monitoring pins.
> I haven't seen an ASRock board being able to monitor DRAM voltage yet.


Okay, so you mean that I can safely hide/disable monitoring those VIN values?
Too bad about the Dram voltage!...
I might contact ASRock support for this...


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, so you mean that I can safely hide/disable monitoring those VIN values?
> Too bad about the Dram voltage!...
> I might contact ASRock support for this...


Yes, you can hide those.
I don't think ASRock will help you if the boards don't have the VDIMM rail attached to a monitoring input...


----------



## Mumak

Quote:


> Originally Posted by *King PWNinater*
> 
> How do I get CPU wattage information in the sensor?


Your CPU or mainboard needs to support monitoring of the current&voltage.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, you can hide those.
> I don't think ASRock will help you if the boards don't have the VDIMM rail attached to a monitoring input...


Ok Martin, thank you!

There is also another temperature reading called Auxiliary. What does that represent?

Wish I had that new beta right now...

Oh, and one last thing: even though I have not installed the drivers of my Intel Ethernet connection it still reads it. It has the same values as the Realtek, the one I use.


----------



## King PWNinater

Quote:


> Originally Posted by *Mumak*
> 
> Your CPU or mainboard needs to support monitoring of the current&voltage.


I am almost sure it does. I have an FX-8350 on an ASUS Crosshair V Formula-Z


----------



## Mumak

Quote:


> Originally Posted by *King PWNinater*
> 
> I am almost sure it does. I have an FX-8350 on an ASUS Crosshair V Formula-Z


Do you have CPU Turbo enabled? On some systems if it's disabled in BIOS, the power readings don't work (probably a BIOS or CPU bug).


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Ok Martin, thank you!
> 
> There is also another temperature reading called Auxiliary. What does that represent?
> 
> Wish I had that new beta right now...
> 
> Oh, and one last thing: even though I have not installed the drivers of my Intel Ethernet connection it still reads it. It has the same values as the Realtek, the one I use.


I'm not sure about the Aux value. Might be invalid as well.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure about the Aux value. Might be invalid as well.


Okay Martin, thank you









I'd also like to inform you that the DRAM Voltage can be set in my BIOS, not sure yet if its real-time value is shown somewhere in there.

Looking forward for your next beta build!!!


----------



## Mumak

Yep, you can set the DRAM value. Theoretically it might be possible to read the actual value set, but this voltage rail is not connected to a monitoring input, which would measure the actual voltage value.
Imagine a situation similar to VID - this value is what the CPU requests and thinks it gets. You can also read the VID back. But the real voltage can be different if the mainboard implements additional offsets. If the mainboard is capable of reading the actual voltage (Vcore), you know what the real voltage is supplied to the CPU.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yep, you can set the DRAM value. Theoretically it might be possible to read the actual value set, but this voltage rail is not connected to a monitoring input, which would measure the actual voltage value.
> Imagine a situation similar to VID - this value is what the CPU requests and thinks it gets. You can also read the VID back. But the real voltage can be different if the mainboard implements additional offsets. If the mainboard is capable of reading the actual voltage (Vcore), you know what the real voltage is supplied to the CPU.


About the DRAM Voltage I'll e-mail ASRock support first thing tomorrow morning.

When it comes to the VID though, the VCore, this important value! In the latest beta I think it is shown for each core under the Core # 0,1,2,3 VID values. These are the only values that agree with CPU-Z. Of course, CPU-Z shows one value only but these are the only ones that are near and sometimes equal to that.

So is this the VCore in this platform (INTEL) then? The Core # VID values are those I should check when I will overclock this processor in the future?

Also, when will that beta come out?









Thank you!


----------



## Mumak

The situation with Haswell CPUs is different, because they feature a Fully Integrated Voltage Regulator (FIVR). So the entire voltage regulation is performed inside the CPU (which makes it hotter as a side-effect). To measure Vcore, one needs special logic implemented on the mainboard, though I'm not sure how reliable this is for Haswell. So only some mainboard manufacturers claim their boards can measure Vcore on Haswell (monitored via a pin from CPU). However, I'm not sure what exact methods they use and how accurate the Vcore values are - in idle they seem just too low.
Anyway, ASRock boards cannot measure Vcore. You can only see VID values, which might not represent the true voltage supplied.

Here's the new build if you can't wait longer







www.hwinfo.com/beta/hw64_445_2325.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The situation with Haswell CPUs is different, because they feature a Fully Integrated Voltage Regulator (FIVR). So the entire voltage regulation is performed inside the CPU (which makes it hotter as a side-effect). To measure Vcore, one needs special logic implemented on the mainboard, though I'm not sure how reliable this is for Haswell. So only some mainboard manufacturers claim their boards can measure Vcore on Haswell (monitored via a pin from CPU). However, I'm not sure what exact methods they use and how accurate the Vcore values are - in idle they seem just too low.
> Anyway, ASRock boards cannot measure Vcore. You can only see VID values, which might not represent the true voltage supplied.
> 
> Here's the new build if you can't wait longer
> 
> 
> 
> 
> 
> 
> 
> www.hwinfo.com/beta/hw64_445_2325.zip


All right, thank you very much for the new beta!!







Now I can see the CPU_2 fans! That CPU Digital IO is still shown twice (with the exact same values), though.. I can always hide it but I'm telling you so that you'll be aware of it. Also, my motherboard has 2 network adapters. A RealTek and an Intel. Even though I have not installed the drivers for the Intel and I am not using it, HWiNFO64 shows the same values on both. I have not disabled the Intel in Device Manager, though.

If Asrock boards cannot measure VCore then how can a person overclock on those boards?!
* the VID values on my system change all the time.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> All right, thank you very much for the new beta!!
> 
> 
> 
> 
> 
> 
> 
> Now I can see the CPU_2 fans! That CPU Digital IO is still shown twice (with the exact same values), though.. I can always hide it but I'm telling you so that you'll be aware of it. Also, my motherboard has 2 network adapters. A RealTek and an Intel. Even though I have not installed the drivers for the Intel and I am not using it, HWiNFO64 shows the same values on both. I have not disabled the Intel in Device Manager, though.


I'm aware of the duplicated CPU Digital IO values, but I don't consider this as an issue.
Can you try to install the Intel drivers if it's reported correctly then ?
Quote:


> Originally Posted by *LostParticle*
> 
> If Asrock boards cannot measure VCore then how can a person overclock on those boards?!
> * the VID values on my system change all the time.


Ask ASRock


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm aware of the duplicated CPU Digital IO values, but I don't consider this as an issue.
> Can you try to install the Intel drivers if it's reported correctly then ?
> Ask ASRock


Okay, I've disabled and hidden both the duplicated value and the entire Intel Network readings. Now everything works fine!









I will e-mail ASRock and ask, for sure!

Once again, thank you very much!


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Anyway, ASRock boards cannot measure Vcore. You can only see VID values, which might not represent the true voltage supplied.


Ηι again, Martin.

I didn't have the chance to e-mail ASRock about this, yet, but I have installed their A-Tuning suite. There, under the System Info tab, they have something called "Vcore Volt."
I went in the BIOS and set my Vcore mode to Override and set the value to 1.090V @4.0 GHz. Back in Windows, here's the screenshot:


Spoiler: Warning: Spoiler!







So, what does this mean? Does it mean that for my motherboard, what HWiNFO calls "Core# VID" is actually the Vcore?


----------



## Mumak

I think this could be the CPU Core Voltage (override) set in the FIVR. If you have override active, it might be equal to VID, since it's static.
You can see these settings in HWiNFO under CPU details/IA Overclocking sections in the main window (with tree) - if you have Sensor-only activated, you will need to disable this mode in order to see the main window. Those values are not displayed in sensors, since they are static.
Anyway, I don't think that value is the true measured Vcore.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think this could be the CPU Core Voltage (override) set in the FIVR. If you have override active, it might be equal to VID, since it's static.
> You can see these settings in HWiNFO under CPU details/IA Overclocking sections in the main window (with tree) - if you have Sensor-only activated, you will need to disable this mode in order to see the main window. Those values are not displayed in sensors, since they are static.
> Anyway, I don't think that value is the true measured Vcore.


I've loaded Optimal Defaults, and I've run x264 stress test for a few seconds. Here is the screenshot:


Spoiler: Warning: Spoiler!







From the little that I observed it, it seems that the values agree, it's just that A-Tuning is not reading them as fast as the other two.

- How is it possible for a brand like ASRock to not provide a sensor/a reading for such a fundamental value as the Vcore and at the same time have a "Vcore Volt." reading on its software?

I also post a screenshot from my BIOS, HWmonitor section, from a few days ago. This is not recent.


Spoiler: Warning: Spoiler!







I think that "VCore Volt." from A-Tuning suite shows this "CPU Vcore" value from the BIOS.

I would also like to add that the DRAM Voltage is shown in A-Tuning.


----------



## LostParticle

Hi again, Martin

Should I expect another beta about this VCore issue with my motherboard? Are you looking at this matter, or not?
Forgive me if I sound pushy, I do not mean so, but my decision on returning this motherboard or not, depends from that, and it is extremely important to me. I will not be able to overclock if I won't have a reliable and real-time value of the VCore.

As you have probably observed A-Tuning is giving a VCore Volt. value and also AIDA64 and HWMonitor give a VCore value, as well. I'm not sure though how accurate their values are, especially the "CPU Vcore" of HWMonitor which seems to stay fixed (!)

Please let me know if you are searching this issue and if there will be a solution, soon.

Thank you










Spoiler: Warning: Spoiler!


----------



## Mumak

There's nothing to look for since I can only repeat myself - those boards cannot really measure Vcore nor DRAM. The values you see there are static / values set - NOT actually measured !
I believe both CPU-Z and AIDA64 show wrong Vcore there. I have just talked to AIDA64 author and he confirmed that you're using an old version of AIDA64, which didn't properly support that mainboard.
If you upgrade AIDA64, you'll find that what you see now as "CPU Core" will become VCCIN (multiplied by 2). Similar for CPU-Z/HWMonitor.
Please discuss further questions with ASRock - it's their design, they have the schematics and know it. I'm not responsible for their design.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> If you upgrade AIDA64, you'll find that what you see now as "CPU Core" will become VCCIN (multiplied by 2). Similar for CPU-Z/HWMonitor.
> Please discuss further questions with ASRock - it's their design, they have the schematics and know it. I'm not responsible for their design.





Spoiler: Warning: Spoiler!







I will contact ASRock and if they cannot measure the actual VCore I will return this.

Which motherboards do provide a real-time VCore sensor/reading that HWiNFO can show?


----------



## Mumak

Still a bug in AIDA64 - just confirmed by its author.
AFAIK GIGABYTE Z97/H97, some higher-end ASUS (except Z97-C, Z97-K, Z97I, Z97M-PLUS, H97) and MSI Z97/H97 should be able to measure Vcore. Though I'm not sure how accurate that is.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Still a bug in AIDA64 - just confirmed by its author.
> AFAIK GIGABYTE Z97/H97, some higher-end ASUS (except Z97-C, Z97-K, Z97I, Z97M-PLUS, H97) and MSI Z97/H97 should be able to measure Vcore. Though I'm not sure how accurate that is.


Ok Martin, thank you very much.

Do you happen to know if ASUS Sabertooth Z97 Mark 2 has that sensor? If it is capable of measuring and showing Vcore accurately?

Thanks again, and my apologies for any inconvenience! Honestly, I cannot understand how all these people with ASRock Extreme series boards, overclock...


----------



## Mumak

Yep, SABERTOOTH Z97 should be able to monitor Vcore, but as I already said - I'm not sure about the accuracy.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yep, SABERTOOTH Z97 should be able to monitor Vcore, but as I already said - I'm not sure about the accuracy.


Thanks, Martin









I'm still waiting a response from Asrock...

Do you know IF the Sabertooth Mark 2 monitors real-time DRAM voltage, as well? Also, this inaccuracy of the Vcore, is it present all over the spectrum or in low values only? The higher values is what interests me.

Congratulations for your new beta!


----------



## Mumak

No, that one doesn't seem to be able to monitor DRAM voltage.
The inaccuracy of Vcore on Haswell is rather at lower values - in a lot of cases it seems to be extremely low (like 0.1-0.2 V) when idle, so that seems not valid at all. I have tried to discuss this with some guys from mainboard manufacturers, but I still haven't got a clear response how they measure it and whether to trust those values.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, that one doesn't seem to be able to monitor DRAM voltage.
> The inaccuracy of Vcore on Haswell is rather at lower values - in a lot of cases it seems to be extremely low (like 0.1-0.2 V) when idle, so that seems not valid at all. I have tried to discuss this with some guys from mainboard manufacturers, but I still haven't got a clear response how they measure it and whether to trust those values.


Those boards from Gigabyte, Z97 series, do they monitor Dram V?
Also, this issue with (my current) ASRock, it's not something that can be fixed with a BIOS update, right?


----------



## Mumak

Yes, GIGABYTE Z97 should be able to monitor both Vcore and VDIMM.
I don't think that a BIOS update might enable it, since I believe it's a matter of mainboard design. ASRock should tell you more...


----------



## LostParticle

Hi again, Martin

I have received an e-mail from ASRock support regarding the VCore matter.

Here is my question to them together with their reply:


Spoiler: Warning: Spoiler!



_Dear Sir,

A few days ago I've purchased a Z97 Extreme6. I've also installed the A-Tuning suite, recently. Does this motherboard have a sensor (or an other way) to measure the true VCore in real time? When I use software like the popular HWiNFO64, there's no VCore value shown there. Only Core # VID is shown (and it is bouncing all the time).

In A-Tuning suite there is a reading called "VCore Volt.". Does this represent the actual VCore, in real-time? I have purchased this motherboard to overclock my Intel processor a bit, and VCore is fundamental._

Their reply:
Dear Customer!
Thank you for contacting ASRock.

Since Intel 8 series chipset(1150-pins Haswell CPU), the fivr integrates legacy power delivery onto processor.
And we have designed sensor from CPU detect pin to super IO for the Vcore Voltage on this model.

There are some model only provide the VID sensor on the motherboard.
Due to the moment of Vcore Voltage is similar to VID and does not exceed VID.
So, some utility may only show VID for user to observe as Vcore Voltage indicator.
If you want to observe the Vcore Voltage on this model, please use A-tuning which shows Vcore Voltage.



What is your opinion?

Thank you.


Spoiler: Warning: Spoiler!



ps: What I'm thinking of doing, to verify this, is to take three screenshots with all available monitoring software running: HWiNFO64, AIDA64, HWmonitor, CPU-Z and finally the A-Tuning suite. The first one will have all these monitoring Optimal Defaults (F9). The second screenshot will show all these monitoring with the Turbo 4.6 ready-made profile loaded. And the last one will show some fixed voltage settings of my own.

Then I will ask them what the real-time VCore is, in each situation.


----------



## Mumak

Well, I can't quite follow their statement. If it's true that they monitor Vcore from a CPU pin to SuperIO (SIO/LPC), you should be able to see this value in HWiNFO (because it displays all SIO voltages read).
Please ask them which VINx on the SuperIO should be reporting the Vcore if it's true.

Also looking at the A-Tuning config files, there's:

Code:



Code:


        <Item Name="CPU_VCORE_V" Interface="HASWELL" />
            <Item Index="1" Name="CPU_VCORE_V" Enable="1" LANID="STR_SYSINFO_VCORE">Vcore Volt.</Item>

Note the "Interface="HASWELL"" - if the Vcore would be read from SIO it would have a different value (as the other monitored values from SIO). Further analysis indicates they read Vcore from the FIVR requested voltage (override) or they might somehow combine it with the VID (in adaptive mode).
So I doubt that A-Tuning is reading the actual Vcore from CPU to SIO..

Try to set Adaptive mode in BIOS and watch how the A-tuning Vcore behaves (in idle and load) and compare with the VID..


----------



## LostParticle

Thanks Martin!

Here's my system -after loading Optimal Defaults in the BIOS- on idle and on running Prime95, blend:


Spoiler: Warning: Spoiler!








What do you think?

I've observed there is this VIN6 value, down below in HWiNFO, which is following Core #VID(s) closely. For a minute I felt happy that I've discovered the VCore until I've disabled SpeedStep in the BIOS. The core freq. of course stayed fixed but the VIN6 was still bouncing. So, this is cannot be the real-time Vcore, right?

I will e-mail them later this evening. Their e-mail came probably from TAIWAN, it has Chinese characters.

By the way, when you say that IF they are right I would be able to see this value in HWiNFO, do you mean in the Sensors' panel? Or somewhere else?

May I ask you, is there a way to fix the "Vcore Voltage Additional Offset" - see A-Tuning, Voltages, 3rd column- to not hide the actual value?
Can I do this from those config files? I cannot see the value, when set.



Spoiler: Warning: Spoiler!



Note: I don't know what to think about this matter anymore. Why would the tech support lie (!). How are the others overclocking on this board?! How have all those review sites managed to O/C? Without actually knowing the TRUE real-time VCore? Is this the new way now?!



EDIT: e-mail sent


----------



## Mumak

Unfortunately I cannot see VIN6 on those screenshots. How is it close to the Vcore Volt and how much does it fluctuate with SpeedStep disabled?

If the Vcore can be measured via SIO as they say, you should be able to see it in HWiNFO too. But I need to know from them more details.

Yes, I believe if you change the A-Tuning XML config file, it should be reflected in the application too.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Unfortunately I cannot see VIN6 on those screenshots. How is it close to the Vcore Volt and how much does it fluctuate with SpeedStep disabled?
> 
> If the Vcore can be measured via SIO as they say, you should be able to see it in HWiNFO too. But I need to know from them more details.
> 
> Yes, I believe if you change the A-Tuning XML config file, it should be reflected in the application too.


I've e-mailed them, let's hope they will reply soon.

Optimal Defaults Idle and Load (prime95, blend, approx. 2 min)


Spoiler: Warning: Spoiler!








Optimal Defaults -SpeedStep + Turbo Disabled- Idle and Load (prime95, blend, approx. 2 min)


Spoiler: Warning: Spoiler!








Could VIN6 be the Vcore IF they actually have that sensor?


----------



## Mumak

Well, maybe the VIN6 is Vcore.. But it would be much better if ASRock would confirm it.
Anyway, the Vcore Volt. reported in A-Tuning seems to be the VID.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, maybe the VIN6 is Vcore.. But it would be much better if ASRock would confirm it.
> Anyway, the Vcore Volt. reported in A-Tuning seems to be the VID.


I have already e-mailed them that question you told me.

What is your opinion about what they write in their e-mail, given also in a previous post:

_There are some model only provide the VID sensor on the motherboard.
Due to the moment of Vcore Voltage is similar to VID and does not exceed VID.
So, some utility may only show VID for user to observe as Vcore Voltage indicator.
_

(please see previous post for their full reply)

Can this be possible? Can VCore be similar to Core# VID and not exceed it, as they claim?
Also, when the Core(s) frequency is fixed can VCore drop that low, as VIN6 is dropping? Sorry, I don't know this stuff much...


----------



## Mumak

I don't have schematics of that mainboard to know for such whether/what/how is routed to the SIO.
FIVR is also a bit of mystery - it's a kind of black-box.. Maybe some other OCers can better answer your question about VID/Vcore relation on Haswell.


----------



## error-id10t

If you see that value being ~0.02v above VID (the value you set in BIOS) then yes it's vcore. If you're using Adaptive and run Prime 28.5 as an example, you should see it ~0.08v above your VID (the value you set in BIOS).

On your other question, yes it can report that because it's using C States, the monitoring programs don't read "stuff" correctly with them enabled, obviously your chip cannot be running say x48 @ 0.016v (which is shows when C6/C7 are enabled and speedstep disabled). It's just polling the chip to report what it sees.


----------



## LostParticle

Quote:


> Originally Posted by *error-id10t*
> 
> If you see that value being ~0.02v above VID (the value you set in BIOS) then yes it's vcore. If you're using Adaptive and run Prime 28.5 as an example, you should see it ~0.08v above your VID (the value you set in BIOS).
> 
> On your other question, yes it can report that because it's using C States, the monitoring programs don't read "stuff" correctly with them enabled, obviously your chip cannot be running say x48 @ 0.016v (which is shows when C6/C7 are enabled and speedstep disabled). It's just polling the chip to report what it sees.


Hi

Thank you very much for your help on this extremely important matter to me!!

I've just run prime95, blend x42 with Adaptive Vcore of 1.15V in the BIOS and cache = 1.2V, override mode. Here are the results:


Spoiler: Warning: Spoiler!







HWiNFO's Core # VID(s) are not shown but they were equal (approx.) with the Core Voltage of CPU-Z.
VIN6 is 0.066V above VID in the BIOS. What do you think?

ps: I don't know to what other question (of mine?) you are referring.


----------



## error-id10t

Updated again.


Spoiler: Adaptive x42 @ 1.15v in BIOS. Idle (C3 disabled, C6/C7 enabled)







Both programs read VID @ 1.125v which is less than what I set. Vcore behaves as expected with C6/C7 enabled and idling.



Spoiler: Adaptive x42 @ 1.15v in BIOS. Prime95 28.5 Blend (C3 disabled, C6/C7 enabled)







Both programs are still reading VID as a same value (1.14v) but it's still below 1.15v set in the BIOS. Vcore however matches 1.15v set in BIOS, unexpected under Adaptive.

I'm going to up the Multi and see how it changes the behaviour, I think this multi is just too low and the board "over-writes" something making it behave this way.

*Update1*.



Spoiler: Changed Multi to x44, no other changes.







I threw in XTU to show it's set to 1.15v using Adaptive but now VID is reported @ 1.194v. Vcore behaves as expected when idling.



Spoiler: Same as above running Prime 28.5 Blend







Running Prime raises both VID and vcore. VID has gone up by 0.02v to 1.21v in both programs and vcore is now 1.23v.

You can now see that 0.08v difference when using Adaptive (BIOS @ 1.15v vs. Prime @ 1.23v) but what get's me is that VID is completely wrong. If VID was showing 1.15v (which is what is set in BIOS) then it would make sense but it's nowhere that value even when idling.

*Update2*.



Spoiler: Changed Multi to x47 @ 1.35v, no other changes







VID is almost matching what's in the BIOS (1.35v), whatever motherboard over-writing stuff was happening raising voltage this high removed it.



Spoiler: Same as above running Prime 28.5 Blend







As what happened with x44, running Prime raises both VID and vcore. VID has gone up by ~0.02v in both programs and vcore matches x44 behaviour.

Depending on how you look at it, if you compare idle VID vs. load vcore then the difference is ~0.04v. If you compare load VID vs. load vcore then the difference is 0.02v. Both are obviously less than the 0.08v that was happening when using x44 multi.

tl;dr, I still don't trust Adaptive, but hope someone else can use that somehow.

*Update3.*



Spoiler: Manual







Trusted Manual mode. VID does not change anymore so I know programs know what I have in BIOS, I can also now see the vcore. Nothing else was changed but note how vcore is 0.02v lower because VID did not rise by 0.02 under load.


----------



## LostParticle

Quote:


> Originally Posted by *error-id10t*
> 
> *Update3.*
> 
> 
> 
> Spoiler: Manual
> 
> 
> 
> 
> 
> 
> 
> Trusted Manual mode. VID does not change anymore so I know programs know what I have in BIOS, I can also now see the vcore. Nothing else was changed but note how vcore is 0.02v lower because VID did not rise by 0.02 under load.


Here are my results, under load, at 4.7GHz, Override Vcore mode set at 1.350V in the BIOS. Running the latest prime95, blend.


Spoiler: Warning: Spoiler!







I have also the A-Tuning suite, from ASRock, running. It shows the voltage values I have set in the BIOS.

(max) VIN6 - BIOS Vcore = 1.384V - 1.350V = 0.034V

All power saving features - disabled.

ps: I've replicated your other settings, as well, but the results seemed "weird" (strange) to me so I did not post them. I have the screenshots, though. We should agree on the settings, especially the power saving settings, and run these test under the same ones, if you wish.


----------



## LostParticle

Hi everyone!

A few minutes ago I have received an e-mail from ASRock's Technical support (ASRock TSD) regarding that Vcore matter. In short, they say that my motherboard does have a Vcore voltage sensor and its reading is represented in HWiNFO64 through the VIN6 value.

Here is my entire communication with them from the beginning, a total of four e-mails. Two from my side and two replies from them. The first two have already been posted in this thread, but I am including them all in this message, for consistency.


Spoiler: Warning: Spoiler!



LostParticle says:

Dear Sir,

A few days ago I've purchased a Z97 Extreme6. I've also installed the A-Tuning suite, recently. Does this motherboard have a sensor (or an other way) to measure the true VCore in real time? When I use software like the popular HWiNFO64, there's no VCore value shown there. Only Core # VID is shown (and it is bouncing all the time).
In A-Tuning suite there is a reading called "VCore Volt.". Does this represent the actual VCore, in real-time? I have purchased this motherboard to overclock my Intel processor a bit, and VCore is fundamental.

ASRock TSD replies:

Dear customer !!
Thank you for contacting ASRock.

Since Intel 8 series chipset(1150-pins Haswell CPU), the fivr integrates legacy power delivery onto processor.
And we have designed sensor from CPU detect pin to super IO for the Vcore Voltage on this model.

There are some model only provide the VID sensor on the motherboard.
Due to the moment of Vcore Voltage is similar to VID and does not exceed VID.
So, some utility may only show VID for user to observe as Vcore Voltage indicator.
If you want to observe the Vcore Voltage on this model, please use A-tuning which shows Vcore Voltage.

LostParticle says:

Dear Sir,

Thank you for your reply.

If it's true that you monitor the real-time, actual, VCore value from a CPU pin to SuperIO (SIO/LPC) I think I would be able to see this value in (latest) HWiNFO64 because it displays all SIO voltages read. Can you please tell me which VINx on the SuperIO should be reporting the real-time VCore? Not the static value set in the BIOS. Please understand I am referring to the real-time value. Also, can you please tell me if my motherboard, the ASRock Z97 Extreme6, has this sensor you mentioned? Does it have this sensor from CPU detect pin to super IO for the Vcore Voltage? Or only higher motherboard models have it?

ASRock TSD replies:

Dear customer !!
Thanks for your feedback.

This model, Z97 Extreme6, have the Vcore Voltage sensor, if you want to observe Vcore voltage in HWiNFO64, please refer the VIN6 which is Vcore voltage from SuperIO.



So, according to ASRock, VIN6 is the actual Vcore. I don't know if this is valid but it is what they claim.

@Mumak, what is your opinion?


----------



## Mumak

Hmmm, interesting.. I don't know if it's true, but it they say so we should probably trust that.. But interesting is also that their A-Tuning tool doesn't report it. Wondering why..
Can you please ask them which of their models support this Vcore from VIN6? I can then add it into HWiNFO.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Hmmm, interesting.. I don't know if it's true, but it they say so we should probably trust that.. But interesting is also that their A-Tuning tool doesn't report it. Wondering why..
> Can you please ask them which of their models support this Vcore from VIN6? I can then add it into HWiNFO.


Okay Martin, I will send them one last e-mail to clarify this. So, the question should something like:

- Which of your models have a Vcore sensor that can be read from HWiNFO64 and other monitoring software?

Kind of like that should I ask?

I've loaded optimal defaults (F9) and then disabled all power saving features (C1E, C3, C6/C7). I've also disabled EIST and Turbo. Finally, I've set LLC (Load Line Calibration) at its strictest level, Level 5.

The results on idle.


Spoiler: Warning: Spoiler!







In my BIOS, HWmonitor section, Vcore = 1,064V


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay Martin, I will send them one last e-mail to clarify this. So, the question should something like:
> 
> - Which of your models have a Vcore sensor that can be read from HWiNFO64 and other monitoring software?
> 
> Kind of like that should I ask?


Better something like:
Which of your 8/9-series models have a Vcore sensor that can be read from HWiNFO64 and other monitoring software (as VIN6) ?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Better something like:
> Which of your 8/9-series models have a Vcore sensor that can be read from HWiNFO64 and other monitoring software (as VIN6) ?


Okay, e-mail sent









Is AVCC the same as +3.3V?


----------



## jlhawn

hwinfo is reporting the 900 series gpu's as 800 series, it shows my GTX 970 as a GTX 870, but all other programs show my gpu correctly.


----------



## FastEddieNYC

Quote:


> Originally Posted by *LostParticle*
> 
> Okay Martin, I will send them one last e-mail to clarify this. So, the question should something like:
> 
> - Which of your models have a Vcore sensor that can be read from HWiNFO64 and other monitoring software?
> 
> Kind of like that should I ask?
> 
> I've loaded optimal defaults (F9) and then disabled all power saving features (C1E, C3, C6/C7). I've also disabled EIST and Turbo. Finally, I've set LLC (Load Line Calibration) at its strictest level, Level 5.
> 
> The results on idle.
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> In my BIOS, HWmonitor section, Vcore = 1,064V


I'm pretty sure that load line level 1 is the strictest. I've found that it affects the cpu input voltage.


----------



## Mumak

Quote:


> Originally Posted by *jlhawn*
> 
> hwinfo is reporting the 900 series gpu's as 800 series, it shows my GTX 970 as a GTX 870, but all other programs show my gpu correctly.


The latest HWiNFO Beta available fixes this. And there will be a new version very soon too


----------



## LostParticle

Quote:


> Originally Posted by *FastEddieNYC*
> 
> I'm pretty sure that load line level 1 is the strictest. I've found that it affects the cpu input voltage.


Two screenshots from my BIOS - because the explanation diagram is minuscule:


Spoiler: Warning: Spoiler!








Whenever I attempt to O/C I set LLC to 1. Actually, the BIOS sets it automatically, I think.

Note: perhaps we use the word "strictest" with a different meaning.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The latest HWiNFO Beta available fixes this. And there will be a new version very soon too


Great news, man!









- Is AVCC the same as +3.3V?

Thanks


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Great news, man!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> - Is AVCC the same as +3.3V?
> 
> Thanks


Yes, AVCC is the analog +3.3 V power input for the Nuvoton chip.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, AVCC is the analog +3.3 V power input for the Nuvoton chip.


Thanks Martin, and also thank you for your new build. It works fine on my system, besides those arbitrary meaningless values like the Auxiliary temperature, VIN12 and VIN14 and the CPU Digital IO value, which is repeated. So, when it comes to that AVCC can I safely disable/hide that, then? I will do the same with the rest I have mentioned.

Finally, I've already e-mailed that question but unfortunately I've forgotten to ask them about the DRAM voltage. It usually takes them 3-4 working days to reply to me. I'll let you know.


----------



## Mumak

Yes, you can hide those values. I display them all in most cases since you never know if some of them might be valid (as you have seen just in this case with VIN6).


----------



## jlhawn

Quote:


> Originally Posted by *Mumak*
> 
> The latest HWiNFO Beta available fixes this. And there will be a new version very soon too


thank you.


----------



## LostParticle

Martin, hi again

Regarding that question towards ASRock's support dep, I got their answer:


Spoiler: Warning: Spoiler!



Dear customer !!
Thanks for your reply.

I'm glad to hear your problem be solved.
About the question from developer of HWiNFO64.
Due to there is a contact window of company for these kind of business communication.
We have passed this issue to our contact window for HWiNFO64.
Thanks for your valuable suggestions.

Thanks a lot !!
ASRock TSD



Do you happen to know if the cache voltage (ring voltage) is shown somewhere in HWiNFO? Is there a sensor for this?


----------



## Mumak

Hum, I have no idea what a "contact window for HWiNFO64" means







But hopefully somebody will answer.
About cache/ring voltage - that's also rather a question to ASRock.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Hum, I have no idea what a "contact window for HWiNFO64" means
> 
> 
> 
> 
> 
> 
> 
> But hopefully somebody will answer.
> About cache/ring voltage - that's also rather a question to ASRock.


Okay Martin, thank you, yes I have already e-mailed them.

By the way, here is a screenshot from my e-mail client, Outlook 2013, showing our last communication with Asrock TSD. I always copy and paste their replies -and my questions- but I've never posted an actual screenshot.


Spoiler: Warning: Spoiler!







Martin, what does CPU SA mean in HWiNFO? Is this the System Agent voltage?

Also, in the latest version of the program, when trying to reorder a few values with the new, drag&drop, method my GPU's sensor title disappeared... I will retry.

Thanks


----------



## Mumak

Yes, SA = System Agent.
I'm not sure what happened with the reorder, but you can check the Layout tab of Settings. If you feel there's something wrong, hit the "Restore Original Order" button.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, SA = System Agent.
> I'm not sure what happened with the reorder, but you can check the Layout tab of Settings. If you feel there's something wrong, hit the "Restore Original Order" button.


Yeah, I thought so about SA but...guess what! CPU SA does not match A-Tuning's System Agent value! Haha... no surprise...

I'll see what I can do.

Thank you.


----------



## FastEddieNYC

Quote:


> Originally Posted by *LostParticle*
> 
> Martin, hi again
> 
> Regarding that question towards ASRock's support dep, I got their answer:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> Dear customer !!
> Thanks for your reply.
> 
> I'm glad to hear your problem be solved.
> About the question from developer of HWiNFO64.
> Due to there is a contact window of company for these kind of business communication.
> We have passed this issue to our contact window for HWiNFO64.
> Thanks for your valuable suggestions.
> 
> Thanks a lot !!
> ASRock TSD
> 
> 
> 
> Do you happen to know if the cache voltage (ring voltage) is shown somewhere in HWiNFO? Is there a sensor for this?


Ring bus(Cache) is VIN 12.
I could be wrong but I thought A-Tune shows the offset for SA, not the actual voltage.


----------



## Duality92

Did you implement what I posted a while back for the item selection boxes and such?


----------



## LostParticle

Quote:


> Originally Posted by *FastEddieNYC*
> 
> Ring bus(Cache) is VIN 12.
> I could be wrong but I thought A-Tune shows the offset for SA, not the actual voltage.


Hello - thanks for your reply









When it comes to CPU cache Override (or even Adaptive) Voltage, I am expecting an input from ASRock's technical support.
IF it will be VIN12, I will be happy!

When it comes to System Agent voltage the last screenshot I have from A-Tuning utility can be seen on this post. I was always leaving SA in Auto. I do not know what values it can take. If you can guide me, I can try.

Since yesterday I do not have the A-Tuning suite installed on my system anymore. I have received my new SanDisk SSD and I have performed a clean install of Windows 7, because it is time now to start using my system regularly - and finish with all these tests. I have found my 24/7 stable o/c, it is 4.7GHz, it is enough for me and I am happy.









I have quite a few other questions about what HWiNFO monitors on my system, but I will ask them in time. Like for example, what are the CPU IA and CPU GT cores temperatures readings, why are PCH 1.05V and PCH 1.5V not present in HWiNFO, why aren't the Additional Offsets monitored, and perhaps a few more. Martin, if you would be so kind to answer - thank you very much!

Here's a screenshot of how I have it so far


Spoiler: Warning: Spoiler!


----------



## FastEddieNYC

If your memory is faster than 1600 I dont recommend using Auto for the voltages. I've found that when I set my ram to XMP profile for 2133 with voltages on auto it added WAY too much voltage to SA(.3),dig and analog IO. When I get home I'll compare your voltages to my settings.
Cpu GT is the haswell GPU temp and IA is the sensor in the cores.
4.7 is a nice OC and your vcore is well within the safe range.


----------



## LostParticle

Quote:


> Originally Posted by *FastEddieNYC*
> 
> If your memory is faster than 1600 I dont recommend using Auto for the voltages. I've found that when I set my ram to XMP profile for 2133 with voltages on auto it added WAY too much voltage to SA(.3),dig and analog IO. When I get home I'll compare your voltages to my settings.
> Cpu GT is the haswell GPU temp and IA is the sensor in the cores.
> 4.7 is a nice OC and your vcore is well within the safe range.


Thanks for your help!









My RAM, also shown in my rig, is 1866MHz, 8-9-9-24 @1.6V - and these are the settings I've manually set in the BIOS for it. I totally agree that the user should input all of the settings manually in the BIOS, and not rely on Auto settings, but my problem with SA and some others is that I do not know their regular or even recommended maximum values! Looking at this table, taken from this awesome guide, I cannot really understand what I should set SA to. I have never tried to change it though, so perhaps I should try.

Thank you for clarifying it about CPU IA cores and CPU GT cores. Martin, can you confirm, please?

EDIT:
Well...I really don't know how this thing (SA volt.) works... It is the FIRST time ever I touch this value - in the 2 weeks or less, I own this system.

So, I went in the BIOS and when it comes to System Agent you can set the Offset of this value, only! So I looked at the HW Monitor tab in the BIOS and it was showing : System Agent voltage = 1.208V - 1.216V. This was its AUTO value - I've never touched it.

Then in the OC-tweaker tab, I set an offset of -0.010, expecting the SA to drop at 1.198V. Look at the value of SA the program is giving me!


Spoiler: Warning: Spoiler!







I don't understand how this works. To which value is the offset added or from which is it subtracted ?...?


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> Did you implement what I posted a while back for the item selection boxes and such?


I started implementing it, but I encountered some difficulties which prevented a successful implementation.
Instead I implemented drag-and-drop support in the main window to easily reorder sensor items. You can use this also to remove items from the list (by dropping outside of the window).


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I have quite a few other questions about what HWiNFO monitors on my system, but I will ask them in time. Like for example, what are the CPU IA and CPU GT cores temperatures readings, why are PCH 1.05V and PCH 1.5V not present in HWiNFO, why aren't the Additional Offsets monitored, and perhaps a few more. Martin, if you would be so kind to answer - thank you very much!


CPU IA Cores (=CPU cores) and GT (GPU) are read from internal CPU sensors.
I don't think that PCH 1.05V and PCH 1.5V can be monitored.
HWiNFO doesn't report all the various settings you can make in the BIOS. There is no universal way how to detect those, it would require special support for each mainboard model and that would be an overkill effort. Not to mention that such information is not publicly available, so not easy to determine.


----------



## Duality92

Quote:


> Originally Posted by *Mumak*
> 
> I started implementing it, but I encountered some difficulties which prevented a successful implementation.
> Instead I implemented drag-and-drop support in the main window to easily reorder sensor items. You can use this also to remove items from the list (by dropping outside of the window).


With that, could you just make the windows to make them appear again larger at least? you can only see 3-4 items in it and when you have 100+ items in it, it makes it hard to search for.


----------



## LostParticle

Quote:


> Originally Posted by *Duality92*
> 
> With that, could you just make the windows to make them appear again larger at least? you can only see 3-4 items in it and when you have 100+ items in it, it makes it hard to search for.


I fully agree. It would be really nice if the HWiNFO window could be expanded and the (rest of the) values displayed in a second or even third column. Right now I have 37 hidden values and still require my monitor in portrait mode to view them all.

Quote:


> Originally Posted by *Mumak*
> 
> CPU IA Cores (=CPU cores) and GT (GPU) are read from internal CPU sensors.
> I don't think that PCH 1.05V and PCH 1.5V can be monitored.
> HWiNFO doesn't report all the various settings you can make in the BIOS. There is no universal way how to detect those, it would require special support for each mainboard model and that would be an overkill effort. Not to mention that such information is not publicly available, so not easy to determine.


Okay, I understand, of course.

Can you please tell me the difference between:

Core # temp - CPU IA cores temp - CPU Package temp?

Thank you.

ps: I asked about PCH 1.05V and PCH 1.5V because my motherboard's utility (A-Tuning) is showing them and I thought that perhaps there was an easy way for HWiNFO to show them, too. I was not expecting to see every value that can be changed in the BIOS, but every value each utility/suite from the manufacturer can show.


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> With that, could you just make the windows to make them appear again larger at least? you can only see 3-4 items in it and when you have 100+ items in it, it makes it hard to search for.


Which window do you exactly mean, the one listing hidden values only ?
Quote:


> Originally Posted by *LostParticle*
> 
> Can you please tell me the difference between:
> 
> Core # temp - CPU IA cores temp - CPU Package temp?


CPU IA cores temp should be the highest among all CPU cores.
CPU Package temp should be the highest among all sensors in CPU, though I'm not exactly sure if this includes some additional sensor that's not documented. Intel doesn't give out such information (not even under NDAs with higher level).


----------



## Duality92

Quote:


> Originally Posted by *Mumak*
> 
> Which window do you exactly mean, the one listing hidden values only ?


Exactly.


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> Exactly.


I have enlarged that one some time ago, about 5 lines should fit. How tall would you like it to have?


----------



## Duality92

Quote:


> Originally Posted by *Mumak*
> 
> I have enlarged that one some time ago, about 5 lines should fit. How tall would you like it to have?


would 10 be asking for too much?


----------



## LostParticle

Duality92 meant something else.

What I meant is shown in the screenshot:


Spoiler: Warning: Spoiler!







Do you see all this empty space when HWiNFO is maximized? It would be really nice to place the rest of the values there, ONLY when the window gets maximized, instead of having to scroll down to see them. I do not know if this is hard to implement, I'm just saying my opinion.









Quote:


> Originally Posted by *Mumak*
> 
> Which window do you exactly mean, the one listing hidden values only ?
> CPU IA cores temp should be the highest among all CPU cores.
> CPU Package temp should be the highest among all sensors in CPU, though I'm not exactly sure if this includes some additional sensor that's not documented. Intel doesn't give out such information (not even under NDAs with higher level).


So, CPU IA cores = Core max (temp) ? [the two readings show the same thing?]
And also, through CPU Package we can observe the Tcase ?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Duality92 meant something else.
> What I meant is shown in the screenshot:


No he meant what I meant. But the feature you propose is in the plan.
Quote:


> Originally Posted by *LostParticle*
> 
> Do you see all this empty space when HWiNFO is maximized? It would be really nice to place the rest of the values there, instead of having to scroll down to see them. I do not know if this is hard to implement, I'm just saying my opinion.
> 
> 
> 
> 
> 
> 
> 
> 
> So, CPU IA cores = Core max (temp) ? [the two readings show the same thing?]
> And also, through CPU Package we can observe the Tcase ?


Core max is calculated by HWiNFO as the max of the values sampled from all cores by HWiNFO.
CPU IA cores is reported by the CPU.
Tcase is something else and cannot be measured using internal CPU sensors like those above.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No he meant what I meant. But the feature you propose is in the plan.


Oh, thanks a lot!








Actually, I meant that he meant something else than what I meant but it's my English again!
Quote:


> Originally Posted by *Mumak*
> 
> Core max is calculated by HWiNFO as the max of the values sampled from all cores by HWiNFO.
> CPU IA cores is reported by the CPU.
> Tcase is something else and cannot be measured using internal CPU sensors like those above.


Now, Martin this is *extremely* important to me!! Which one of those two values should I trust when seeking for the Core MAX temp? CPU IA or Core max? In my HWiNFO64 I have two alerts (rules):

- Shutdown computer (or kill the specific stress test) if core max >=91
- Shutdown computer (or kill the specific stress test) if VCore >= 1.45V

On the first rule which value should I monitor/use? CPU IA or Core Max?
[Core Max can be higher than CPU IA cores]


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Now, Martin this is *extremely* important to me!! Which one of those two values should I trust when seeking for the Core MAX temp? CPU IA or Core max? In my HWiNFO64 I have two alerts (rules):
> 
> - Shutdown computer (or kill the specific stress test) if core max >=91
> - Shutdown computer (or kill the specific stress test) if VCore >= 1.45V
> 
> On the first rule which value should I monitor/use? CPU IA or Core Max?
> [Core Max can be higher than CPU IA cores]


I think they both should be quite same, since they read it from the same sensor (though I'm not sure about the IA Cores exact implementation which is not published by Intel). Small CPU temperature spikes might happen between HWiNFO refresh cycles (refresh period) and thus might not be captured.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think they both should be quite same, since they read it from the same sensor (though I'm not sure about the IA Cores exact implementation which is not published by Intel). Small CPU temperature spikes might happen between HWiNFO refresh cycles (refresh period) and thus might not be captured.


Well, yeah...who knows...


Spoiler: Warning: Spoiler!



Ambient temp = 26C





I'm not stressing my PC that much anyway.


----------



## Mumak

The differences between them depend on exact sampling time of the temperature, because spikes often occur between them.
But if you notice the Average values, they are very close.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The differences between them depend on exact sampling time of the temperature, because spikes often occur between them.
> But if you notice the Average values, they are very close.


Yeah, you are right. Surprising though that AIDA64 has not peaked those spikes on its Maximum. Well...I guess I will keep monitoring "Core Max" (in my Alerts).


Spoiler: Warning: Spoiler!



We are living in 2014 and the engineers still have not managed to give ONE accurate value about (critical) temperatures and ONE accurate value about the (critical) voltage, so that the user -and the programmer, as well- will be able to monitor and control his system with peace in his mind.


----------



## taem

Hey Mumak-

My z97 board has 2 extra sata ports from an Asmedia controller. There isn't a bios option to turn off the hot swap function on these Asmedia ports on this mob, which my z87 had.

Whenever I launch hwinfo, the hdds connected to the Asmedia ports disconnect and I have to reboot to get them back.

Hope there's some box I can un/check to avoid this?


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Hey Mumak-
> 
> My z97 board has 2 extra sata ports from an Asmedia controller. There isn't a bios option to turn off the hot swap function on these Asmedia ports on this mob, which my z87 had.
> 
> Whenever I launch hwinfo, the hdds connected to the Asmedia ports disconnect and I have to reboot to get them back.
> 
> Hope there's some box I can un/check to avoid this?


Try to "Disable Drive Scan" in HWiNFO - Settings. Let me know in case it didn't help.


----------



## LostParticle

@Mumak

Hello there, Martin!

I just received some feedback from ASRock support, regarding a few questions of mine. Perhaps it might interest you.



Spoiler: Warning: Spoiler!



Dear customer !!
Thanks for your reply.

My question : _Is there a DRAM voltage sensor on this board, able to show DRAM voltage in real time?_
The DRAM voltage sensor is from superIO, it just detect how many voltage you have adjusted, the default DRAM voltage is 1.50V.

My question : _The CPU cache Voltage, is it shown in real-time or it shows the fixed value set in the BIOS? Where is [the] CPU cache voltage in HWiNFO64? Is it VIN12?_
In our superIO pin define, the CPU cache voltage is VIN2 and 106 superIO pin.
But we cannot guarantee the CPU cache voltage in HWiNFO64 is VIN2, you may need to contact HWiNFO64 vendor for their define.

My question : _[Regarding] VCore Volt. in A-Tuning suite : [it] is not equal to Vcore (VIN6) in HWiNFO64&#8230; It seems more like VID._
In A-Tuning, the Vcore Voltage is real Vcore Voltage, since we have designed the re-flash rate to slower than other utility (It's average of ten times Vcore Voltage of every re-flash).
So, it may looks like VID. Please feel free to use it.

Thanks a lot !!
ASRock TSD


----------



## Mumak

Thanks. So..
"DRAM voltage": I don't understand what they mean








"CPU cache voltage": that means, VIN12 in HWiNFO is indeed "CPU cache voltage". I'll adjust the label for this.
Vcore in A-Tuning: now that's a mess - they make an average of 10 Vcore values.. I'm wondering what's the use of such value...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. So..
> "DRAM voltage": I don't understand what they mean
> 
> 
> 
> 
> 
> 
> 
> 
> "CPU cache voltage": that means, VIN12 in HWiNFO is indeed "CPU cache voltage". I'll adjust the label for this.
> Vcore in A-Tuning: now that's a mess - they make an average of 10 Vcore values.. I'm wondering what's the use of such value...


Thank you

Regarding DRAM Voltage they mean that their utility, A-Tuning, and their mobo implementation, is capable of showing just what the user sets in the BIOS, for example in my case 1.6V for my DRAM module. IF you wish and it is not a big deal, add a label called "DRAM voltage" in the new build, for us ASRock owners to not feel intimidated by not having any DRAM readings there, meaning no temperature - no voltage. Just kidding, think about it tho, if it's not a fuss.









I AM Happy that this is the actual Uncore (cache) voltage!! You are sure, right? Me-Happy!!

I do not have A-Tuning installed any more.

I'm forming the opinion that ASRock is decent.


----------



## Mumak

But they say "The DRAM voltage sensor is from superIO" and from their words I understand it that some of the VINs in HWiNFO should be reading the actual DRAM voltage offset from 1.5V ? So in your case, some of that Nuvoton values should be 0.1V.. Or do I get that wrong? It would be very unusual and weird that a SuperIO voltage sensor measures an offset anyway...


----------



## mfdoom7

why does my motherboard vrm sensor does not work ?
ive monitored like 3hours and no change


----------



## Mumak

Quote:


> Originally Posted by *mfdoom7*
> 
> why does my motherboard vrm sensor does not work ?
> ive monitored like 3hours and no change


VR T1 belongs to the 1st loop of the VRM, so this is the current temperature of that VRM. VR T2 reflects the 2nd loop, which I cannot see on the screenshot, otherwise you should see a second instance of the VRM. So I guess the second one is not present and thus VR T2 is invalid and should be ignored.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> But they say "The DRAM voltage sensor is from superIO" and from their words I understand it that some of the VINs in HWiNFO should be reading the actual DRAM voltage offset from 1.5V ? So in your case, some of that Nuvoton values should be 0.1V.. Or do I get that wrong? It would be very unusual and weird that a SuperIO voltage sensor measures an offset anyway...


Martin, hello again









To be honest, what I get from their phrase is this:

--the default DRAM voltage is 1.5V -meaning when loading Optimal Defaults (F9) the motherboard sets DRAM @1333MHz, 1.5V - I confirm this.
--their DRAM voltage sensor just detects how much voltage you have set in the BIOS (and just that) - meaning it shows the static voltage value and not the real-time DRAM voltage value.
--this DRAM voltage sensor is from Super IO.

That is what I can understand. Now, I don't know how these things work, and also their original phrase is on my previous message, copied & pasted from my e-mail.

Please Martin, make sure that the Uncore (cache) voltage is and will be measured accurately! At least, as accurately as their sensor is measuring it.

Going for a clean install now, hope to have your new build soon


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Martin, hello again
> 
> 
> 
> 
> 
> 
> 
> 
> 
> To be honest, what I get from their phrase is this:
> 
> --the default DRAM voltage is 1.5V -meaning when loading Optimal Defaults (F9) the motherboard sets DRAM @1333MHz, 1.5V - I confirm this.
> --their DRAM voltage sensor just detects how much voltage you have set in the BIOS (and just that) - meaning it shows the static voltage value and not the real-time DRAM voltage value.
> --this DRAM voltage sensor is from Super IO.
> 
> That is what I can understand. Now, I don't know how these things work, and also their original phrase is on my previous message, copied & pasted from my e-mail.
> 
> Please Martin, make sure that the Uncore (cache) voltage is and will be measured accurately! At least, as accurately as their sensor is measuring it.
> 
> Going for a clean install now, hope to have your new build soon


It's technically not possible to measure a thing like a setting for DRAM voltage in BIOS via a SuperIO.
The only thing I can adjust is the name of VIN12 - the value it reads should what they say (as long as they don't perform any additional adjustments with the value like they do with the Vcore averaging).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It's technically not possible to measure a thing like a setting for DRAM voltage in BIOS via a SuperIO.
> The only thing I can adjust is the name of VIN12 - the value it reads should what they say (as long as they don't perform any additional adjustments with the value like they do with the Vcore averaging).


Okay, I believe you









The only thing I feel "obliged" to do is to post a screenshot from my e-mail client where everything I've copied and pasted is clearly seen.


Spoiler: Warning: Spoiler!







Going for a Windows clean installation now.


----------



## FastEddieNYC

Does anyone know what VIN 14 voltage is for Asrock Extreme 4?


Ive tried changing voltages in bios one at a time but nothing seems to change that voltage.


----------



## Duality92

I'm more curious on that CPU2 fan, it most push out quite a quantity of air hahaha


----------



## Mumak

VIN14 might not be connected at all, so it provides just 'random garbage'.
CPU2 fan indeed looks invalid, is there a fan connected ?


----------



## FastEddieNYC

Quote:


> Originally Posted by *Duality92*
> 
> I'm more curious on that CPU2 fan, it most push out quite a quantity of air hahaha


That's my Scythe Ultra Kaze fans. When I slow them down they don't read the correct rpm. They are a bit noisy at 3000 rpm but pushing 130 cfm of air through my rads keep my water delta low.


----------



## FastEddieNYC

Quote:


> Originally Posted by *Mumak*
> 
> VIN14 might not be connected at all, so it provides just 'random garbage'.
> CPU2 fan indeed looks invalid, is there a fan connected ?


I noticed that the voltage value does change slightly when under full load. I'll do a little more investigating but you are probably right it may not be a valid reading. My fans don't report correctly when I slow them down.


----------



## Mumak

Quote:


> Originally Posted by *FastEddieNYC*
> 
> That's my Scythe Ultra Kaze fans. When I slow them down they don't read the correct rpm. They are a bit noisy at 3000 rpm but pushing 130 cfm of air through my rads keep my water delta low.


OK, I'll will filter out those invalid fan values, so it rather reports 0 than those very high numbers.


----------



## LostParticle

Thanks for the new beta!









May I ask, what is the difference between GPU Temperature and GPU Temperature (HW)?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thanks for the new beta!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> May I ask, what is the difference between GPU Temperature and GPU Temperature (HW)?


"GPU Temperature" is read via a public NVIDIA interface (NVAPI).
"GPU Temperature (HW)" is read straight from the hardware.
I keep both values since some users claimed there were differences, so everyone can choose what he likes


----------



## Duality92

I noticed yesterday my 7790 shows a few GPUs types it could be, but when it lists the Rx xxx series is puts R9 260, when actually it's R7, tiny correction


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> I noticed yesterday my 7790 shows a few GPUs types it could be, but when it lists the Rx xxx series is puts R9 260, when actually it's R7, tiny correction


Can you please provide a screenshot of that so I can see exactly ?


----------



## Duality92

I don't have my computer up right now but for example when I have my 7790 plugged in it should read : 7700 series/r7 260, instead it shows 7700 sries/r*9* 260. That's it.


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> I don't have my computer up right now but for example when I have my 7790 plugged in it should read : 7700 series/r7 260, instead it shows 7700 sries/r*9* 260. That's it.


I have checked the AMD Catalyst drivers and they say the same: "AMD Radeon R9 260". So is Catalyst reporting the wrong as well ?


----------



## Duality92

Yup lol

http://www.amd.com/en-us/products/graphics/desktop/r7


----------



## Mumak

I took the brand names from Cat drivers and didn't validate it







Will fix that in the next build.


----------



## Duality92

I would've assuming AMD had their own drivers labeled correctly too


----------



## Mumak

Quote:


> Originally Posted by *Duality92*
> 
> I would've assuming AMD had their own drivers labeled correctly too


Me too


----------



## SSDdrivei7

It's a tough job, Mumak,







agreed, but you're doing an awesome job! You always have! I use HWINFO when my systems boot. I've used it for years. Can't remember never using or relying on it. Plain and simple: I would feel naked without it running, where I like knowing what is going on with my hardware or my friend's at any given time regardless of which computer I'm currently using/troubleshooting. So, 'Thanks, Mumak!'









Oh, repped U!


----------



## LostParticle

Well, I'd really like to Thank you very much, as well, because in your latest beta build you gave me the ability to monitor my chassis fans which are all connected to my Aquaero. I've been too lazy - too busy overclocking, so I have not set up the Aquasuite yet... It is amazing that I can keep an eye on them, through HWiNFO64!

Thanks a lot, once again!


----------



## Mumak

You're welcome guys and thanks for your kind words.
The Aquaero support might need some more testing and tuning. I don't have any hardware yet to test it, but I should get a controller soon from Aquacomputer which have been so nice to send me it for free.


----------



## LostParticle

You are welcome, too, Martin!
I have an Aquaero 5 LT









IF you wish me to test something, or do any comparisons after you will receive yours, let me know!

Thanks again


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> You are welcome, too, Martin!
> I have an Aquaero 5 LT
> 
> 
> 
> 
> 
> 
> 
> 
> 
> IF you wish me to test something, or do any comparisons after you will receive yours, let me know!
> 
> Thanks again


Yes, please test anything you can. The labels of particular sensors cannot be properly determined yet (Aquaero doesn't have a suitable method to do this yet, maybe they will add that in future).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, please test anything you can. The labels of particular sensors cannot be properly determined yet (Aquaero doesn't have a suitable method to do this yet, maybe they will add that in future).


Oh, okay!









I took a screenshot :


Spoiler: Warning: Spoiler!







I have two temperature sensors - those provided with the device. One is placed in the Front compartment of my chassis, the other on the rear. I have a Corsair Air 540, and I call "Front Compartment" the space where the motherboard is placed, and "Rear compartment" the space where the PSU is placed. HWiNFO reads them accurately - I will rename them as I did in Aquasuite.

Please guide me on to what exactly you would like me to test and on how exactly I should do so


----------



## Mumak

Well, I'm not sure how to exactly test, because I have no experience with using Aquaero yet. Basically just compare values seen in HWiNFO with those in Aquasuite. The more sensors, the better...
But it seems all is well on your system.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, I'm not sure how to exactly test, because I have no experience with using Aquaero yet. Basically just compare values seen in HWiNFO with those in Aquasuite. The more sensors, the better...
> But it seems all is well on your system.


Yeah, everything seems to get measured accurately on my system









Here is another screenshot:


Spoiler: Warning: Spoiler!







As you can see all the values shown in Aquasuite are in agreement with HWiNFO, with some rounding taking place. For the time being I have all my chassis fans working at full power because, even like this, they are almost silent. What I really appreciate in this new build of HWiNFO64 is that it will allow me to use longer names (about the fans), later when I will be constructing the layout of the Aquasuite.
Aquasuite permits only a limited number of characters. For example, I cannot call my first fan "Noctua NF-S12A PWM (front - intake)". Now I will be able to do this!









I suggest you to leave a post in OCN Aquaero Owners Club in this site. This way other people who have pumps and other Aqua devices will be able to support you. I have my Corsair H110, (4 fan setup), controlled by my motherboard.


----------



## Mumak

Thanks for the feedback.


----------



## LostParticle

@Mumak

Hi Martin!

Can you please tell me if it is possible to log only certain values, like for example the VCore and the Core Max values? I started to use the logging feature a bit, for the first time, but it logs everything monitored. Is there a way to make the software log only the values I will select?

Thank you


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Hi Martin!
> 
> Can you please tell me if it is possible to log only certain values, like for example the VCore and the Core Max values? I started to use the logging feature a bit, for the first time, but it logs everything monitored. Is there a way to make the software log only the values I will select?
> 
> Thank you


Only hidden sensor items are not included in the CSV log. Even if it logs a lot of values, you can easily delete what you don't need using any spreadsheet tools (Excel, etc.).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Only hidden sensor items are not included in the CSV log. Even if it logs a lot of values, you can easily delete what you don't need using any spreadsheet tools (Excel, etc.).


Okay Martin, thanks








Yeah, I know how to process the CSV in Excel 2013, I was just hoping I could avoid the inserting process







No prob tho


----------



## King PWNinater

The program is not displaying the VRM Temperatures for my second GPU, just GPU one.


----------



## Mumak

Quote:


> Originally Posted by *King PWNinater*
> 
> The program is not displaying the VRM Temperatures for my second GPU, just GPU one.


Do you have ULPS active? That might be one reason.
Otherwise please provide more details, at least a screenshot.


----------



## LostParticle

Hey Martin, hope all is well!









I have a simple question:

- Is there a way to save my current configuration -meaning the renaming, the order, the layout in general - so that I will be able to use it again after a clean Windows installation? And not have to redo all the work again?

Thank you!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, hope all is well!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have a simple question:
> 
> - Is there a way to save my current configuration -meaning the renaming, the order, the layout in general - so that I will be able to use it again after a clean Windows installation? And not have to redo all the work again?
> 
> Thank you!


This is something I recently implemented and it will be available in the next Beta build, which is to be released today or tomorrow


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> This is something I recently implemented and it will be available in the next Beta build, which is to be released today or tomorrow


Thanks Martin, looking forward to it!









For some reason, I thought saving your preferences, like those I mentioned, was already available for quite some time now...

Anyway, thank you


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thanks Martin, looking forward to it!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> For some reason, I thought saving your preferences, like those I mentioned, was already available for quite some time now...
> 
> Anyway, thank you


It's released. Use the "Backup User Settings" button in Settings.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It's released. Use the "Backup User Settings" button in Settings.


Thank you, Martin, already got it!









Later today I will perform a clean Windows 7 installation. After I will finish I will inform you if the new setting worked.

Keep up the good work!


----------



## LostParticle

@Mumak

Hey Martin, I am trying to test the new "Backup User Settings" features on my system, I have not performed the clean installation yet.

So, I have saved the .reg file but...I am not able to find it! Where is it stored?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Hey Martin, I am trying to test the new "Backup User Settings" features on my system, I have not performed the clean installation yet.
> 
> So, I have saved the .reg file but...I am not able to find it! Where is it stored?


It should be stored in the same folder as HWiNFO is (or where you launch it from).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It should be stored in the same folder as HWiNFO is (or where you launch it from).


Unfortunately, it is not there... Also, it's nowhere on my computer, I have searched for it. I keep the HWiNFO folder on my desktop. Only the configuration file and the application file is there.


----------



## Mumak

That's weird.. Please try to run from the command line this:

Code:



Code:


regedit -e HWiNFO64_settings.reg HKEY_CURRENT_USER\Software\HWiNFO64

it should have the same effect.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's weird.. Please try to run from the command line this:
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> regedit -e HWiNFO64_settings.reg HKEY_CURRENT_USER\Software\HWiNFO64
> 
> it should have the same effect.


I run it, as Administrator. If by "the same effect" you mean the creation of that back up settings file, it did not happen. No back up settings file has been created and stored on the program's folder.

Did you mean something else, perhaps?

Finally, how will I store my current settings to use them on the new Windows installation I will perform right after we clarify this ?

Thank you


----------



## Mumak

Yes, I meant that it should create the same file. Please try the following:
- Run "regedit" only from the command file - it should open the Windows Registry Editor. Then close it.
- Change to some other folder of you preference (could be even TEMP, or anything else) and try to run the above full command again.

If this will work, then you just need to launch the generated .reg file and all settings will be restored back into the registry.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, I meant that it should create the same file. Please try the following:
> - Run "regedit" only from the command file - it should open the Windows Registry Editor. Then close it.
> - Change to some other folder of you preference (could be even TEMP, or anything else) and try to run the above full command again.
> 
> If this will work, then you just need to launch the generated .reg file and all settings will be restored back into the registry.


What do you mean by "Run "regedit" only from the command file" ? Do you mean "from the command line"?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> What do you mean by "Run "regedit" only from the command file" ? Do you mean "from the command line"?


Just run:
regedit
from the command line. I just need to know that it opens the registry editor.

You might also run "cmd" from the command line. And then enter those commands ("regedit").


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Just run:
> regedit
> from the command line. I just need to know that it opens the registry editor.
> 
> You might also run "cmd" from the command line. And then enter those commands ("regedit").


Okay, now it worked!









So, I save this in my USB stick, perform the Windows clean installation, and when the time of HWiNFO64 installation will come -I use the portable version- I just copy the .reg file on my desktop, double-click on it, and voila, I have my settings again?









Also, on the new installation, do I have to use this procedure each time I wish to back up my settings? Like with the command prompt, etc?


----------



## Mumak

Yes.
Also remember to backup the HWiNFO64.INI file, since this stores some other settings (those which are supposed to be portable).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes.
> Also remember to backup the HWiNFO64.INI file, since this stores some other settings (those which are supposed to be portable).


Okay, thanks. I will report here again after I will be done with everything.


----------



## Mumak

OK, I'll change this, so that the user can choose the path and filename for the backup file, so it's more clear.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I'll change this, so that the user can choose the path and filename for the backup file, so it's more clear.


Okay Martin, that would be nice, (I'll be) waiting for the new beta









For the record, after finishing with the fully updated installations of Windows 7 64bit and Office 2013 Professional Plus, I've downloaded the latest beta of HWiNFO64, portable version. I run it - everything was OK.
Then I've closed the program, copied my backed up .ini and .reg files on its folder - .ini was replaced - doubled-clicked on the .reg and updated my Registry and finally, opened HWiNFO64. All my previous settings, like the hidden values, the renaming, the ordering, some changes in the units of measurement and stuff like that, were all back and applied correctly!









So, all is good









I'd like to ask you something, if it's not too much trouble... Can you, please, post a list of the Registry keys affected by HWiNFO64?
I mean, IF I wish to delete everything related to HWiNFO64 in my Registry which values (keys) do I have to remove and where are they located?

Thank you.


----------



## Mumak

Thanks for the feedback.
All settings are stored in the registry under: HKEY_CURRENT_USER\Software\HWiNFO64
This is essentially what the backup function does save. And if you press the "Reset Preferences" button, all it does is to delete that key.
So it's that simple


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback.
> All settings are stored in the registry under: HKEY_CURRENT_USER\Software\HWiNFO64
> This is essentially what the backup function does save. And if you press the "Reset Preferences" button, all it does is to delete that key.
> So it's that simple


Thanks









After scanning my Registry with "HWiNFO64" in the Find command box I also found the key:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\HWiNFO32

which I have also deleted.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> 
> 
> After scanning my Registry with "HWiNFO64" in the Find command box I also found the key:
> 
> HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\services\HWiNFO32
> 
> which I have also deleted.


That's the kernel driver of HWiNFO. You can uninstall it using "Driver Management" in settings of HWiNFO.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's the kernel driver of HWiNFO. You can uninstall it using "Driver Management" in settings of HWiNFO.


Okay, thanks Martin!

Now, I come to you with a more important question:

- Why isn't my cache Voltage represented properly in the latest beta of HWiNFO64?

Here is a screenshot:



In this example, besides the other settings, I have set my Cache (Uncore) Ratio at 41x and the Cache Voltage at 1.107V, in the BIOS.
A-Tuning suite is showing this correctly. I was not able to find this value in HWiNFO64. The Cache Voltage there has the value of 0.568V, as you can see.

The motherboard is the ASRock Z97 Extreme6, with the latest BIOS. All C-States and EIST are disabled so that all values stay fixed.

ps: I have deleted everything related to HWiNFO64 and downloaded and installed it again, because I have decided to start from the beginning on this clean installation of my system, on this specific motherboard.


----------



## Mumak

I think we already discussed that - I included that value per ASRock support information (from you). But as you can see it's value doesn't seem to be correct. I'm not sure why exactly is that, maybe it can't be properly monitored, or it works only in certain voltage mode (fixed/adaptive ?). If it can't be monitored you might see its value in the main window / CPU / Overclocking (as a static value).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think we already discussed that - I included that value per ASRock support information (from you). But as you can see it's value doesn't seem to be correct. I'm not sure why exactly is that, maybe it can't be properly monitored, or it works only in certain voltage mode (fixed/adaptive ?). If it can't be monitored you might see its value in the main window / CPU / Overclocking (as a static value).


Yeah.... I remember it, too. I think it was working back then, though... or not?
In the meantime I've purchased and used another motherboard, as shown in my signature, so I do not recall exactly. The VCore seems to work. But that value called "CPU cache" in the latest HWiNFO64 does not represent the actual Cache Voltage, anymore







It stays fixed at ~ 0.560V and never changes...

From my e-mail -screenshot posted on the link- I see they were suggesting that "_In our superIO pin define, the CPU cache voltage is VIN2 and 106 superIO pin._". You have renamed VIN12. Without misunderstanding me, please, could you tell me: - Is there any chance that something has been not set correctly in the latest beta? If not, is there any way this can be fixed so that I will be able to see my Cache voltage in real-time?

Please understand that I am just trying to resolve this matter. These values are important.

IF there's no other value that HWiNFO can read and it to be the actual cache, do you think that I should write to them again and ask them?

Thank you.


----------



## Mumak

I haven't changed anything in this area since then, so I think it might be a difference between those mainboards (or their BIOSes).
It's possible that this model can't monitor Vcache and the value displayed by the ASRock tool is in fact the one read from CPU (as a setting), which should be easy to compare (displayed in the main window section I described earlier).
Best way would be to ask ASRock.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I haven't changed anything in this area since then, so I think it might be a difference between those mainboards (or their BIOSes).
> It's possible that this model can't monitor Vcache and the value displayed by the ASRock tool is in fact the one read from CPU (as a setting), which should be easy to compare (displayed in the main window section I described earlier).
> Best way would be to ask ASRock.


Okay, so there is no VIN2 somewhere, anywhere, that can be read and displayed? I am mentioning "VIN2" because this is what they claim in their e-mail to be the cache voltage, as can be seen.

I will e-mail them again, for sure. With screenshots and everything, after I will test this matter more.

Quick question: are you referring to the System Summary window? Where is that / CPU / Overclocking ? On the main window, where it says "Central Processor(s)" ? There, there is a section called IA Overclocking. There are no voltage values there...

Also, another thing I've observed: with the system on Optimal Defaults, I've watched it for a couple of minutes having both HWiNFO64 and the A-Tuning suite, open. Both the Core and Uncore ratios drop at 8x in your program, but in A-Tuning suite I have never seen this "8x" value! Never! They drop there as well, but never to 8x. Do you think this is malfunction or it does not "catch" the value to show it? Is this possible? Shouldn't it show the 8x, too?

ps: by saying that I switched to a different mobo, in the meantime, I meant that I've left this ASRock board aside - I didn't play with it anymore, until yesterday when I mounted it and start using it again. I did not expect the Gigabyte to have the same monitoring features as this ASRock.


----------



## Mumak

VIN2 described by ASRock is the same as VIN12 in HWiNFO (which is renamed to "CPU Cache" for your mainboard). It's just a different name used in HWiNFO.
The Main Window is displayed only if Sensor-only mode is disabled - it's the large window with a tree on the left side.
I though you changed the mainboard, I don't remember which one you had. It's not possible for me to remember all this, because there are just too many users...
Hmm, would maybe multiplying the CPU Cache by 2 give a better value? It's just a speculation, ASRock should know more...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> VIN2 described by ASRock is the same as VIN12 in HWiNFO (which is renamed to "CPU Cache" for your mainboard). It's just a different name used in HWiNFO.
> The Main Window is displayed only if Sensor-only mode is disabled - it's the large window with a tree on the left side.
> I though you changed the mainboard, I don't remember which one you had. It's not possible for me to remember all this, because there are just too many users...
> Hmm, would maybe multiplying the CPU Cache by 2 give a better value? It's just a speculation, ASRock should know more...


Okay... and finally, the VIN12, which is the same as ASRock's VIN2, reads the value from the 106 superIO pin?
Sorry if I do not express this correctly but I do not know about such things.

I've set the cache voltage at 1.111V in the BIOS, fixed voltage (Override Mode). All C-States + EIST , disabled. In Windows the A-Tuning suite shows this value and it never drops, of course, with these settings. The "CPU cache" in HWiNFO64 took a max of 0.544V, after running MSE a bit. So, 0.544V * 2 = 1.088V. This is not equal to 1.111V cache, that I've set in the BIOS, but could you be right you think?

Anyway, even IF you are right, arbitrarily multiplying this value by 2, when it should be measured and shown accurately in the first place, is not such a good idea, I suppose. Of course, I have no experience in these monitoring tools.

For my system please check my signature, I always keep it updated.

After your reply I will test this matter thoroughly and prepare my e-mail to ASRock. By the way, this cache value I've set is not shown anywhere on the main window / / CPU / Overclocking section.

*EDIT:*

I found a screenshot dated from 9/10/2014, so the first days of October. I have reproduced the same settings and tested today: system on Optimal Defaults in both situations, running the latest Prime95, Blend test.

The screenshots:

Today


9 October 2014


The version of HWiNFO64 can be seen. Observe please that VIN12 is changing in v.4.45.2327, whereas on the latest beta, today, the CPU cache -which is the renamed VIN12 - does not change at all !

So, what is happening here, then?


----------



## Duality92

Great work so far guys, I'm impressed.


----------



## Mumak

Well, it looks like VIN12/VIN2 is not the real CPU Cache voltage. I'm not sure what changed between October and now, but I don't think it was HWiNFO. Maybe that's also the reason why ASRock tools don't report this value..?
If you notice the screenshot from the past, the min value was 0.728V which seems too low to be true.
I'm not sure if you can set different fixed voltages in the BIOS, but if that's possible, it might be worth trying different voltages and then look at VIN12 values (min/max/current) in idle and load. They should not differ much for each setting. If you set different values and they seem to be somehow reflecting the measurement, it might be it..

Now a bit explanation-
Regarding multiplying the value - this would be normal. Since the sensor inputs can usually measure a certain range only, mainboard designers use resistors to adjust to the desired level. So for example the sensor chip can measure only voltages 0 to 2.048 V and if you want to measure +3.3V this voltage needs to be reduced by resistors (R2/(R1+R2)). Then the monitoring tool needs to know which mainboard uses what resistors to adjust the measured value (e.g. VIN1 is +3.3V and needs to be multiplied by 2). This is the reason why universal monitoring tools are so difficult to implement - they need to know about each mainboard model. But anyway, for measuring Vcache it's highly unlikely that this voltage was reduced, since its value should perfectly fit into the default sensor range, so requiring a *2 is very unlikely.


----------



## LostParticle

Quote:


> Originally Posted by *Duality92*
> 
> Great work so far guys, I'm impressed.


IF, Sir, that is you being politely sarcastic then you are spot on! Well done!...

Quote:


> Originally Posted by *Mumak*
> 
> Well, it looks like VIN12/VIN2 is not the real CPU Cache voltage. I'm not sure what changed between October and now, but I don't think it was HWiNFO. Maybe that's also the reason why ASRock tools don't report this value..?
> If you notice the screenshot from the past, the min value was 0.728V which seems too low to be true.
> I'm not sure if you can set different fixed voltages in the BIOS, but if that's possible, it might be worth trying different voltages and then look at VIN12 values (min/max/current) in idle and load. They should not differ much for each setting. If you set different values and they seem to be somehow reflecting the measurement, it might be it..


Absolutely nothing has changed in my ASRock motherboard and my system in comparison with that period of October 2014, when the oldest screenshot was taken. A new system with a clean Windows installation it was back then, the same it is now. The motherboard had and has the same latest BIOS - but I could re-flash it, IF that could be the problem.

The only thing that changed is the version of HWiNFO64. When it comes to the min of VIN12 = the cache Voltage, and to the min of Vcore, as well, we already know this. You've expressed in the past your doubt about how accurate this measuring can be since these voltages can take "insane" minimum values. Well...it is how it is. This is how it is. In most Z97 motherboards, as far as I know, being them ASUS, Gigabyte, ASRock or whatever, the minimums in VCore, Cache V etc can take very low values without this being considered an error or a fault.

In my case I face something different and it is important: I cannot monitor the Cache (Uncore) voltage! VRING is not shown in my system (with this mobo). When, in the recent past, it was (shown).......

And of course I can set different fixed voltages in my BIOS, both for Vcore and the Cache. And anything else I desire. The result will be this:
- IF the C-States + EIST will be disabled the fixed voltages I will set will take up to +0.02V - 0.03V, under heavy load - especially the VCore.
- IF the C-States + EIST will be enabled the fixed voltages I will set will fluctuate from a MIN to a MAX value, depending the load. On full load they will equal the above values.

I know all these things. The point is: will HWiNFO64 show them to me, as it used to do, or....I will have to guess them from now on?

Quote:


> Originally Posted by *Mumak*
> 
> Now a bit explanation-
> Regarding multiplying the value - this would be normal. Since the sensor inputs can usually measure a certain range only, mainboard designers use resistors to adjust to the desired level. So for example the sensor chip can measure only voltages 0 to 2.048 V and if you want to measure +3.3V this voltage needs to be reduced by resistors (R2/(R1+R2)). Then the monitoring tool needs to know which mainboard uses what resistors to adjust the measured value (e.g. VIN1 is +3.3V and needs to be multiplied by 2). This is the reason why universal monitoring tools are so difficult to implement - they need to know about each mainboard model. But anyway, for measuring Vcache it's highly unlikely that this voltage was reduced, since its value should perfectly fit into the default sensor range, so requiring a *2 is very unlikely.


Okay, thank you for explaining a bit how it works. Personally, what I genuinely care for is to have a bit of an accuracy in some fundamentally important values, when overclocking. The reason I insist on the Cache Voltage so much is that it seems impossible to me that a modern and very nice board like this ASRock, does not actually offer a reliable Cache V reading. And as we have seen in October this worked!

I will try setting a couple of fixed Vcore and cache values and try them on idle and full load. I will do this in the latest beta. With Power Saving features (C-States, EIST) disabled. Is that how you want me to test this?

I will also try the stable HWiNFO version and also that beta where VIN12 was not renamed yet. Can you please give me a link to the v.4.45-2327 ?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I will try setting a couple of fixed Vcore and cache values and try them on idle and full load. I will do this in the latest beta. With Power Saving features (C-States, EIST) disabled. Is that how you want me to test this?
> 
> I will also try the stable HWiNFO version and also that beta where VIN12 was not renamed yet. Can you please give me a link to the v.4.45-2327 ?


Yes, that's what I wanted to test.

Unfortunately I don't have a backup of Beta versions. So the closest version I can give you is v4.46-2330, which is only 3 builds away from 2327. You can get it here: www.hwinfo.com/beta/hw64_446.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, that's what I wanted to test.
> 
> Unfortunately I don't have a backup of Beta versions. So the closest version I can give you is v4.46-2330, which is only 3 builds away from 2327. You can get it here: www.hwinfo.com/beta/hw64_446.zip


Thanks.

Okay, so here is what I have noticed: no matter what fixed Cache value I will set in the BIOS the CPU Cache Voltage (former VIN12) does not change. For example, it goes from 0.576V to 0.584V, these being min-max, respectively, with a Cache voltage of.....1.30V in the BIOS!

I have observed another strange (?) thing, as well, though! My BIOS, as all of them, has a monitoring section called H/W Monitor. When I set a fixed Cache voltage value, disable C-States + EIST, save&exit, when I reboot then back in the BIOS, in HW Monitor there, I see the "CPU cache voltage" equal to 0.592V or something! Whereas the Vcore I set is shown correctly in the HW Monitor section of my BIOS, the cache is not!

But when I open the A-Tuning suite in Windows the set cache voltage value appears! For the example that exaggerated 1.30V value shows in A-Tuning!

- Is this normal?
- Should I re-flash the BIOS?
- Is it a mobo flaw?
- How can (how is it possible) A-Tuning show the correct fixed value -it does not change though- and in the BIOS, HW monitor section, and also in HWiNFO64 it is not shown?


----------



## Mumak

Oh dear, I dunno








One theory would be that the BIOS health screen displays the VIN12/VIN2 value, whereas A-Tuning only displays the SETTING in BIOS.. Generally if a SETTING is displayed, it doesn't change, but if you measure something, you should be able to see slight changes...


----------



## LostParticle

I have re-flashed the latest official BIOS, even though I already had it, just to be sure.

The result is the same: the Cache Voltage is not shown correctly, neither it is measured, in either HWiNFO64 (all versions I have) or even...in the BIOS H/W Monitor menu...!
This last fact struck me down!!

How is it possible to set a fixed value of the Uncore (Cache) voltage in the BIOS, save & exit, and then to check the monitoring tool of the BIOS and show whatever?! A monitoring tool can make mistakes. But the BIOS itself?!?!

I have tried various settings.
Override Mode, meaning a fixed voltage, and C-States + EIST = Disabled.
Override Mode and these states Enabled.
Adaptive Mode with a +0.8V.

In the BIOS and in HWiNFO64, as well, the so called "CPU cache Voltage" stays fixed at 0.560V or fluctuates a tiny miserable bit, like 0.568 - 0.576, when the values for the cache are between 1.250V and up to 1.300V, in the various tests I have made. It is ridiculous.

The A-Tuning suite, when the cache voltage is fixed, yes, it does show this fixed SETTING. What is the $%[email protected]@$%# - point of showing a fixed SETTING when the user cannot observe and watch the values it takes?! The BIOS.....yeah....you guessed it already: it is desperately in love with ~0.568V or something............

I tend to believe that my motherboard is faulty or that something happened to it... Unfortunately, back in the first days of October 2014, it was still newly purchased, we fixed the Vcore + the Uncore problems, as shown in that screenshot I've posted, and I did NOT deal with this matter further.

For sure I will ask the support what is the meaning of this 0.560-something-Cache voltage in the BIOS-no-matter-what-the-user-sets!

Perhaps, I am missing some big invention here! A bright new idea I cannot grasp....

see ya.

ps: in that earlier beta given above, the ONLY difference I have observed is that VIN12 can take a really low min value. It does never exceed that 0.560something cache V, though.


----------



## LostParticle

Quote:


> Originally Posted by *Duality92*
> 
> Great work so far guys, I'm impressed.


Thank you very much and pardon me for my tone..









I thought you were being sarcastic, because you would have every right to laugh at what you read here! In 2015 almost we are, and there are a couple of fundamental values an overclocker (not me) should be able to check - the Uncore Voltage being one of them! And we, here, cannot conclude on what is really going on...............and charge the Responsibility to whoever deserves it!

Thank you, though!


----------



## error-id10t

@Mumak, what do you need to know / see to be able to determine if we can see the VRM temps of the 970 Gigabyte G1 cards? I'd love to be able to see them and am wondering if it's possible if we can get the right information..


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> @Mumak, what do you need to know / see to be able to determine if we can see the VRM temps of the 970 Gigabyte G1 cards? I'd love to be able to see them and am wondering if it's possible if we can get the right information..


I need you to post (or send me) the HWiNFO Debug File including sensor data. Then I can analyze whether there are any such devices present. That would require a digital PWM, for which the chances are rather small I believe...


----------



## error-id10t

HWiNFO64.zip 47k .zip file


I think this is it, let me know if I missed something?


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> HWiNFO64.zip 47k .zip file
> 
> 
> I think this is it, let me know if I missed something?


Yep, that's the file I needed.
However I can't see there any GPU VR devices that would allow readout, so it's not possible


----------



## LostParticle

Hi again

I do not have any concrete - definite answers on the cache voltage matter, on the ASRock Z97 Extreme6, but I'd like to post a screenshot of something I've observed: after setting the Cache voltage of my system in various modes and values, meaning Override / Adaptive / Auto modes, C-States + EIST enabled / disabled, using various values, the closer value to what I have been setting that I have observed, is the so called "LLC/Ring" voltage value in HW Monitor. Unfortunately, this value stays fixed as well, all the time, like it stays in the A-Tuning suite, but at least it is the closest to what I set, observed in a third party software. This (is valid), taking in consideration the +0.02 - 0.03V that my board adds anyway.

Here is the screenshot:



As you can see (in A-Tuning suite) I have set a fixed Cache voltage of 1.111V, in the BIOS. A-Tuning shows it - it does not monitor it, though, so it does not show it in real-time (like the Vcore).

Next, HWiNFO64 shows a completely false value, as you can see.

And finally, HW Monitor has this LLC/Ring = 1.138V = 1.111V + 0.027V. Once again though, this value stays fixed all the time - as shown from the constant min-max values. It's worth mentioning that VIN13 in HW Monitor is equal with VIN12 (or CPU Cache) in HWiNFO64. These two take the exact same values and they also change simultaneously.

I have placed questions in other threads, too, asking ASRock owners about their Cache voltage, IF it is shown in the BIOS HW Monitor menu, as they set it, and IF it is monitored in real-time. No reply yet.

I have also contacted the Technical Support and they have replied to me! They said they cannot observe this problem on their boards. They suggested clearing the CMOS - I did it - it didn't fix it. Also, they stated again that "_In our superIO pin define, the CPU cache voltage is VIN2 and 106 superIO pin. So, it is able to measure the CPU Cache Voltage._"
I have explained the problem again, describing the procedure step by step, and asking specific questions.

@Mumak if you have the time and the pleasure to think about this matter a bit, I would appreciate it deeply. You are very experienced - you know how these things work - we have already achieved this once, on that beta back in October, this year. Any idea, help, suggestion will make huge good.

Thank you.


----------



## Mumak

I believe that the LLC/Ring voltage you see in HWMonitor is the same value as the one in HWiNFO / Main Window / CPU / Overclocking. This is the setting read from the CPU.
As for the SIO reported values - VIN2 / VIN12 (HWiNFO) / VIN13 in HWMonitor - these all come from the source suggested by ASRock and the fact that HWMonitor reads the same value confirms it's the real measured value.
I'd suggest to wait for the results from owners of other (either the same or close models) of that mainboard if they observe the same values...


----------



## LostParticle

I've checked it and, finally, it is exactly the value that I, the user, set in the BIOS. In the following screenshots it shows it.

I set cache voltage = 1.111V, fixed!


Spoiler: Warning: Spoiler!







After saving & exiting and rebooting the BIOS reads... 0.680V.







[observe please how the VCore is read correctly]


Spoiler: Warning: Spoiler!







HWiNFO64 reads -most probably- the correct values : 1.111V as target and ~ 0.680V , as the BIOS says :


Spoiler: Warning: Spoiler!







So, everyone is happy!









Besides me. Because, where is the 1.111V that I have set? Is it monitored? Can I see the values it takes according to load? Can I monitor its min - max - average, like I do with the rest of the values? Can I monitor it in real-time?

And IF I cannot, whose fault is this?
Is my motherboard faulty?

ps: I've left these screenshots -and questions- here for a more integrated understanding of the problem but also because if after 12 hours I won't have a reply from other users I have asked, I will open a new topic in this forum, to ask, and I will use these screenshots, as an example. Meanwhile, perhaps someone will tell me what's going on here.

ps1: not trying to blame anyone, of course not. Just trying to figure out what's going on and correct this.


----------



## error-id10t

Quote:


> Originally Posted by *Mumak*
> 
> Yep, that's the file I needed.
> However I can't see there any GPU VR devices that would allow readout, so it's not possible


nps, thanks for checking.


----------



## LostParticle

I'm back to state something:

- This trouble I am having with the Cache Voltage value showing erroneously is most probably a result of a faulty sensor on my motherboard. It used to work correctly couple of months ago, now it seems it does not work anymore. Another user with an ASRock Z97 Extreme6, but with a different processor, has tested this and on his system, whatever Cache Voltage is set in the BIOS is shown correctly both in H/W Monitor menu of the BIOS and in HWiNFO64.

So, this is *not* a problem of the ASRock Z97 Extreme6 motherboards, neither of HWiNFO64.

Most probably, it's just me having a faulty motherboard.

I will RMA it, as soon as possible.

For all this info I am 99% sure. I just need one more confirmation from a user with the same mobo/chip, as mine.

Thank you.


----------



## LostParticle

@Mumak

Hi Martin

Can you please tell me what does the "VR VIN (ATX +12V)" mean in this screenshot, taken while a Gigabyte Z97X SOC Force is running Prime95, blend?

As you can see it lowers down to 10.938V. How do you find this value? Does it show that my PSU is perhaps faulty or not functioning the way it should?

I am facing a problem with this motherboard and I am trying to figure out if my PSU is the problem (or if it is just a faulty mobo). Since I do not know / do not wish to test my PSU using a multimeter, I am trying to figure it out by using software, HWiNFO64 in this case. I don't know what the above reading means though.

Do you know, please?

Thank you.


----------



## Mumak

That's the on-board voltage regulator (Digital PWM) for the CPU VCCIN rail. +12V there should be the voltage on input of the VR (so it should come from the PSU).
I suggest to either log values, or open a graph to watch if that low value was just a short peak, or it persists during high load.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's the on-board voltage regulator (Digital PWM) for the CPU VCCIN rail. +12V there should be the voltage on input of the VR (so it should come from the PSU).
> I suggest to either log values, or open a graph to watch if that low value was just a short peak, or it persists during high load.


Unfortunately Martin, I cannot do this anymore because that Z97X SOC Force is already packed and waiting to be RMA-ed. The reason is that in the last few days it has been giving me random restarts and afterwards it could not power on. It tried to power on itself but it was failing. Specifically, the fans were spinning for half a second and the MBIOS led was lid for half a second, and then the motherboard was shutting down again. Then it tried to power on itself. It was looping continuously like this until I would hold the start button pressed for 4-5 seconds to power it off. Nothing on the board's LCD little screen, nothing on my monitors (was shown), during this failed powering on attempt. And of course, I have tried everything like taking the motherboard outside of the chassis, and finally leaving it with the CPU, its cooler, and one stick of RAM. Still the same behavior. And all this, on stock during idling or light - normal usage.

Right now I have the same PSU -see rig- on my old Gigabyte GA-990XA-UD3 mobo, with an AMD FX-8350. For more than 12 hours it is working without any issue, and has run already Prime95, too, a bit.

So, just to fully understand you - because I do not:

- Does this value of the "VR VIN (ATX +12V)" seem normal to you? Above there is another value called "+12V", locked at 11.952V. It was locked at this value all the time. Assuming that this "VR VIN (ATX +12V)" had a constant low of 10.938V -sorry, cannot retest this- what does this tell?

- That the SOC Force is faulty or that the PSU is faulty?

Anyway, I own this PSU approx. 2 years now and I have never faced any issue with it. It has worked with various motherboards, including the two shown in my rig right now. It was just with this new SOC Force that I've had these random restarts, initially, to end up with the mobo not powering on, as I described.


----------



## Mumak

IMO, 10.9V for the +12V rail is a bit lower, but I'm not enough skilled in overclocking, so I suggest to ask other OCers about their opinion.
Also, if you look at the power usage (POUT), the CPU VCCIN rail draws 171W power, which is quite high I think. It would be better to compare this value with the one reported under the CPU sensor. But that's probably not possible, since you can't run more tests...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> IMO, 10.9V for the +12V rail is a bit lower, but I'm not enough skilled in overclocking, so I suggest to ask other OCers about their opinion.
> Also, if you look at the power usage (POUT), the CPU VCCIN rail draws 171W power, which is quite high I think. It would be better to compare this value with the one reported under the CPU sensor. But that's probably not possible, since you can't run more tests...


Thank you, Martin.

IF this "VR VIN (ATX +12V)" shows the real-time +12V value under load then 10.9V is definitely very low for the 12V input!
- So, that other +12V value above, what is that?

When it comes to those 171W I do not know what to say, I do not have sufficient experience. I can only say that this Prime95 Blend test was run for 10 minutes on stock values, meaning after loading Optimized Defaults, always using the latest official BIOS, of course.

Could it be that my PSU broke, all of the sudden?









Right now I have it for more than half a day on this AMD system and I did not have any issues, at all! Later today I will run Prime95 for an hour or two - I am sure though I will not have any problems.

I could remount my Intel system back and test but, besides the pain in the a... this is, the real problem is that I might not be able to even start the system! Because that was my problem in the first place. It's not that my system crashed or powered off during stress testing. It was randomly restarting on idle and most importantly, after a point it did not power on, ever again. It was just trying to power on but it could not.

Anyway, I still believe it is the motherboard. I'll see what I can do.

Thanks Martin.

IF you have something more to add, anything, I'd appreciate your help!


----------



## Mumak

Only the mainboard designer knows exactly what those +12V rails really measure. Theoretically they should show similar values.
Maybe the +12V measured by VR is the dedicated +12V CPU rail and the ITE measures a different one.
Unfortunately since you can't make more tests, we don't know if that 10.9V was only a very short drop, or was a rather steady value...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Only the mainboard designer knows exactly what those +12V rails really measure. Theoretically they should show similar values.
> Maybe the +12V measured by VR is the dedicated +12V CPU rail and the ITE measures a different one.
> Unfortunately since you can't make more tests, we don't know if that 10.9V was only a very short drop, or was a rather steady value...


Okay, thanks Martin

1) I will write to the Gigabyte support.
2) I am 99% sure that this SOC Force is faulty.
3) Without being fully sure I believe that those 171W are the result of the latest Prime95 using the AVX and FMA3 command sets on Haswell.
4) I am ordering an ASUS Maximus Hero VII today - right after winning the Titan fight with my mother that will follow... (oh boy, I can feel the thunders approaching...)
5) With the refund from one of the these two boards I will get a new PSU, as well, most probably this one.

Thank you.


----------



## Mumak

My theory is that the VCCIN VR +12V is the value of the dedicated CPU voltage rail and the ITE +12V is the other +12V PSU rail.
Indeed, when running heavy AVX load, the CPU can temporary cross it's power limits - this is a 'feature' of many Intel CPUs.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> My theory is that the VCCIN VR +12V is the value of the dedicated CPU voltage rail and the ITE +12V is the other +12V PSU rail.
> Indeed, when running heavy AVX load, the CPU can temporary cross it's power limits - this is a 'feature' of many Intel CPUs.


Oh okay, Martin, I see...

Well, I do not fully understand you, yeah sorry...

For me the most important thing is to understand if this SOC Force is faulty or if my PSU is faulty. Now...taking in consideration that this Corsair PSU has been functioning for approx. 2 years with various motherboards and both Intel and AMD processors, and also taking in consideration that this SOC Force, as well, has worked without problems for almost a week and then it showed these problems, I can safely conclude that there is something wrong with it and not with my PSU -which by the way, is still working flawlessly on my "old" AMD setup, as I am typing, now.

When the HERO VII will arrive tomorrow or the day after the latest -order placed!







- I will be 100% about this!

Thanks!


----------



## Asus11

wanted to ask a trivial question ive had for a while,

when in HWinfo and its showing the % of the Total GPU Power

for example I set my Power target in EVGA precision to 110%

& the HWinfo says max im using is 102%

but when I set 200% Power Target (flashed bios) in evga precision its still using 102% does that mean its using the same as when set to 110% or much higher now?

myself I think its still probably using the same amount as before but just wanted to make sure that if it was using more shouldn't it be more % etc

thanks


----------



## Mumak

Quote:


> Originally Posted by *Asus11*
> 
> wanted to ask a trivial question ive had for a while,
> 
> when in HWinfo and its showing the % of the Total GPU Power
> 
> for example I set my Power target in EVGA precision to 110%
> 
> & the HWinfo says max im using is 102%
> 
> but when I set 200% Power Target (flashed bios) in evga precision its still using 102% does that mean its using the same as when set to 110% or much higher now?
> 
> myself I think its still probably using the same amount as before but just wanted to make sure that if it was using more shouldn't it be more % etc
> 
> thanks


According to NVIDIA, that value is "normalized to respective default TDP limit" which IMO implies that it represents the fraction of original TDP limit (not the raised power value). So I think in your case it's consuming the same power in both cases.


----------



## Im Batman

Martin you beautiful soul.

Thank you for your work.


----------



## LostParticle

Hey Martin,

I'm on a new motherboard now, the ASUS Maximus Hero VII, and I'd like to show you a few things I've observed on the latest beta:



- The CPU and Motherboard temperature readings are shown twice.
- What does Temp2, Temp4, Temp5 mean?

And one last question, please:

Does HWiNFO64 require the " ASUS Probe II Sense Driver" to function properly on this motherboard?
Or this driver has nothing to do with your program?

Thanks.


----------



## Mumak

Yep, there are more sources of the CPU temperature. I believe "CPU" is the diode in socket, whereas CPU (PECI) should reflect the internal DTS temperature.
The other temps (Temp2, etc) are unknown to me, though reported by the sensor. They might be just invalid, or belong to some other undisclosed sources. It might require some experiments (which I'm sure you'll do







) to determine it.
The ASUS driver is not required for HWiNFO.


----------



## LostParticle

Yes, I know the drill








Experimenting + e-mailing the Technical Support and questioning about these sensor values!...

Regarding the CPU and Motherboard values though, if you'll look closely you'll see that they are shown twice. CPU (PECI) is another, different, value I am aware of. The problem is that I do not know yet which of those duplicated CPU and Motherboard values I should keep... When stress testing I'm sure I've observed that they take different values. I will run some test soon and post the results - I will also reorder things to be shown more clearly and I will hide the unnecessary to me values.

Also, yeah...I should have asked you about that ASUS driver before. Now I went on and installed it. It is required for their suite which I have not / will not install. No worries - I'm just testing now - I can always reinstall Windows 7.

Martin, please, one last question - it is important!

- The ASUS boards are pretty popular. According to your experience, does HWiNFO64 require their AI Suite to be installed, to function properly, does it need any "weird" little drivers to function properly, or HWiNFO64 works fine in these boards, just by installing the normal latest chipset drivers, in the right order?

Sorry, just woke up but you know what I mean.

Good day, man.


----------



## Mumak

I believe the most important CPU temperatures are those under the CPU (or the reflected PECI one, which should be the highest among all cores).
No, HWiNFO should not require the AI Suite.


----------



## LostParticle

Okay, so here are my conclusions after testing this a bit.

- I am talking about the ASUS Maximus Hero VII. Clean Windows 7 64bit installation, fully updated, latest drivers installed.
- I have installed the latest AI Suite from the ASUS site. The darn thing required to unblock it, from the zip's properties menu, to get installed!...








- In the latest beta of HWiNFO64 I have hidden some unnecessary values and reordered a few others.

x264 stress test :


Prime95 v28.5, Blend test:


*Conclusions*
- The highlighted "CPU" temperature value under the Nuvoton NCT6791D sensor seems to be the valid one - the other one (just above) can be disabled/hidden.

- Regarding the duplicated Motherboard temp value I could not distinguish any difference so I guess keeping either one should be ok.

- Temp2, Temp4, Temp5 appear to be invalid/arbitrary values.

- VCCIN is the CPU Input Voltage on this motherboard. I do not know what VCOREREFIN is.

*Questions:*
- Martin, if I would like to contact the ASUS Technical Support asking about those Temp2, Temp4, Temp5 values, how should I phrase the question?

- What is VCOREREFIN?

- Where can I find, in HWiNFO64, the "CPU Power" that is shown in AI Suite? In the following example it has the value of 137.8W, during Prime95, Blend. Should I trust the AI Suite on this or HWiNFO64?


Spoiler: Warning: Spoiler!







Thank you









ps: I wrote my conclusions. If anyone disagrees, please correct me.


----------



## Mumak

Temp2 is Reg 0x12 (AUXTIN0), Temp4 is Reg 0x14 (AUXTIN2) and Temp5 is Reg0x15 (AUXTIN3).
Frankly, I don't know what exactly VCOREREFIN means, nor where the AI Suite gets that CPU Power value. Maybe they could explain...


----------



## GrimDoctor

@Mumak are the HWiNFO readings for GPU Clocks usually pretty accurate? What's the margin of error?
I got this result, if it's correct it's fantastic but thought I'd check


----------



## Mumak

Yep, that should be accurate. You can also see that the max GPU Power reached was 115% of TDP.


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> Yep, that should be accurate. You can also see that the max GPU Power reached was 115% of TDP.


I'm starting to get well beyond 1600 now and the sceptics are coming thick and fast. Just wanted to check


----------



## Mumak

Please tell me which exact GPU VRM sensor is on that board. I don't see it on the screenshot, because the string is shortened. I see that some max values for this sensor seem to be invalid (like GPU VRM temperature and VRM Current Out), so I'd like to filter that out. It would be useful if you could attach the HWiNFO Debug FIle with sensor data, so I can check that in detail.


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> Please tell me which exact GPU VRM sensor is on that board. I don't see it on the screenshot, because the string is shortened. I see that some max values for this sensor seem to be invalid (like GPU VRM temperature and VRM Current Out), so I'd like to filter that out. It would be useful if you could attach the HWiNFO Debug FIle with sensor data, so I can check that in detail.


I'm new to OCing GPUs and HWiNFO. Tell me how and I'll send it along.


----------



## Mumak

Before launching HWiNFO, enable the Debug Mode option in Settings - Safety. Then run it, open sensors and let it run for a while. Best would be to wait until you see those erratic values under that GPU VRM sensor. Then close HWiNFO and attach (or send me) the HWiNFO64.DBG file it produced.
After that disable the Debug Mode for normal usage, since it slows down HWiNFO.


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> Before launching HWiNFO, enable the Debug Mode option in Settings - Safety. Then run it, open sensors and let it run for a while. Best would be to wait until you see those erratic values under that GPU VRM sensor. Then close HWiNFO and attach (or send me) the HWiNFO64.DBG file it produced.
> After that disable the Debug Mode for normal usage, since it slows down HWiNFO.


Does it matter that in my display I hide the sensors I don't need to monitor?
Also where will that debug file be?<--ignore found it


----------



## Mumak

Quote:


> Originally Posted by *GrimDoctor*
> 
> Does it matter that in my display I hide the sensors I don't need to monitor?


Yes, it does. If you hide a sensor, it won't be scanned/read-out.


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> Yes, it does. If you hide a sensor, it won't be scanned/read-out.


Ok setting to default now. Will restoring the old INI later restore that?


----------



## Mumak

Quote:


> Originally Posted by *GrimDoctor*
> 
> Ok setting to default now. Will restoring the old INI later restore that?


No, the INI keeps only few portable settings. Sensor-related settings are stored in the registry and can be exported via "Backup User Settings", which is available since the latest Beta build of HWiNFO (v4.49).


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> No, the INI keeps only few portable settings. Sensor-related settings are stored in the registry and can be exported via "Backup User Settings", which is available since the latest Beta build of HWiNFO (v4.49).


I'm not using the beta, I usually stck to non beta versions :/


----------



## Mumak

Quote:


> Originally Posted by *GrimDoctor*
> 
> I'm not using the beta, I usually stck to non beta versions :/


There should be no problem with that Beta, feel free to upgrade.


----------



## LostParticle

Quote:


> Originally Posted by *GrimDoctor*
> 
> I'm not using the beta, I usually stck to non beta versions :/


One question, if I may:

- I see you have the Hero VII. Do you also get a duplicated value for the Motherboard and the CPU temp readings? I mean, do you see these values twice?

The betas of HWiNFO64 are not bad or buggy. I use them all the time.


----------



## GrimDoctor

Quote:


> Originally Posted by *LostParticle*
> 
> One question, if I may:
> 
> - I see you have the Hero VII. Do you also get a duplicated value for the Motherboard and the CPU temp readings? I mean, do you see these values twice?
> 
> The betas of HWiNFO64 are not bad or buggy. I use them all the time.


I do have the Hero VII and I've seen your previous comments. I am not saying BETAs are bad don't get me wrong, I just tend to stick to non BETA versions for anything I use in general.


----------



## GrimDoctor

@Mumak since changing to debug mode, closing and reopening, the software won't run. Reinstalling now with the beta.


----------



## LostParticle

@GrimDoctor

I do the same with everything besides...HWiNFO64! So I understand you completely and I agree with you!









Please, now that you will get the latest beta observe IF you are also getting these duplicated values - just wish to verify this.

Thank you very much


----------



## TRusselo

Quote:


> Originally Posted by *Mumak*
> 
> Well, HWiNFO does have support for Corsair Link protocol, however it's disabled. The main reason for this is, that this protocol is not well designed and when the Corsair software is running, any other application trying to access it will case collisions and both utilities will not report correct values. You would have to disable the Corsair software in order to run other tools. Apparently, Corsair should come up with a new version of their software which will allow other tools to use its protocol sometimes in 2014.


Quote:


> Originally Posted by *Mumak*
> 
> You won't be able to activate it, because it's hard-disabled
> 
> 
> 
> 
> 
> 
> 
> I made such a decision to avoid potential problems users would get when launching it on a system via Corsair Software running.


Quote:


> Originally Posted by *Mumak*
> 
> I'm currently playing with the idea to enable this sensor with a warning to users, that they need to disable Corsair software, but I still believe that this might cause more problems than advantages...


well its almost 2015 and corsair link is not much improved, can we get that checkbox with the warning message now?


----------



## Mumak

You're right - Corsair somehow forgot about this, or they don't consider it as important.
I'm already thinking about enabling this with a warning. Will probably happen in the next beta build.


----------



## TRusselo

thanks. the situation with the sensors and "other programs" conflicting is the same situation as with HWinfo, and the on board EC sensors of my motherboard VS. Asus AI Control Center.
if both HWinfo and Asus AI are running the sensor readings and CPU useage get laggy. and up to 18% usage spikes on an 8 core 8320.


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> thanks. the situation with the sensors and "other programs" conflicting is the same situation as with HWinfo, and the on board EC sensors of my motherboard VS. Asus AI Control Center.
> if both HWinfo and Asus AI are running the sensor readings and CPU useage get laggy. and up to 18% usage spikes on an 8 core 8320.


Yep, it's a similar situation.
Some sensors were simply not designed to be read by multiple applications simultaneously.


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> well its almost 2015 and corsair link is not much improved, can we get that checkbox with the warning message now?


Check the new Beta build 2365.
I have tested it on my H80i's and it should be quite universal, though I'm not sure how it will work with some others...
Report back if there are any issues, etc.
And of course - don't use together with other tools accessing the Corsair Link, otherwise you can get garbage or malfunction.


----------



## TRusselo

Just upgraded... cant find this "option", is it a check box? or just a disabled sensor?

if its just a disabled sensor... then it is not showing anywhere, however. I am not using an H*anything... using the Corsair RM1000 psu, it has basic monitoring, fan speed, and 12V rail Current (Amps drawn). The PSU connects directly to the motherboard USB header via what they call a USB dongle cable. No link commander needed. just plug into mobo and run corsair link.


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> Just upgraded... cant find this "option", is it a check box? or just a disabled sensor?
> 
> if its just a disabled sensor... then it is not showing anywhere, however. I am not using an H*anything... using the Corsair RM1000 psu, it has basic monitoring, fan speed, and 12V rail Current (Amps drawn). The PSU connects directly to the motherboard USB header via what they call a USB dongle cable. No link commander needed. just plug into mobo and run corsair link.


There's no switch used, it should work straight and display a warning if such a device is found. I haven't tested it with PSUs though, that may require a different protocol.
Please attach (or send me) the HWiNFO Debug File with sensor data, so I can check the details...


----------



## TRusselo

Quote:


> Originally Posted by *Mumak*
> 
> There's no switch used, it should work straight and display a warning if such a device is found. I haven't tested it with PSUs though, that may require a different protocol.
> Please attach (or send me) the HWiNFO Debug File with sensor data, so I can check the details...


EDIT: found it....

HWiNFO64debug.zip 63k .zip file


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> EDIT: found it....
> 
> HWiNFO64debug.zip 63k .zip file


Hmm, so it seems your PSU is using a new controller device. I have no information about this one yet, but let's give it a try and assume it's compatible with previous models.
So please try this build: www.hwinfo.com/beta/hw64_449_2367.zip
and let me know the results. In either case, please attach the new HWiNFO Debug File for analysis.
In case it works and you see a Corsair sensor in HWiNFO, please attach a screenshot too.

I have also noticed in the previous Debug File you posted that it looked like a crash had occurred. If that's the case, try to disable the GPU I2C Support.


----------



## TRusselo

nothing new sensor info that i saw.. and no warning message

new debug file!

HWiNFO64.TR.debug2.zip 50k .zip file


----------



## error-id10t

Quote:


> Originally Posted by *LostParticle*
> 
> Prime95 v28.5, Blend test:
> 
> 
> *Conclusions*
> - The highlighted "CPU" temperature value under the Nuvoton NCT6791D sensor seems to be the valid one - the other one (just above) can be disabled/hidden.
> 
> ps: I wrote my conclusions. If anyone disagrees, please correct me.


Bare in mind that AI SUITE that you're using to match the CPU temperature on HWInfo is wrong by ~10 degrees. A generation or two back now they changed that value in AI SUITE to reflect this, they gave a reason but bugger it if I can remember it.

Just look at your core temps, they're ~10 warmer compared to the CPU measurement. Me personally, I just look at CPU (PECI) and/or the actual cores.

add: also, though we have different boards the sensor is the same on our boards (Nuvoton NCT6791D). I see what you see, I ignore them personally as they make no sense.

add2: If you want to see power-use on HWinfo and see if it reflects AI SUITE then you need to enable SVID in BIOS, otherwise it won't reflect in HWInfo.


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> nothing new sensor info that i saw.. and no warning message
> 
> new debug file!
> 
> HWiNFO64.TR.debug2.zip 50k .zip file


I'm afraid, that controller seems not to be compatible with previous generations and doesn't respond. So I cannot support it until I get some information from Corsair








How is that connected to the machine, via some Corsair USB bridge ?


----------



## TRusselo

yeah a usb "dongle" as they call it. plugs directly into a USB header on the mother board on one end, to a small brick, then to the PSU via 4 wires.


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> yeah a usb "dongle" as they call it. plugs directly into a USB header on the mother board on one end, to a small brick, then to the PSU via 4 wires.


Hmm, one more idea.. Please give it one more try using this build: www.hwinfo.com/beta/hw64_449_2368.zip
And attach a new Debug File.


----------



## TRusselo

well that version of HWinfo just makes my computer "black-screen" (3 times). had to reboot.

not sure if this Debug file is complete...

HWiNFO64.TR.debug3.zip 44k .zip file


----------



## Mumak

Quote:


> Originally Posted by *TRusselo*
> 
> well that version of HWinfo just makes my computer "black-screen" (3 times). had to reboot.
> 
> not sure if this Debug file is complete...
> 
> HWiNFO64.TR.debug3.zip 44k .zip file


Thanks. That BSOD should be avoided by disabling the GPU I2C Support option.
But this file tells me that the 2nd idea didn't work either. It seems this device is using a different protocol


----------



## TRusselo

wasnt a BSOD (blue screen) exactly
was a BLACK screen.. happened 3 times each after rebooting and starting program.
even the power and reboot hardware buttons didnt work anymore. had to hit the PSU switch.
computer fully un-responsive. even took an extra 5-10 seconds just to turn on after flipping the PSU switch back on.

HWinfo was also taking a LONG time to load with the past 2 test builds..


----------



## LostParticle

Quote:


> Originally Posted by *error-id10t*
> 
> Bare in mind that AI SUITE that you're using to match the CPU temperature on HWInfo is wrong by ~10 degrees. A generation or two back now they changed that value in AI SUITE to reflect this, they gave a reason but bugger it if I can remember it.
> 
> Just look at your core temps, they're ~10 warmer compared to the CPU measurement. Me personally, I just look at CPU (PECI) and/or the actual cores.
> 
> add: also, though we have different boards the sensor is the same on our boards (Nuvoton NCT6791D). I see what you see, I ignore them personally as they make no sense.
> 
> add2: If you want to see power-use on HWinfo and see if it reflects AI SUITE then you need to enable SVID in BIOS, otherwise it won't reflect in HWInfo.


Thanks

I always use Core Max as an indication of the cpu temperature. On the SOC Force happens the same (as you describe). I will give SVID enabling a try but if it will destabilize my current (and modest) 4.6 o/c it will go. I also use a kill-o-watt to watch power consumption but I do not really care about this. What interests me is for HWiNFO64 to function properly in my system and if it does not, how can I make it work in the best possible way, cooperating with its developer.


----------



## Pikaru

I'm sure this question has been asked before, but for whatever reason, HWiNFO had been causing stuttering in my games after opening GPU Tweak. I've found just closing completely out solves the stuttering.

After reading some of the thread, I found that disabling sensors could solve the problem. I found that the VRM sensors on my GPUs are what causes stuttering. Is there any fix to this other than disabling the VRM sensor? Not using GPU Tweak isn't really an option since I need it to modifying my 2 Strix's voltages without a hard mod. So any help would be appreciated.

Currently on v4.48.


----------



## Mumak

Quote:


> Originally Posted by *Pikaru*
> 
> I'm sure this question has been asked before, but for whatever reason, HWiNFO had been causing stuttering in my games after opening GPU Tweak. I've found just closing completely out solves the stuttering.
> 
> After reading some of the thread, I found that disabling sensors could solve the problem. I found that the VRM sensors on my GPUs are what causes stuttering. Is there any fix to this other than disabling the VRM sensor? Not using GPU Tweak isn't really an option since I need it to modifying my 2 Strix's voltages without a hard mod. So any help would be appreciated.
> 
> Currently on v4.48.


This stuttering might be indeed caused by the GPU VRM sensors, though it's a bit strange that it happens only if both HWiNFO and GPU Tweak are active. Maybe you could solve this by setting the desired voltage and then close GPU Tweak. I'm not aware of another solution, though it's possible that some NVIDIA driver update might fix this (because accessing those sensors is entirely in the hands of NVIDIA drivers).


----------



## Pikaru

Quote:


> Originally Posted by *Mumak*
> 
> This stuttering might be indeed caused by the GPU VRM sensors, though it's a bit strange that it happens only if both HWiNFO and GPU Tweak are active. Maybe you could solve this by setting the desired voltage and then close GPU Tweak. I'm not aware of another solution, though it's possible that some NVIDIA driver update might fix this (because accessing those sensors is entirely in the hands of NVIDIA drivers).


Thanks. I'll just keep testing with the new driver releases. Closing GPU Tweak doesn't work for whatever reason. It's like there's some background app running that I can't find. Closing HWiNFO works instantly.

If I just run HWiNFO, everything works fine. Opening GPU Tweak is what messes everything up. In order to run HWiNFO again without stuttering in games, I'd have to restart and not open GPU Tweak.

I'll just monitor GPU VRM temps through MSI AB. Not completely the end of the world. Would've liked everything to just be all in one.


----------



## Archea47

I love the product Mumak, thanks so much


----------



## error-id10t

With the latest BETA what are these values shown for GPU Video Clock? Different values I see:

1350 MHz
1084.4 MHz
875.3 MHz
405.0 MHz

Also what is the "normalised" TDP difference from standard TDP? Under idle "normalised" is always higher as per below but when push comes to shove, it's the other way around even though it's close (this is FS Extreme example).


----------



## Mumak

The former is probably some Video Engine Clock. Unfortunately that's all information NVIDIA provides about those values


----------



## samoth777

Hello, I have a question about HWInfo64. How dependable or accurate is the gpu vrm temperature? thanks


----------



## Mumak

Quote:


> Originally Posted by *samoth777*
> 
> Hello, I have a question about HWInfo64. How dependable or accurate is the gpu vrm temperature? thanks


That depends on the type of the VRM circuit/sensor, but so far I have seen pretty accurate information from them.


----------



## Archea47

On my 290Xs I get 3 sections of sensors/readings in HWinfo64 for each card. The first two make sense but the third is the same sensor names as the second (though a couple of the readings look flipped)

Is this normal/expected? I can take a screenshot this evening. The only other hardware monitoring tool in use is MSI Afterburner


----------



## Mumak

Quote:


> Originally Posted by *Archea47*
> 
> On my 290Xs I get 3 sections of sensors/readings in HWinfo64 for each card. The first two make sense but the third is the same sensor names as the second (though a couple of the readings look flipped)
> 
> Is this normal/expected? I can take a screenshot this evening. The only other hardware monitoring tool in use is MSI Afterburner


I will check, but need that screenshot.


----------



## Archea47

Quote:


> Originally Posted by *Mumak*
> 
> I will check, but need that screenshot.


Thanks! Let me know what else I can provide or if it's expected

Omega drivers on two Sapphire Tri-X 290Xs


----------



## Mumak

The 1st section per each card is general GPU information, the other two are concerning the VRMs - 2nd is most probably the GPU Core VRM, but I'm not sure what the 3rd is. Usually the 3rd is GPU Memory VRM, but in your case 1.001V is too low for a GPU Memory voltage. Any idea what might be running at such voltage on your GPU?


----------



## madmalkav

I'm somewhat confuse here, can anyone explain me the difference between CPU temperatures reported by CPU and Nuvoton? CPU reports temperatures similar to the Motherboard -I assume that is the socket temperature?- ones on the Nuvoton, not the CPU ones.

Mobo is an Asrock 990FX Extreme3


----------



## Mumak

Quote:


> Originally Posted by *madmalkav*
> 
> I'm somewhat confuse here, can anyone explain me the difference between CPU temperatures reported by CPU and Nuvoton? CPU reports temperatures similar to the Motherboard -I assume that is the socket temperature?- ones on the Nuvoton, not the CPU ones.
> 
> Mobo is an Asrock 990FX Extreme3


First, a clarification is needed regarding the internal/core CPU temperature (the one you see under CPU [#0]: AMD...): for recent AMD CPUs, there's a flaw in the temperature sensor of the CPU. This causes that the values returned are not reliable, especially in the lower range (room/idle temperature). This has been acknowledged by AMD and there's no fix for that.
The values you see under Nuvoton are the external temperatures - "CPU" there means the socket temperature.


----------



## madmalkav

Thanks for the clarification.


----------



## daguardian

Hi Mumak, first off I did not realise the author HWiNFO was present here, I use this program regularly, thankyou for your work, and to support it like you are is great









I have a question about the CPU voltage readings.

What is the difference between the following, namely the Vcore reading in the Nuvoton NCT6776F and the CPUcore reading in the ASUS ROG section -


----------



## Mumak

Quote:


> Originally Posted by *daguardian*
> 
> Hi Mumak, first off I did not realise the author HWiNFO was present here, I use this program regularly, thankyou for your work, and to support it like you are is great
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I have a question about the CPU voltage readings.
> 
> What is the difference between the following, namely the Vcore reading in the Nuvoton NCT6776F and the CPUcore reading in the ASUS ROG section -


I think both of those values should be pretty close and report the same thing.
Though I'm afraid, I can't give you a precise answer, because the exact implementation of those sensors (especially the ROG) is ASUS proprietary, so only they know exactly.
If you see larger differences, I suggest to check with ASUS tool, which of those better matches the ASUS reported Vcore value.


----------



## daguardian

I don't have any of the ASUS software installed at the moment, I thought the usual advice here on OCN was to not use that sort of software.

It was just the figure of 1.528V for the CPU Core in that section that seemed a bit high, and I was trying to find if that is accurate and if it could be causing problems.

Thanks for your quick reply, I will keep troubleshooting here.


----------



## error-id10t

The only value I can find in BIOS - mine isn't ROG so I don't see as much as you - is PCH VLX which is 1.5v. Your DRAM is of course separate from that so it's not that.

Anyhow, that leads to my query.

- PCH Core voltage = 1.066
- PCH VLX voltage = 1.5
- VTTDDR voltage = 0.825

I see these in BIOS but in no other monitoring programs. Is it possible to see if HWInfo can capture this? I also see that VTT = Digital I/O on my board at least?

debug.zip 47k .zip file


----------



## Mumak

If those values are not present in any monitoring tool and neither in the BIOS System Health/monitoring screen, they cannot be monitored. That means you can only set a desired value, but cannot read back the actual one.


----------



## error-id10t

They are (their voltage) shown in the BIOS though, that's what I mean. Because they're there, I'm hoping they could be shown by SW also.


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> They are (their voltage) shown in the BIOS though, that's what I mean. Because they're there, I'm hoping they could be shown by SW also.


But important is whether they are in the monitoring section, or just as an option to set their value.
Also, can you post a screenshot from HWiNFO, especially the ASUS EC sensor ? I believe the PCH voltage should be listed in HWiNFO under that sensor.


----------



## error-id10t

Ah ok well the BIOS monitoring section is completely useless, only covers PSU and fan speeds.

In HWInfo, the ASUS EC area shows PCH which matches PCH Core voltage. Other than that the ASUS EC sensor simply shows DRAM and Cache, so I guess that's it for this board.


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> Ah ok well the BIOS monitoring section is completely useless, only covers PSU and fan speeds.
> 
> In HWInfo, the ASUS EC area shows PCH which matches PCH Core voltage. Other than that the ASUS EC sensor simply shows DRAM and Cache, so I guess that's it for this board.


I see there two additional values hidden (according to the dump you posted earlier), but I don't know to which sensor they belong to.
The exact values (from the dump) are:
0.99351
1.04712
Any idea what that might be?


----------



## error-id10t

Any possibility of creating a beta or similar that I could use on my end, I'll then go into BIOS and change few voltages that I have no idea what they're set to today (for example Analog I/O) and see if these 2 mystery values change.


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> Any possibility of creating a beta or similar that I could use on my end, I'll then go into BIOS and change few voltages that I have no idea what they're set to today (for example Analog I/O) and see if these 2 mystery values change.


Sure, here's such build: www.hwinfo.com/beta/hw64_449_2391.zip
Those additional voltages are called V1 and V5.
Note: If you're not able to download it, try to hit refresh a few times. This is because the entire HWiNFO site is currently being moved to another server.
Please let me know the results, I'm curious too !


----------



## error-id10t

Thanks hmm, not seeing what those could be, changing available volts in BIOS don't change these specifically. Observations however:

Idle V1: 0.981v - 1.123v (average 1.009v)
Idle V5: 1.047v - 1.107v (average 1.056v)

Load V1: 1.3v - 1.325v
Load V5: 1.29v - 1.3v

Wonder if some ROG users have a go and give them a try too we could figure it out.


----------



## Mumak

Hm, what are your CPU voltages (core, ring, SA) in idle/load ? Can you see some relation there ?


----------



## error-id10t

They're related to vcore or some other voltage which raises at the same time.

When I used default settings and just XMP they only went to ~1.18v under load. When I upped vcore to 1.275v which I use for my Multi they rise up to the previous post values again - however, I don't have C states on at the moment so vcore stays at that 1.275v but these drop to the low values.

System Agent is 0.832v and Cache is 1.17v, changing these doesn't change V1 and V5 behaviour.


----------



## jdorje

My h80i appears to be reporting correctly in version 4.50. Yay!


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> My h80i appears to be reporting correctly in version 4.50. Yay!


Thanks for the feedback. Please make sure you don't have the Corsair Link software running, it can cause several issues when using along with HWiNFO (or any other tool reading Corsair devices).


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback. Please make sure you don't have the Corsair Link software running, it can cause several issues when using along with HWiNFO (or any other tool reading Corsair devices).


Yeah, I read that and have not had it running. What are the issues? Will sensors just not report correctly, or will my pump and fans explode?


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Yeah, I read that and have not had it running. What are the issues? Will sensors just not report correctly, or will my pump and fans explode?


When I tested it on my H80i's the values in both tools were going crazy and there were errors reported. So theoretically this can cause a malfunction in the fan control logic as well.
The Corsair Link protocol doesn't allow more applications to access the devices. We have contacted Corsair several times and came with recommendations how this could be fixed, but they haven't done so yet. They promised to bring a new version of their software a year ago (which should solve this too), but that didn't happen yet.


----------



## madmalkav

Sorry for the offtopic, but I have a little idea of trying in my free time to make an atmega board to read temperature and water flow sensor for my water cooling loop. Is there any standard format documented of how I must output that data to PC so it can be recognized by HWInfo and similar software?


----------



## LostParticle

@Mumak

Hello again, Martin!









Yesterday I got my new motherboard, the ASRock Z97 OC Formula. After performing a clean Windows 7 64bit installation on an unallocated SSD, I've downloaded and installed the latest version of HWiNFO64. To my great surprise I've noticed that many things are out of order...

Here are two screenshots of the system running on Optimized Defaults using RAM XMP profile_1 :


Spoiler: Warning: Spoiler!








What can be seen:

1) The motherboard provides four (4) VCore readings but only one, VCore, appears in HWiNFO64, and even this one is giving a false reading.
2) Why is the +12V reading of my Corsair AX 760 PSU showing approx. 22V?
3) On the second screenshot we see eight (8) temperature sensors which exist on this motherboard and are shown in Formula Drive. Why aren't they showing in HWiNFO64?
4) The Vccin reading, which represents the CPU Input Voltage, is showning wrong in HWiNFO64

Perhaps there are other issues as well that I have not noticed yet.

Can you please correct any of these issues, Martin?

Thank you very much!


----------



## Mumak

Quote:


> Originally Posted by *madmalkav*
> 
> Sorry for the offtopic, but I have a little idea of trying in my free time to make an atmega board to read temperature and water flow sensor for my water cooling loop. Is there any standard format documented of how I must output that data to PC so it can be recognized by HWInfo and similar software?


I'm afraid, there's no universal method how to report such values to the system (and monitoring applications). There are many different interfaces and methods how sensor values are reported.
You might try to emulate certain SMBus or ISA devices, or implement an USB HID interface. But I think that's quite tricky and would require more effort.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Hello again, Martin!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yesterday I got my new motherboard, the ASRock Z97 OC Formula. After performing a clean Windows 7 64bit installation on an unallocated SSD, I've downloaded and installed the latest version of HWiNFO64. To my great surprise I've noticed that many things are out of order...
> 
> Here are two screenshots of the system running on Optimized Defaults using RAM XMP profile_1 :
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 
> What can be seen:
> 
> 1) The motherboard provides four (4) VCore readings but only one, VCore, appears in HWiNFO64, and even this one is giving a false reading.
> 2) Why is the +12V reading of my Corsair AX 760 PSU showing approx. 22V?
> 3) On the second screenshot we see eight (8) temperature sensors which exist on this motherboard and are shown in Formula Drive. Why aren't they showing in HWiNFO64?
> 4) The Vccin reading, which represents the CPU Input Voltage, is showning wrong in HWiNFO64
> 
> Perhaps there are other issues as well that I have not noticed yet.
> 
> Can you please correct any of these issues, Martin?
> 
> Thank you very much!


Thanks for the report. You're right HWiNFO doesn't yet have proper support of this model, but I'll look into this ASAP.
I'll probably need a little help from you in order to identify all values reported. As first, please attach a screenshot of all Nuvoton sensor found here - your 1st screenshot shows only one and I think there might be 2. Also, please attach the HWiNFO Debug File.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the report. You're right HWiNFO doesn't yet have proper support of this model, but I'll look into this ASAP.
> I'll probably need a little help from you in order to identify all values reported. As first, please attach a screenshot of all Nuvoton sensor found here - your 1st screenshot shows only one and I think there might be 2. Also, please attach the HWiNFO Debug File.


Okay Martin, I'll help you as much as I can because I will surely keep this motherboard. I will not replace this one.

I believe that in the two screenshots I provided, all available (Nuvoton) sensors can be seen. There is only one Nuvoton NCT6791D sensor showing in HWiNFO64. Anyway, here are the screenshots showing the complete interface of HWiNFO64 sensor status:


Spoiler: Warning: Spoiler!









Thank you.

ps: another issue I've just observed is that the CPU Digital IO is reported twice.

I hope this is the file you asked:

HWiNFO64.zip 43k .zip file


----------



## Mumak

That's strange, I'd expect more of those sensors..
Please see here how to create the Debug File: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's strange, I'd expect more of those sensors..
> Please see here how to create the Debug File: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


Yes, thank you, I've edited my post above. Regarding the number of the sensors I don't know what to say.. Perhaps HWiNFO cannot see them? Anyway, I am waiting for your suggestions. After a little while I will install the entire rig inside my chassis - because now I have it on open air- and I will use my other PSU, the EVGA - see rig. While I had it open, I've measured the Formula Drive values with my Digital Multimeter. They are OK. They are almost completely accurate.


----------



## Mumak

Thanks. It seems it will require more changes to HWiNFO, since there's indeed a second Nuvoton that provides more values, but I'll first need to update HWiNFO to recognize it properly.
I'll do that as soon as I can - it's weekend and family requires attention too


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. It seems it will require more changes to HWiNFO, since there's indeed a second Nuvoton that provides more values, but I'll first need to update HWiNFO to recognize it properly.
> I'll do that as soon as I can - it's weekend and family requires attention too


Okay Martin, thank you very much, I will proceed with the installation of my system inside my chassis, where my Aquaero will be connected as well, and then return with screenshots of the complete system, so that you will have the complete picture. Perhaps it's worth mentioning that no other monitoring tool is providing correct readings for this motherboard: I have also tried "Open Hardware Monitor" and "Hardware Monitor x64", all latest versions, and neither works (= reports accurately).

Have a nice weekend with your family - looking forward to the next updated beta.


----------



## Mumak

Please try this build: www.hwinfo.com/beta/hw64_451_2401.zip
and let me know the result. A new Debug File will be helpful to check internally if all is OK.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Please try this build: www.hwinfo.com/beta/hw64_451_2401.zip
> and let me know the result. A new Debug File will be helpful to check internally if all is OK.


Thanks for the fast response!









Unfortunately, few issues remain. Here are the screenshots for the entire HWiNFO sensor status, after installing my system into my chassis. It is shown in my sig-rig. I am using the EVGA PSU.


Spoiler: Warning: Spoiler!










The debug file

HWiNFO64.zip 49k .zip file


From a quick look:

- The +12V seems to be read OK
- VCore3 is repeated twice whereas there's no VCore2
- CPU Digital IO is repeated twice
- I do not know what VIN14, VIN10, VIN13, VIN5 represent

I will check it out further. There seems to be other problems, too. Quite a few values are shown twice, others do not agree with ASRock's software. Please, have a look at ASRock's Formula Drive and compare. Would you like me to take a screenshot from my BIOS, monitor section, so that you will see what values are shown there?

Thank you.


----------



## Mumak

Thanks for the feedback. Now it looks much better, though some items need fixing.
Please try this: www.hwinfo.com/beta/hw64_451_2402.zip
Now I think all values should be in sync with ASRock's tool, though I cannot find a correlation for VTT DDR, PCH 1.05, PCH 1.5 and DRAM (maybe those are not monitored?).
The other VINx values are those for which I cannot find a meaning - they might be not connected at all.

I also see that some Aquaero values will need fixing, but I need some comparison to know what's correct.
All the Fill Level and Flow values must be wrong, I'll filter them out.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback. Now it looks much better, though some items need fixing.
> Please try this: www.hwinfo.com/beta/hw64_451_2402.zip
> Now I think all values should be in sync with ASRock's tool, though I cannot find a correlation for VTT DDR, PCH 1.05, PCH 1.5 and DRAM (maybe those are not monitored?).
> The other VINx values are those for which I cannot find a meaning - they might be not connected at all.
> 
> I also see that some Aquaero values will need fixing, but I need some comparison to know what's correct.
> All the Fill Level and Flow values must be wrong, I'll filter them out.


Thanks for the new beta.









Unfortunately, still things are missing/confusing... Here is a screenshot of Prime95, Blend test, running at stock settings.



Let's focus on those two Nuvoton NCT 6791D sensors. Are there two of them, identical? Is it only one, read twice? As you can see lots of values are repeated... CPU, Motherboard and Auxiliary (?) Temperatures, CPU (PECI)... these, and others, are shown twice ...with different or the same values! Then on the top sensor CPU Digital IO is shown twice with the exact same value. [EDIT: it seems that CPU (PECI) under the second sensor is invalid. It always shows 40C].

When it comes to VTT DDR, PCH 1.05, PCH 1.5 and DRAM values, all these are shown in the HW_Monitor menu of my BIOS, and in ASRock's utility, as well. IF you mean that they are not monitored in real-time, perhaps you're right - I haven't checked it out yet, neither was I able to figure out how to...take a screenshot from my BIOS on this motherboard!...

My Aquaero device controls just four chassis fans in my setup. My AIO is connected and controlled from the motherboard. If you can filter the other wrong values out it would be great. I used to hide them.

Martin, thank you for your patience and the work you put in HWiNFO! Can we please do something to make your awesome tool work efficiently on my motherboard, as well? It is very discouraging and disappointing that such issues exist - and I don't know what (readings and values) to trust anymore...What about those thermal sensors this mobo has, shown in an earlier screenshot?

Anyway...

Thank you.

UPDATE:

I've run Prime95, Blend, again and took some screenshots and the debug file to give as much info as possible:

HWiNFO64.zip 109k .zip file



Spoiler: Warning: Spoiler!


----------



## error-id10t

You can open up the debug file in text or hex editor and see what it picks up, of course I have no idea how to convert those values but it gives you an idea what it's picking up. I'm puzzled as to why you see more than me when we have the same chip: NCT6791D (for example Digital I/O).


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thanks for the new beta.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Unfortunately, still things are missing/confusing... Here is a screenshot of Prime95, Blend test, running at stock settings.
> 
> 
> 
> Let's focus on those two Nuvoton NCT 6791D sensors. Are there two of them, identical? Is it only one, read twice? As you can see lots of values are repeated... CPU, Motherboard and Auxiliary (?) Temperatures, CPU (PECI)... these, and others, are shown twice ...with different or the same values! Then on the top sensor CPU Digital IO is shown twice with the exact same value. [EDIT: it seems that CPU (PECI) under the second sensor is invalid. It always shows 40C].
> 
> When it comes to VTT DDR, PCH 1.05, PCH 1.5 and DRAM values, all these are shown in the HW_Monitor menu of my BIOS, and in ASRock's utility, as well. IF you mean that they are not monitored in real-time, perhaps you're right - I haven't checked it out yet, neither was I able to figure out how to...take a screenshot from my BIOS on this motherboard!...
> 
> My Aquaero device controls just four chassis fans in my setup. My AIO is connected and controlled from the motherboard. If you can filter the other wrong values out it would be great. I used to hide them.
> 
> Martin, thank you for your patience and the work you put in HWiNFO! Can we please do something to make your awesome tool work efficiently on my motherboard, as well? It is very discouraging and disappointing that such issues exist - and I don't know what (readings and values) to trust anymore...What about those thermal sensors this mobo has, shown in an earlier screenshot?
> 
> Anyway...
> 
> Thank you.
> 
> UPDATE:
> 
> I've run Prime95, Blend, again and took some screenshots and the debug file to give as much info as possible:
> 
> HWiNFO64.zip 109k .zip file
> 
> 
> 
> Spoiler: Warning: Spoiler!


Those Nuvoton sensors are each different and separate. I believe the T Sensor values you see are from those Nuvoton chips and I'll adjust them in HWiNFO in the next build - I think I can see a correlation between ASRock tool and the outputs.
As for the additional voltages, I can only adjust them if you can see a correlation between some VINx in HWiNFO and ASRock tool.

EDIT: Ah, this is crazy! It seems on this mainboard some voltage sensors are used to measure temperature ! So I have to add special support and conversion.


----------



## LostParticle

Thank you, Martin!!

I will go right now and set the following units to specific fixed values in my BIOS: VTT DDR, PCH 1.05, PCH 1.5 and DRAM values. Then I will post a screenshot here to see what each tool reports.

UPDATE:
Okay, so I've set all the above units manually, in the BIOS. All my changes are shown in ASRock's Utility but they are not shown anywhere in HWiNFO64.

Martin, I know that your point of view is that only real-time monitored values should appear under the Sensor Menu of HWiNFO64 but...but IF you wish, please consider adding the above values, as well







DRAM and VTT DDR[*] and also the PCH voltages are valuable to view at a glance, even IF they are not monitored in real-time. And of course the user who dislikes them can always hide them









Looking forward to your new beta!







Sorry that this one is giving you troubles but it will be great if you will make your tool understand it, as well

Thanks!









[*]: a VTT exists in HWiNFO but it is invalid and always remains static.

UPDATE:

@Mumak

I promised a couple of screenshots from my BIOS, showing everything monitored there. [You get it by connecting a thumb drive and pressing F12]. Here they are:


Spoiler: Warning: Spoiler!








These screenshots show what is monitored and the system is currently at its Optimized Default settings, running under RAM XMP profile_1. Below them are also the Fan Settings but I didn't capture those.

Good Luck with your work, Martin!


----------



## Mumak

OK, so it took a while to unravel additional items... Here's a new build: www.hwinfo.com/beta/hw64_451_2404.zip
I have:
- Updated some temperature and fixed some voltage values
- Added T Sensor temperatures. But 3,4,6 and 8 are in fact voltage inputs used to measure temperature and the conversion is rather weird. It took me a while to find the best formula. So I'm not sure about the accuracy of these values. Also I think that these temperatures reported by the ASRock tool might not be precise in some cases.
- Added PCH +1.5V and PCH +1.05V, but I'm not sure if these are correct
- Some VINs will disappear now, since those are in fact voltages as mentioned above
- What I was unable to determine (based on the values reported by BIOS which I believe are those which can be monitored) is the DRAM voltage







Maybe ASRock support might help..
- Filtered out some invalid Aquaero values


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, so it took a while to unravel additional items... Here's a new build: www.hwinfo.com/beta/hw64_451_2404.zip
> I have:
> - Updated some temperature and fixed some voltage values
> - Added T Sensor temperatures. But 3,4,6 and 8 are in fact voltage inputs used to measure temperature and the conversion is rather weird. It took me a while to find the best formula. So I'm not sure about the accuracy of these values. Also I think that these temperatures reported by the ASRock tool might not be precise in some cases.
> - Added PCH +1.5V and PCH +1.05V, but I'm not sure if these are correct
> - Some VINs will disappear now, since those are in fact voltages as mentioned above
> - What I was unable to determine (based on the values reported by BIOS which I believe are those which can be monitored) is the DRAM voltage
> 
> 
> 
> 
> 
> 
> 
> Maybe ASRock support might help..
> - Filtered out some invalid Aquaero values


Thanks Martin for all the good work!

Here's a screenshot of the recent build:


Spoiler: Warning: Spoiler!







The debug file:

HWiNFO64.zip 53k .zip file


Besides those invalid temperatures the PCH +1.5V has the value of 1.502V in ASRock's utility. The PCH +1.05V is shown correctly.


----------



## Mumak

Sorry about the invalid temps, this should fix it: www.hwinfo.com/beta/hw64_451_2405.zip
PCH +1.5V: I know, but if you look at the BIOS screenshot, it reports 1.520V, so what if the BIOS reports value measured and ASRock tool the value set? Anyway, I'm not sure about that, it's just my assumption...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Sorry about the invalid temps, this should fix it: www.hwinfo.com/beta/hw64_451_2405.zip
> PCH +1.5V: I know, but if you look at the BIOS screenshot, it reports 1.520V, so what if the BIOS reports value measured and ASRock tool the value set? Anyway, I'm not sure about that, it's just my assumption...


Okay Martin, thanks a lot for this new beta, as well! This one seems to work OK but, of course, I need a couple of days to test it...
When it comes to PCH +1.5V, I have set it in the BIOS to 1.4V and now HWiNFO64 shows 1.408V whereas ASRock's utility shows 1.402V, for this value.
1.408V is also the value shown in the BIOS. For fractions of a second it raises up to 1.424V in the BIOS. In HWiNFO64 it stays fixed at 1.408V.
Anyway, IF you consider it better to leave it as it is, I have no problem.

So, I will test this new build a bit and report back here.

If I'd like to contact ASRock's Technical support regarding the DRAM and VTT DDR voltages, how should I phrase the question? So that these values will appear, too, in HWiNFO64, even if they are just static (and not real-time monitored) ?

Thank you!


----------



## Mumak

I believe that reporting 1.408 when set to 1.4 confirms, that this is the right value and the accuracy is pretty good.

If you contact ASRock support, I'd suggest to first ask how to monitor those values - from which chip (SIO) are they read and from which register.
I'm sorry, but I don't don't have reporting of such static values (settings) in my short-term plan. This is a very complex area and very different across boards.


----------



## LostParticle

@Mumak

When I powered on my PC today and run the latest beta, here is what I get:



Motherboard T-Sensors 3, 4 and 8 have vanished. I have reset the Preferences, even deleted the configuration file and rebooted, still the same, they are gone.

Regarding everything else:

- Today I will perform a few stress tests at stock settings, at 4.6 GHz and at 4.7 GHz, the two O/C profiles I have already created on this board. Unfortunately, my system is inside my chassis now but I will bring it up and I will use my Digital Multimeter to measure every available V value. I do not own a Temperature gun to measure those 8 T-Sensors.

- Yesterday I've run Prime95 a bit on stock, and I observed that T-Sensor 8 was the only one out of line, when compared with ASRock's utility. A couple of other T-Sensors where in disagreement by 1-2C, but T-8 was showing 39C in Formula Drive and 30C in HWiNFO64. Just mentioning this, today I will test this further.

- Since it is so hard to implement the report of those static values (DRAM and VTT voltage), I forget it. I will not e-mail them.

IF it is possible, please tell me why those T-Sensors do not appear any more. I'll be back later with the results from my testing.

Thank you.


----------



## Mumak

Is that screenshot capturing the situation after resetting preferences? You might also try to do "Restore Original Order"..

I have expected a slight difference between those T Sensor values, because I believe that ASRock's utility doesn't properly convert them in some cases. Actually they convert it based on a static table which doesn't have all values listed and doesn't provide proper rounding. What I did was that I translated the conversion into a polynomial function which I think might be more accurate. But anyway the difference for T-Sensor 8 is too high, I'll need more details about its behavior and a new Debug File.

As for the other values I still think it might be possible to monitor DRAM as the BIOS is showing it. But I don't know where to read it from yet.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Is that screenshot capturing the situation after resetting preferences? You might also try to do "Restore Original Order"..


Thank you! Even though I never reordered anything, after restoring original order those T-Sensors appeared again!

Quote:


> Originally Posted by *Mumak*
> 
> I have expected a slight difference between those T Sensor values, because I believe that ASRock's utility doesn't properly convert them in some cases. Actually they convert it based on a static table which doesn't have all values listed and doesn't provide proper rounding. What I did was that I translated the conversion into a polynomial function which I think might be more accurate. But anyway the difference for T-Sensor 8 is too high, I'll need more details about its behavior and a new Debug File.


Here are two screenshots, one from Idle state and one from 10 minutes Prime95, Blend. This time I reordered just those T-Sensors so that it can be easily compared. Do you want a debug file from idle state or one under stress testing?


Spoiler: Warning: Spoiler!








In any case, I trust your intelligence more than ASRock's!

Quote:


> Originally Posted by *Mumak*
> 
> As for the other values I still think it might be possible to monitor DRAM as the BIOS is showing it. But I don't know where to read it from yet.


Okay, I see!
So, to understand this clearly: - Would you like me to e-mail ASRock, then? I'd love to have these values in HWiNFO! Should I mail them something like this?

- From which chip (SIO) are the DRAM and VTT DDR voltage values read and from which register? Because I want to inform HWiNFO's developer to add them under the Sensor's screen.

Is this correctly expressed?

Thank you, Martin!


----------



## Mumak

Yes, please attach a Debug File from both idle and load and add the values reported for T-Sensor 8 by ASRock (so I know what should be correct). Best if there would be a larger difference between idle and load temperatures if possible.

As for support - yes, please try to contact them. They already replied to your questions in the past with reliable information, so they might again. Your question looks OK, maybe I'd put at the front a question whether it is possible to measure those values at all. And if yes...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, please attach a Debug File from both idle and load and add the values reported for T-Sensor 8 by ASRock (so I know what should be correct). Best if there would be a larger difference between idle and load temperatures if possible.


Okay, done!









Idle, stock, room temperature 19C


Spoiler: Warning: Spoiler!





HWiNFO64-IDLE.zip 52k .zip file




Prime95 Blend, stock, room temperature 19C


Spoiler: Warning: Spoiler!





HWiNFO64-PRIME.zip 108k .zip file




Quote:


> Originally Posted by *Mumak*
> 
> As for support - yes, please try to contact them. They already replied to your questions in the past with reliable information, so they might again. Your question looks OK, maybe I'd put at the front a question whether it is possible to measure those values at all. And if yes...


Okay, I will e-mail them right away. I trust you mean IF those two values can be monitored (measured) in real-time?

After a little while I will open my chassis and start testing the Voltage values with my multimeter.


----------



## Mumak

Thanks, the report is perfect, just one issue - in both situations the reported T-Sensor8 value is same. Is it possible to generate two different reports with a higher difference between the reported value?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks, the report is perfect, just one issue - in both situations the reported T-Sensor8 value is same. Is it possible to generate two different reports with a higher difference between the reported value?


Well, the best I could think to do is to stop all my chassis fans, controlled from my Aquaero, and run Small FFTs. It raised the T-8 sensor value by 1C. I don't know if this is sufficient... Please advise me on what else I could do.


Spoiler: Warning: Spoiler!





HWiNFO64-small.zip 87k .zip file


----------



## Mumak

Thanks. I have adjusted the formula to be more precise. Also when I checked the previous images where ASRock reported 37 C for this value, it should in fact be 36 C, because this is much closer to their own values. It's just that the tool doesn't properly convert it.
Please check again with this: www.hwinfo.com/beta/hw64_451_2406.zip
Note: I have also been updating the general code for recent Nuvoton series, which was not related to your reports. So with this build you might notice some new values appearing. However these might not be used/connected.. So just in case you would wonder about that.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I have adjusted the formula to be more precise. Also when I checked the previous images where ASRock reported 37 C for this value, it should in fact be 36 C, because this is much closer to their own values. It's just that the tool doesn't properly convert it.
> Please check again with this: www.hwinfo.com/beta/hw64_451_2406.zip
> Note: I have also been updating the general code for recent Nuvoton series, which was not related to your reports. So with this build you might notice some new values appearing. However these might not be used/connected.. So just in case you would wonder about that.


Thanks for this beta, too, Martin, it seems that this one works correctly with those T-Sensors!









Spoiler: Warning: Spoiler!



Prime95, Small FFTs, stock, all chassis fans stopped, room temperature 19.3C





There is one important, to me, thing I've observed in this latest beta, though: the +12V value looks fixed, it does not drop at all, whereas in the recent betas it was dropping a bit. Is this normal or can this be, somehow, fixed? It is important to me to check my PSU(s). [EDIT: on idle, right now, it drops! -- I don't know... I think it is supposed to drop a bit on heavy load]

I'm glad we have fixed the thermal sensors. So, now I will test all the voltages using my multimeter. Let's hope they will be accurate, I will report later on, today.

Thank you!










ps: yes, I've also observed those new AUXTIN values, they make no sense to me, I will hide them.


----------



## Mumak

Thanks for the feedback and test.
I haven't done anything to the +12V value, maybe allow more time to see if it changes...
There's just one minor glitch - VIN5 under the 2nd Nuvoton should not be there, I forgot to remove it. Will do that, but I think there's no need for a new Beta because of this - just ignore that.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback and test.
> I haven't done anything to the +12V value, maybe allow more time to see if it changes...
> There's just one minor glitch - VIN5 under the 2nd Nuvoton should not be there, I forgot to remove it. Will do that, but I think there's no need for a new Beta because of this - just ignore that.


Yes, sure Martin! There are a few other "matters", as well, I haven't referred to those yet, cause now I will start dealing with the Voltage (and the rest):
- Two Auxiliary temperature values - I don't know to what they refer to.
- A "Motherboard" temperature value when there are...eight (8) mobo sensors.
- CPU Digital IO is shown twice.
- The VIN5 value you've mentioned.
- 3VSB reported twice.
- AVCC reported twice.
- VIN9...no idea what that might be.

Thank you very much again - back in a couple of hours to report about the Voltages.


----------



## Mumak

Most of the values you mention are sort of generic values - you might remove or ignore them if you like...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Most of the values you mention are sort of generic values - you might remove or ignore them if you like...


Thank you, Martin!

I've done a few tests and (almost) everything seems to work fine!









The voltage values between Formula Drive and the latest beta of HWiNFO64 are in agreement. Here's a screenshot of both while running the x264 test, under my 4.6 GHz profile, on this motherboard:


Spoiler: Warning: Spoiler!







I've reordered a few values and I will also rename some, according to my preferences.

One glitch I have observed, in this profile, is that on idle the VCore takes the weird value of... 4.080V!


Spoiler: Warning: Spoiler!







I've observed this on VCore0 and Vcore1 readings, so far. Perhaps it's happening to all of these VCore values. Since it appears on Formula Drive as well, I think it is a sensor problem and not of HWiNFO.

I've also measured the voltages with my digital multimeter, last night. I run Prime95, Blend, at stock and at 4.6 GHz. Vcore and CPU Input Voltage are spot on. PCH +1.5V was reading at 1.518V. The rest of the readings were showing a bit lower on the multimeter. For example, CPU cache was 1.187V on the meter whereas it was showing a fixed 1.192V in both monitoring tools. System Agent (SA) was 1.207V on the meter whereas it was showing a steady 1.216V in both monitoring tools. I suppose this is expected though. (?)

Well, I'm glad that everything works great (or as good as it can work)!









I will e-mail ASRock technical support regarding DRAM and VTT voltages.

Once again, thank you very much for all your support and contribution!


----------



## Mumak

Thanks for the report!
Yes, I do believe that those 4.08V values are invalid readouts from the SIO. I'll filter them out and plan to release a new public Beta build in a few minutes...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the report!
> Yes, I do believe that those 4.08V values are invalid readouts from the SIO. I'll filter them out and plan to release a new public Beta build in a few minutes...


Thanks Martin! I've installed it and it seems to work great! I will test further, later today!

May I ask your opinion / help on something irrelevant, please?

I am trying to rename those Thermal Sensors... So far, I've managed what's showing in the following screenshot. Can you please suggest me a better naming and/or help me rename those two (2) thermal sensors left?










Spoiler: Warning: Spoiler!







Thank you very much!


----------



## Mumak

Oh, I'm not sure about those exact T-Sensor names - you'll have to look at your board, or manual what's exactly placed where (i.e. T-Sensor-5 is close to some chip which I'm not sure what is that, maybe the Z97 PCH?).
But if you find the correct names, I'll update this in HWiNFO as well !


----------



## Mumak

I looked at some pictures on web.. T-Sensor 5 might be close to the PCH and T-Sensor 8 is close to the RealTek HDA (Purity Sound 2). Others looks OK.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Oh, I'm not sure about those exact T-Sensor names - you'll have to look at your board, or manual what's exactly placed where (i.e. T-Sensor-5 is close to some chip which I'm not sure what is that, maybe the Z97 PCH?).
> But if you find the correct names, I'll update this in HWiNFO as well !


Quote:


> Originally Posted by *Mumak*
> 
> I looked at some pictures on web.. T-Sensor 5 might be close to the PCH and T-Sensor 8 is close to the RealTek HDA (Purity Sound 2). Others looks OK.


Thanks Martin, the truth is I've already looked at my motherboard's layout and the manual before asking but I couldn't figure out an appropriate name to call them. So, I have finally named T-Sensor 5 as "Z97 PCH" and T-Sensor 8 as... "Rear Down Left Side" (lmao) :


Spoiler: Warning: Spoiler!



*Still under construction!*

note: 4.6 GHz, VCore & Cache voltages: 1.250V, Adaptive mode. Prime95, Blend has run a bit, too.





Anyway, the good thing is that the software works!









Finally, I've e-mailed ASRock, asking them about DRAM and VTT voltages, and another question regarding the editing of the layout of their Formula Drive utility (System Info menu). They provide an XML file which you can edit and make changes to the layout -and I've already accomplished that on my previous ASRock Extreme6- but it doesn't work. I edit it in NotePad++, I save the changes and it accepts that, but when I reopen the program the changes are not applied.

Well... I'm glad that we fixed HWiNFO and now it works with this motherboard, too.







The OC Formula is one of the best, if not THE best board for overclocking! Few people in here own it, and I recall one particular guy who's posting splendid results on this other thread in this forum but...he has never-ever used HWiNFO64... Now though everyone can! Because it works!


----------



## Mumak

Thank you







Any new user of HWiNFO is of course welcome


----------



## LostParticle

Hi again, Martin!

I got an e-mail from ASRock, regarding (the question) from which chip (SIO) and from which register are the DRAM and VTT voltage values read. Here is their reply:

For the VTT_DDR chip is control by 3933 OUT1 chip, Address is:0x2A.

I've copied and pasted it exactly as they wrote it.

Does this help?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi again, Martin!
> 
> I got an e-mail from ASRock, regarding (the question) from which chip (SIO) and from which register are the DRAM and VTT voltage values read. Here is their reply:
> 
> For the VTT_DDR chip is control by 3933 OUT1 chip, Address is:0x2A.
> 
> I've copied and pasted it exactly as they wrote it.
> 
> Does this help?


Thanks. Oh yes, that's the NCT3933 and it doesn't allow monitoring (just driving).
But they haven't replied about DRAM voltage. I know that this is set using the same NCT3933, but don't know how to monitor it. Can you please ask them about that DRAM voltage, especially how to monitor it ?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. Oh yes, that's the NCT3933 and it doesn't allow monitoring (just driving).
> But they haven't replied about DRAM voltage. I know that this is set using the same NCT3933, but don't know how to monitor it. Can you please ask them about that DRAM voltage, especially how to monitor it ?


I already asked them, about the DRAM voltage too, but they have not replied. I will ask them again.

So, is it possible for you to add that VTT on the Sensor menu then, and the DRAM voltage as well, when they will hopefully reply to me about that?

Going to e-mail them again now.

Thank you, Martin


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> So, is it possible for you to add that VTT on the Sensor menu then, and the DRAM voltage as well, when they will hopefully reply to me about that?


I'm sorry, but I cannot add it. Supporting settings via this chip would be very specific and difficult to implement. And it's not monitoring.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm sorry, but I cannot add it. Supporting settings via this chip would be very specific and difficult to implement. And it's not monitoring.


Ah, okay, I see... Well, if it is indeed such a big deal to add it, no problem









I've opened the Formula Drive bundle and observed the DRAM and VTT DDR voltages a bit: they do not change at all. Perhaps this means that they are not monitored in real-time.



I also post a screenshot from this program because ASRock has e-mailed me a new .XML file for my motherboard. The problem I was facing was that a few labels, specifically VCore Volt. Additional Offset, was overlapping with the value. I edited the previous XML but it did not apply the change. With the new XML this has been resolved. This issue, by the way, appeared because in my system I use a DPI of 125%. When the Windows Font Size (DPI) is at 100% (default), the interface of Formula Drive appears all good and aligned.

Sorry for the off topic -


----------



## Mumak

Well, I though that the DRAM voltage *might* be possible to monitor since this is the only value left that's reported in the BIOS monitoring screen. I have recognized all others there. So maybe there's a small hope that this might be monitored as well.

I'm not sure if ti's the same ASRock XML file which defines sensor registers, but it might be worth that I have a look at it if you attach. If it's the one and they changed some sensor values I'd like to check that...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure if ti's the same ASRock XML file which defines sensor registers, but it might be worth that I have a look at it if you attach. If it's the one and they changed some sensor values I'd like to check that...


Sure Martin, here it is:

Z97OCFormula.zip 32k .zip file


----------



## Mumak

Nothing new there concerning monitoring..


----------



## LostParticle

@Mumak

Hello again!

I've received an e-mail from ASRock's Technical support. Here is what they wrote about the DRAM voltage on the ASRock Z97 OC Formula:

The DRAM Voltage on H/W Monitor [ _in their bundle software_ ] is read from PWM (Smbus address 0xE0 register 0xDA).
DRAM Voltage = ((Register Value - 1) * 10 + 500)/1000

Does this help a bit and can it be used to monitor VTT voltage, as well?

Thank you, Martin!


----------



## GrimDoctor

@mumak is there anything you can do to improve the voltage reporting in the Asus 980 Strix? Or is it something on the Strix end? Basically it shows lower voltage than what is running and I'm not too keen on soldering permanent connectors to the pcb.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Hello again!
> 
> I've received an e-mail from ASRock's Technical support. Here is what they wrote about the DRAM voltage on the ASRock Z97 OC Formula:
> 
> The DRAM Voltage on H/W Monitor [ _in their bundle software_ ] is read from PWM (Smbus address 0xE0 register 0xDA).
> DRAM Voltage = ((Register Value - 1) * 10 + 500)/1000
> 
> Does this help a bit and can it be used to monitor VTT voltage, as well?
> 
> Thank you, Martin!


Thanks, that's interesting.. it seems there must be some new chip which I don't know/support yet. I'll need to prepare a special build of HWiNFO just to check what might be that, then we will see more...
Are you able to find out which PWM might be used there for the DRAM rail?
EDIT2: According to some reviews on net it seems to use Intersil ISL6379 for VCCIN, but I couldn't find info about the DRAM PWM.


----------



## Mumak

Quote:


> Originally Posted by *GrimDoctor*
> 
> @Mumak is there anything you can do to improve the voltage reporting in the Asus 980 Strix? Or is it something on the Strix end? Basically it shows lower voltage than what is running and I'm not too keen on soldering permanent connectors to the pcb.


Where exactly does it show this value, which sensor is that? Are other tools reporting the same voltage ?


----------



## GrimDoctor

Quote:


> Originally Posted by *Mumak*
> 
> Where exactly does it show this value, which sensor is that? Are other tools reporting the same voltage ?


Pretty much anything that can monitor GPU voltage reports maximum of 1.200v even though the Strix runs at 1.23ish from stock and more with OCing. I would say it's something on the Strix side that's causing this reporting because it's across several programs.

If it's something you might be able to look into and add to HWiNFO let me know what you need, I'm sure many OCers would be interested


----------



## menthuslayer

Maximus VII Formula here, getting an error about the Asus EC sensor when I open HWinfo. Not sure if this is a common error or not.


----------



## Mumak

Quote:


> Originally Posted by *menthuslayer*
> 
> Maximus VII Formula here, getting an error about the Asus EC sensor when I open HWinfo. Not sure if this is a common error or not.


That's not an error, but a warning so you're aware of the issues that might arise when reading values from its EC sensor. It's always displayed if such a sensor is found.


----------



## error-id10t

Quote:


> Originally Posted by *menthuslayer*
> 
> Maximus VII Formula here, getting an error about the Asus EC sensor when I open HWinfo. Not sure if this is a common error or not.


Under the ASUS EC tab, check V1 and V5.. can you tell me if you find anything in your BIOS that might be those values?


----------



## mark_thaddeus

Hey Mumak!

I have a question about HWinfo and host writes to SSDs, does HWinfo by default write to an SSD? What do I need to turn off for HWinfo to stop it from writing to my SSD (If it does indeed write to it)?


----------



## Mumak

Quote:


> Originally Posted by *mark_thaddeus*
> 
> Hey Mumak!
> 
> I have a question about HWinfo and host writes to SSDs, does HWinfo by default write to an SSD? What do I need to turn off for HWinfo to stop it from writing to my SSD (If it does indeed write to it)?


Unless you have sensor logging or Debug Mode active there's no reason for HWiNFO to write to the drive (including SSD).


----------



## mark_thaddeus

Quote:


> Originally Posted by *Mumak*
> 
> Unless you have sensor logging or Debug Mode active there's no reason for HWiNFO to write to the drive (including SSD).


How do I make sure both are turned off?


----------



## Mumak

Debug Mode is enabled in the main settings window (before launching scan) and sensor logging is activated in the sensors window using button on the bottom.


----------



## mark_thaddeus

Quote:


> Originally Posted by *Mumak*
> 
> Debug Mode is enabled in the main settings window (before launching scan) and sensor logging is activated in the sensors window using button on the bottom.


There's a debug mode and a debug write direct (under safety tab in settings - right clicking HWinfo in system tray), I unchecked debug write direct, (debug mode is unchecked) is this ok?


----------



## Mumak

Quote:


> Originally Posted by *mark_thaddeus*
> 
> There's a debug mode and a debug write direct (under safety tab in settings - right clicking HWinfo in system tray), I unchecked debug write direct, (debug mode is unchecked) is this ok?


Yes. When Debug Mode is disabled, then the other option has no effect.


----------



## mark_thaddeus

Quote:


> Originally Posted by *Mumak*
> 
> Yes. When Debug Mode is disabled, then the other option has no effect.


Thank you sir! + rep!


----------



## jdorje

On my gb z97x-sli, the ring voltage is not read by hwinfo. Is there a way to see this value?


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> On my gb z97x-sli, the ring voltage is not read by hwinfo. Is there a way to see this value?


Please post the HWiNFO Debug File for checking this. Is the Vring displayed by the mainboard vendor's monitoring tool ?


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> Please post the HWiNFO Debug File for checking this. Is the Vring displayed by the mainboard vendor's monitoring tool ?


Seems like it is not









Looking at gigabyte system information viewer...everything shown there is also in hwinfo. So I guess that's good.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Seems like it is not
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Looking at gigabyte system information viewer...everything shown there is also in hwinfo. So I guess that's good.


Then I think it's not possible to monitor it. You can see the static (set) value in the main HWiNFO window under CPU/Overclocking.


----------



## LostParticle

Hi again, Martin









I finally got an answer from ASRock in which, among other things, they said that:

The chip on OC-Formula to control DRAM PWM is "INTERSIL ISL6379 CRZ-T".

I thought that I should inform you.

Besides that, the latest beta you have provided to me works great on my Z97 OC Formula! I did not have the chance to measure things with my multimeter yet but it seems to work well









Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi again, Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I finally got an answer from ASRock in which, among other things, they said that:
> 
> The chip on OC-Formula to control DRAM PWM is "INTERSIL ISL6379 CRZ-T".
> 
> I thought that I should inform you.
> 
> Besides that, the latest beta you have provided to me works great on my Z97 OC Formula! I did not have the chance to measure things with my multimeter yet but it seems to work well
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you.


Thanks for the info. It confirms my assumptions. Currently I believe HWiNFO supports that chip (and your mainboard) as best as it can, so this will make it into public beta soon.


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> Then I think it's not possible to monitor it. You can see the static (set) value in the main HWiNFO window under CPU/Overclocking.


Is there a chance harassing gigabyte would change this? Or is this necessarily a hardware limitation? Just curious on this.

I also have two random feature requests:

1) An option to always load into the settings or sensors page, skipping the opening window. That'd save everyone 10 seconds every time they open hwinfo







.

2) An option to color-code a particular line of the sensors page. My idea is you would just right-click on that line and have a "color" submenu to make the background most likely red. This would let you focus on a few values that you're monitoring and always easily find them among the sea of data.

I know these (particulary #2) would be a lot of work, so yeah just ideas. Hwinfo is a great tool; thanks for making it.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Is there a chance harassing gigabyte would change this? Or is this necessarily a hardware limitation? Just curious on this.
> 
> I also have two random feature requests:
> 
> 1) An option to always load into the settings or sensors page, skipping the opening window. That'd save everyone 10 seconds every time they open hwinfo
> 
> 
> 
> 
> 
> 
> 
> .
> 
> 2) An option to color-code a particular line of the sensors page. My idea is you would just right-click on that line and have a "color" submenu to make the background most likely red. This would let you focus on a few values that you're monitoring and always easily find them among the sea of data.
> 
> I know these (particulary #2) would be a lot of work, so yeah just ideas. Hwinfo is a great tool; thanks for making it.


I think that's a hardware limitation - that voltage rail is not bound to a monitoring input.
1. This is possible by disabling the "Show Welcome Screen and Progress" option.
2. That's an interesting idea, I'll put it into my to-do list 








Currently you can change the order of any sensor in the list, so you can put your favorite values to the top of the list.


----------



## jdorje

Um, how do you un-hide a value that you have hidden?

Edit: "restore original order" in the sensor setting seems to do it.


----------



## Mumak

You don't need to completely restore all items, below in that tab is the list of hidden items, which you can restore individually.


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> You don't need to completely restore all items, below in that tab is the list of hidden items, which you can restore individually.


Hm. Restore original order unhides everything but doesn't turn back on monitoring. Unhiding an individaul item always puts it at the bottom, where you have to then still restore the order. I'm not sure how it should work but this is too much work to make any real order modifications worthwhile.


----------



## LostParticle

Thank you for the latest public beta, Martin! It seems to work great - I need a couple of days to test it.

Whenever a new beta is publicly available I "Backup User Settings" on a .REG file on my desktop, then go into the Registry and delete the key relative to HWiNFO64. I run the program again and I check for eventual changes. I then run the .REG file right after closing HWiNFO64, and voilà, I have that latest beta [with the values] reordered and renamed according to my personal preferences.


----------



## jdorje

Okay, I have another feature request, or maybe it's a bug report, or just a suggestion/complaint.

The new versions of hwinfo are nice with the better taskbar support. I'm tempted to use it for 24/7 monitoring (I have been using coretemp for this). There's just one problem: cpu usage. hwinfo, with 2 second poll interval, takes up like 0.3% CPU usage on average. Coretemp, by comparison, takes up 0.0% (I guess it rounds to the nearest .1%).

I assume there are two ways to lower the cpu usage: monitor less data, or use a larger polling interval. What I'm asking for, which might already exist for all I know, is an easy way to swap between monitor-everything and 24-7 profiles. The 24/7 profile would probably just monitor a few data points, on a 10 second polling interval or something, and take up basically no computer resources.

Also, coretemp has a much prettier task bar temperature display.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Okay, I have another feature request, or maybe it's a bug report, or just a suggestion/complaint.
> 
> The new versions of hwinfo are nice with the better taskbar support. I'm tempted to use it for 24/7 monitoring (I have been using coretemp for this). There's just one problem: cpu usage. hwinfo, with 2 second poll interval, takes up like 0.3% CPU usage on average. Coretemp, by comparison, takes up 0.0% (I guess it rounds to the nearest .1%).
> 
> I assume there are two ways to lower the cpu usage: monitor less data, or use a larger polling interval. What I'm asking for, which might already exist for all I know, is an easy way to swap between monitor-everything and 24-7 profiles. The 24/7 profile would probably just monitor a few data points, on a 10 second polling interval or something, and take up basically no computer resources.
> 
> Also, coretemp has a much prettier task bar temperature display.


CoreTemp surely has a lower CPU usage because it monitors only CPU temperatures, so you can't expect a similar usage from a tool like HWiNFO which reports tons of other information. Though I still believe that the CPU usage (and memory footprint) of HWiNFO is very low.
There are certain sensors that might cause a higher CPU usage when information is read from them like the disk sensor, so you might try to disable those if you don't need them.
The feature you request is not available, but with a few tricks you might achieve something similar. Set the sensors as you would like to for one profile and then do a settings backup (into a REG file). Then do the same with the other configuration. You can then switch between your profiles by launching particular settings you have stored.


----------



## Mumak

.. and one more thing BTW.. I'm currently working on a feature that will allow to display multiple sensor tables horizontally, so more information can fit on a single screen







But it's a lot of work and will take some time...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> .. and one more thing BTW.. I'm currently working on a feature that will allow to display multiple sensor tables horizontally, so more information can fit on a single screen
> 
> 
> 
> 
> 
> 
> 
> But it's a lot of work and will take some time...


AWESOME!


----------



## Mumak

Here a quick engineering preview









Still a lot of work ahead...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Here a quick engineering preview
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Still a lot of work ahead...


This looks really nice so far! Will it have the possibility to function in "a single column", as well, like the current version? And only when the user pulls the Sensor Window to become a "multiple column" layout?


----------



## Mumak

Sure, by default all should remain as is now. Only when the user wants to expand the window, additional tables will be added.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Sure, by default all should remain as is now. Only when the user wants to expand the window, additional tables will be added.


Excellent!!

Martin, since you've decided to battle with this, consider please adding the functionality of the SHIFT and the CTRL buttons!








IF it is not a big deal/harshness, allow please the user to select multiple values with the SHIFT and/or the CTRL buttons and move them around or outside the window, like now, to hide them.









Thank you!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Excellent!!
> 
> Martin, since you've decided to battle with this, consider please adding the functionality of the SHIFT and the CTRL buttons!
> 
> 
> 
> 
> 
> 
> 
> 
> IF it is not a big deal/harshness, allow please the user to select multiple values with the SHIFT and/or the CTRL buttons and move them around or outside the window, like now, to hide them.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you!


That's actually more work than it seems. But it's on my list.


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> CoreTemp surely has a lower CPU usage because it monitors only CPU temperatures, so you can't expect a similar usage from a tool like HWiNFO which reports tons of other information. Though I still believe that the CPU usage (and memory footprint) of HWiNFO is very low.
> There are certain sensors that might cause a higher CPU usage when information is read from them like the disk sensor, so you might try to disable those if you don't need them.
> The feature you request is not available, but with a few tricks you might achieve something similar. Set the sensors as you would like to for one profile and then do a settings backup (into a REG file). Then do the same with the other configuration. You can then switch between your profiles by launching particular settings you have stored.


Yeah coretemp is more lightweight because it does less!

I could achieve the same result by disabling a ton of sensors, leaving only CPU temp and maybe a couple others available. I suppose I should do this and see if it actually uses <0.1% CPU before proceeding.

What I can't do (AFAIK) is easily switch between that and monitoring everything. The settings backup with a REG file I guess does it, just...not easily







.


----------



## jdorje

Okay I have two other random things to note.

Right below the h80i section in the sensors window i have 24 blank lines. Below that is one line saying "RTSS", then another blank line. It's a bit odd! [EDIT: Doing "restore original order" removes these, but where did they come from in the first place? Hmmm...it looks like my whole GPU section was missing from there, but not hidden. Very strange.]

Is there a way to report system or program uptime in the sensors window? Ideally there'd just be a time section, with one entry for system uptime (presumably readible from the OS) and one for program uptime (which is trivial). Yeah I know I can see this info elsewhere, but still.


----------



## LostParticle

Hey Martin

I'm on a SOC Force since yesterday, I'm testing this mobo because it has a bent (or missing) pin. So far it works without any issues. I thought you'd like to know how the latest beta looks like on this motherboard











Spoiler: Warning: Spoiler!









Keep up the good work!


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Okay I have two other random things to note.
> 
> Right below the h80i section in the sensors window i have 24 blank lines. Below that is one line saying "RTSS", then another blank line. It's a bit odd! [EDIT: Doing "restore original order" removes these, but where did they come from in the first place? Hmmm...it looks like my whole GPU section was missing from there, but not hidden. Very strange.]
> 
> Is there a way to report system or program uptime in the sensors window? Ideally there'd just be a time section, with one entry for system uptime (presumably readible from the OS) and one for program uptime (which is trivial). Yeah I know I can see this info elsewhere, but still.


Difficult to say what caused that, but I assume the GPU was disabled (ULPS or other power saving). In that mode it's not possible to read values from it.

System uptime in sensors is currently not available. I might add this sometime in future.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin
> 
> I'm on a SOC Force since yesterday, I'm testing this mobo because it has a bent (or missing) pin. So far it works without any issues. I thought you'd like to know how the latest beta looks like on this motherboard
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Keep up the good work!


Thanks for the feedback


----------



## LostParticle

Heeeyy!!
















I just got the latest version!! It seems to work great and I REALLY like it!!









Here is a screenshot from my current setup! (I'm running on this, the last few days, because I'm waiting for my Intel CPU replacement - Intel's Tuning Plan)


Spoiler: Warning: Spoiler!







I really like the new layout and for me personally it is very functional and practical! I did not have the chance to play around with it much yet, but I've observed that the CTRL and SHIFT buttons are working! I (also) observed that the "tables" can be re-sized by the interface's outer frame only, and not by selecting those vertical lines, inside the Sensor's panel. Is there a possibility to enable this feature, as well?

Thank you very much, Martin! This is INDEED a great upgrade!!


----------



## Mumak

Thanks for the feedback, I'm glad that you like it.
There might still be some bugs, because it was a quite huge change (especially internally). You'll see when you start playing with it, but some might be 'features'








Yes, tables can't be resized individually, they keep the same size and are automatically adjusted to window size. I'll reconsider such a change. Also note, that when you have locked order enabled the item count in each table (except the rightmost/last) is automatically adjusted as you change the window/tables size. If you disable it, then you're on your own. I have also added a clarification when you disable locked order, because some users were a bit confused in unlocked mode. The way it works is intentional and I had to consider several different scenarios how to handle different situations for best experience and also to maintain backwards compatibility especially for those who liked the previous modes.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback, I'm glad that you like it.
> There might still be some bugs, because it was a quite huge change (especially internally). You'll see when you start playing with it, but some might be 'features'
> 
> 
> 
> 
> 
> 
> 
> 
> Yes, tables can't be resized individually, they keep the same size and are automatically adjusted to window size. I'll reconsider such a change. Also note, that when you have locked order enabled the item count in each table (except the rightmost/last) is automatically adjusted as you change the window/tables size. If you disable it, then you're on your own. I have also added a clarification when you disable locked order, because some users were a bit confused in unlocked mode. The way it works is intentional and I had to consider several different scenarios how to handle different situations for best experience and also to maintain backwards compatibility especially for those who liked the previous modes.


Thanks, I really like it and I will play with it a bit more, on this old AMD system. I've also discovered item's automatic adjustment according to Sensor window's re-sizing, handy! It would be great if you'd implement individual table's re-sizing, those vertical lines. No big deal, here's an example of what happens though when I try it - the scroll bars appear:



Spoiler: Warning: Spoiler!







In the screenshot above that pop-up can also be seen, when I've shift selected my SSD's read-write activity to move these values in the third table - so to reorder them. I'd like to ask: what do you mean with

"_...thus sensor values can loose their coupling to a particular sensor_" ?

In my example I've moved Read and Write Activity from the bottom of the second table to the top of the third table, so that I will have them all together. Does this mean that after this reordering the Read and Write Activity might not report (monitor) these values correctly? So does it become a risk to (simply) reorder a couple of values?

Thank you!


----------



## Mumak

Resizing - you can avoid that scroll bar by resizing the tabs - just move the table's header entry.

"...thus sensor values can loose their coupling to a particular sensor" means that HWiNFO doesn't care anymore where you place any value, so for example you can move a core temperature beneath the S.M.A.R.T. sensor and then it will look like it's the disk temp







So it's up to the user.. But all values will still report the same values as they do always - you just change their positions.
Maybe the wording in that sentence should be changed so it doesn't look scary


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Resizing - you can avoid that scroll bar by resizing the tabs - just move the table's header entry.


Yes, I have already figured that out but what I really meant was that only by enabling the control of those vertical lines that appear between the tables would give precise re-sizing. In any case, it does not bother me at all









Quote:


> Originally Posted by *Mumak*
> 
> "...thus sensor values can loose their coupling to a particular sensor" means that HWiNFO doesn't care anymore where you place any value, so for example you can move a core temperature beneath the S.M.A.R.T. sensor and then it will look like it's the disk temp
> 
> 
> 
> 
> 
> 
> 
> So it's up to the user.. But all values will still report the same values as they do always - you just change their positions.
> Maybe the wording in that sentence should be changed so it doesn't look scary


Yes, this is a bit delicate and I, as well, think that the wording should be changed. Here is an example where I moved the CPU 0 temperature under the SMART of my SSD:


Spoiler: Warning: Spoiler!







It seems to work fine, nothing has changed, the label and the value is correct. So, I still do not understand what you meant with that phrase in the pop-up window; when values are reordered they still work fine, and I think this was happening in the previous version, too, right?

One other thing I've observed is that when you press the X button (close) on the top right corner, it also saves the current setup. In the previous version you should press the big X button on the bottom right corner (Save and Exit), for that. Now the changes are saved even when the little red X button is used. IF it is not a big deal, can you please change that to the way it was ?







I used to test a few things and then close without saving - now I cannot do that.

Thanks!


----------



## Mumak

Yes, this reordering works the same as before. It's just to make users aware. There were for example situations when a user had a dual-GPU system. He run HWiNFO, changed order of items, but the secondary GPU was still switched off, so HWiNFO could not read nor report any values from it (the 2nd GPU sensor was empty). Then later the 2nd GPU was enabled by the system and HWiNFO recognized new values, but didn't know where to insert them because the items were already in a different order. So in this case they are always put at the bottom of the list. Thus the user was confused - didn't see those values under the 2nd GPU sensor, or found them at the bottom below the network sensor..

Yes, that close handling was changed recently too per request from several other users. There are many used to close windows using the red "X" and were confused why HWiNFO doesn't retain the settings. So now only if you press "Esc" to exit the window it won't save the settings.

So as you can see there come many different request from users and I need to find a solution for all those which are reasonable. It's not easy sometimes...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, this reordering works the same as before. It's just to make users aware. There were for example situations when a user had a dual-GPU system. He run HWiNFO, changed order of items, but the secondary GPU was still switched off, so HWiNFO could not read nor report any values from it (the 2nd GPU sensor was empty). Then later the 2nd GPU was enabled by the system and HWiNFO recognized new values, but didn't know where to insert them because the items were already in a different order. So in this case they are always put at the bottom of the list. Thus the user was confused - didn't see those values under the 2nd GPU sensor, or found them at the bottom below the network sensor..


Ah, I see, okay now I understand!
Well, I have an external HDD in an enclosure and it is not "seen" by HWiNFO64 unless I will close the program and start it again. I do not mind about this though, it is not important to me.

Quote:


> Originally Posted by *Mumak*
> 
> Yes, that close handling was changed recently too per request from several other users. There are many used to close windows using the red "X" and were confused why HWiNFO doesn't retain the settings. So now only if you press "Esc" to exit the window it won't save the settings.


Oh, okay, I didn't know that. I have no problem, thank you for telling me about the "Esc" button









Quote:


> Originally Posted by *Mumak*
> 
> So as you can see there come many different request from users and I need to find a solution for all those which are reasonable. It's not easy sometimes...


Yeah, I can imagine, and actually I have one "small" (?) request, as well : is it easy/possible to implement bold font type for the user to use in some (any) labels-values?

Finally, I would like to ask you to make a couple of tests on the "Reset Preferences" button and on the "Restore Original Order" command: whenever I want to be sure that HWiNFO64 will return at its original state I go to the Registry and delete its key. All other ways some times work, other times -most of the times- do not.

Even if you won't test / fix all these, I personally am very satisfied with your tool!









Thank you.


----------



## Mumak

You mean to be able to specify a bold font for a particular sensor item/row ? I have already a request on my list for a different color, so adding a bold font will be easy once I start that.

I believe that the "Reset Preferences" button should work very well - it does the same thing as when you delete the registry keys, which you can easily check yourself.
I have also tested "Restore Original Order" several times in different conditions and I think it works well too.
If you feel it's not OK, then please provide exact details and how to reproduce the scenario.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> You mean to be able to specify a bold font for a particular sensor item/row ? I have already a request on my list for a different color, so adding a bold font will be easy once I start that.


Yes, that's what I'm referring to, nice idea, looking forward to its implementation then, please consider _Italics_, too
















Quote:


> Originally Posted by *Mumak*
> 
> I believe that the "Reset Preferences" button should work very well - it does the same thing as when you delete the registry keys, which you can easily check yourself.
> I have also tested "Restore Original Order" several times in different conditions and I think it works well too.
> If you feel it's not OK, then please provide exact details and how to reproduce the scenario.


Yeah, I did some tests right now and it seems to work OK. What I was missing was that I ought to uncheck "Remember Preferences" so that "Reset Preferences" to work. Once I did that it worked as expected. When it comes to "Restore Original Order" it does restore it, as I've observed, but with red-X before the labels and no value-monitoring. Here's how it looks like after I've hidden some values, saved and exited, run the program again, and restored original order:


Spoiler: Warning: Spoiler!







I should underline though that perhaps this is how the program normally functions and this is not an issue. I do not mind it anyway, because I do not reorder - restore so much [after I set my preferred order / labeling].


----------



## Mumak

Ah yes, that's probably a 'feature'








When you hide (or remove) some items they are first disabled (the same as Disable Monitoring) and then hidden. So when you restore the order, or make them appear back, they are displayed, but retain their disabled state.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Ah yes, that's probably a 'feature'
> 
> 
> 
> 
> 
> 
> 
> 
> When you hide (or remove) some items they are first disabled (the same as Disable Monitoring) and then hidden. So when you restore the order, or make them appear back, they are displayed, but retain their disabled state.


Yeap, and it makes sense: since one is hiding the values why keep monitoring them? In the latest beta, after those values reappear the user can select them all with shift and/or the ctrl button and Enable Monitoring again!









Okay Martin, thanks a LOT for this latest beta! Personally, I find it splendid! No more hidden values for me! And no more thoughts on placing my second monitor in... portrait mode - just to be able to see everything...

Looking forward to that Bold / Italics / Font color implementation, whenever you will feel like it!

Keep up the good work and thank you very much!
















PS:


Spoiler: Warning: Spoiler!



Regarding what we were discussing a few days ago, about the chip on the ASRock Z97 OC-Formula that controls the DRAM V, so the PWM "INTERSIL ISL6379 *CRZ-T*" have you checked that last part?


----------



## Mumak

That "INTERSIL ISL6379 CRZ-T" doesn't matter, it's still the same and the way how I support it now is all I know so far.


----------



## Mumak

I have rolled out a new build that should fix an issue with migrating from the single list to new multi-list (on some systems with unlocked order migration could cause an empty screen on the first run).


----------



## LostParticle

Works fine for me


----------



## LostParticle

Thanks for the latest beta









Seems to work fine so far











Spoiler: Warning: Spoiler!



Still testing - still under construction. Adaptive Vcore and Cache voltages. CPU cooler fan profile = Silent. Room temp = 20C

After fully scanning the system with MSE.


----------



## LostParticle

Hey Martin

There's one thing I've observed on the latest beta, on my system:

I have an Aquaero fan controller which controls all my chassis fans. I have HWiNFO64 loading on Windows start up. My chassis fans are not shown in HWiNFO64 when it loads. I have to close it and open it again for the fans (controlled by the Aquaero) to show in the sensor's panel. Is there anything that can be done to fix this?

Thank you.


----------



## Mumak

Are those fans monitored by the Nuvoton, or Aquaero sensor? Heh, now when you reordered them it's not easy to determine


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Are those fans monitored by the Nuvoton, or Aquaero sensor? Heh, now when you reordered them it's not easy to determine


Oh, sorry!
These fans are monitored by the Aquaero. When HWiNFO64 is on its original state (default items' order) these fans appear under the Aquaero header.

Hope this helps









ps: I think that if HWiNFO would open one second later these would appear. Sorry if I'm saying something stupid.


----------



## Mumak

So after startup are all other Aquaero sensors show except the fans?
You might try to open Windows Task Scheduler and raise the startup delay for HWiNFO task to see if that helps.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> So after startup are all other Aquaero sensors show except the fans?
> *You might try to open Windows Task Scheduler and raise the startup delay for HWiNFO task to see if that helps.*


Thanks, that did the trick!










Spoiler: Warning: Spoiler!







I even returned the value to 5 seconds, its default setting, and it still works. Actually, this "issue" appears only when I have my external hard drive, in an enclosure, running while Windows is booting. The PC freezes for a couple of seconds then, until the drive is seen/read. I do not mind that because 99.9% of the times I power on this external drive while being in Windows. When it comes to if the other Aquaero values appear, sorry I don't have time to check it right now but I think they do. I might check it out later.

Finally, this external drive of mine is not seen/read from HWiNFO64 if I will power it on while the tool is running. I have to close it and open it again, HWiNFO that is, for the drive's temp to be shown. Minor "glitch" for which I do not mind at all, just mentioning it to you


----------



## LostParticle

Hey again, Martin

I've observed something else, too.

Why is it showing the Vcore2 sensor when I am running on just one core, for testing purposes?


Spoiler: Warning: Spoiler!







I would also like to say that what I've mentioned yesterday, about the fans controlled by my Aquaero, has not been fixed, after all. It's just that it doesn't do it every time so I rushed to assume I have resolved it. The truth is that even when I set it to start after 10 seconds from Windows log on, if my external HDD (in the enclosure) is already running, when HWiNFO64 starts it does not show these fans.

Thank you.


----------



## Mumak

Well, it's still getting some value from the Core2 sensor.. You can hide it if you don't like.

Try to raise the delay even higher than 10 seconds, it's possible that the slow start of the HDD causes other services to be delayed and thus not all Aquaero values are available yet.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, it's still getting some value from the Core2 sensor.. You can hide it if you don't like.


Yes, I know that. I'm just reporting it to you because I believe that you would like to know any "glitch" appearing on the software








Quote:


> Originally Posted by *Mumak*
> 
> Try to raise the delay even higher than 10 seconds, it's possible that the slow start of the HDD causes other services to be delayed and thus not all Aquaero values are available yet.


Nah, it's okay, no problem. I never power on my external HDD before logging into Windows anyway, so I don't really need it. This period I am testing my overclocks on my new chip though and I keep rebooting so the drive stays on. I have my x264 test and I run it from that drive. I'm done today though, so no problem.


----------



## taem

Two questions.

1. I'm sure this has been asked a lot so sorry to ask again, but, any way to know what the various Nuvoton readings are coming from?



I'm not worried about the cpu reading because I'll look to the core sensors for those, but what are Temp2, Temp4, Temp5 and the two Motherboard readings?

2. My board (Maximus VII Gene) has a 2 pin temp sensor header. It shows up in AI Suite III as SENSOR1. How would hwinfo64 report from this header?


----------



## Mumak

Those temperature values come from various inputs, though some of them might not be used and provide invalid values. ASUS doesn't seem to report them, so they are most probably not valid, or contain some unofficial sensors. This is unfortunately almost impossible to determine without access to ASUS design information. If you see there static values, or jumping very high/low then those are not valid.

The SENSOR1 temperature should be reported under the ASUS EC sensor if present.


----------



## LostParticle

Deleted!


----------



## error-id10t

Still following up ASUS regarding those V1 and V5 values.

Curiously, the swings (min/max) with those volts are now much lower as I use a G3258 compared to 4790K


----------



## LostParticle

Martin, please read this post of mine because I am having an issue with the Aquasuite and I am trying to figure it out. Help if you can!









Thank you

UPDATE:
If I install HWiNFO, and not use the portable version, it works. Is this a glitch of the latest beta then?


----------



## Mumak

Could the difference be that it works when you don't change item order in HWiNFO ?
I'm not sure now how well Aquasuite supports SHM from HWiNFO, but it should support SHM v2 interface. I suggest to check with Aquasuite whether they properly support SHM v2.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Could the difference be that it works when you don't change item order in HWiNFO ?
> I'm not sure now how well Aquasuite supports SHM from HWiNFO, but it should support SHM v2 interface. I suggest to check with Aquasuite whether they properly support SHM v2.


Thank you for replying, Martin, since yesterday I have tried "everything" to make this work but I have failed.









- I have completely uninstalled / removed from my system both the Aquasuite and HWiNFO64. This means that I have used Revo Uninstaller Pro 3.1.2 to remove the Aquasuite, then cleaned the Registry with CCleaner and then performed a manual search in the Registry using "Aquasuite" and "HWiNFO" as identifiers and removed all entries found. There was one LEGACY_HWiNFO32 key which was giving me an "Access Denied" but I've managed to delete it after gaining ownership. I've also entered the "Program Data" hidden folder and deleted the respective folder there.

- Then I have installed both and kept them at their original (default) state.

It doesn't work.









The "best" thing I achieved was Aquasuite to see HWiNFO's values for one time and then, after reopening it and/or after rebooting it was stuck at the previous values or returned back to 50C - the default value.

I have also used the installer and I installed the latest stable HWiNFO64 version. This one works but I did this one time only, because I definitely appreciate / need the functionality of the latest beta!!

In addition, I don't know if you've read my recent messages on the OCN club but two people, one with an ASUS board and one with an MSI are using the latest beta and Aquasuite without any issues. _Of course, I do not know how much they have tested it._

I will leave a question on the OCN thread about that SHM v2 interface, but what is that? How should I phrase the question?

Thank you very much!

EDIT:
Okay...this is crazy... Right now, at this very moment, I opened the Aquasuite and it works! I always have HWiNFO64 running and it is customized, of course. I kept my settings saved in a .reg file and I applied it, earlier. Right now I've opened it and it works! The Software Temperature Sensors I have set, function! I honestly don't know what to say...

Also, here is a screenshot after opening the Aquasuite! Observe all the obsolete new values that have appeared!!


Spoiler: Warning: Spoiler!







And now that I have re-opened the Aquasuite, once again it does not work. And all those "crazy" values appeared in HWiNFO64 again.


----------



## Mumak

Well, that looks like an issue with Aquasuite, since there are many other plugins (HWiNFOMonitor, Rainmeter, etc) used by many users and they have no issues. They all access HWiNFO sensor data using SHM (Shared Memory Interface). Version 2 (v2) of this interface is required to be supported. So I suggest to contact Aquaero to discuss your problems. If they need more information about SHM v2, they can contact me anytime.

EDIT: Hm, now when looking at those crazy values.. Is the problem only when they appear in HWiNFO ? They should not be there definitively. Maybe it's a conflict between HWiNFO and Aquasuite (or any other tool reading Aquaero values) ? Can you try to run HWiNFO without Aquasuite to see if that might be the case ? Not sure whether the problem in Aquasuite can be linked to those invalid values read by HWiNFO, but that's also possible. Maybe there are 2 problems:
1. Appearing of those invalid value in HWiNFO. A conflict maybe ?
2. Aquasuite cannot properly read values from HWiNFO. If this happens only when those invalids are read, then it might be because Aquasuite doesn't properly handle SHM v2.


----------



## LostParticle

Okay Martin, thank you. I will quote both of your today's posts here and place them on the "OCN Aquaero Owners Club" thread, asking a solution from the representative.

Quote:


> Originally Posted by *Mumak*
> 
> EDIT: Hm, now when looking at those crazy values.. Is the problem only when they appear in HWiNFO ? They should not be there definitively. Maybe it's a conflict between HWiNFO and Aquasuite (or any other tool reading Aquaero values) ? Can you try to run HWiNFO without Aquasuite to see if that might be the case ? Not sure whether the problem in Aquasuite can be linked to those invalid values read by HWiNFO, but that's also possible. Maybe there are 2 problems:
> 1. Appearing of those invalid value in HWiNFO. A conflict maybe ?
> 2. Aquasuite cannot properly read values from HWiNFO. If this happens only when those invalids are read, then it might be because Aquasuite doesn't properly handle SHM v2.


- No, the problem appears all the time. I mean that the "Software Temperature sensors" in Aquasuite do not work as expected, independently from if I use the latest beta or the latest stable (installed) version. I have tried it earlier today.

- When I run HWiNFO64 v4.51-2444 with the Aquasuite closed (not running) everything works perfect: no obsolete "Aquaero" values appear in "HWiFO": this is how it appears inside the Aquasuite









If you'd like me to test further, tell me


----------



## Mumak

Hm, then it seems like a conflict between Aquasuite and HWiNFO. Do those invalid values started to appear since Aquasuite 2015-4 ?
Please attach a HWiNFO Debug File from the situation when they appear. Maybe I'll be able to see something more there.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Hm, then it seems like a conflict between Aquasuite and HWiNFO. Do those invalid values started to appear since Aquasuite 2015-4 ?
> Please attach a HWiNFO Debug File from the situation when they appear. Maybe I'll be able to see something more there.


I had to run both [programs] 3-4 times for the problem to appear again. And yes, I observed this with the Aquasuite 2015-4 *but* I haven't used the Aquasuite for quite a long time so I do not know if it was functioning properly with previous versions. (I suppose you've seen my earlier post where I say that two people, one with an ASUS and one with an MSI motherboard run this with no issue).

Both programs reset at their default - original state:



Spoiler: Warning: Spoiler!







HWiNFO64.zip 58k .zip file


Looking forward to your ideas.

ps: there are more "Aquaero" values continuing below. I didn't take a screenshot.


----------



## Mumak

I'm sorry, but the current debug data don't provide enough information for me. I have made another build for better capturing of what's happening.
Please repeat the previous process with this build: www.hwinfo.com/beta/hw64_451_2446.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm sorry, but the current debug data don't provide enough information for me. I have made another build for better capturing of what's happening.
> Please repeat the previous process with this build: www.hwinfo.com/beta/hw64_451_2446.zip


Okay, here it is



Spoiler: Warning: Spoiler!







HWiNFO64.zip 71k .zip file


----------



## Mumak

Very well







Now I can see it - HWiNFO gets a packet that was probably requested by Aquaero, so it's clearly a conflict.
I'll try to filter this out somehow..


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Very well
> 
> 
> 
> 
> 
> 
> 
> Now I can see it - HWiNFO gets a packet that was probably requested by Aquaero, so it's clearly a conflict.
> I'll try to filter this out somehow..


Okay Martin, thank you, looking forward for the new beta!









Will this resolve the issue -my main issue- of the "Software Temperature sensors" in Aquasuite not working? As you can see in the recent screenshots, even though set, it does not work. I hope it will be resolved.

Thank you


----------



## Mumak

I'm not sure if it will resolve that, since the main problem is probably solely Aquasuite-related.


----------



## Mumak

OK, here the new build: www.hwinfo.com/beta/hw64_451_2447.zip
With this you should no longer get those erratic values.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, here the new build: www.hwinfo.com/beta/hw64_451_2447.zip
> With this you should no longer get those erratic values.


Okay, thank you for this latest beta. I have tested it, I have opened and closed it and also rebooted quite a few times, and indeed when I open the Aquasuite those erratic values do not appear any more.









Unfortunately, the "Software Temperature sensors" problem has not been resolved. I realize this is most probably Aquasuite-related, I describe though to you what happens because perhaps you might suggest an idea:

I have reset the Aquasuite to its factory defaults: it didn't work.
I have stopped the Service and Uninstalled it.
Then I installed the Service again.

It worked after that. For a little while I was able to see HWiNFO's values in the "Software Temperature sensors" panel. I closed the Aquasuite and opened it again. It was still working. Then I closed it and opened it for one more time and the values were stuck... For example, the "Motherboard" value was stuck at 26C. After rebooting it was still the same: stuck values. And after a couple of seconds, as I was watching it, all the values in that panel changed to 50C, the default value they take when no Software sensor is connected.

Do you have any idea what this might be?

I will now copy this post, edit it a bit, and paste it in the "OCN Aquaero Owners Club", for @Shoggy to see it. I will also quote your post #745 and 1st part of post #747.

Thank you.

PS: Oh!! One *important* question!! I have my preferences backed up in a .reg file. Can I apply this file on this latest beta or do I have to customize it from the beginning?


----------



## Mumak

I have no idea what might be causing it, I believe it's an internal Aquasuite issue.

There's no reason for customizing the values from scratch, your past settings will work as before.


----------



## taem

Question about using hwinfo64 with Asus boards.

Does the Asus EC Sensor polling issue apply only when you're running AI Suite alongside hwinfo?

Or is it the case that even if I uninstall AI Suite I will still have the polling issue if I enable EC Sensor for hwinfo?

I want to be able to monitor two of the values from the EC Sensor via hwinfo.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I have no idea what might be causing it, I believe it's an internal Aquasuite issue.
> 
> There's no reason for customizing the values from scratch, your past settings will work as before.


Thank you very much, Martin, works like a charm! (Phew!)

One final screenshot.

EDIT:

For what it's worth, AIDA64 does not work either...


----------



## Mumak

Quote:


> Originally Posted by *taem*
> 
> Question about using hwinfo64 with Asus boards.
> 
> Does the Asus EC Sensor polling issue apply only when you're running AI Suite alongside hwinfo?
> 
> Or is it the case that even if I uninstall AI Suite I will still have the polling issue if I enable EC Sensor for hwinfo?
> 
> I want to be able to monitor two of the values from the EC Sensor via hwinfo.


The behavior seems to be different depending on particular ASUS mainboard model, so I can't give you an exact answer, but basically - if ASUS AI Suite is active the issue can have a bigger impact. If AI Suite is not active, then the impact is lesser, on some systems it might be minimal.


----------



## LostParticle

Hello Martin!








Hope it's going well!

- The latest beta of HWiNFO64 works fine on my system, thank you!

- A guy with the motherboard I'm using this period, the ASRock Z97 OC Formula, has posted a screenshot recently, in which it is shown a sensor called "DIMM Temperature Sensor". Is this something he did or is this a new temperature sensor? I have restored HWiNFO in its original state but this sensor does not appear on my system.

- Remember that issue with my Aquaero 5LT that we discussed couple of days ago? I have managed to resolve it! I just had to connect my keyboard -shown in my sig-rig- in a free USB3.0 port in the rear I/O panel of my motherboard. Now everything works flawlessly, meaning that the Software Temperature Sensors work! It has also worked when I have connected my previous PS/2 keyboard.
For almost a week we've been trying with Aquaero's Technical Support to discover the problem, I even reinstalled Windows! Nothing worked until I connected my keyboard to the USB3.0 port. The only time things worked, while I had my keyboard connected to its regular USB2.0 port, was when I used Open Hardware Monitor. It works since it does not read back any values from the Aquaero, as they said. Perhaps my OC Formula does not like two USB keyboards connected to it - will check it out again, later this year, with my other two mobos.

Thank you


----------



## Mumak

Thanks for the feedback.
"DIMM Temperature Sensor" is a sensor embedded on the memory module, you will need to have a module supporting DIMM-TS to report it. There are not many modules which can do this.
Oh, it's really odd that a keyboard can have such influence







I'm not sure why exactly it was an issue, but it's good to know that it's resolved


----------



## TRusselo

idea/feature request...

In the sensor status window, it would be nice to have a quick filter to show: temps, speeds, power, /all


----------



## LostParticle

^^ Nice idea!

I will leave a request-idea here, too. A "*VCore Max*" value, similar to the already existing "Core Max" temperature value








_Martin, I know I've PM-ed you about this already, just placing it here, as well._


----------



## Mumak

That is already possible - go into settings and the first tab.


----------



## TRusselo

oh.. hey look at that. there they are. and they are live! nice....


----------



## LostParticle

Thank you for the latest version, Martin









It appears to work fine except one thing which is the first time, ever, I see in HWiNFO64. Here's a screenshot - after 5 hours of having it open


Spoiler: Warning: Spoiler!







It is the first time, ever, that I see my "Bus Clock" and "PCIe Clock" changing! When it comes to the Bus Clock (BCLK) I even have it set manually in my BIOS to 100MHz, on this specific OC profile I am currently running. In no other version of HWiNFO64, being it a beta or an official, have I seen those values change, even when I was leaving them on Auto (in the BIOS). Is this a glitch, you think?

Thank you


----------



## Mumak

That's OK - the BCLK is measured by HWiNFO so such a small discrepancy is absolutely OK. PCIe clock is derived from BCLK, so it reflects that change.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's OK - the BCLK is measured by HWiNFO so such a small discrepancy is absolutely OK. PCIe clock is derived from BCLK, so it reflects that change.


Well, okay Martin. Personally, I don't mind. I repeat though: only in this version of HWiNFO64 I have seen this. In all the previous versions, beta or official, I have never seen this matter - and to be honest, I preferred it to stay fixed at 100MHz, as it used to. Something similar is happening with CPU-Z and I've heard lots of people using other versions of CPU-Z or even setting the BCLK manually in their BIOS to avoid this "99.9", for example.

Personally, I don't mind. I wonder how did this appear on this specific version of the software, though...


----------



## Mumak

I don't think it's caused by the latest version. I'm rather surprised that the measurement is so precise. If you don't want to see it fluctuate, disable BCLK Periodic Polling in HWiNFO.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I don't think it's caused by the latest version. I'm rather surprised that the measurement is so precise. If you don't want to see it fluctuate, disable BCLK Periodic Polling in HWiNFO.


Okay, you definitely know better since you are the developer.









All I can reassure of is that it is the first time ever I've seen those two sensors changing from the value of "100.0 MHz". I am not used to this, so yes, it feels kind of awkward but...IF they are more accurate than before, so IF, for example, this max of 100.9 MHz that I see right now for both represents the actual - accurate Max these values have taken, then I will leave it as it is, because among everything else I am interested in accuracy. Thank you for the "Periodic Polling" function, as well, I was not aware of it. I will try it









Martin, I'd like to remind you that "VCore Max" request of mine, something similar to the "Core Max" temperature








Whenever you'll feel like implementing it, I will definitely welcome it!!









Thank you.

ps_1: if you would like a Debug file I could provide it.
ps_2: each time a new version becomes available I delete the Registry key, start it and observe the changes, and finally close it - load my preferences again (the .reg file), start it, close it (save it) and reboot. I don't know if this procedure I follow might have provoked a glitch or something.


----------



## Mumak

I'm sorry, but I don't think I'll implement the Vcore Max value soon. This is a mainboard-specifc value and thus a bit difficult to integrate (internally) into the existing framework.
I'll rather concentrate on custom font type/color for the sensor items.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm sorry, but I don't think I'll implement the Vcore Max value soon. This is a mainboard-specifc value and thus a bit difficult to integrate (internally) into the existing framework.
> I'll rather concentrate on custom font type/color for the sensor items.


How is the VCore Max implementation, motherboard specific? Will it not (can it not) take its value from the already monitored values of VCore # ?

I've also read the pop-up about the periodic polling... Well yeah, but this would mean to read the BCLK value one time and not monitor it... I don't like that. So, do you think that these two values are monitored more accurately now than they were previously ?


----------



## Mumak

It's difficult to explain how internally HWiNFO works, but believe me, it's quite complicated









No, those values are monitored the same way as they were before.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It's difficult to explain how internally HWiNFO works, but believe me, it's quite complicated
> 
> 
> 
> 
> 
> 
> 
> 
> 
> No, those values are monitored the same way as they were before.


Okay Martin, I thought that this "VCore Max" value could be somehow implemented by simply seeking the already monitored maximum values from "Current", "Min" and "Max" of the VCore(s) # and show it, calculating the Average of it on the last column.

Regarding the Bus / PCIe clock(s) unexpected new behavior, I will leave it as it is. I suppose if this is a "glitch" other users will refer to this, too.

Good luck with the custom font type / color


----------



## LostParticle

Hey Martin, just passing by to let you know that the latest beta works fine on my system










Spoiler: Warning: Spoiler!







How is that "custom font type/color" feature going?

Thanks!


----------



## EarlZ

Hi,

Is the Gigabyte Z87 G1 Sniper M5 supported for VRING reading ?


----------



## Mumak

Quote:


> Originally Posted by *EarlZ*
> 
> Hi,
> 
> Is the Gigabyte Z87 G1 Sniper M5 supported for VRING reading ?


Yes, it might be supported. Do you see an IT8790 reported? Please post some screenshots of the sensors screen.


----------



## EarlZ

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *EarlZ*
> 
> Hi,
> 
> Is the Gigabyte Z87 G1 Sniper M5 supported for VRING reading ?
> 
> 
> 
> Yes, it might be supported. Do you see an IT8790 reported? Please post some screenshots of the sensors screen.
Click to expand...

I dont see that sensor to be listed on what I have.


----------



## Mumak

Then I'm afraid, it doesn't seem that the G1.Sniper M5 supports monitoring of VRING, while the G1.Sniper B5 does.
I'll improve monitoring of other sensor values for this board in the next build.


----------



## 331149

Strange that settings are saved in a reg file. Do not like.


----------



## EarlZ

Quote:


> Originally Posted by *Mumak*
> 
> Then I'm afraid, it doesn't seem that the G1.Sniper M5 supports monitoring of VRING, while the G1.Sniper B5 does.
> I'll improve monitoring of other sensor values for this board in the next build.


Awesome cant wait!


----------



## Mumak

Quote:


> Originally Posted by *TheBDK*
> 
> Strange that settings are saved in a reg file. Do not like.


Portable settings are saved in the INI file and others, which are machine-specific, in the registry. Registry is the place for all such settings and all applications use that.


----------



## long99x

I use the 4.50 version, I have two asus r9 290 dc2, hwinfo read my card sensor very slow


----------



## LostParticle

Quote:


> Originally Posted by *long99x*
> 
> I use the 4.50 version, I have two asus r9 290 dc2, hwinfo read my card sensor very slow


Why don't you update to the latest beta and see how this works for you?


----------



## Mumak

Quote:


> Originally Posted by *long99x*
> 
> I use the 4.50 version, I have two asus r9 290 dc2, hwinfo read my card sensor very slow


You mean the detection phase takes too long? Then you might try to disable GPU I2C Support in HWiNFO. If the GPU doesn't have additional sensors (like PWMs) you won't loose any sensors in HWiNFO, while the speed-up will be significant. If there are such sensors, disabling that option will cause to not show them, so you might rather try to exclude particular GPU I2C buses in HWiNFO. Depends on your GPUs..


----------



## long99x

Quote:


> Originally Posted by *LostParticle*
> 
> Why don't you update to the latest beta and see how this works for you?


I will try








Quote:


> Originally Posted by *Mumak*
> 
> You mean the detection phase takes too long? Then you might try to disable GPU I2C Support in HWiNFO. If the GPU doesn't have additional sensors (like PWMs) you won't loose any sensors in HWiNFO, while the speed-up will be significant. If there are such sensors, disabling that option will cause to not show them, so you might rather try to exclude particular GPU I2C buses in HWiNFO. Depends on your GPUs..


I disabled the GPU I2C it's faster but i lose my card vrm temp


----------



## Mumak

Quote:


> Originally Posted by *long99x*
> 
> I disabled the GPU I2C it's faster but i lose my card vrm temp


OK, so your GPU has such a sensor. Try to enable the GPU I2C support back and instead exclude all I2C buses except one (might be 6 or 7 where your GPU VRM resides) so that you notice a speed-up without loosing the GPU VRM sensors.


----------



## mirzet1976

Quote:


> Originally Posted by *long99x*
> 
> I use the 4.50 version, I have two asus r9 290 dc2, hwinfo read my card sensor very slow


Quote:


> Originally Posted by *Mumak*
> 
> You mean the detection phase takes too long? Then you might try to disable GPU I2C Support in HWiNFO. If the GPU doesn't have additional sensors (like PWMs) you won't loose any sensors in HWiNFO, while the speed-up will be significant. If there are such sensors, disabling that option will cause to not show them, so you might rather try to exclude particular GPU I2C buses in HWiNFO. Depends on your GPUs..


For me it's the same R9 290 and R9 290 readings went also quite slow, but with what is proposed Mumak now HWiNFO opens instantly. I've turned off except GPU I2C bus 6th


----------



## long99x

Quote:


> Originally Posted by *Mumak*
> 
> OK, so your GPU has such a sensor. Try to enable the GPU I2C support back and instead exclude all I2C buses except one (might be 6 or 7 where your GPU VRM resides) so that you notice a speed-up without loosing the GPU VRM sensors.


Quote:


> Originally Posted by *mirzet1976*
> 
> For me it's the same R9 290 and R9 290 readings went also quite slow, but with what is proposed Mumak now HWiNFO opens instantly. I've turned off except GPU I2C bus 6th


many thanks, it's faster now


----------



## kc5vdj

I need some help if possible. The chip in question shows up as Temp #6. This is on the Gigabyte GA-Z97X-Gaming G1 WIFI-BK motherboard. The chip is located under the small heatsink that has the label "G1 Gaming" on it.

What are your idle and loaded temperatures, as listed in HWiNFO64, current version?

I have been trying to get someone at Gigabyte to help me out with this issue, yet they claim they don't have to even pay attention to the issue because the temperature was measured by "unsupported third party software". Their dissembling apparently disappeared when I wrote a reply to them to keep the ticket open (The ticket is posted in this post at the end), so maybe it's been escalated... I need some backing on this......, so if you have a WIFI-BK, please post screenshots of your temp 6.

I made the correlation between "Temperature 6" and the PLX PEX chip with my finger. Temperature that high, and no smoke (yet), obviously under a heatsink. Only one heatsink that hot.

Thank you.


----------



## LostParticle

@Mumak

I have a question, too. Which value in the latest HWiNFO64 represents the CPU Total TDP, as monitored/shown in Intel XTU, in the following screenshot?


Spoiler: Warning: Spoiler!







Is it the CPU Package Power in HWiNFO64?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *kc5vdj*
> 
> I need some help if possible. The chip in question shows up as Temp #6. This is on the Gigabyte GA-Z97X-Gaming G1 WIFI-BK motherboard. The chip is located under the small heatsink that has the label "G1 Gaming" on it.
> 
> What are your idle and loaded temperatures, as listed in HWiNFO64, current version?
> 
> I have been trying to get someone at Gigabyte to help me out with this issue, yet they claim they don't have to even pay attention to the issue because the temperature was measured by "unsupported third party software". Their dissembling apparently disappeared when I wrote a reply to them to keep the ticket open (The ticket is posted in this post at the end), so maybe it's been escalated... I need some backing on this......, so if you have a WIFI-BK, please post screenshots of your temp 6.
> 
> I made the correlation between "Temperature 6" and the PLX PEX chip with my finger. Temperature that high, and no smoke (yet), obviously under a heatsink. Only one heatsink that hot.
> 
> Thank you.


Sorry, I can't give you an exact answer, because only GIGABYTE knows for sure. But it's highly possible that the Temp #6 is an invalid value (could be a not connected sensor), which happens quite often on many mainboards.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> I have a question, too. Which value in the latest HWiNFO64 represents the CPU Total TDP, as monitored/shown in Intel XTU, in the following screenshot?
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> Is it the CPU Package Power in HWiNFO64?
> 
> Thank you.


I can't speak for XTU because I don't know how it works internally, but yes, I think it's the "CPU Package Power" in HWiNFO.


----------



## LostParticle

Hey Martin!

Thank you very much for the latest beta, it works fine on my system - I've only had less than an hour to check it out - I'm sure it will work splendid, though!

Here is a screenshot while running Prime95, blend, on Optimized Defaults. I've played with the new features a little, JUST for testing purposes - not planning to leave it this way :


Spoiler: Warning: Spoiler!







As you can see, everything I've set works great!









One thing that I would LOVE to be able to accomplish is the changing of the color of an item to be set separately-independently from the other rules. Here is what I mean. In the following screenshot you can see the rule I've set for "Core Max" :


Spoiler: Warning: Spoiler!







The computer is forced to restart if Core Max >= 94C. I'd love to be able to see it red (color) when above 75C, for example.

Anyway, even if this last thing is not possible/too hard to implement, no worries, the new beta is really nice and it works great on my system!









It also works fine on Windows 10 Technical Preview that I am testing these days, with the only difference being (in comparison to Win 7), that my CPU Cache Minimum drops down to 0.000V, something I've never observed on Windows 7.

Thank you once again, keep up the good work!


----------



## Mumak

Thanks for your feedback.
I see what you mean, I'm thinking about it. Also other features, i.e. it might be nice to come with a set of default colors for some critical values (like throttling, CPU temp close to Tj,max, etc). But I have to think about how to do that so that it's useful as default, but could be reconfigured or disabled for users which don't want it.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for your feedback.
> I see what you mean, I'm thinking about it. Also other features, i.e. it might be nice to come with *a set of default colors for some critical values* (like throttling, CPU temp close to Tj,max, etc). But I have to think about how to do that so that it's useful as default, but could be reconfigured or disabled for users which don't want it.


You are welcome!

Yes, your other ideas sound useful, as well, as long as the user will be still able to return everything to default. For example, I've observed that in this latest beta some "Headings" - like "_Intel Core i7-4790K_" come italicized by default - something I haven't decided yet if it suites me, I'm glad I can always change it, though! Actually, I think I will set mine to *bold* since a "Heading" makes more sense on bold than on Italics.

Kind of like this, for now:


Spoiler: Warning: Spoiler!







Please, also consider implementing the re-sizing of the interior tables - those 2 perpendicular lines in my screenshot, and finally...once again I will refer to the importance of a "VCore Max"...









- Can it not be programmed to just read the values of the already monitored VCore(s) # and calculate the "VCore Max", similarly to the temperature item of "Core Max"?

Thank you.

PS: it would be nice, as well, the user to be able to rename an empty line. In my example, to be able to add an empty line above my fans and name it "System Fans".


----------



## Mumak

Well, you like it bold, I have already reports where others like it italic







So you see that there are many different opinions and I want to satisfy all if possible and reasonable.


----------



## Speedster159

Is this software safe to use to manually controls fans on a Alienware system?


----------



## Mumak

Quote:


> Originally Posted by *Speedster159*
> 
> Is this software safe to use to manually controls fans on a Alienware system?


AFAIK, it is the only software that's able to control fans for Alienware.
There can be some issues on some systems, which in most cases can be fixed by removing the battery. More info about AW fan control here: http://forum.techinferno.com/hwinfo32-64-discussion/65-alienware-fan-control.html


----------



## Faster_is_better

Is there any reason why my 2nd r9 290 wouldn't show all the same sensors as my first card? They are both reference design, but with different BIOS. I'm not sure if there is a setting in HWinfo I need to check to enable it, or if it is just sensor info lacking on the 2nd card for whatever reason.

It seems to be missing a few but the one I'm missing the most is VRM temperatures. It has been this way since installation and through several versions of HWinfo. I'm expecting its more of a fault on the card/BIOS itself than your software.

Thanks for info and the software itself


----------



## Mumak

Quote:


> Originally Posted by *Faster_is_better*
> 
> Is there any reason why my 2nd r9 290 wouldn't show all the same sensors as my first card? They are both reference design, but with different BIOS. I'm not sure if there is a setting in HWinfo I need to check to enable it, or if it is just sensor info lacking on the 2nd card for whatever reason.
> 
> It seems to be missing a few but the one I'm missing the most is VRM temperatures. It has been this way since installation and through several versions of HWinfo. I'm expecting its more of a fault on the card/BIOS itself than your software.
> 
> Thanks for info and the software itself


This could be because your 2nd GPU if not utilized, is switched off by the ULPS feature. In that case it's not possible to read hardware parameters of the GPU (it might cause a system crash). You can try to disable ULPS, or put some load on the 2nd GPU and the values should appear in HWiNFO.


----------



## Faster_is_better

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Faster_is_better*
> 
> Is there any reason why my 2nd r9 290 wouldn't show all the same sensors as my first card? They are both reference design, but with different BIOS. I'm not sure if there is a setting in HWinfo I need to check to enable it, or if it is just sensor info lacking on the 2nd card for whatever reason.
> 
> It seems to be missing a few but the one I'm missing the most is VRM temperatures. It has been this way since installation and through several versions of HWinfo. I'm expecting its more of a fault on the card/BIOS itself than your software.
> 
> Thanks for info and the software itself
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> This could be because your 2nd GPU if not utilized, is switched off by the ULPS feature. In that case it's not possible to read hardware parameters of the GPU (it might cause a system crash). You can try to disable ULPS, or put some load on the 2nd GPU and the values should appear in HWiNFO.
Click to expand...

Good suggestion, at first I didn't think that could effect it but now I have an idea how to test it. I can get like 80% of the sensors that my first card has, but the 2nd card is missing a few is all. I will swap the 2 cards and make the other one Primary and see if it has the sensors, that would at least tell me they are readable at some point and not just altogether missing from the card. I can mess with the ULPS settings as well and see if that makes a difference. Thanks for the idea.


----------



## EarlZ

Hi,

I noticed in Windows 8.1 the Total CPU usage indicator is about 10-15% lower than what the Task manager is showing. I have the update rate set to 1000ms and "normal" on task manager, is this a known issue or are they really not supposed to sync? In win7 they did in +/- 1%


----------



## Mumak

Quote:


> Originally Posted by *EarlZ*
> 
> Hi,
> 
> I noticed in Windows 8.1 the Total CPU usage indicator is about 10-15% lower than what the Task manager is showing. I have the update rate set to 1000ms and "normal" on task manager, is this a known issue or are they really not supposed to sync? In win7 they did in +/- 1%


I haven't seen such issue reported yet. The method used to calculate the CPU usage is same on both systems (Win7 and 8.1).
What's are the exact values you're getting, are you measuring them while the CPU usage is at a stable level for at least a few seconds ?
Can you see the same issue when running a 100% load (Task Manager: 100%, HWiNFO: 90%) ?


----------



## LostParticle

Hello Martin,

I just want to ask if you are planning on / working on giving the user the possibility of adding a new custom Label. For example, to be able to add a new blank line and name it "System's Fans" or anything else he'd desire.

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hello Martin,
> 
> I just want to ask if you are planning on / working on giving the user the possibility of adding a new custom Label. For example, to be able to add a new blank line and name it "System's Fans" or anything else he'd desire.
> 
> Thank you.


No, I don't have such a feature in plan.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, I don't have such a feature in plan.


Too bad because it would be useful. After having added the ability to define custom colors and font style of items in the sensor window and the ability to change sensor item color when an alert is triggered, and after the new "multi-table" format, I was expecting that this simple feature would not be so hard to implement...

I also have an inquiry:

In v4.63 build 2510 it says : _Added reporting of Distance to Tj max_. Is this shown in the Sensor panel? Where can I find and how can I set this?


----------



## EarlZ

Hi,

Im using your CPU Utilization monitor
Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *EarlZ*
> 
> Hi,
> 
> I noticed in Windows 8.1 the Total CPU usage indicator is about 10-15% lower than what the Task manager is showing. I have the update rate set to 1000ms and "normal" on task manager, is this a known issue or are they really not supposed to sync? In win7 they did in +/- 1%
> 
> 
> 
> I haven't seen such issue reported yet. The method used to calculate the CPU usage is same on both systems (Win7 and 8.1).
> What's are the exact values you're getting, are you measuring them while the CPU usage is at a stable level for at least a few seconds ?
> Can you see the same issue when running a 100% load (Task Manager: 100%, HWiNFO: 90%) ?
Click to expand...

Here are the screenshots

Capture.PNG 45k .PNG file


Capture_2.PNG 89k .PNG file


----------



## EarlZ

attached screenshots


----------



## Mumak

Thanks. The actual CPU usage can be different in case the particular core/thread usage is fluctuating and can depend on the time when it's being sampled by applications.
I have tried a Win8.1 system with different (constant) usage levels and I can see a very good corelatiion between HWiNFO and Task Manager.
Can you please try a situation where each thread's usage is constant ?


----------



## LostParticle

Since you're here,

Quote:


> Originally Posted by *LostParticle*
> 
> I also have an inquiry:
> 
> In v4.63 build 2510 it says : _Added reporting of Distance to Tj max_. Is this shown in the Sensor panel? Where can I find and how can I set this?


----------



## EarlZ

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. The actual CPU usage can be different in case the particular core/thread usage is fluctuating and can depend on the time when it's being sampled by applications.
> I have tried a Win8.1 system with different (constant) usage levels and I can see a very good corelatiion between HWiNFO and Task Manager.
> Can you please try a situation where each thread's usage is constant ?


That second screenshot is the most constant thing I can do. Ran X264 benchmark to load the cpu @ 100%.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> In v4.63 build 2510 it says : Added reporting of Distance to Tj max. Is this shown in the Sensor panel? Where can I find and how can I set this?


A Beta version with this feature has not yet been released to public (it's not a part of 2510). I'm planning to do that tomorrow.
The latest non-public Beta is currently here if you can't wait that long







www.hwinfo.com/beta/hw64_463_2511.zip


----------



## Mumak

Quote:


> Originally Posted by *EarlZ*
> 
> That second screenshot is the most constant thing I can do. Ran X264 benchmark to load the cpu @ 100%.


Well, I can still see several fluctuations in those screenshots, so I'm not sure if one can really compare those results.
In my case I used BOINC, but I guess you're not a cruncher so you might have a look at some other tools that can provide a more stable core load.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> A Beta version with this feature has not yet been released to public (it's not a part of 2510). I'm planning to do that tomorrow.
> The latest non-public Beta is currently here if you can't wait that long
> 
> 
> 
> 
> 
> 
> 
> www.hwinfo.com/beta/hw64_463_2511.zip


Thank you, it seems to work well and great idea, by the way!










Spoiler: Warning: Spoiler!







The only "problem" I face is that now I will have to redesign my layout, lol









By the way, Tj MAX of the i7-4790K is considered 100C, and if I'd wish to change this value I can do this from Custom/ Customize values/ Add, am I right? In case of subtraction I'd add a negative value. Correct?

Thank you.


----------



## Mumak

Why would you want to change the Tj,max value used to calculate core temps in HWiNFO? For those CPUs the correct one is burned inside the chip and read out by HWiNFO. Changing this value was meant for older CPUs where this value was not stored inside the CPU and only kind of estimated based on Intel data provided (in some cases it was rather vague).
Anyway, there's an easier way how to accomplish this in HWiNFO: right-click on the Core temperature and choose "Adjust Tj,max".


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Why would you want to change the Tj,max value used to calculate core temps in HWiNFO? *For those CPUs the correct one is burned inside the chip and read out by HWiNFO*. Changing this value was meant for older CPUs where this value was not stored inside the CPU and only kind of estimated based on Intel data provided (in some cases it was rather vague).
> Anyway, there's an easier way how to accomplish this in HWiNFO: *right-click on the Core temperature and choose "Adjust Tj,max"*.


Ah, okay, thank you. I was not aware of this information.

Looking forward for the next public beta then!









PS: one situation when I'd wish to change Tj max is, for example, for testing the "Change Item Color" Alert : I'd bring the Tj, max down a bit and test if this feature works properly on my system / HWiNFO's current build.


----------



## EarlZ

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *EarlZ*
> 
> That second screenshot is the most constant thing I can do. Ran X264 benchmark to load the cpu @ 100%.
> 
> 
> 
> Well, I can still see several fluctuations in those screenshots, so I'm not sure if one can really compare those results.
> In my case I used BOINC, but I guess you're not a cruncher so you might have a look at some other tools that can provide a more stable core load.
Click to expand...

Maybe an option can be added to pull the value from the task manager instead? Rainmeter seems to show me the same values as task manager does.

I used prime to make a 100% consistent stable load and it shows me 100% other apps that dont have a consistent load will show a different value on task manager vs hwinfo but I dont see why we are comparing 100% load since the issue I see is on the variable load.


----------



## Mumak

Quote:


> Originally Posted by *EarlZ*
> 
> Maybe an option can be added to pull the value from the task manager instead? Rainmeter seems to show me the same values as task manager does.
> 
> I used prime to make a 100% consistent stable load and it shows me 100% other apps that dont have a consistent load will show a different value on task manager vs hwinfo but I dont see why we are comparing 100% load since the issue I see is on the variable load.


I don't think it's possible to pull the values from Task Manager.

It's also possible to maintain a <100% constant load by only loading a certain number of CPU threads. But the load has to be constant in order to be able to compare it between various tools.
Another idea might be to reduce the "Scan Interval" in HWiNFO, maybe disabling some sensor items (like SMART, GPU VRs, EC sensors) too.


----------



## EarlZ

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *EarlZ*
> 
> Maybe an option can be added to pull the value from the task manager instead? Rainmeter seems to show me the same values as task manager does.
> 
> I used prime to make a 100% consistent stable load and it shows me 100% other apps that dont have a consistent load will show a different value on task manager vs hwinfo but I dont see why we are comparing 100% load since the issue I see is on the variable load.
> 
> 
> 
> I don't think it's possible to pull the values from Task Manager.
> 
> It's also possible to maintain a <100% constant load by only loading a certain number of CPU threads. But the load has to be constant in order to be able to compare it between various tools.
> Another idea might be to reduce the "Scan Interval" in HWiNFO, maybe disabling some sensor items (like SMART, GPU VRs, EC sensors) too.
Click to expand...

I noticed with Prime95 after removing some cores on the app I can get your app to sync with Task Manger takes about 1-2 refresh cycles. I have never had this issue since Windows 7 but I no longer have a Win7 machine to verify. Either this issue came up when I had 8.1 or maybe along the lines of the newer version. I'll see about disabling other sensor readings.


----------



## LostParticle

@Mumak

Thanks for the latest beta, it works great!

I have a question: is there any way to increase the font size in HWiNFO64? [Is there] Something I could set in the .ini file or in the Registry to make the Sensor Panel text bigger? I'm referring to all the text, Labels, Values, everything.

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Thanks for the latest beta, it works great!
> 
> I have a question: is there any way to increase the font size in HWiNFO64? [Is there] Something I could set in the .ini file or in the Registry to make the Sensor Panel text bigger? I'm referring to all the text, Labels, Values, everything.
> 
> Thank you.


No, there's no such option available.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, there's no such option available.


I understand.

I'm struggling to set the appropriate text size on the latest Windows 10 Technical preview -this is why I asked- but, as it seems, I will not escape setting both my monitors at 125% DPI.
This is how I have it on Windows 7 and it works great. On 10 some menus (Task Scheduler, for example) appear blurry when set like this. I hope M$ will fix this.

Thank you.


----------



## criss100

good
I have a problem with hwinfo64 v4.62-2500
I do not know dada's fault or not
AUXTIN1 minimum 16 and maximum temp of 125 ???
Is it possible? or is a seszor crazy ???


----------



## Mumak

Quote:


> Originally Posted by *criss100*
> 
> good
> I have a problem with hwinfo64 v4.62-2500
> I do not know dada's fault or not
> AUXTIN1 minimum 16 and maximum temp of 125 ???
> Is it possible? or is a seszor crazy ???


That's definitively a not connected sensor and should be ignored.


----------



## LostParticle

Quote:


> Originally Posted by *criss100*
> 
> good
> I have a problem with hwinfo64 v4.62-2500
> I do not know dada's fault or not
> AUXTIN1 minimum 16 and maximum temp of 125 ???
> Is it possible? or is a seszor crazy ???


No, it's just some erratic / arbitrary value which you should hide. And if there are more you should hide those, too.
Finally, remember to always update the program to its latest, even latest beta, build - version.


----------



## DjokovicFan

Is there a reason that "Vcore' sensor is shown under the motherboard tab and not the CPU tab? i thought it was a CPU setting?


----------



## deepor

Quote:


> Originally Posted by *DjokovicFan*
> 
> Is there a reason that "Vcore' sensor is shown under the motherboard tab and not the CPU tab? i thought it was a CPU setting?


Things seem to be grouped by what chip/device the data is coming from. There's a "Super I/O" controller chip on the motherboard that has sensors wired to it. What you see for the "motherboard" section is the data HWINFO managed to get out of that chip. It seems motherboard makers can have all kinds of info data wired to that chip, and they collect whatever they think they might need for control tasks in there.


----------



## Mumak

Quote:


> Originally Posted by *deepor*
> 
> Things seem to be grouped by what chip/device the data is coming from. There's a "Super I/O" controller chip on the motherboard that has sensors wired to it. What you see for the "motherboard" section is the data HWINFO managed to get out of that chip. It seems motherboard makers can have all kinds of info data wired to that chip, and they collect whatever they think they might need for control tasks in there.


Perfect response, thanks


----------



## LostParticle

Hey Martin, what are all these new values in the latest beta monitoring?









Do they have to do with the "monitoring of Performance Limit Reasons (why frequency is limited)" ?

What does this mean ?









Thanks.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, what are all these new values in the latest beta monitoring?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Do they have to do with the "monitoring of Performance Limit Reasons (why frequency is limited)" ?
> 
> What does this mean ?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks.


Yes, those are reasons why the CPU frequency was clipped to a value lower than requested. As you know, modern CPUs use sophisticated methods to squeeze the last bit of performance, while maintaining certain limits (there is a lot of variables entering the power control mechanism). So this information should be useful to diagnose performance issues (i.e. if there was a temperature, power or current limit hit). This was requested by multiple users (including one big company which uses HWiNFO to test their systems).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, those are reasons why the CPU frequency was clipped to a value lower than requested. As you know, modern CPUs use sophisticated methods to squeeze the last bit of performance, while maintaining certain limits (there is a lot of variables entering the power control mechanism). So this information should be useful to diagnose performance issues (i.e. if there was a temperature, power or current limit hit). This was requested by multiple users (including one big company which uses HWiNFO to test their systems).


Okay, so in simple words this means that whenever we see a "Yes" in one of those values should we do...what exactly? Can you please give a couple of examples?








Is there a post, somewhere, or a help file, explaining these new values?

Thanks Martin! Congrats for your awesome work!

PS: Remember that issue I've talked to you about in a PM? The fact that on Windows 10 the first line of the Sensor Panel, where it says "Sensor Current Minimum Maximum Average" is not clearly distinguishable from what follows below? Like it is on Windows 7? Well, yesterday I have clean-installed Windows 10 build 10162 from Microsoft's official ISO and it still persists. It has not been fixed yet. Can you do something about it, please?


----------



## Mumak

I don't think there's a guide that would explain all values. But basically, if you see a thermal reason then it's clear - overheating. Other reasons like reaching power limits depend on particular system design and Power Limits (PL1, 2, 3) set by BIOS - those will most probably depend on TDP and power supply capability. ICCmax is reaching the power limit (i.e. PSU, brick adapter supply capability). If for example a CPU with iGPU on the IA domain reports "Graphics Driver" reason, then it means the IA (CPU cores) were throttled because the GPU reached the limit.
I think more might be explained in the public Intel IA-32 Software Developer's Manual.


----------



## LostParticle

Hey Martin

On the latest Windows 10 TP (build 10162), clean-installed from the MS ISO, I have created two virtual desktops. I have set HWiNFO64, latest beta, to Auto Start on Windows startup, and I have placed it on my second desktop. Each time I reboot though HWiNFO64 pops up on my first desktop (Desktop 1, as Windows 10 call it). How can I make HWiNFO open on my second virtual desktop, (Desktop 2, according to Windows)?

You see, I want to create (at least) two virtual desktops : one will be completely clean to do whatever I wish. The other will display HWiNFO64 on my DELL monitor and the Aquasuite's Overview Page on my HP, my main, monitor. I wish this to be my "Monitoring Desktop". Is this possible, you think?

EDIT: I've just checked with the Aquasuite and the same happens. Its Overview page opens on Desktop 1, as well. I will post on the respective thread, too.

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin
> 
> On the latest Windows 10 TP (build 10162), clean-installed from the MS ISO, I have created two virtual desktops. I have set HWiNFO64, latest beta, to Auto Start on Windows startup, and I have placed it on my second desktop. Each time I reboot though HWiNFO64 pops up on my first desktop (Desktop 1, as Windows 10 call it). How can I make HWiNFO open on my second virtual desktop, (Desktop 2, according to Windows)?
> 
> You see, I want to create (at least) two virtual desktops : one will be completely clean to do whatever I wish. The other will display HWiNFO64 on my DELL monitor and the Aquasuite's Overview Page on my HP, my main, monitor. I wish this to be my "Monitoring Desktop". Is this possible, you think?
> 
> EDIT: I've just checked with the Aquasuite and the same happens. Its Overview page opens on Desktop 1, as well. I will post on the respective thread, too.
> 
> Thank you.


I guess this is another new feature that will require explicit support in applications








Does it at least keep the position within the desktop even though displaying on #1 (i.e. if you put it into the right corner on #2, will it show in the same place, but on #1) ?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I guess this is another new feature that will require explicit support in applications
> 
> 
> 
> 
> 
> 
> 
> 
> Does it at least keep the position within the desktop even though displaying on #1 (i.e. if you put it into the right corner on #2, will it show in the same place, but on #1) ?


Yes, in my system it does remember (keep) the position









I always open HWiNFO64 on my second monitor, on the upper left corner of the screen. So, it always opens there on both virtual Desktop 1 and virtual Desktop 2 - both utilizing my two monitors. And I have just reconfirmed it by the way, by setting it on a different position, on Desktop 1 and then on Desktop 2, signing out and then signing back in : it does remember the position, it just does not remember the virtual Desktop it was set to, so it always pops up on Desktop 1.

If I may :


Spoiler: Warning: Spoiler!



Dear Martin, this feature together with that other feature, the "Change only the text size", for which we've already talked about and has no effect on HWiNFO, I believe it would be wise if you'd start working on them the soonest. You are brilliant, among other things, in that you are NOT responding with the typical ignorance some others respond : "a well known issue which will not get fixed"....





Thank you!


----------



## Mumak

Both those features seem to be new to Win10 and I haven't yet found programming details how to deal with them.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Both those features seem to be new to Win10 and I haven't yet found programming details how to deal with them.


Yes Martin, I understand now









I was not aware of this but from what I have been reading (yesterday) the "TaskView" is currently pretty basic. Perhaps MS will upgrade this feature over the next year or so.

Anyway, IF you could at least develop the other feature, so HWiNFO to be able to increase its text size (at least in the Sensor panel) according to "Change only the text size" it would be a tremendous change for the better for my system! Or at least, I think so! Now I have to use a "global Zoom" of 125% for the text to display at the appropriate size in my monitors but this causes blurry + ugly bold text in many Windows components (ie the Device Manager, the Disk Management, and many-many more).

By "Changing only the text size" to 12 or to 11, though, from its default of 9, it makes all text, or at least what interests me, to appear crisp, crystal clear and at the appropriate size.









I really hope it can be done. Otherwise I will either have to compromise or struggle with a combination of custom DPI and various text size values until reaching a satisfactory result... Not even sure if it can be accomplished...


----------



## Mumak

I know, you have told me several times about that. And I have searched how to handle that, but the only thing I found is:
https://social.msdn.microsoft.com/Forums/en-US/cfdec628-0562-4372-aa3e-dec969bf06bd/what-api-is-used-to-change-the-default-text-size-of-menu-text?forum=windowsgeneraldevelopmentissues
and the MS answer was "it's not possible". Hm...


----------



## LostParticle

Hey Martin









Thanks for the latest main build - _even though I do not fully understand what all these new values do and how to use them._

A new Windows 10 build was released yesterday, build 10240, which is supposed to be very similar to the "final" product. Here is how HWiNFO looks like on Win 7 and on Win 10 :

*Win 7*


*Win 10, build 10240*


Can you do something so that the space between "Sensor Current Minimum Average" and what follows below to become more distinguishable? So, to be clearly visible that these are Headers, like it is (visible) in Win 7?

Thank you.

PS: I do not know if it is me only (who could be helped) but I believe that creating a post in your site or here to explain a bit the usage of all these new sensors (values) added recently, would be much appreciated! Otherwise the users will simply hide them.


----------



## Mumak

I'm not yet sure why that line is missing, but HWiNFO doesn't do anything special there in Windows 10. It does the same on all systems.
Do you see this issue also with other lists in HWiNFO like Sensor Settings, or maybe in other applications that contain lists too?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm not yet sure why that line is missing, but HWiNFO doesn't do anything special there in Windows 10. It does the same on all systems.
> Do you see this issue also with other lists in HWiNFO like Sensor Settings, or maybe in other applications that contain lists too?


Unfortunately Martin, I cannot check this right now because I have clean-installed Win 10 and I wish to keep it without any program installed until the latest build will arrive. As you probably know the latest 10240 can be installed only through Win Update. As soon as I will have it installed I'll check this out though.

I think that it's not a line actually, it looks embossed to me.

Another application using lists is, of course, MS Excel. While I was using MS Excel 2016, on Win 10 TP, I have never observed any line missing.

Hope I've helped. In max 24h I will receive the latest build and I'll check out other areas of HWiNFO, too.


----------



## Mumak

I just did a test on Win10, but I don't see this issue here:


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I just did a test on Win10, but I don't see this issue here:


Oh, I see!
Which build are you using?


----------



## Mumak

10130 currently. It's a bit older, I'm updating now to 10240.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> 10130 currently. It's a bit older, I'm updating now to 10240.


Okay, I am on build 10162 - waiting for 10240 after max 24h via the Win Update.

I've downloaded HWiNFO again and here is how it displays on my system :



So, yes, I see this issue on HWiNFO's lists, as well....


----------



## Mumak

I have just got back a report from the latest Win10 build and it confirms what you see.
But other applications are affected as well including Windows Explorer - just check








So this seems to be a new standard 'look' for lists in Windows 10.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I have just got back a report from the latest Win10 build and it confirms what you see.
> But other applications are affected as well including Windows Explorer - just check
> 
> 
> 
> 
> 
> 
> 
> 
> So this seems to be a new standard 'look' for lists in Windows 10.


Well, I've just checked the _File Explorer_ on my Win 10 installation and...wherever they've decided to place a horizontal line, I do see it. So, I do not understand exactly what you mean with "the new standard look for lists".
On the other hand, I've just now checked HWiNFO's Layout panel - from the Sensor's panel menu- on Win 7, and under the hidden items no distinguishable lines are shown either. So, okay, I'm not expecting them on Win 10, either.

How does it display on the latest build, have you completed your upgrade? Does that first line "Sensor....Current.....Minimum....etc" distinguishes from the rest? Like on build 10130?


----------



## Mumak

I have got a report from a different machine running the latest build and there the line was missing too.

Here's a screenshot of Windows Explorer - the line is missing there too. And other applications that display lists are similar.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I have got a report from a different machine running the latest build and there the line was missing too.
> 
> Here's a screenshot of Windows Explorer - the line is missing there too. And other applications that display lists are similar.


Ah, okay, now I understand what you mean exactly.

I will risk a personal and subjective opinion : what you show on Windows 10 File explorer does not look that bad. To me it looks OK. Modern, I'd say. On HWiNFO64 though it does not look so good... Can you do something about it, please?


----------



## Mumak

Applications using standard Windows controls (like lists) are not responsible for drawing them - this is done by Windows.
So I'm afraid, I don't' think I'm going to do anything about it.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Applications using standard Windows controls (like lists) are not responsible for drawing them - this is done by Windows.
> So I'm afraid, I don't' think I'm going to do anything about it.


I'm not aware, of course, of how HWiNFO is implemented but can you not just give that first line a different color, at least?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I'm not aware, of course, of how HWiNFO is implemented but can you not just give that first line a different color, at least?


What I wanted to say is that I'm not drawing those lines (and several other items in the list like the header, etc). This is done by Windows and if I want to change it, I'd have to draw the entire table myself, which is just too much effort for such a minuscule issue.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> What I wanted to say is that I'm not drawing those lines (and several other items in the list like the header, etc). This is done by Windows and if I want to change it, I'd have to draw the entire table myself, which is just too much effort for such a minuscule issue.


Okay, now that I've heard of those "lists" I understand this matter a bit better. Is it too much effort though to give another, a different, color on that first line? I am just asking simply because I do not know how much it takes to be done.

Thank you.


----------



## jdorje

Recent (maybe just the most recent?) versions of hwinfo have populated my sensors list with 3 copies of the h80i data.

I went into sensor settings->layout and did a "restore original order", but it remained with 3 copies.

A bit strange!


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Recent (maybe just the most recent?) versions of hwinfo have populated my sensors list with 3 copies of the h80i data.
> 
> I went into sensor settings->layout and did a "restore original order", but it remained with 3 copies.
> 
> A bit strange!


I too have an H80i, but I can see it OK. Please attach the HWiNFO Debug File, I'll check that.


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> I too have an H80i, but I can see it OK. Please attach the HWiNFO Debug File, I'll check that.


Thanks for the quick reply. The plot thickens though! I made a bug report post.

http://www.hwinfo.com/forum/Thread-3-copies-of-h80i-and-a-crash


----------



## kc5vdj

A couple of bug reports in the new version.

first off, missing standard sensors (PCH, etc)

second, I can reorder things in the single-column mode, but when switching to double column mode, "Performance limit reasons" returns to the middle of the right pane, instead of further down just before SMART where I moved it.

third.... HALF A GIG AND GROWING AFTER 106 HOURS?!?!?!?!?!


----------



## kc5vdj

Quote:


> Originally Posted by *kc5vdj*
> 
> A couple of bug reports in the new version.
> 
> first off, missing standard sensors (PCH, etc)
> 
> second, I can reorder things in the single-column mode, but when switching to double column mode, "Performance limit reasons" returns to the middle of the right pane, instead of further down just before SMART where I moved it.
> 
> third.... HALF A GIG AND GROWING AFTER 106 HOURS?!?!?!?!?!


okay, i had the "x"'ed out ones actually disabled previously, the new version restored them to the screen, that's fixed.

only the second issue remains. reordering the new fields to where they are all the way at the bottom just won't work in fullscreen mode.

upgrading to 5.02-2575 may have fixed the memory leak.


----------



## Mumak

Quote:


> Originally Posted by *kc5vdj*
> 
> okay, i had the "x"'ed out ones actually disabled previously, the new version restored them to the screen, that's fixed.
> 
> only the second issue remains. reordering the new fields to where they are all the way at the bottom just won't work in fullscreen mode.
> 
> upgrading to 5.02-2575 may have fixed the memory leak.


It looks like you disabled the PCH and few other sensors. Try to right-click and enable them.

Reordering should work the same way in multi-column mode as well. If you have problem, try to click "Restore Original Order".

The fast release of v5.02 was the main reason to fix the memory leak you saw. So with v5.02 it should be back to normal.


----------



## CrazyElf

I have a strange problem going on right now with my system. HWInfo64 seems to cause an instantaneous shutdown when I start the application.

This is with v5.02. I'm not sure why this is happening though.

CPUID HWMonitor does not seem to cause this, nor do applications like HCI MemTest.


----------



## Mumak

Quote:


> Originally Posted by *CrazyElf*
> 
> I have a strange problem going on right now with my system. HWInfo64 seems to cause an instantaneous shutdown when I start the application.
> 
> This is with v5.02. I'm not sure why this is happening though.
> 
> CPUID HWMonitor does not seem to cause this, nor do applications like HCI MemTest.


Please attach the HWiNFO Debug File from the crash for analysis as described here: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## CrazyElf

Quote:


> Originally Posted by *Mumak*
> 
> Please attach the HWiNFO Debug File from the crash for analysis as described here: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


The problem I have right now is that my HWInfo64 crashes during the "Gathering system configuration" cycle right after I click the ok. I cannot get into the configuration.

I have edited the INI file and set DebugMode to 1:


Spoiler: Warning: Spoiler!



[LogfileSettings]
COMP=1
COMP_SP=1
COMP_Name=1
COMP_Os=1
COMP_User=0
CPU=1
CPU_Name=1
CPU_ID=1
CPU_Vendor=1
CPU_Stepping=1
CPU_Type=1
CPU_BrandID=1
CPU_PN=1
CPU_Clock=1
CPU_MaxFreq=1
CPU_CacheL1=1
CPU_CacheL2=1
CPU_TLB_I=1
CPU_TLB_D=1
CPU_Features=1
CPU_PIROM=1
MEM=1
MEM_TotalSize=1
MEM_Timing=1
MEM_Row=1
MEM_Row_Size=1
MEM_Row_Type=1
MEM_Row_Speed=1
MEM_Row_Model=1
MEM_Row_ECC=1
MEM_Row_Date=1
MEM_Row_SN=1
MEM_Row_Cfg=1
MEM_Row_Latency=1
MEM_Row_Features=1
MEM_Row_iFeatures=1
BUS=1
BUS_PCI=1
BUS_PCI_DevName=1
BUS_PCI_DevNumber=1
BUS_PCI_Resources=1
BUS_PCI_Features=1
BUS_PCI_DevSpecific=1
BUS_PCIX_Features=1
BUS_PCIe_Features=1
BUS_PCI_DRV_INFO=1
BUS_EISA=1
DMI=1
DMI_0=1
DMI_1=1
DMI_2=1
DMI_3=1
DMI_4=1
DMI_5=1
DMI_6=1
DMI_7=1
DMI_8=1
DMI_9=1
DMI_10=1
DMI_11=1
DMI_12=1
DMI_13=1
DMI_14=1
DMI_15=1
DMI_16=1
DMI_17=1
DMI_18=1
DMI_19=1
DMI_20=1
DMI_21=1
DMI_22=1
DMI_23=1
DMI_24=1
DMI_25=1
DMI_26=1
DMI_27=1
DMI_28=1
DMI_29=1
DMI_30=1
DMI_31=1
DMI_32=1
DMI_33=1
DMI_34=1
DMI_35=1
DMI_36=1
DMI_37=1
DMI_38=1
DMI_39=1
DMI_129=1
DMI_130=1
DMI_131=1
VIDEO=1
VIDEO_Chipset=1
VIDEO_Memory=1
VIDEO_Card=1
VIDEO_Bus=1
VIDEO_RAMDAC=1
VIDEO_BIOSver=1
VIDEO_Clock=1
VIDEO_HWID=1
VIDEO_DRV_INFO=1
VIDEO_DirectX=1
MON=1
MON_Name=1
MON_SN=1
MON_Date=1
MON_Dimensions=1
MON_DisplayType=1
MON_InputSignal=1
MON_Gamma=1
MON_DPMSinput=1
MON_DPMSmodes=1
MOBO=1
MOBO_Model=1
MOBO_Chipset=1
MOBO_CompName=1
MOBO_MachineType=1
MOBO_Slots=1
MOBO_BIOS_Manuf=1
MOBO_BIOS_Date=1
MOBO_PNP_Devs=1
MOBO_PNP_Nodes=1
MOBO_ACPI_Devs=1
MOBO_ACPI_Enum=1
DRIVE=1
DRIVE_IDE=1
DRIVE_IDE_Ctrller=1
DRIVE_IDE_Channel=1
DRIVE_IDE_Model=1
DRIVE_IDE_Rev=1
DRIVE_IDE_SN=1
DRIVE_IDE_Capacity=1
DRIVE_IDE_Geometry=1
DRIVE_IDE_Cache=1
DRIVE_IDE_Xfer=1
DRIVE_IDE_BasicCapab=1
DRIVE_IDE_ATA2Capab=1
DRIVE_IDE_SMART=1
DRIVE_SCSI=1
DRIVE_SCSI_ID=1
DRIVE_SCSI_Desc=1
DRIVE_SCSI_Class=1
DRIVE_Floppy=1
NETWORK=1
NETWORK_HWID=1
NETWORK_DRV_INFO=1
AUDIO=1
AUDIO_DRV_INFO=1
AUDIO_HWID=1
PORTS=1
BUS_USB=1
BUS_USB_DRV_INFO=1
BATTERY=1
SENSORS=1

[Settings]
HighestIdeAddress=0
AcpiEnum=0
SWSMI=1
DebugMode=1
SMBus=1
TempScale=C
AC97CodecID=1
SkipProblematicPciDev=0
GPUI2C=1
LPC=1
DefReportType=5
TPM=0
PCIdirect=0
OpenSystemSummary=1
RememberPreferences=1
LargeFonts=0
OpenSensors=0
MinimalizeMainWnd=0
MinimalizeSensors=0
PersistentDriver=0
UseHPET=1
AutoUpdate=1
GPUI2CNVAPI=1
GPUI2CADL=0
SensorsOnly=0
AcpiEval=1
CpuClkFromBusClk=1
BusClkPolling=1
SMBusAdrExclude=11111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000
GPUI2CBusExclude=00000000
SensorsSM=1
IoctlKernel=0
SummaryOnly=0
WakeGPUs=1
FlushBuffers=1
iMEsupport=1
GPUI2Ccaching=1
MinimizeGraphs=1
TextButtons=0



Will this work?


----------



## Mumak

Quote:


> Originally Posted by *CrazyElf*
> 
> The problem I have right now is that my HWInfo64 crashes during the "Gathering system configuration" cycle right after I click the ok. I cannot get into the configuration.
> 
> I have edited the INI file and set DebugMode to 1:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> [LogfileSettings]
> COMP=1
> COMP_SP=1
> COMP_Name=1
> COMP_Os=1
> COMP_User=0
> CPU=1
> CPU_Name=1
> CPU_ID=1
> CPU_Vendor=1
> CPU_Stepping=1
> CPU_Type=1
> CPU_BrandID=1
> CPU_PN=1
> CPU_Clock=1
> CPU_MaxFreq=1
> CPU_CacheL1=1
> CPU_CacheL2=1
> CPU_TLB_I=1
> CPU_TLB_D=1
> CPU_Features=1
> CPU_PIROM=1
> MEM=1
> MEM_TotalSize=1
> MEM_Timing=1
> MEM_Row=1
> MEM_Row_Size=1
> MEM_Row_Type=1
> MEM_Row_Speed=1
> MEM_Row_Model=1
> MEM_Row_ECC=1
> MEM_Row_Date=1
> MEM_Row_SN=1
> MEM_Row_Cfg=1
> MEM_Row_Latency=1
> MEM_Row_Features=1
> MEM_Row_iFeatures=1
> BUS=1
> BUS_PCI=1
> BUS_PCI_DevName=1
> BUS_PCI_DevNumber=1
> BUS_PCI_Resources=1
> BUS_PCI_Features=1
> BUS_PCI_DevSpecific=1
> BUS_PCIX_Features=1
> BUS_PCIe_Features=1
> BUS_PCI_DRV_INFO=1
> BUS_EISA=1
> DMI=1
> DMI_0=1
> DMI_1=1
> DMI_2=1
> DMI_3=1
> DMI_4=1
> DMI_5=1
> DMI_6=1
> DMI_7=1
> DMI_8=1
> DMI_9=1
> DMI_10=1
> DMI_11=1
> DMI_12=1
> DMI_13=1
> DMI_14=1
> DMI_15=1
> DMI_16=1
> DMI_17=1
> DMI_18=1
> DMI_19=1
> DMI_20=1
> DMI_21=1
> DMI_22=1
> DMI_23=1
> DMI_24=1
> DMI_25=1
> DMI_26=1
> DMI_27=1
> DMI_28=1
> DMI_29=1
> DMI_30=1
> DMI_31=1
> DMI_32=1
> DMI_33=1
> DMI_34=1
> DMI_35=1
> DMI_36=1
> DMI_37=1
> DMI_38=1
> DMI_39=1
> DMI_129=1
> DMI_130=1
> DMI_131=1
> VIDEO=1
> VIDEO_Chipset=1
> VIDEO_Memory=1
> VIDEO_Card=1
> VIDEO_Bus=1
> VIDEO_RAMDAC=1
> VIDEO_BIOSver=1
> VIDEO_Clock=1
> VIDEO_HWID=1
> VIDEO_DRV_INFO=1
> VIDEO_DirectX=1
> MON=1
> MON_Name=1
> MON_SN=1
> MON_Date=1
> MON_Dimensions=1
> MON_DisplayType=1
> MON_InputSignal=1
> MON_Gamma=1
> MON_DPMSinput=1
> MON_DPMSmodes=1
> MOBO=1
> MOBO_Model=1
> MOBO_Chipset=1
> MOBO_CompName=1
> MOBO_MachineType=1
> MOBO_Slots=1
> MOBO_BIOS_Manuf=1
> MOBO_BIOS_Date=1
> MOBO_PNP_Devs=1
> MOBO_PNP_Nodes=1
> MOBO_ACPI_Devs=1
> MOBO_ACPI_Enum=1
> DRIVE=1
> DRIVE_IDE=1
> DRIVE_IDE_Ctrller=1
> DRIVE_IDE_Channel=1
> DRIVE_IDE_Model=1
> DRIVE_IDE_Rev=1
> DRIVE_IDE_SN=1
> DRIVE_IDE_Capacity=1
> DRIVE_IDE_Geometry=1
> DRIVE_IDE_Cache=1
> DRIVE_IDE_Xfer=1
> DRIVE_IDE_BasicCapab=1
> DRIVE_IDE_ATA2Capab=1
> DRIVE_IDE_SMART=1
> DRIVE_SCSI=1
> DRIVE_SCSI_ID=1
> DRIVE_SCSI_Desc=1
> DRIVE_SCSI_Class=1
> DRIVE_Floppy=1
> NETWORK=1
> NETWORK_HWID=1
> NETWORK_DRV_INFO=1
> AUDIO=1
> AUDIO_DRV_INFO=1
> AUDIO_HWID=1
> PORTS=1
> BUS_USB=1
> BUS_USB_DRV_INFO=1
> BATTERY=1
> SENSORS=1
> 
> [Settings]
> HighestIdeAddress=0
> AcpiEnum=0
> SWSMI=1
> DebugMode=1
> SMBus=1
> TempScale=C
> AC97CodecID=1
> SkipProblematicPciDev=0
> GPUI2C=1
> LPC=1
> DefReportType=5
> TPM=0
> PCIdirect=0
> OpenSystemSummary=1
> RememberPreferences=1
> LargeFonts=0
> OpenSensors=0
> MinimalizeMainWnd=0
> MinimalizeSensors=0
> PersistentDriver=0
> UseHPET=1
> AutoUpdate=1
> GPUI2CNVAPI=1
> GPUI2CADL=0
> SensorsOnly=0
> AcpiEval=1
> CpuClkFromBusClk=1
> BusClkPolling=1
> SMBusAdrExclude=11111111111111110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000
> GPUI2CBusExclude=00000000
> SensorsSM=1
> IoctlKernel=0
> SummaryOnly=0
> WakeGPUs=1
> FlushBuffers=1
> iMEsupport=1
> GPUI2Ccaching=1
> MinimizeGraphs=1
> TextButtons=0
> 
> 
> 
> Will this work?


That INI will work, but you can also right before clicking OK hit the Settings button and enable it there


----------



## EarlZ

Hi,

Im currently using V5.02-2575 I have a GIgabyte G1.Sniper M5

CPU VRIN @ 1.836v
VR VOUT (CPU VCCIN) @ 1.787v



VRIN on my motherboard header readout shows 1.9v ( which is what I have on the bios )
VRING is at 1.3 but I have it at 1.17v in bios though

my question is the CPU VRIN and VCCIN on the app have any relation to the VRIN & VRING voltages are or they totally different ?


----------



## Mumak

VRIN is reported in HWiNFO by 2 sensors - the ITE one measures the rail probably somewhere between the voltage regulator and the CPU. The VRIN (=VCCIN) under the first IRF sensor is a direct measurement of the DIgital PWM output (VR).
VRING is a different value and is probably not possible to monitor on your mainboard.


----------



## LostParticle

I've downloaded the latest beta (v5.03-2585) and I have applied my customizations by running the .reg file, saved from my previous build. Besides the fact that I had to remove lots of thousand separators which looked awkward (for example, Core #0 clock 3,495.2 MHz), it's not working properly. I try to set two (2) decimal digits on my Current DL and UP rate, and I also try to set one (1) decimal digit on my SSD's and GPU's temp indications and it does not keep it (it does not remember it). I set these, I close the program from the big X button on the bottom right corner, or even the other close button, I open it again and these return to their defaults.



Another thing, not shown in the screenshot, is that whereas my motherboard's temp values come with one decimal digit, all of my Core # temps, CPU Package, IA and GT Cores, come with no decimal digit at all. So now I have to go through all these and set one decimal digit, to look alike.......

I've tried it with one, Core Max, and it does NOT remember (keep) this setting either!...

Finally, one thing that I've just observed (!) is that all the values in the Sensor panel are right aligned. My personal opinion is that they should have a center alignment, IF that is possible and not a big deal.

PS: I've restored the program to its original state (by deleting the Registry keys) and all I wrote above is still happening.


----------



## Mumak

Thanks for your report.
The things you see now are new features that I implemented per other requests. But every user prefers different features/options, so it's difficult to satisfy all. That's why I implemented so many options and configurable features.
I have also changed the default number of decimal digits for some values like temperatures which have an integer resolution to show those without decimal digits (no need to display with higher resolution when it's always an integer).
I can confirm that not remembering the number of decimal digits set by user is a bug and I'm fixing this ASAP.
Values are right aligned for easier readout - imagine the clock for some cores at a 3-digit number, while for others in the GHz range. I think it would not look good if this would be center-aligned.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for your report.
> The things you see now are new features that I implemented per other requests. But every user prefers different features/options, so it's difficult to satisfy all. That's why I implemented so many options and configurable features.
> I have also changed the default number of decimal digits for some values like temperatures which have an integer resolution to show those without decimal digits (no need to display with higher resolution when it's always an integer).
> I can confirm that not remembering the number of decimal digits set by user is a bug and I'm fixing this ASAP.
> Values are right aligned for easier readout - imagine the clock for some cores at a 3-digit number, while for others in the GHz range. I think it would not look good if this would be center-aligned.


Okay, looking forward to the new fixed build then, and when it comes to the alignment I think I agree. One question regarding the integer number of the temperatures:

- In my screenshot above you can see the Current temp of my T_Sensor 8 to be 51.*7*. On this specific screenshot it appears like it is stuck but I can reassure you that it works fine. A screenshot from v5.02-2575 :



So, according to your opinion these two sensor readings are faulty? The decimals appearing in the above screenshots are invalid? And should I just truncate them and use an integer number for these temperatures?


----------



## Mumak

It's OK, that sensor supports a higher resolution. Integer values are shown only for those which return integers only.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It's OK, that sensor supports a higher resolution. Integer values are shown only for those which return integers only.


Yeap, I thought so: my sensors work fine. The thing is that now I am obliged either to truncate ALL of the temperature sensors to zero decimal digits or add one decimal (zero) to those without higher resolution, because imagine, for example in the previous screenshot, how it will look if some of the values will display with one decimal and some others with no decimal digits. They won't be aligned properly and this will struck the eye immediately! :/

I will compromise and I will use integer temperature values for everything from now on.

Thank you, hope the new build will come out soon.


----------



## Mumak

If you need the fix, I can build it ASAP (tomorrow, now I'm heading to bed...)


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> If you need the fix, I can build it ASAP (tomorrow, now I'm heading to bed...)


Good morning









Well, yes I would like this fixed version as soon as possible because I am always running the latest version of the program and this time I'll have to modify the layout and afterwards save my new .reg file. These settings I will carry and apply from now on.

IF, on the other hand, a new version will be publicly available today or tomorrow then I'll wait.

Thank you.


----------



## Mumak

Here you go: www.hwinfo.com/beta/hw64_503_2586.zip


----------



## LostParticle

Thank you but it still does not work.

I have set all the temperature values shown in my rightmost table with no decimal digits. I saved from the big X on the bottom right corner and from the other close button. I opened it again and this is the result:



It has reset all the DTS values to one decimal again! And my SSD's and GPU's temps, too!

I have also deleted the Registry keys, not all of them, opened the program on its default state, closed without saving (Esc key), applied my .reg file, reopened it and retried. It has the same result: it does not keep the modifications. My .reg file has been created this morning from version 5.02-2575, which works fine on my system. (To be honest though, I've not tried if that one saves or forgets the modifications, as well).


----------



## Mumak

I see, sorry about that. This one should be OK: www.hwinfo.com/beta/hw64_503_2587.zip


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I see, sorry about that. This one should be OK: www.hwinfo.com/beta/hw64_503_2587.zip


All right, thank you, this one works!











I'd like your opinion on something. Beside the temperature values, I've also truncated the decimal digits from the values with the red line beside them, on the screenshot above.

- Is this appropriate / correct?
- Which other values can I truncate? For example, Bus and PCIe Clock? Can I set those to show 100 MHz, instead of 100.0 MHz? Any other value?

Thank you


----------



## Mumak

Yes, for that CPU the clock is integer only. I'll add this to be truncated by default for those CPUs which have the ratio integer only.
The BCLK can vary, so I'd not set it to integer, but the PCIe clock can be truncated (that's actually now done by default, but you have probably overridden it).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, *for that CPU the clock is integer only*. I'll add this to be truncated by default for those CPUs which have the ratio integer only.
> The BCLK can vary, so I'd not set it to integer, but the PCIe clock can be truncated (that's actually now done by default, but you have probably overridden it).


All right, thank you, I've removed the decimal from the PCIe clock already. Regarding the clock of my CPU, you mean that right now that I see Core #0 Clock 1699.*5* MHz, for example, that decimal is kind of invalid? So, should I remove the decimals from all the Core # and the Uncore # clock(s), as well?

Finally, please your opinion about the Memory, shown in my screenshot above.

Thank you.


----------



## Mumak

Sorry, I meant *Clock Ratio* (multiplier), not the frequency in MHz.
As for the memory load values they seem to be shown as integer only, though they should be calculated with a higher precision. I'm checking this now in order to improve the resolution.

Update:
I'll update so that "Virtual Memory Load" and "Physical Memory Load" values will be reported with 1 decimal digit precision.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Sorry, I meant *Clock Ratio* (multiplier), not the frequency in MHz.
> As for the memory load values they seem to be shown as integer only, though they should be calculated with a higher precision. I'm checking this now in order to improve the resolution.
> 
> Update:
> I'll update so that "Virtual Memory Load" and "Physical Memory Load" values will be reported with 1 decimal digit precision.


Okay, thanks, looking forward for the new version.


----------



## LostParticle

And by the way, is there an option to change the decimal mark in HWiNFO? Because in my country we use Arabic numerals with decimal comma.


----------



## Mumak

No, there's no such option.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, there's no such option.


Care to implement it?









Since there is an option for the thousand separator, why not be one for the decimal, as well?

In my system IF I will make use of the thousand separator it won't make sense. For example, Core clock = 3,500.7 is wrong in my language. On the other hand, 3.500.7 is completely wrong again. So, I can only use 3500.7, like I have it now, which is wrong again.


----------



## majnu

I found this useful for monitoring cpu usage whilst gaming but for some reason during gaming it introduces too much latency. I know it may sound BS or strange but everytime I run it I can't hit a barn door from 10 metres away.

Edit - I'm on v5.02


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Care to implement it?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Since there is an option for the thousand separator, why not be one for the decimal, as well?
> 
> In my system IF I will make use of the thousand separator it won't make sense. For example, Core clock = 3,500.7 is wrong in my language. On the other hand, 3.500.7 is completely wrong again. So, I can only use 3500.7, like I have it now, which is wrong again.


OK, I'll put that on my list


----------



## Mumak

Quote:


> Originally Posted by *majnu*
> 
> I found this useful for monitoring cpu usage whilst gaming but for some reason during gaming it introduces too much latency. I know it may sound BS or strange but everytime I run it I can't hit a barn door from 10 metres away.
> 
> Edit - I'm on v5.02


Try to disable some sensors in HWiNFO - the EC or SMART sensors can sometimes (depending on drivers ) cause such lags.


----------



## majnu

Quote:


> Originally Posted by *Mumak*
> 
> Try to disable some sensors in HWiNFO - the EC or SMART sensors can sometimes (depending on drivers ) cause such lags.


Thanks mate I will give that a try. Also when I installed the program for the first time it noticed that I had a Corsair H100i and that it could cause "problems" or something along those lines. I chose to disable that sensor.

Edit -
Quote:


> 2. Higher system load or latency during sensor monitoring.
> Description: When performing sensor monitoring, on some systems (depending on sensors present), the user might experience higher system load or latency (including DPC). This can be caused by certain sensors, especially sensors of the "EC" type, "DELL SMI", or disk SMART sensors (depending on controller and disk driver used).
> Workaround: Disable monitoring of particular sensor items (right-click and "Disable monitoring") until the latency/load is reduced. If this is caused by the Disk (SMART) sensors, try to upgrade the storage drivers.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I'll put that on my list


Thank you!


----------



## Mumak

Quote:


> Originally Posted by *majnu*
> 
> Thanks mate I will give that a try. Also when I installed the program for the first time it noticed that I had a Corsair H100i and that it could cause "problems" or something along those lines. I chose to disable that sensor.
> 
> Edit -


That warning about Corsair was only if you're using the Corsair Link software too. In that case it can cause issues. I too have a few Corsair water coolers and have uninstalled their CL software (it was a big pain). For monitoring them HWiNFO is very well, you just can't use it along with CL.


----------



## CrazyElf

I've attached a Debug file of a crash. Not sure what is happening - could be my system or the program.

HWiNFO64.zip 44k .zip file


The crash seems to be as the application starts up and completely freezes, needing a hard reset.


----------



## Mumak

Quote:


> Originally Posted by *CrazyElf*
> 
> I've attached a Debug file of a crash. Not sure what is happening - could be my system or the program.
> 
> HWiNFO64.zip 44k .zip file
> 
> 
> The crash seems to be as the application starts up and completely freezes, needing a hard reset.


That seems like a storage driver (IRST) issue - it crashes when queried for disks attached.
Can you try to upgrade the driver and see if that helps?


----------



## majnu

Just wondering if the program would be able to read temperature from probles, fan speeds, voltages etc attached to fan controllers?
I have a lamptron fc5v2 and use a probe which is sticking outside my case to monitor ambient temps, crude but it works lol


----------



## Mumak

Quote:


> Originally Posted by *majnu*
> 
> Just wondering if the program would be able to read temperature from probles, fan speeds, voltages etc attached to fan controllers?
> I have a lamptron fc5v2 and use a probe which is sticking outside my case to monitor ambient temps, crude but it works lol


What connection to the PC does it use? Do they offer some SDKs or code how to support it?


----------



## majnu

Quote:


> Originally Posted by *Mumak*
> 
> What connection to the PC does it use? Do they offer some SDKs or code how to support it?


Hi, there is no SDK to support it but it's connected via molex straight from the PSU.

I do have an Aqua Computer Aquaero 5 LT USB Fan-Controller stashed away somewhere. See link below. It does have some software you can install to monitor temps (similar to the Corsair Link software). That is connected via the internal USB2.0 ports on the motherboard and has a molex connector for power.

https://www.overclockers.co.uk/showproduct.php?prodid=WC-011-AQ


----------



## deepor

Quote:


> Originally Posted by *majnu*
> 
> Hi, there is no SDK to support it but it's connected via molex straight from the PSU.
> 
> I do have an Aqua Computer Aquaero 5 LT USB Fan-Controller stashed away somewhere. See link below. It does have some software you can install to monitor temps (similar to the Corsair Link software). That is connected via the internal USB2.0 ports on the motherboard and has a molex connector for power.
> 
> https://www.overclockers.co.uk/showproduct.php?prodid=WC-011-AQ


There is no way to read data from this Lamptron device you currently use if it's just Molex for power from the PSU and no connection towards the motherboard.


----------



## Mumak

Quote:


> Originally Posted by *deepor*
> 
> There is no way to read data from this Lamptron device you currently use if it's just Molex for power from the PSU and no connection towards the motherboard.


Right.
Quote:


> Originally Posted by *majnu*
> 
> Hi, there is no SDK to support it but it's connected via molex straight from the PSU.
> 
> I do have an Aqua Computer Aquaero 5 LT USB Fan-Controller stashed away somewhere. See link below. It does have some software you can install to monitor temps (similar to the Corsair Link software). That is connected via the internal USB2.0 ports on the motherboard and has a molex connector for power.
> 
> https://www.overclockers.co.uk/showproduct.php?prodid=WC-011-AQ


HWiNFO supports reading data from Aquaero devices and Aquasuite can also read values from HWiNFO vice-versa


----------



## majnu

Quote:


> Originally Posted by *deepor*
> 
> There is no way to read data from this Lamptron device you currently use if it's just Molex for power from the PSU and no connection towards the motherboard.


Quote:


> Originally Posted by *Mumak*
> 
> Right.
> HWiNFO supports reading data from Aquaero devices and Aquasuite can also read values from HWiNFO vice-versa


I thought so, anyway I installed the aquaero and it was plug and play basically and everything worked of the bat. Thanks guys

Just one slight aesthetic niggle. I use MSI Aafter Burner to monitor my GPU and HWinfo for CPU and Ambient Temps whilst gaming. Because I like to keep an eye on things so have it show on the OSD.

As you can see (pic 1 below) MSI AB labels each line, so I know what is being monitored. Is it possible to have a CPU label and a "custom" ambient Temp label ? I know that I can select temp from the Aquaero but to make things more meaningful I would prefer "Ambient temp" or to possibly rename it. For the CPU unfortunately the label is Core(x), but it would be useful to have the parent as it shows better info (pic 2)





Thanks


----------



## Mumak

You can rename any sensor item in HWiNFO and that should be reflected in other apps as well, just check the settings.


----------



## LostParticle

Hey Martin,

I'm running the latest beta, v.5.03-2595 and it seems to run great. Besides the Virtual and Physical Memory values, which now appear to be more precise since their decimals take values, what other bugs have been fixed? Does it remember the user's settings now? I haven't seen a choice for the decimal separator anywhere, so I suppose this has not been implemented yet?

Thank you.


----------



## Mumak

The list of changes can be found on the HWiNFO page, or in the forum under Announcements.
Yes, it should remember the preferences.
I didn't yet have time to implement the custom decimal separator. I have spent a great amount of time with new things like support of Z170-series mainboards and especially native NVMe support. And still a lot of higher priority issues in the queue...


----------



## majnu

Quote:


> Originally Posted by *Mumak*
> 
> You can rename any sensor item in HWiNFO and that should be reflected in other apps as well, just check the settings.


ah you do it from the main page, excellent.
I've disabled sensors that I'm not bothered about and so far haven't had any crashes but will need to have some proper long gaming sessions whilst recording to see how it holds up
I've customised it to how I like it now.


----------



## LostParticle

Hey Martin

Just passing by to report that the latest beta, v5.03-2600, works fine on my system, under Win 10 Pro. I was hoping for that customizable decimal separator but it's not here yet.

Keep up the good work


----------



## jdorje

So I really wanted to add a custom calculation sensor to monitor the quality of the TIM inside my chip before and after I delid!









The value would be "(cpu_package_temp - h80i_temp) / cpu_package_power" (arithmetic calculation from 3 different sensor values).

This isn't possible I think? But it seems like it shouldn't be hard...


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> So I really wanted to add a custom calculation sensor to monitor the quality of the TIM inside my chip before and after I delid!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The value would be "(cpu_package_temp - h80i_temp) / cpu_package_power" (arithmetic calculation from 3 different sensor values).
> 
> This isn't possible I think? But it seems like it shouldn't be hard...


No, this isn't possible.


----------



## dreamhope

Hi,

Thanks for the wonderful software.

I've just noticed that among the sensor readings I have 'Yes' under 'Drive Failure' while 'No' under 'Drive Warning'. Does this mean imminent failure?

Among SMART readings, there's a reading of 116 under 'G-Sense Error Rate'. There's a red cross to the left. Other readings seem fine. The drive is approaching 15000 hours.

Thanks a lot!


----------



## Mumak

Quote:


> Originally Posted by *dreamhope*
> 
> Hi,
> 
> Thanks for the wonderful software.
> 
> I've just noticed that among the sensor readings I have 'Yes' under 'Drive Failure' while 'No' under 'Drive Warning'. Does this mean imminent failure?
> 
> Among SMART readings, there's a reading of 116 under 'G-Sense Error Rate'. There's a red cross to the left. Other readings seem fine. The drive is approaching 15000 hours.
> 
> Thanks a lot!


Yes, this can mean a serious event occurred that could have an impact on drive health. "G-Sense Error Rate" indicates a vibration event.


----------



## ScrapmasterFlex

Hi I was wondering if I could ask a question- I did a bit of Googling a few days back and it didn't leave my question answered, so I was going to give up. Then I saw this thread and thought I could give it a try asking The Man Himself-

I built a new machine recently- built upon an i7 4790K , on an ASrock Z97 OC Formula.... I am using a Cooler Master Seidon 240M liquid cooler, along with my full-tower case with 4 built-in fans plus an extra purchased fan.

The 4 case fans are connected to the case's own PCB which allows me to control the speed with two buttons on the case front panel. However, the CPU cooler has 2 connections to the Motherboard (CPU1 and CPU2 - 1 is the actual pump, 2 is a 2-in-1-connector for both 120mm fans that blow on the radiator) , and the extra purchased fan is connected to one of the other motherboard fan connections (there's 2 or 3 additional , separate from CPU1 and CPU2).

My question is this -- can I control the fan speed with HWiNFO64? I can clearly see them listed , and the RPMs , but I can't figure out if I can actually adjust them with HWiNFO - I Googled this quite a bit, and it seemed like the answer was "Sometimes yes, sometimes no, and Probably not if you have an ASRock motherboard" -

I am just wondering if this is really true, or am I doing something wrong? Because there seems to be only 2 ways to control the fans. within ASrock's BIOS , but the fan control settings don't seem to actually control the fan speeds..... Or I can use another program such as Speed Fan, which seems to be a mini-little-HWiNFO64 that I have no other need of , except for controlling the fans. Am I messing up or just not capable?

Thanks very much for your time and help and if I need to clarify something I certainly will try.


----------



## Mumak

Quote:


> Originally Posted by *ScrapmasterFlex*
> 
> Hi I was wondering if I could ask a question- I did a bit of Googling a few days back and it didn't leave my question answered, so I was going to give up. Then I saw this thread and thought I could give it a try asking The Man Himself-
> 
> I built a new machine recently- built upon an i7 4790K , on an ASrock Z97 OC Formula.... I am using a Cooler Master Seidon 240M liquid cooler, along with my full-tower case with 4 built-in fans plus an extra purchased fan.
> 
> The 4 case fans are connected to the case's own PCB which allows me to control the speed with two buttons on the case front panel. However, the CPU cooler has 2 connections to the Motherboard (CPU1 and CPU2 - 1 is the actual pump, 2 is a 2-in-1-connector for both 120mm fans that blow on the radiator) , and the extra purchased fan is connected to one of the other motherboard fan connections (there's 2 or 3 additional , separate from CPU1 and CPU2).
> 
> My question is this -- can I control the fan speed with HWiNFO64? I can clearly see them listed , and the RPMs , but I can't figure out if I can actually adjust them with HWiNFO - I Googled this quite a bit, and it seemed like the answer was "Sometimes yes, sometimes no, and Probably not if you have an ASRock motherboard" -
> 
> I am just wondering if this is really true, or am I doing something wrong? Because there seems to be only 2 ways to control the fans. within ASrock's BIOS , but the fan control settings don't seem to actually control the fan speeds..... Or I can use another program such as Speed Fan, which seems to be a mini-little-HWiNFO64 that I have no other need of , except for controlling the fans. Am I messing up or just not capable?
> 
> Thanks very much for your time and help and if I need to clarify something I certainly will try.


I'm sorry, HWiNFO doesn't support fan control on your mainboard. It does this on very few specific machines only (some Alienware, DELL) as a special feature because no other tool was able to accomplish this. But fan control has never been something that was intended to be supported.


----------



## ScrapmasterFlex

OK thank you very much , at least I know now so I can stop messing with things I shouldn't be messing with lol. Thanks again very much.


----------



## gotovato

Hey, quick question, im currently running HWinfo64, been using it for a while really love the program! one issue im having right now though, I recently upgraded to an x99 setup with a 5930k, and hwinfo is only showing 4 of my cores temps, the other 2 aren't showing up, aswell as cpu usage, its only showing up to core 5 thread 0, but not showing core 5 thread 1. ive reinstalled it a few times and made sure nothing is hidden in the options. I believe im running the latest version, v5.02-2575. any help would be great, thanks!


----------



## LostParticle

Quote:


> Originally Posted by *gotovato*
> 
> Hey, quick question, im currently running HWinfo64, been using it for a while really love the program! one issue im having right now though, I recently upgraded to an x99 setup with a 5930k, and hwinfo is only showing 4 of my cores temps, the other 2 aren't showing up, aswell as cpu usage, its only showing up to core 5 thread 0, but not showing core 5 thread 1. ive reinstalled it a few times and made sure nothing is hidden in the options. I believe im running the latest version, v5.02-2575. any help would be great, thanks!


Have you tried the latest beta, v. 5.03-2600 ?


----------



## Mumak

Quote:


> Originally Posted by *gotovato*
> 
> Hey, quick question, im currently running HWinfo64, been using it for a while really love the program! one issue im having right now though, I recently upgraded to an x99 setup with a 5930k, and hwinfo is only showing 4 of my cores temps, the other 2 aren't showing up, aswell as cpu usage, its only showing up to core 5 thread 0, but not showing core 5 thread 1. ive reinstalled it a few times and made sure nothing is hidden in the options. I believe im running the latest version, v5.02-2575. any help would be great, thanks!


It's possible that Windows limits the number of threads (via bcdedit).
Do you see the full core temps and usage in other tools and in Task Manager ?


----------



## gotovato

Task manager shows all threads, real temp shows all 6 core temps no problem


----------



## Mumak

Quote:


> Originally Posted by *gotovato*
> 
> Task manager shows all threads, real temp shows all 6 core temps no problem


Please post here (or send me via e-mail) the HWiNFO Debug File as described here: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
I'll then analyze what's going on...


----------



## gotovato

Quote:


> Originally Posted by *Mumak*
> 
> Please post here (or send me via e-mail) the HWiNFO Debug File as described here: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
> I'll then analyze what's going on...


I have emailed you the debug file. i hope there is a solution for my issue. Thanks!


----------



## Mumak

Quote:


> Originally Posted by *gotovato*
> 
> I have emailed you the debug file. i hope there is a solution for my issue. Thanks!


I don't see anything wrong there. Try to do a "Reset Preferences" in HWiNFO.


----------



## gotovato

Quote:


> Originally Posted by *Mumak*
> 
> I don't see anything wrong there. Try to do a "Reset Preferences" in HWiNFO.


wow that worked! didn't think to do that, such a simple fix. Thank you!!


----------



## Mumak

Quote:


> Originally Posted by *gotovato*
> 
> wow that worked! didn't think to do that, such a simple fix. Thank you!!


You're welcome. I think the issue was that you previously had a 4-core CPU in the machine and HWiNFO has retained the previous settings after upgrading.


----------



## PlasticTramp

Since the last beta and now final version, these colons start to appear. Is this a bug?


----------



## Mumak

That looks like a bug. Shall be fixed in the next (Beta) build.


----------



## PlasticTramp

Quote:


> Originally Posted by *Mumak*
> 
> That looks like a bug. Shall be fixed in the next (Beta) build.


Thanks!


----------



## JourneymanMike

HWiNFO 64 blue screens my computer when I start the program...

After I make the selection to run the sensors it does nothing then BSOD's...

I've never had this issue before now...

This is on a clean install of Windows 7 Ultimate 64 bit and is the newest version of HWiNFO 64...

My system specs are in my SIG RIG...

Any ideas? Need more info?

BTW: HW-Monitor doesn't do this...


----------



## Mumak

Quote:


> Originally Posted by *JourneymanMike*
> 
> HWiNFO 64 blue screens my computer when I start the program...
> 
> After I make the selection to run the sensors it does nothing then BSOD's...
> 
> I've never had this issue before now...
> 
> This is on a clean install of Windows 7 Ultimate 64 bit and is the newest version of HWiNFO 64...
> 
> My system specs are in my SIG RIG...
> 
> Any ideas? Need more info?
> 
> BTW: HW-Monitor doesn't do this...


As first I suggest to try to disable GPU I2C Support in Settings prior starting HWiNFO.
If that doesn't help please enable Debug Mode and after the BSOD reboot and attach the HWiNFO64.DBG file produced for analysis.


----------



## TwirlyWhirly555

works great , Thanks : D


----------



## jdorje

I did a fresh OS install (windows 10) and now my h80i data isn't available. Do I have to install corsair link software for hwinfo to see the h80i? That seems strange.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> I did a fresh OS install (windows 10) and now my h80i data isn't available. Do I have to install corsair link software for hwinfo to see the h80i? That seems strange.


No, I strongly recommend against using the CL software - it cannot work with other tools like HWiNFO and is full of bugs.

The issue you see is because Windows 8.1 and later enable a feature called "EnhancedPowerManagement", which is not properly supported by Corsair firmware. So I believe the CL software won't work there either.
You will have to disable that feature either via registry: http://forum.corsair.com/forums/showthread.php?p=676000
or using the SIV tool: http://forum.corsair.com/forums/showthread.php?t=140665


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> No, I strongly recommend against using the CL software - it cannot work with other tools like HWiNFO and is full of bugs.
> 
> The issue you see is because Windows 8.1 and later enable a feature called "EnhancedPowerManagement", which is not properly supported by Corsair firmware. So I believe the CL software won't work there either.
> You will have to disable that feature either via registry: http://forum.corsair.com/forums/showthread.php?p=676000
> or using the SIV tool: http://forum.corsair.com/forums/showthread.php?t=140665


Previously I had link installed but never running. But I also didn't disable enhanced power management...would link have done that when I installed it?

Thanks for the quick reply.


----------



## Mumak

I'm not sure, but my guess is that it won't disable it.


----------



## Archea47

I tried turning on the OSD reporting while in a game of BF4 and was kicked by PunkBuster. Coincidence? Is it just because BF was already running?

Hesitant to try again - don't want to be banned if possible


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure, but my guess is that it won't disable it.


Yeah, not sure why I was confused. I had to do the registry fix originally to get link to work. Registry fix worked again but this time I didn't bother to install link. Thanks again.


----------



## error-id10t

Hey Mumak, hoping you can help.

I'm running a simple Cinebench R15 for OpenGL. In HWInfo under Performance Limit Reasons it is showing "RING: Max VR Voltage, ICCmax, PL4" as: YES. When I do the CPU test, no limits appear so it's iGPU related.

I have no dGPU. Can you tell me what this could possibly mean and what do I need to do to fix this limiter?


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> Hey Mumak, hoping you can help.
> 
> I'm running a simple Cinebench R15 for OpenGL. In HWInfo under Performance Limit Reasons it is showing "RING: Max VR Voltage, ICCmax, PL4" as: YES. When I do the CPU test, no limits appear so it's iGPU related.
> 
> I have no dGPU. Can you tell me what this could possibly mean and what do I need to do to fix this limiter?


It indicates that the Ring clock was reduced due to one of those mentioned reasons, but I'm afraid I cannot give you an exact answer why it happens. Anyway, I don't think this indicates a problem.


----------



## jdorje

Quote:


> Originally Posted by *error-id10t*
> 
> Hey Mumak, hoping you can help.
> 
> I'm running a simple Cinebench R15 for OpenGL. In HWInfo under Performance Limit Reasons it is showing "RING: Max VR Voltage, ICCmax, PL4" as: YES. When I do the CPU test, no limits appear so it's iGPU related.
> 
> I have no dGPU. Can you tell me what this could possibly mean and what do I need to do to fix this limiter?


What's your ring multiplier and voltage? Is either one set to "auto" in the bios? What does iccmax and pl4 even mean?

At a guess you have ring multiplier and voltage set to auto. The multiplier auto scales up and the voltage with it, hitting the voltage cap, causing it to scale back down.


----------



## error-id10t

It's at auto, ring I believe is cache?

The problem I have is that the iGPU is flickering under load and I'm trying to find the cause. The problem can be fixed either by removing XMP or lowering the OC. The CPU is stable as per other tests and "ignoring" this problem. Every time it does flicker (like a lost monitor signal), this "RING: Max VR Voltage, ICCmax, PL4" shows up as YES.

add: just forced max. cache to x32 instead of default x41 with no change. I don't think it's this.


----------



## Mumak

Well, that reason seems to be triggered when CPU's (Ring bus) maximum limits are hit - for voltage (VR limit), current (IccMax) or power (PL4). So I assume you're pushing the CPU to the max and that's why it throttles down.
Note, that the ring voltage is the same as the core voltage as they share the same VR.
You should also be able to see the Max and Current ring ratios/clock in HWiNFO to see how they change.


----------



## error-id10t

Have some good news, fixed this limiter by reducing SA/IO volts from 1.15v to 1.1v in BIOS, they were set by XMP earlier. Not exactly sure how these tie to those measurements but now I don't get this alert in the program or any other weirdness.


----------



## Mumak

I guess that reducing the voltage reduced the power, which is no longer hitting the ceiling (PL4) under load, so the throttling does no longer occur.


----------



## Archea47

Hey Mumak,

Love the software!

I'm trying to get HWInfo64 start with Windows 7 (sp1 pro) as quickly as possible. My Aquaero gets and curves fans off sensor data from HWInfo with their Aquasuite software.

Can I ...
Have HWInfo64 start and run before logging into my user?
Make it boot quicker?

Also is there a way to open Summary when HWInfo is started as Sensors Only?


----------



## Mumak

Quote:


> Originally Posted by *Archea47*
> 
> Hey Mumak,
> 
> Love the software!
> 
> I'm trying to get HWInfo64 start with Windows 7 (sp1 pro) as quickly as possible. My Aquaero gets and curves fans off sensor data from HWInfo with their Aquasuite software.
> 
> Can I ...
> Have HWInfo64 start and run before logging into my user?
> Make it boot quicker?
> 
> Also is there a way to open Summary when HWInfo is started as Sensors Only?


It's not possible to start HWiNFO program sooner than other applications before logging-in, but there are certain optimizations possible:
Currently HWiNFO has a 5 second delay during automatic start as a scheduled task. This was introduced, because sometimes HWiNFO needed certain services to be active. You can adjust this delay by going into Windows Task Scheduler and change the properties of the HWiNFO task.
Also, if you think that HWiNFO scan takes too long, which can happen on some systems, there are options (like disabling GPU I2C Support), to make it significantly faster. But this depends on the configuration of a particular machine.


----------



## jdorje

Quote:


> Originally Posted by *Archea47*
> 
> Hey Mumak,
> 
> Love the software!
> 
> I'm trying to get HWInfo64 start with Windows 7 (sp1 pro) as quickly as possible. My Aquaero gets and curves fans off sensor data from HWInfo with their Aquasuite software.
> 
> Can I ...
> Have HWInfo64 start and run before logging into my user?
> Make it boot quicker?
> 
> Also is there a way to open Summary when HWInfo is started as Sensors Only?


Can't you get the aquero software to delay its startup?


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> Can't you get the aquero software to delay its startup?


I'm not sure as I'm not using it. But in case it starts via Task Scheduler (as most tasks to), then you can adjust it as you wish and add a custom delay or trigger.


----------



## Archea47

Quote:


> Originally Posted by *Mumak*
> 
> It's not possible to start HWiNFO program sooner than other applications before logging-in, but there are certain optimizations possible:
> Currently HWiNFO has a 5 second delay during automatic start as a scheduled task. This was introduced, because sometimes HWiNFO needed certain services to be active. You can adjust this delay by going into Windows Task Scheduler and change the properties of the HWiNFO task.
> Also, if you think that HWiNFO scan takes too long, which can happen on some systems, there are options (like disabling GPU I2C Support), to make it significantly faster. But this depends on the configuration of a particular machine.


Thanks Mumak! I'll use the tweaks until I graduate into curving off my DeltaT on the aquaero
Quote:


> Originally Posted by *jdorje*
> 
> Can't you get the aquero software to delay its startup?


The issue is that the Aquero is waiting for Aquasuite to send it a fan speed curved off of temperature sensors in HWinfo. Until that happens the PC is Purdy loud


----------



## Elkim

What is the best way to use sensor .csv logs for graphs form? GenericLogViewer is pretty limited and useless.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> What is the best way to use sensor .csv logs for graphs form? GenericLogViewer is pretty limited and useless.


Hi Friend,

Not sure if I understood the question in the correct context, but I always use Microsoft Excel when graphing the logs of HWInfo if that helps. I like raw data as I wanted to slice-and-dice it to form graphs based on my interest.


----------



## Elkim

Quote:


> Originally Posted by *topet2k12001*
> 
> Hi Friend,
> 
> Not sure if I understood the question in the correct context, but I always use Microsoft Excel when graphing the logs of HWInfo if that helps. I like raw data as I wanted to slice-and-dice it to form graphs based on my interest.


Hi, thanks for quick reply. Can you explain me how exactly do you work with csv hwinfo64 logs @ MS Excel? Because those logs are pretty messy. All those vallues are stacked next to each other so I think its a little hard to work with it.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> Hi, thanks for quick reply. Can you explain me how exactly do you work with csv hwinfo64 logs @ MS Excel? Because those logs are pretty messy. All those vallues are stacked next to each other so I think its a little hard to work with it.


Hi Friend,

Ah, so it means I understood your question then. 

Do you usually work with Microsoft Excel at work? If not, then it might be a bit challenging for you. This question of yours now becomes a "Microsoft Excel how-to" kind of question. 

Try to Google "how to make a chart" if you want to learn more about it. Anyway, here's a very simple example I created for you. Just follow and apply the logic to the data produced by HWInfo. 

sample.xlsx 14k .xlsx file


I have previous Excel charts when I was overclocking my Sandy Bridge (Intel Core i7-2700K). I'll look for it and I'll send you so that you have more samples.


----------



## Elkim

In fact, I don't work with Excel so I don't know much about it and I know I'll have to learn it. I was just exploring options because correct me if I'am wrong but I have to manually "export" all those values I want to use in graphs because in the logs hwinfo64 creates I can't mark all values I want at the same time, is that correct?


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> In fact, I don't work with Excel so I don't know much about it and I know I'll have to learn it. I was just exploring options because correct me if I'am wrong but I have to manually "export" all those values I want to use in graphs because in the logs hwinfo64 creates I can't mark all values I want at the same time, is that correct?


I see. It's okay, there's always a first time to everything. 

You can, actually. I never have to export stuff over (or copy-paste them to a new worksheet in Excel format). You can create graphs straight from a worksheet that is in CSV format.

If not, you can always do a "Save As..." and then save it as a regular Excel file.

Yeah, if you find the whole data set to be a bit confusing, you can also consider copy-pasting only those that you need. When you become more accustomed to using MS Excel, you won't have to.  Just choose the columns that you are interested in making a graph, copy-paste to a new worksheet, and then create the appropriate graph.

Which reminds me, if I remember correctly I did post/upload my graphs in the "Sandy Stable Club" thread along with the Excel files. I am a HWInfo user by the way. But of course, the data in those Excel files are from an old version of HWInfo. But still, it serves the same purpose.

Try searching for my posts (visit my profile) and then look for my posts in the "Sandy Stable Club". You should be able to find those posts.

Try this: http://www.overclock.net/newsearch/?search=&resultSortingPreference=recency&byuser=topet2k12001&output=posts&sdate=0&newer=1&type=all&containingthread%5B0%5D=968053&advanced=1

*EDIT:* I think I understand your question now. You mean you want to select certain columns but they are not beside each other, correct? The trick is to press and hold the Ctrl key when selecting columns that are not beside each other. While pressing/holding Ctrl, use the mouse to highlight the column/s you want to make a graph for. But for beginners, yes you can simply copy-paste the columns you want in a new/separate worksheet.


----------



## Elkim

Quote:


> Originally Posted by *topet2k12001*
> 
> I see. It's okay, there's always a first time to everything.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> You can, actually. I never have to export stuff over (or copy-paste them to a new worksheet in Excel format). You can create graphs straight from a worksheet that is in CSV format.
> 
> If not, you can always do a "Save As..." and then save it as a regular Excel file.
> 
> Yeah, if you find the whole data set to be a bit confusing, you can also consider copy-pasting only those that you need. When you become more accustomed to using MS Excel, you won't have to.
> 
> 
> 
> 
> 
> 
> 
> Just choose the columns that you are interested in making a graph, copy-paste to a new worksheet, and then create the appropriate graph.
> 
> Which reminds me, if I remember correctly I did post/upload my graphs in the "Sandy Stable Club" thread along with the Excel files. I am a HWInfo user by the way. But of course, the data in those Excel files are from an old version of HWInfo. But still, it serves the same purpose.
> 
> Try searching for my posts (visit my profile) and then look for my posts in the "Sandy Stable Club". You should be able to find those posts.
> 
> Try this: http://www.overclock.net/newsearch/?search=&resultSortingPreference=recency&byuser=topet2k12001&output=posts&sdate=0&newer=1&type=all&containingthread%5B0%5D=968053&advanced=1
> 
> *EDIT:* I think I understand your question now. You mean you want to select certain columns but they are not beside each other, correct? The trick is to press and hold the Ctrl key when selecting columns that are not beside each other. While pressing/holding Ctrl, use the mouse to highlight the column/s you want to make a graph for. But for beginners, yes you can simply copy-paste the columns you want in a new/separate worksheet.


Thank you for you patience and willing to expůain this to me. I did work with Excel in the past a bit but my problem and questions is, that I cant choose the same value in one column. All those datas are so stacked that I can't have same type of values in one column.

For better undestanding, I want to export from the whole log "GPU LOAD" value only. The thing is that those values doesnt stick within a same column even if I try extend specific column. It behaves like if those values are written across all columns and doesn't care, that there are any columns at all.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> Thank you for you patience and willing to expůain this to me. I did work with Excel in the past a bit but my problem and questions is, that I cant choose the same value in one column. All those datas are so stacked that I can't have same type of values in one column.
> 
> For better undestanding, I want to export from the whole log "GPU LOAD" value only. The thing is that those values doesnt stick within a same column even if I try extend specific column. It behaves like if those values are written across all columns and doesn't care, that there are any columns at all.


Hm, I'm having difficulty visualizing your problem. Can you send/upload a copy of your Excel file so that I can take a look? You're interested only on the GPU load, correct?

You're saying that (let's say for, example, "GPU Load" is on Column A)...the data of "GPU Load" sometimes appears in Column B and not all "GPU Load" raw data is located in Column A, did I get that right?

Let me try to run Prime95 for 15 minutes and I'll check the raw data. On your end, please send me the actual and unmodified Excel CSV and I'll take a look at it.


----------



## Elkim

Quote:


> Originally Posted by *topet2k12001*
> 
> Hm, I'm having difficulty visualizing your problem. Can you send/upload a copy of your Excel file so that I can take a look? You're interested only on the GPU load, correct?


 HWiNFO_LOG_1461937.CSV 63k .CSV file


Here is an example. Maybe you have different version/release of MS OFFICE. Or maybe I just don't know how to sellect the specific vallue at all







Yes, please try to export just only value, it can be anyone.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> HWiNFO_LOG_1461937.CSV 63k .CSV file
> 
> 
> Here is an example. Maybe you have different version/release of MS OFFICE. Or maybe I just don't know how to sellect the specific vallue at all
> 
> 
> 
> 
> 
> 
> 
> Yes, please try to export just only value, it can be anyone.


I got the file.

Let's try making a graph. What are you interested to see?

*EDIT:* the raw data looks fine by the way. I asked because I wanted to check if there are any errors in producing the CSV (by HWiNFO). No issues so far and the data is usable. So it's really more of how-to in Excel at this point.


----------



## LostParticle

Quote:


> Originally Posted by *Elkim*
> 
> HWiNFO_LOG_1461937.CSV 63k .CSV file
> 
> 
> Here is an example. Maybe you have different version/release of MS OFFICE. Or maybe I just don't know how to sellect the specific vallue at all
> 
> 
> 
> 
> 
> 
> 
> Yes, please try to export just only value, it can be anyone.


Why don't you just Import the CSV file? Do not open it, just import it in Excel. The wizard will guide you to format it in an appropriate manner. An example I have just created :


Spoiler: Warning: Spoiler!


----------



## topet2k12001

Quote:


> Originally Posted by
> 
> LostParticle.xlsx 75k .xlsx file
> 
> 
> Why don't you just Import the CSV file? Do not open it, just import it in Excel. The wizard will guide you to format it in an appropriate manner.


I think I see now where you are having a problem. 

CSV can be opened in Excel directly. No need to "export" it to Excel (or open Excel and "import" it).

Here's your file. See the second sheet/tab. As you can see, I created a graph directly from the CSV and just did a "Save As..." (select regular Excel file: ".xls" for Excel 2003 or ".xlsx" for Excel 2007 onwards).

*EDIT:* lol...sorry apparently I responded to you you, @LostParticle.  My post was intended for the other person. He has difficulty creating a graph from the CSV Log...Excel can work directly with CSV Logs and even make graphs out of it (no need for "import"/"export"...at least with HWiNFO data).

@Elkim: just edit the graph I created and select/include the column that you are specifically interested in. If you want to show more than one column of data as a graph, then edit the graph to include the columns that you are specifically interested in. If you find the raw data to be confusing, copy-paste only the columns you need to a new worksheet. And then create the graph from there.


----------



## Elkim

You guys are the best!







I've got it


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> You guys are the best!
> 
> 
> 
> 
> 
> 
> 
> I've got it


Ahaha! Bascially you wanted to adjust the width of the columns!  OMG. 

1. Select the entire worksheet. The entire worksheet will be highlighted in blue.

2. Hover your mouse to a a column border (example, between Columns A and B there is a divider). You will notice that the mouse cursor will change from a white "plus sign" to a black "plus sign" that is thin.

3. When you see it change, double-click on your mouse and it will automatically adjust the column width of the entire worksheet.

Good to know you have your data you want it to be.


----------



## Elkim

That was what I tried to do the whole time, but it didnt work.

The procedure is following. Excel -> DATA -> FROM TEXT -> unmark tab and mark comma -> FINISH

This wonderful funny speaking guy did explain to me







)


----------



## LostParticle

@Elkim, glad you made it and thank you









@Mumak, hey Martin how is it going?

- Do you observe the three decimals in the Time column of the LOG CSV I have posted at post #956 and also shown at post #958? Is there a way you could eliminate those in the CSV? They are imported as text in Excel so they are interpreted and treated as text. Date formation does not apply. Could you do something about it, please?

The latest stable works great on my system, thank you very much.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> That was what I tried to do the whole time, but it didnt work.
> 
> The procedure is following. Excel -> DATA -> FROM TEXT -> unmark tab and mark comma -> FINISH
> 
> This wonderful funny speaking guy did explain to me
> 
> 
> 
> 
> 
> 
> 
> )


Hm...strange that the simple steps mentioned earlier didn't work out for you. I did those steps I mentioned in the file you sent me and it worked without any problems. I tested both on Excel 2016 and 2007. Anyway, glad you have it sorted out.


----------



## Elkim

Tryied it again but didnt work. Thank you for your time anyways







I appreciate it!


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> Tryied it again but didnt work. Thank you for your time anyways
> 
> 
> 
> 
> 
> 
> 
> I appreciate it!


No worries. I actually had to create a video recording of how I did it, if you are still interested.

In any case, that is less important. In Excel there is always more than one way of achieving the same result.


----------



## Elkim

I would like to see that video


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> I would like to see that video


Okay, please hold on. I'll edit this post. Please give me a few minutes...

*EDIT: *Sorry for the delay, Internet is slow today as there is a typhoon here in the Philippines, currently. So it is affecting my upload. Also I think there's a problem uploading the video here; I'll upload via YouTube instead...thank you for your patience.


----------



## topet2k12001

Hi @Elkim,

The video is available here: 



.


----------



## Elkim

Quote:


> Originally Posted by *topet2k12001*
> 
> Hi @Elkim,
> 
> The video is available here:
> 
> 
> 
> .


This video is privat, cant see it.


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> This video is privat, cant see it.


Sorry.  Updated the video's privacy settings. Please check now.


----------



## Mumak

Thanks @topet2k12001 and @LostParticle for the help with Excel









The last field in Time column of the CSV report are milliseconds. Correct importing into Excel might depend on regional settings.


----------



## Elkim

Quote:


> Originally Posted by *topet2k12001*
> 
> Sorry.
> 
> 
> 
> 
> 
> 
> 
> Updated the video's privacy settings. Please check now.


Thank you for the video but please look at the screen I attached before. When you open your csv files, all thos vallues are straight and correct in rows and columns. Mine raw logs ain't.


----------



## jdorje

I've used Google sheets. I irc just uploading/importing the csv info it will give you a usable spreadsheet.


----------



## Elkim

Quote:


> Originally Posted by *jdorje*
> 
> I've used Google sheets. I irc just uploading/importing the csv info it will give you a usable spreadsheet.


I've allready found how to do it. Just for curiosity i tried gsheets but those vallues are not correct.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks @topet2k12001 and @LostParticle for the help with Excel
> 
> 
> 
> 
> 
> 
> 
> 
> 
> The last field in Time column of the CSV report are milliseconds. Correct importing into Excel might depend on regional settings.


Well.... I don't think that anyone would find milliseconds useful especially in a text value. So, why don't you truncate them from the CSV? I mean, in Excel it's just a =LEFT(A1;FIND(".";A1)-1), assuming cell A1 contains the time but I was just wondering if it could be exported appropriately in the CSV already..

Note:
From HWiNFO's CSV only the Date is imported in Date Format . The rest is text and the numbers are numbers, of course. I mean you can do calculations with them. So, the time appearing as text would better come without the milliseconds.

@Elkim,
Man, you have found the correct and appropriate solution already!







Do not bother your head with other matters. The CSV file in the video the other guy posted above, is ALREADY imported in Excel, or at least it seems to be so! When I open the CSV directly in Excel 2013, so without importing it, it opens like you have shown in your post and the columns can NOT get selected. They do not exist, even, I think! So, don't bother...


----------



## Elkim

I was just curious, but you're right, thanks alot man


----------



## topet2k12001

Quote:


> Originally Posted by *Elkim*
> 
> I've allready found how to do it. Just for curiosity i tried gsheets but those vallues are not correct.


Strange...

@LostParticle: I didn't have to do anything special with Excel; from downloading his CSV file, I merely opened it via Excel and that was it. No modifications or import/export done from my end. The first few seconds of the video showed that I opened the CSV file directly via Excel (I double-clicked it).

@Elkim: yup, you don't have to worry if you weren't able to get it the way I did. As I have mentioned in my previous post, there is always more than one way to get the same result in Microsoft Excel.


----------



## LostParticle

Thank you, Martin, for the latest beta!!

Memory Timings look great!










Spoiler: Warning: Spoiler!


----------



## v1ral

My question may have been answered already.

Is there a reason the bus clock reading tead differently than what is set in bios?

Is it a glitch or something.


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> My question may have been answered already.
> 
> Is there a reason the bus clock reading tead differently than what is set in bios?
> 
> Is it a glitch or something.


How different is it and which CPU ? On most CPUs the BCLK is measured real-time and thus there can be slight differences.


----------



## v1ral

Quote:


> Originally Posted by *Mumak*
> 
> How different is it and which CPU ? On most CPUs the BCLK is measured real-time and thus there can be slight differences.


4790k and it goes from 100 to 102.x, which according to HWInfo put it's clock 1 multi up e.g 4900-5xxxMhz.


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> 4790k and it goes from 100 to 102.x, which according to HWInfo put it's clock 1 multi up e.g 4900-5xxxMhz.


You might disable the "Periodic polling" option in "HWiNFO - Settings - Safety - CPU Clock Measurement" to avoid such fluctuations.


----------



## v1ral

Quote:


> Originally Posted by *Mumak*
> 
> You might disable the "Periodic polling" option in "HWiNFO - Settings - Safety - CPU Clock Measurement" to avoid such fluctuations.


Hmm, i cant find those options in settings.
Im on the v5.06 build of the program and i see it no where.

Or wait its in the initial set up settings..


----------



## LostParticle

Quote:


> Originally Posted by *v1ral*
> 
> LostParticle
> I am wondering what "vring" part of mine says.. it's always 1.8xx as I labeled my VCCIN to what I think is the right one..
> Maybe I am reading it wrong...
> I will try and get a screen shot of the Default set up, as I omit useless info like you do.
> 
> Latest beta version, is it really better to use?


Using the latest version of HWiNFO64 is always the best thing. The program notifies you whenever there's a new version and you should download it and use it.

The easiest way to restore HWiNFO64 at its default state is to run RegEdit and search for the value "HWiNFO". The search will lead you to the following key, which you should delete:
HKEY_CURRENT_USER\SOFTWARE\HWiNFO64

After deleting this key run the program. It will open at its default state. Use the arrow keys at the bottom left corner to expand it in at least three (3) tables. Use your computer for a couple of minutes and then take some time to study all the monitored values. Decide which are important for you to monitor and keep them. Remove the rest, those you find useless, by right-clicking on each one and selecting "Disable Monitoring" and "Hide". I am not sure right now if "Hide" disables monitoring, as well. Perhaps @Mumak can enlighten me on this one. [EDIT: yes, it does]. You can select multiple values at once by using Shift and Ctrl.

After deciding which values you wish to keep you ought to customize the program a bit, to fit in your monitor, to reorder and rename the values according to your preferences, and even to change the color in some, if you find this helpful.

Pay attention that with "renaming" a value I do not mean re-labeling it! You say that you labeled your VCCIN to what you think is the right one&#8230; This is completely wrong! You can rename a value, like giving it a shorter name, but to completely re-label a value you should consult the developer and the Technical Support of your motherboard's manufacturer to get the appropriate information. If you will search posts of mine in this thread you will see that I have re-labeled some values for my ASRock Z97 OC Formula, and for other motherboards, as well, but I have done so ONLY after getting the appropriate information from ASRock tech. support and ONLY in cooperation with the developer. So, he released a new beta in which he re-labeled the respective value. Not me.

So, after customizing HWiNFO64 to your preferences, you save and close it, then reopen it, and then you should save your work by going to Settings and select "Back up user preferences." This will create a.reg file. Save it in a secure place and double-click it each time you wish to apply your customizations again. I keep this .reg file in a USB stick together with all the required drivers for a clean installation for my system. With Windows 10 I have to clean install regularly due to TP builds' regular releases. In each new installation HWiNFO64 is the first program installed, and I apply my backed up settings so it works as I've left it.

Finally, I consider the use of HWiNFO64&#8230;compulsory! With Windows 10 and the Virtual Desktops it's not going to take up space, it does not consume resources, and for those who overclock it is very important to get a complete idea about what's going on in their systems. Also, whenever you face an issue HWiNFO is the best way to provide a complete snapshot of your system so that the people will be more able to help you.

All these represent my personal and subjective opinion.

Post a screenshot of HWiNFO64 showing ALL the values it monitors in your system at its default state. You might need to post two or even three. Then I or the developer could help you in customizing it.


----------



## v1ral

Spoiler: Warning: Spoiler!



Quote:


> Originally Posted by *LostParticle*
> 
> Using the latest beta of HWiNFO64 is always the best thing. The program notifies you whenever there's a new version and you should download it and use it.
> 
> The easiest way to restore HWiNFO64 at its default state is to run RegEdit and search for the value "HWiNFO". The search will lead you to the following key, which you should delete:
> HKEY_CURRENT_USER\SOFTWARE\HWiNFO64
> 
> After deleting this key run the program. It will open at its default state. Use the arrow keys at the bottom left corner to expand it in at least three (3) tables. Use your computer for a couple of minutes and then take some time to study all the monitored values. Decide which are important for you to monitor and keep them. Remove the rest, those you find useless, by right-clicking on each one and selecting "Disable Monitoring" and "Hide". I am not sure right now if "Hide" disables monitoring, as well. Perhaps @Mumak can enlighten me on this one. You can select multiple values at once by using Shift and Ctrl.
> 
> After deciding which values you wish to keep you ought to customize the program a bit, to fit in your monitor, to reorder and rename the values according to your preferences, and even to change the color in some, if you find this helpful.
> 
> Pay attention that with "renaming" a value I do not mean re-labeling it! You say that you labeled your VCCIN to what you think is the right one&#8230; This is completely wrong! You can rename a value, like giving it a shorter name, but to completely re-label a value you should consult the developer and the Technical Support of your motherboard's manufacturer to get the appropriate information. If you will search posts of mine in this thread you will see that I have re-labeled some values for my ASRock Z97 OC Formula, and for other motherboards, as well, but I have done so ONLY after getting the appropriate information from ASRock tech. support and ONLY in cooperation with the developer. So, he released a new beta in which he re-labeled the respective value. Not me.
> 
> So, after customizing HWiNFO64 to your preferences, you save and close it, then reopen it, and then you should save your work by going to Settings and select "Back up user preferences." This will create a.reg file. Save it in a secure place and double-click it each time you wish to apply your customizations again. I keep this .reg file in a USB stick together with all the required drivers for a clean installation for my system. With Windows 10 I have to clean install regularly due to TP builds' regular releases. In each new installation HWiNFO64 is the first program installed, and I apply my backed up settings so it works as I've left it.
> 
> Finally, I consider the use of HWiNFO64&#8230;compulsory! With Windows 10 and the Virtual Desktops it's not going to take up space, it does not consume resources, and for those who overclock it is very important to get a complete idea about what's going on in their systems. Also, whenever you face an issue HWiNFO is the best way to provide a complete snapshot of your system so that the people will be more able to help you.
> 
> All these represent my personal and subjective opinion.
> 
> Post a screenshot of HWiNFO64 showing ALL the values it monitors in your system at its default state. You might need to post two or even three. Then I or the developer could help you in customizing it.






Thanks for your time.
I usually rename "cpu fan 1" and "cpu fan 2" to what it's connected to e.g pump and fans, then I hide disk drives and things that don't give me info.
I'll post the screens shots of the default then a screen shots with things disabled/hidden.

Some stuff cut off.

HWInfo1.png 226k .png file

Continued where it cut off.

HWInfo2.png 230k .png file

x264 Run with things disabled.

x471.224x401.12xPASS.png 817k .png file


Again thanks for your time!


----------



## LostParticle

Quote:


> Originally Posted by *v1ral*
> 
> 
> Thanks for your time.
> I usually rename "cpu fan 1" and "cpu fan 2" to what it's connected to e.g pump and fans, then I hide disk drives and things that don't give me info.
> I'll post the screens shots of the default then a screen shots with things disabled/hidden.
> 
> Some stuff cut off.
> 
> HWInfo1.png 226k .png file
> 
> Continued where it cut off.
> 
> HWInfo2.png 230k .png file
> 
> x264 Run with things disabled.
> 
> x471.224x401.12xPASS.png 817k .png file
> 
> 
> Again thanks for your time!


Thank you for your time and your cooperation!

Please, do me one favor: run the latest HWiNFO64, like you already did, but this time leave it to monitor for at least five (5) minutes while you are using your computer normally. Then post again, please, these two screenshots showing ALL the values monitored. And please, if it is possible, upload your screenshots directly here, in a spoiler, so that I won't have to download them on my computer (and so that everyone else can directly view them).

Thank you









Meanwhile, here is my personal opinion about this.



In the indigo rectangles I have placed the values which, according to my personal opinion, you should hide / disable monitoring. This is completely up to you, though.

In the red rectangles I have placed the values that look erratic to me. (Just 29 seconds of monitoring are not enough, though). I believe that you should definitely check out these values and try to correct what can be fixed and/or disable/hide what is arbitrary. If I were you I would ask @Mumak what is going on, and he would most probably phrase the appropriate question for me to ask at MSI tech support. Then provide him this info so that in a later beta he will correct the readings for your motherboard.

Good Luck!


----------



## v1ral

Quote:


> Originally Posted by *LostParticle*
> 
> Thank you for your time and your cooperation!
> 
> Please, do me one favor: run the latest HWiNFO64, like you already did, but this time leave it to monitor for at least five (5) minutes while you are using your computer normally. Then post again, please, these two screenshots showing ALL the values monitored. And please, if it is possible, upload your screenshots directly here, in a spoiler, so that I won't have to download them on my computer (and so that everyone else can directly view them).
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Meanwhile, here is my personal opinion about this.
> 
> 
> 
> In the indigo rectangles I have placed the values which, according to my personal opinion, you should hide / disable monitoring. This is completely up to you, though.
> 
> In the red rectangles I have placed the values that look erratic to me. (Just 29 seconds of monitoring are not enough, though). I believe that you should definitely check out these values and try to correct what can be fixed and/or disable/hide what is arbitrary. If I were you I would ask @Mumak what is going on, and he would most probably phrase the appropriate question for me to ask at MSI tech support. Then provide him this info so that in a later beta he will correct the readings for your motherboard.
> 
> Good Luck!





Spoiler: Warning: Spoiler!






running chrome


----------



## LostParticle

Quote:


> Originally Posted by *v1ral*
> 
> ...
> running chrome


Okay, thanks for running it but...you have not used the latest beta... Anyway, my suggestions are still the same:



In the red rectangles, again, are the values which look wrong, to me. Check them out as I suggested you in my previous post. When it comes to the CPU temp value, IF this is your CPU Socket temperature, then it looks kind of erratic to me. I am not sure about this, though.

Okay, so I hope I've helped
For sure when the working week will start, Martin will offer his opinion, as well!









Good Luck.


----------



## v1ral

Spoiler: Warning: Spoiler!



Quote:


> Originally Posted by *LostParticle*
> 
> Thank you for your time and your cooperation!
> 
> Please, do me one favor: run the latest HWiNFO64, like you already did, but this time leave it to monitor for at least five (5) minutes while you are using your computer normally. Then post again, please, these two screenshots showing ALL the values monitored. And please, if it is possible, upload your screenshots directly here, in a spoiler, so that I won't have to download them on my computer (and so that everyone else can directly view them).
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Meanwhile, here is my personal opinion about this.
> 
> 
> 
> In the indigo rectangles I have placed the values which, according to my personal opinion, you should hide / disable monitoring. This is completely up to you, though.
> 
> In the red rectangles I have placed the values that look erratic to me. (Just 29 seconds of monitoring are not enough, though). I believe that you should definitely check out these values and try to correct what can be fixed and/or disable/hide what is arbitrary. If I were you I would ask @Mumak what is going on, and he would most probably phrase the appropriate question for me to ask at MSI tech support. Then provide him this info so that in a later beta he will correct the readings for your motherboard.
> 
> Good Luck!


Here you go.
Running Chrome...
Quote:


> Originally Posted by *LostParticle*
> 
> Okay, thanks for running it but...you have not used the latest beta... Anyway, my suggestions are still the same:
> 
> 
> 
> In the red rectangles, again, are the values which look wrong, to me. Check them out as I suggested you in my previous post. When it comes to the CPU temp value, IF this is your CPU Socket temperature, then it looks kind of erratic to me. I am not sure about this, though.
> 
> Okay, so I hope I've helped
> For sure when the working week will start, Martin will offer his opinion, as well!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Good Luck.





what is the latest beta?

Edit:
Nevermind, I thought it was installed..
brb


Spoiler: Warning: Spoiler!


----------



## LostParticle

Quote:


> Originally Posted by *v1ral*
> 
> what is the latest beta?


It is the one you've used already for 29 seconds in a previous post of yours: *v.5.07-2670*


----------



## v1ral

Quote:


> Originally Posted by *LostParticle*
> 
> It is the one you've used already for 29 seconds in a previous post of yours: *v.5.07-2670*


updated last post


----------



## cy-one

Heya,

I'm just starting out with overclocking, using one of the extensive guides in the Intel section. One value that needs attention is Vcore... Which I am unable to find in my HWinfo64 :/

Halp?
http://i.imgur.com/bWHgbBZ.png <- Screenshot of Sensor Status window


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I am not sure right now if "Hide" disables monitoring, as well. Perhaps @Mumak can enlighten me on this one. You can select multiple values at once by using Shift and Ctrl.


Yes, hide does disable monitoring too.

@v1ral: What's the main issue you have - is it the VRING value? Indeed it looks pretty high. Can you please check in the BIOS (or use the tool from MSI) what VRING value is report there (if any) ?

@cy-one: On Haswell-based systems it depends on mainboard whether it supports monitoring of Vcore because of FIVR (Fully Integrated Voltage Regulator. Note, that only certain mainboards support this and some tools show VID instead of true Vcore there.


----------



## cy-one

I have this FIVR-Feature (Thanks, now I actually know what it means XD).
So.... Does that mean I'm **** outta luck? (Sorry, still very new to this).


----------



## Mega Man

i wanted to say thanks and sub to this thread ! loved hwinfo for years now !


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, hide does disable monitoring too.


Thank you, Martin!


----------



## Mumak

Quote:


> Originally Posted by *cy-one*
> 
> I have this FIVR-Feature (Thanks, now I actually know what it means XD).
> So.... Does that mean I'm **** outta luck? (Sorry, still very new to this).


Well, you might still be lucky since some ASRock 8-series boards seem to be able to monitor Vcore (even though it's not official), which is the VIN6. On your screenshot I see the VIN6 value is 0.856V (which matches VID quite well) but it's not changing. Can you please try to make screenshots under various CPU load - important is to see the actual VIN6 and VID values. If they look reasonable, I think that this value might be the Vcore.


----------



## cy-one

Not today, buuuut I will gladly help and make some various screenshots while doing RealBench (for example) and idle, as well as cam-skype, etc.


----------



## v1ral

Quote:


> Originally Posted by *Mumak*
> 
> Yes, hide does disable monitoring too.
> 
> @v1ral: What's the main issue you have - is it the VRING value? Indeed it looks pretty high. Can you please check in the BIOS (or use the tool from MSI) what VRING value is report there (if any) ?
> 
> @cy-one: On Haswell-based systems it depends on mainboard whether it supports monitoring of Vcore because of FIVR (Fully Integrated Voltage Regulator. Note, that only certain mainboards support this and some tools show VID instead of true Vcore there.


Actually I am wondering with is "Vring" and "VCCIN" , "VCCIN is the closest to what it should say in bios.


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> Actually I am wondering with is "Vring" and "VCCIN" , "VCCIN is the closest to what it should say in bios.


VCCIN is the input voltage for CPUs with FIVR - these CPUs take just a single voltage that is then transformed internally by FIVR to voltages like Vcore, etc.
Do you see a VRING voltage in BIOS? If yes, what's the value?


----------



## v1ral

Quote:


> Originally Posted by *Mumak*
> 
> VCCIN is the input voltage for CPUs with FIVR - these CPUs take just a single voltage that is then transformed internally by FIVR to voltages like Vcore, etc.
> Do you see a VRING voltage in BIOS? If yes, what's the value?


I don't I believe... but what would HWInfo be sensing it as?


----------



## LostParticle

@Mumak

Hey Martin









Why is the Core # ratio of all my cores at max while testing just one core only, after setting the affinity accordingly?



Spoiler: Warning: Spoiler!









Thank you


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> Hey Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Why is the Core # ratio of all my cores at max while testing just one core only, after setting the affinity accordingly?
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you


That's because the CPU does not support each core running at different ratios, thus all active cores will run at the resolved P-state ratio.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's because the CPU does not support each core running at different ratios, thus all active cores will run at the resolved P-state ratio.


Okay, thanks. I'll set my system to a per-core O/C and check again. In this example I used an all core O/C of 4.7 GHz.

Martin, according to your personal opinion, does the affinity function as it should, as shown in my second screenshot? So, when I've set in that specific example CPU 2 and CPU 3 to run exclusively the x264 test, has this really happened? Like the Resource Monitor is showing? So, does this mean that I was testing just my second core, on this specific example?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Martin, according to your personal opinion, does the affinity function as it should, as shown in my second screenshot? So, when I've set in that specific example CPU 2 and CPU 3 to run exclusively the x264 test, has this really happened? Like the Resource Monitor is showing? So, does this mean that I was testing just my second core, on this specific example?
> 
> Thank you.


Yes, it seems so.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, it seems so.


Okay, thank you









For what it's worth, I've set a simple per-core O/C of x45 x44 x43 x42, Override VCore = 1.260V and I've run Prime95 and the x264, after setting the affinity for my Core 3 (CPU 6 and CPU 7). It was taking the values of x45 and x44, fluctuating between them, during the tests. Then I run the tests on Core 3 and Core 2. They both took the value of x44 but also x43. Similarly, 3 Cores reached up to x43 but also x42.

All this is normal, right? Why do they drop, even if it is for a very short time period? Shouldn't they stay fixed? For example, my Core 3 shouldn't stay at x45 fixed all the time during the test?


----------



## Mumak

Yes.


----------



## LostParticle

Ok, thanks


----------



## JourneymanMike

Quote:


> Originally Posted by *Mumak*
> 
> As first I suggest to try to *disable GPU I2C Support in Settings* prior starting HWiNFO.
> If that doesn't help please enable Debug Mode and after the BSOD reboot and attach the HWiNFO64.DBG file produced for analysis.


The BSOD problem went away for a while... All on it's own!

Now it is back with my new build...

Now, on your suggestion, do you mean settings in HWiNFO? If so, that's not going to happen... The Blue Screen comes fast...

So, exactly, what settings are you talking about, and where are they?

Thanks much,

Mike


----------



## JourneymanMike

Quote:


> Originally Posted by *JourneymanMike*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Mumak*
> 
> As first I suggest to try to *disable GPU I2C Support in Settings* prior starting HWiNFO.
> If that doesn't help please enable Debug Mode and after the BSOD reboot and attach the HWiNFO64.DBG file produced for analysis.
> 
> 
> 
> The BSOD problem went away for a while... All on it's own!
> 
> Now it is back with my new build...
> 
> Now, on your suggestion, do you mean settings in HWiNFO? If so, that's not going to happen... The Blue Screen comes fast...
> 
> So, exactly, what settings are you talking about, and where are they?
> 
> Thanks much,
> 
> Mike
Click to expand...

I found the Disable 12C Support - then disabled it...

BSOD immediately when choosing to run the sensor scan...

Are there any other things, that I can try, in Settings, that might solve the BSOD problem?

Thanks,

Mike


----------



## JourneymanMike

Quote:


> Originally Posted by *JourneymanMike*
> 
> Quote:
> 
> 
> 
> Originally Posted by *JourneymanMike*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Mumak*
> 
> As first I suggest to try to *disable GPU I2C Support in Settings* prior starting HWiNFO.
> If that doesn't help please enable Debug Mode and after the BSOD reboot and attach the HWiNFO64.DBG file produced for analysis.
> 
> 
> 
> The BSOD problem went away for a while... All on it's own!
> 
> Now it is back with my new build...
> 
> Now, on your suggestion, do you mean settings in HWiNFO? If so, that's not going to happen... The Blue Screen comes fast...
> 
> So, exactly, what settings are you talking about, and where are they?
> 
> Thanks much,
> 
> Mike
> 
> Click to expand...
> 
> I found the Disable 12C Support - then disabled it...
> 
> BSOD immediately when choosing to run the sensor scan...
> 
> Are there any other things, that I can try, in Settings, that might solve the BSOD problem?
> 
> Thanks,
> 
> Mike
Click to expand...

I found Debug Mode, it appears to be working fine... But I haven't stressed the system yet...

Do I now take it out of Debug Mode, or do I continue to run it?


----------



## Mumak

Quote:


> Originally Posted by *JourneymanMike*
> 
> I found Debug Mode, it appears to be working fine... But I haven't stressed the system yet...
> 
> Do I now take it out of Debug Mode, or do I continue to run it?


So it doesn't crash when you have Debug Mode enabled ? That's odd.. What I needed was to reproduce the crash when Debug Mode is enabled and then attach the resulting DBG file for analysis.
Another option you might try to disable is the Drive Scan.


----------



## JourneymanMike

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *JourneymanMike*
> 
> I found Debug Mode, it appears to be working fine... But I haven't stressed the system yet...
> 
> Do I now take it out of Debug Mode, or do I continue to run it?
> 
> 
> 
> So it doesn't crash when you have Debug Mode enabled ? That's odd.. What I needed was to reproduce the crash when Debug Mode is enabled and then attach the resulting DBG file for analysis.
> Another option you might try to disable is the Drive Scan.
Click to expand...

Unfortunately,the second time around, it crashed in Debug Mode, I'll have to take it out of Debug, and try it when I get home...

Also, I will try disabling Drive Scan...


----------



## Mumak

Quote:


> Originally Posted by *JourneymanMike*
> 
> Unfortunately,the second time around, it crashed in Debug Mode, I'll have to take it out of Debug, and try it when I get home...
> 
> Also, I will try disabling Drive Scan...


It would be great if you could attach the DBG file it produced when it crashed - I could analyze it and come with ideas what could be causing it.


----------



## LostParticle

Hey Martin,

I have decided to change my layout a bit by bringing on some of my SSDs' sensor values (and hiding the DRAM timings, which are static anyway). Can you please enlighten me on what do these percentages represent? For example, in the screenshot provided we see that my SanDisk SSD, which is my current C:\ , has reached a max = 100% Read Activity and a smaller percentage of Write activity. What does this mean? How are these values interpreted?

Thank you










Spoiler: Warning: Spoiler!







PS:
One thing I have also observed: I have set my decimal separator as a comma (,) and my thousands separator as a dot (.), according to my regional metric system. It works fine on the Sensor's panel and as soon as I set them both, the Sensor panel changes accordingly. When I go to "Custom" though and select a value the Thousands Separator is still a comma (,) and not a dot, as I have set it.


----------



## Mumak

Disk activity percentage should represent the percentage of time the disk is servicing particular requests.

The thousands separator setting in the General tab is a global setting that doesn't override particular custom values, but takes precedence when a particular custom value is the default one (comma). This is to preserve backwards compatibility with older versions that didn't have the global setting.


----------



## Mega Man

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin,
> 
> I have decided to change my layout a bit by bringing on some of my SSDs' sensor values (and hiding the DRAM timings, which are static anyway). Can you please enlighten me on what do these percentages represent? For example, in the screenshot provided we see that my SanDisk SSD, which is my current C:\ , has reached a max = 100% Read Activity and a smaller percentage of Write activity. What does this mean? How are these values interpreted?
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> PS:
> One thing I have also observed: I have set my decimal separator as a comma (,) and my thousands separator as a dot (.), according to my regional metric system. It works fine on the Sensor's panel and as soon as I set them both, the Sensor panel changes accordingly. When I go to "Custom" though and select a value the Thousands Separator is still a comma (,) and not a dot, as I have set it.


you should look into " smart data " as that is what is being read, with the exception of the write and read activity, which is literally the writing / reading


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Disk activity percentage should represent the percentage of time the disk is servicing particular requests.


Martin, can you please elaborate a bit, explain it a bit further, because I do not fully understand you? The % of time? So what does 100% stand for? Give me please an example based on my screenshot or guide me to make a new one and post it.

@Mega Man, thank you, yeah those that you see are what I kept to monitor from the S.M.A.R.T. values of my SSDs. It's just that I have renamed them to suite my personal preferences.


----------



## JourneymanMike

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *JourneymanMike*
> 
> I found Debug Mode, it appears to be working fine... But I haven't stressed the system yet...
> 
> Do I now take it out of Debug Mode, or do I continue to run it?
> 
> 
> 
> So it doesn't crash when you have Debug Mode enabled ? That's odd.. What I needed was to reproduce the crash when Debug Mode is enabled and then attach the resulting DBG file for analysis.
> *Another option you might try to disable is the Drive Scan*.
Click to expand...

Disabled Drive Scan, all is fine!









Thanks much,

Mike


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Martin, can you please elaborate a bit, explain it a bit further, because I do not fully understand you? The % of time? So what does 100% stand for? Give me please an example based on my screenshot or guide me to make a new one and post it.


It's simple - 100% means the disk is under full load and cannot execute more tasks at that time.


----------



## error-id10t

@Mumak bug report.. samsung 950 pro. It reads idle temp fine, as in it matches what AIDA64 shows when started but the temperature never changes. When I run something intensive the temperatures go up as expected in AIDA64 but in HWInfo they remain the same, not inching up or down.

Let me know if there's something you need.


----------



## Mumak

Quote:


> Originally Posted by *error-id10t*
> 
> @Mumak bug report.. samsung 950 pro. It reads idle temp fine, as in it matches what AIDA64 shows when started but the temperature never changes. When I run something intensive the temperatures go up as expected in AIDA64 but in HWInfo they remain the same, not inching up or down.
> 
> Let me know if there's something you need.


Please post the HWiNFO Debug File including sensor data, so I can check...


----------



## error-id10t

Quote:


> Originally Posted by *Mumak*
> 
> Please post the HWiNFO Debug File including sensor data, so I can check...


Here you go.

HWiNFO64.zip 78k .zip file


----------



## Mumak

Thanks. Can you also please post a screenshot of how the NVMe drive appears in Sensors ?


----------



## error-id10t

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. Can you also please post a screenshot of how the NVMe drive appears in Sensors ?


Sure, I put some load on so you see it's changing data but temps don't change.


----------



## Mumak

Thanks! I think I found the bug. It shall be fixed in the next version (5.10) that will be released in a few minutes


----------



## Mumak

Done, v5.10 released.
@error-id10t please let me know if it's OK now.


----------



## error-id10t

Quote:


> Originally Posted by *Mumak*
> 
> Done, v5.10 released.
> @error-id10t please let me know if it's OK now.


Hi there, confirmed working good now. Thanks


----------



## LostParticle

@Mumak

In the Alerts menu when I set "Change Item Color" only the Current value is set to RED and not the Maximum value, as well. Is this how it is supposed to work or the Maximum should change color, too?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak
> 
> In the Alerts menu when I set "Change Item Color" only the Current value is set to RED and not the Maximum value, as well. Is this how it is supposed to work or the Maximum should change color, too?


Yes


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes


If I understand you correctly, this is how it is supposed to work. Wouldn't it be better if the Maximum value would also turn RED and remain RED (since it's the Max) until reset? As a distinctive visual of the exceeded threshold the user set? I'm referring to the Alerts.

What's interesting (or weird, depending from your point of view) is that when setting _Custom / Red color (critical) if_, for a certain value, it works as expected: the Max and Current sensors become RED when the threshold is exceeded, and the Max remains RED, afterwards. When setting an Alert - with _Change Item Color_ - about the same sensor though, only the Current value becomes RED and this for as long as the value is above threshold. Then it returns to the default color. The Max value never turns RED.


----------



## [T]yphoon

still no working version that will show HWINFO on LCDHOST?


----------



## Mumak

Quote:


> Originally Posted by *[T]yphoon*
> 
> still no working version that will show HWINFO on LCDHOST?


There was an LCDHost plugin for HWiNFO, done by a guy there, but it seems it needs to be updated. You should check at their forums.


----------



## Barefooter

I'm trying to find my Asus Maximus Extreme VI VRM temperature reading in HWiNFO 64. I see under the motherboard section it lists Temp2, Temp4, and Temp5. Is it one of these?

Going to put a water block on the board soon, I've never really checked the VRM temps, but want to be able to see the difference putting it under water makes.


----------



## Mumak

Quote:


> Originally Posted by *Barefooter*
> 
> I'm trying to find my Asus Maximus Extreme VI VRM temperature reading in HWiNFO 64. I see under the motherboard section it lists Temp2, Temp4, and Temp5. Is it one of these?
> 
> Going to put a water block on the board soon, I've never really checked the VRM temps, but want to be able to see the difference putting it under water makes.


I don't think the MAXIMUS VI is able to measure VRM temperatures.


----------



## error-id10t

Quote:


> Originally Posted by *Barefooter*
> 
> I'm trying to find my Asus Maximus Extreme VI VRM temperature reading in HWiNFO 64. I see under the motherboard section it lists Temp2, Temp4, and Temp5. Is it one of these?
> 
> Going to put a water block on the board soon, I've never really checked the VRM temps, but want to be able to see the difference putting it under water makes.


If the temps are anywhere near similar to HERO VIII and they'd be I would say you're wasting money. Ambient here is 30 degrees at the moment, been folding for ~5 hours and mine show up as 47 degrees.


----------



## Barefooter

Quote:


> Originally Posted by *error-id10t*
> 
> If the temps are anywhere near similar to HERO VIII and they'd be I would say you're wasting money. Ambient here is 30 degrees at the moment, been folding for ~5 hours and mine show up as 47 degrees.


Are you reading your VRM temps through HWiNFO or through AI Suite? If through HWiNFO, which reading is it?

I know probably don't need the block, but already have it. Plus I'll be running three GPUs and I understand the PLX chip gets pretty warm.


----------



## error-id10t

Quote:


> Originally Posted by *Barefooter*
> 
> Are you reading your VRM temps through HWiNFO or through AI Suite? If through HWiNFO, which reading is it?
> 
> I know probably don't need the block, but already have it. Plus I'll be running three GPUs and I understand the PLX chip gets pretty warm.


I don't use AI SUITE so through the HWInfo, it's the reading labelled VRM







I've moved my values around but I think it's under the ASUS EC heading if it's there for you.


----------



## Mumak

ASUS MAXIMUS VIII (and VII too) can measure VR temperatures (under ASUS EC sensor as already noted), but I don't think the MAXIMUS VI has such a sensor.


----------



## falcon26

Is their a way to change the temp info to Fahrenheit?


----------



## Mumak

Quote:


> Originally Posted by *falcon26*
> 
> Is their a way to change the temp info to Fahrenheit?


Sure, just choose Configure Sensor (the wheel button).


----------



## v1ral

Mumak...
I posted screenshots a while back and I am wondering if you can point out the proper VCCIN section. I've relabeled something closest to what I have put in bios am I right in doing so? I have a "Vring" but it's pretty far from what I actually set in bios, so I don't use that reading.


Spoiler: Warning: Spoiler!



http://cdn.overclock.net/5/53/53e2bcc2_1.png



I was being helped before when I posted the screen shot, but I strayed away from the thread.


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> Mumak...
> I posted screenshots a while back and I am wondering if you can point out the proper VCCIN section. I've relabeled something closest to what I have put in bios am I right in doing so? I have a "Vring" but it's pretty far from what I actually set in bios, so I don't use that reading.
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> http://cdn.overclock.net/5/53/53e2bcc2_1.png
> 
> 
> 
> I was being helped before when I posted the screen shot, but I strayed away from the thread.


Well, looks like you might be right about the VRING. But to be sure I have sent a question to my MSI contact. Will let you know...


----------



## v1ral

Thanks!

Was it alright for me to rename what I think is VCCIN?


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> Thanks!
> 
> Was it alright for me to rename what I think is VCCIN?


Which one you think is VCCIN, the last value called VRING ?
Isn't the first VCCIN shown by HWiNFO correct ?


----------



## jdorje

Vrin is the input voltage. Vring is ring voltage. Or am I missing something?


----------



## v1ral

Quote:


> Originally Posted by *Mumak*
> 
> Which one you think is VCCIN, the last value called VRING ?
> Isn't the first VCCIN shown by HWiNFO correct ?


I would think the closest one to what I set it bios...


----------



## Mumak

Quote:


> Originally Posted by *v1ral*
> 
> I would think the closest one to what I set it bios...


MSI confirmed that your board should have the values as shown by default in HWiNFO.
What is your actual VRING and VCCIN value set in BIOS and which ones have you relabeled in HWiNFO ?
It would be best if you tell me your actual settings, post a HWiNFO screenshot showing original (not relabeled vales) and tell me which ones you think are not correct.


----------



## SgtRotty

hello! i was wondering what the voltage V1 is representing? ive seen it climb as high as 1.425v. ive searched in my bios, theres nothing set to that voltage. any help would be appreciated!
MB: Asus z97AR


----------



## Mumak

I'm sorry I don't know what that voltage might be, only ASUS knows..


----------



## LostParticle

Quote:


> Originally Posted by *SgtRotty*
> 
> 
> 
> hello! i was wondering what the voltage V1 is representing? ive seen it climb as high as 1.425v. ive searched in my bios, theres nothing set to that voltage. any help would be appreciated!
> MB: Asus z97AR


If you want further help post a screenshot of the latest beta of HWiNFO64 showing all the available (voltage and other) values the tool can monitor in your system, while under some load (for example scanning your PC with your Antivirus). Also try to move some values on the tables on the right, since you have expanded it.

If that doesn't work either, your best bet is what has been already *suggested to you*.


----------



## Associated

Hello!

Any ideas why ASRock MOBO has voltage sensors all messed up? I managed to identify VIN6 is VCCSA and VIN12 is DRAM voltage. But I can't find Cache voltage...


----------



## Mumak

Are you sure the voltages you mention can be monitored ? I have checked and the F-Stream tool doesn't report them, it might however report only the values set via BIOS (not really monitored).


----------



## Associated

No I am not sure, that's why I asked







That would be logical explanation... HWMonitor shows voltage and it's slightly higher than bios setting (around 0.03V higher) F-Stream just shows the BIOS setting.


----------



## Mumak

Well, it's possible that those values are what you assume - the board might monitor more values than F-Stream supports. This has already happened with ASRock boards - @LostParticle already got such a proof.
But it would be much better if ASRock could confirm this...


----------



## Associated

Yeah... I am really disappointed by ASRocks software (BIOS)... Do you maybe know whats the most effective way to contact them?


----------



## jdorje

I'd like an android app to view my hwinfo data. Does such a thing exist? Should I write it?


----------



## Mumak

Quote:


> Originally Posted by *Associated*
> 
> Yeah... I am really disappointed by ASRocks software (BIOS)... Do you maybe know whats the most effective way to contact them?


@LostParticle did so in the past, he might give you a suggestion.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> I'd like an android app to view my hwinfo data. Does such a thing exist? Should I write it?


There were some projects for such app: http://www.hwinfo.com/forum/Forum-3rd-Party-Extensions-Plug-ins-Gadgets but AFAIK they are not yet finished.
If you would like to develop such an app, it would be great - just let me know.


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> There were some projects for such app: http://www.hwinfo.com/forum/Forum-3rd-Party-Extensions-Plug-ins-Gadgets but AFAIK they are not yet finished.
> If you would like to develop such an app, it would be great - just let me know.


Where can I read about the server network interface?


----------



## tolis626

Hi Mumak. First off, let me say I love your work. Like others, I've used quite a few monitoring apps but always come back to HWiNFO. So thanks for that!









Now, on to the issue at hand. Sometimes I will get what seems to be erratic values on some sensors, like in this screenshot:


At first, I panicked and posted about it on the Devil's Canyon Owners' thread, but LostParticle pointed me here. When I realized that there is no way that my cache and I/O received 2.4V and survived (Not to mention my mobo VRM being at -40C or something like that), I thought that maybe I would try to pinpoint what the issue is. So far, I've been unsuccessful. The only thing I've noticed is that it usually happens when the GPU is under load. At least that's what I think. It just happened again and I'd only run 20 minutes BF4, then a FireStrike run and two Valley runs for testing my GPU stability.

Also, and don't take my word for this, I think it started happening only after updating to version 5.13. Again, I'm not sure, I just think so. It doesn't happen every day either, so I can't be sure.

Bad thing is, it didn't happen as long as I had debugging enabled and I forgot to turn it back on after I downloaded the latest beta, so the last time it happened went unrecorded, sadly. Apart from screeenies and a debug log, what else can I do to help you diagnose the issue?


----------



## Mumak

Quote:


> Originally Posted by *tolis626*
> 
> Hi Mumak. First off, let me say I love your work. Like others, I've used quite a few monitoring apps but always come back to HWiNFO. So thanks for that!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Now, on to the issue at hand. Sometimes I will get what seems to be erratic values on some sensors, like in this screenshot:
> 
> 
> At first, I panicked and posted about it on the Devil's Canyon Owners' thread, but LostParticle pointed me here. When I realized that there is no way that my cache and I/O received 2.4V and survived (Not to mention my mobo VRM being at -40C or something like that), I thought that maybe I would try to pinpoint what the issue is. So far, I've been unsuccessful. The only thing I've noticed is that it usually happens when the GPU is under load. At least that's what I think. It just happened again and I'd only run 20 minutes BF4, then a FireStrike run and two Valley runs for testing my GPU stability.
> 
> Also, and don't take my word for this, I think it started happening only after updating to version 5.13. Again, I'm not sure, I just think so. It doesn't happen every day either, so I can't be sure.
> 
> Bad thing is, it didn't happen as long as I had debugging enabled and I forgot to turn it back on after I downloaded the latest beta, so the last time it happened went unrecorded, sadly. Apart from screeenies and a debug log, what else can I do to help you diagnose the issue?


It looks you have moved some items from their original position in the sensor list, so I assume all the problematic values originally belong to the ASUS EC sensor.
Well, this one is problematic and that's also why you get the initial warning from HWiNFO. The values you see are certainly wrong and caused by erratic readout from the sensor. Unfortunately because access to that sensor is not well designed (by origin), erratic readouts can happen when for example using multiple tools to access this sensor (including ASUS AI Suite). High system load can also be the reason, because it causes the agents trying to read values from this sensor to get out of sync with the Embedded Controller. I'm afraid there's nothing I can do to fix this - it's a bad design choice for this sensor/interface. So I can only suggest to ignore those erratic values and don't worry about it.


----------



## tolis626

Quote:


> Originally Posted by *Mumak*
> 
> It looks you have moved some items from their original position in the sensor list, so I assume all the problematic values originally belong to the ASUS EC sensor.
> Well, this one is problematic and that's also why you get the initial warning from HWiNFO. The values you see are certainly wrong and caused by erratic readout from the sensor. Unfortunately because access to that sensor is not well designed (by origin), erratic readouts can happen when for example using multiple tools to access this sensor (including ASUS AI Suite). High system load can also be the reason, because it causes the agents trying to read values from this sensor to get out of sync with the Embedded Controller. I'm afraid there's nothing I can do to fix this - it's a bad design choice for this sensor/interface. So I can only suggest to ignore those erratic values and don't worry about it.


Well, you assumed correctly. I do get kind of OCD about how things on my screen are laid out, so I move stuff around a lot. And yes, these were all from that sensor, so it appears that either it had happened before without me noticing, or it just randomly happened now for no reason.

Still, knowing that it's actually just the reading that's wrong was a relief. At this point I'd only wanted to see if it had anything to do with the app and perhaps I could help solve any problems. Since it's Asus' problem, it's also for them to solve.

Thanks for your time, then! Keep up the great work!


----------



## Tideman

Installed this today and when I started it up my H110i GTX fans immediately went nuts. This was before I even selected anything (yes I did disable its sensor)??

The fans did not sound normal again until I restarted my system.. Uninstalled for now. Anyone else had this?


----------



## Mumak

Quote:


> Originally Posted by *Tideman*
> 
> Installed this today and when I started it up my H110i GTX fans immediately went nuts. This was before I even selected anything (yes I did disable its sensor)??
> 
> The fans did not sound normal again until I restarted my system.. Uninstalled for now. Anyone else had this?


You're probably running the Corsair Link Software. Unfortunately the CL software doesn't play nice with any other tool accessing their hardware and it can cause the problems you see. HWiNFO and other tools accessing the CL are synchronized to work together except Corsair Link. We (and several other tools developers) are trying to convince Corsair to implement a simple synchronization to avoid such problems since several years, but they are ignoring it. Their forums are full of such issues.
So currently the only way if you want to monitor their coolers using other tools like HWiNFO is to stop using Corsair Link.


----------



## Mega Man

Because they are..... nvm, let's just leave it at it was not nice


----------



## Tideman

Quote:


> Originally Posted by *Mumak*
> 
> You're probably running the Corsair Link Software. Unfortunately the CL software doesn't play nice with any other tool accessing their hardware and it can cause the problems you see. HWiNFO and other tools accessing the CL are synchronized to work together except Corsair Link. We (and several other tools developers) are trying to convince Corsair to implement a simple synchronization to avoid such problems since several years, but they are ignoring it. Their forums are full of such issues.
> So currently the only way if you want to monitor their coolers using other tools like HWiNFO is to stop using Corsair Link.


Thanks for your reply. Yes corsair link was installed but I'm not a fan of it and actually don't keep it running and it was not running at the time.


----------



## Mumak

Quote:


> Originally Posted by *Tideman*
> 
> Thanks for your reply. Yes corsair link was installed but I'm not a fan of it and actually don't keep it running and it was not running at the time.


If you're using Corsair Link v4, the service also needs to be stopped. Please make sure that the "CLink4Service" is stopped (can be done via Task Manager on Win7 and above).


----------



## shremi

Hey Mumak thanks for all of your hard work i didn't now you had a thread over here .... i am having some issues with the Voltages not reporting right with my msi z170 board .... Is there a way i can send you some info in order for you to check them out ???

As you can see in the picture it states that my actual Vcore is 1.128 while i entered 1.345 in the BIOS and Cpuz reports the vcore correctly since i am using auto LLC for now ....



TIA

Shremi


----------



## Mumak

Quote:


> Originally Posted by *shremi*
> 
> Hey Mumak thanks for all of your hard work i didn't now you had a thread over here .... i am having some issues with the Voltages not reporting right with my msi z170 board .... Is there a way i can send you some info in order for you to check them out ???
> 
> As you can see in the picture it states that my actual Vcore is 1.128 while i entered 1.345 in the BIOS and Cpuz reports the vcore correctly since i am using auto LLC for now ....
> 
> 
> 
> TIA
> 
> Shremi


Sorry for the delay in response, I had to check in detail about this. It seems your mainboard model requires a bit special handling for Vcore reporting. This shall be fixed in the next HWiNFO build








Just please confirm your exact model - is it MS-7968 (Z170A XPOWER GAMING TITANIUM EDITION) ?


----------



## LostParticle

Thanks for the latest beta, the newly added shortcuts are really handy!


----------



## shremi

Quote:


> Originally Posted by *Mumak*
> 
> Sorry for the delay in response, I had to check in detail about this. It seems your mainboard model requires a bit special handling for Vcore reporting. This shall be fixed in the next HWiNFO build
> 
> 
> 
> 
> 
> 
> 
> 
> Just please confirm your exact model - is it MS-7968 (Z170A XPOWER GAMING TITANIUM EDITION) ?


Yeah that's the one looking froward to the next build and again thanks for all of your hard work


----------



## xaxas

So what is really my vcore? i know you guys use hwinfo and i trust it but hwmonitor is showing 1.7 vcore while cpuz and hwinfo is showing what i have it set at in bios 1.34 or 1.33
im a bit worried about the 1.7 reading though im pretty sure it cant be right. I've never had a reading that far off if I can recall on hwmonitor. Just recently found out about hwinfo from these forums so will be using from now on but that reading bothers me from hwmonitor


----------



## Mega Man

another bug for hw monitor and the reason i never recommend it


----------



## xaxas

Wow had no idea it could be so far off. So it's for sure not actually 1.7 then. I guess my Temps would be sky rocketing if so if it would even boot at that point


----------



## Mega Man

i would bet not, as the cpu is still alive, however only _for sure_ method would be to test with a DMM which may not be easy depending on your mobo


----------



## xaxas

Yeah Temps are no higher and I played rainbow six siege for two hours so I doubt it's really 1.7. I have gigabyte gaming 7 z170. I really dislike the bios compared to my old Asus p67.
Sometimes settings don't save or they change for some reason even when I set manually.


----------



## Mumak

That's certainly a not correct reading in HWMonitor. I bet the other values there (like +5V, +12V, -12V) are way off too.
It just doesn't (yet) properly support your mainboard model.


----------



## scanferr

I have a question regarding the Vcore sensor in HWInfo. I have a ASRock Extreme 3 Z97 and I can't figure out which one is the Vcore in the sensor list.







Any ideas?


----------



## Mumak

I don't think your mainboard is capable of monitoring Vcore.


----------



## scanferr

Quote:


> Originally Posted by *Mumak*
> 
> I don't think your mainboard is capable of monitoring Vcore.


Sadly, it seems so. Cheers, nonetheless!


----------



## misoonigiri

Hi, thanks for providing us with this wonderful utility!








I'd like to ask abt this glitch for my rear case fan speed. At cpu idle when speeds are low (800+rpm), the RPM will jump between 800+ to 20000-35000. When cpu is at load and the case fan goes above 1000rpm, the glitching doesn't occur.

Previously while I was still in the midst of finding my overclock & doing stability tests, I was using either the Turbo or Standard fan profile in the bios (Q-fan, ASUS Hero) -> No glitching.
http://www.overclock.net/t/1570313/skylake-overclocking-guide-with-statistics/5580#post_24867879

Then recently I re-calibrated the fans in bios (Q-fan), and used the profile given after-calibration which I think uses minimum fan speeds at cpu idle -> Likely the glitching started after I did this.
 

It's a minor issue, but do you think there is anything to fix? Or should I just push up the fan speed until the glitching stops? Thank you.


----------



## misoonigiri

I forgot to mention I'm using Corsair 730T and stock case fans, http://www.corsair.com/en/graphite-series-730t-full-tower-case


----------



## Mumak

Well, there are 2 possible reasons for such a glitch:
1. Some other tool is interfering with HWiNFO. In case you're using other monitoring tools (including ASUS AI Suite), try to close them and check if the problem still happens.
2. The fan speed measuring logic on mainboard fails to properly measure low fan speeds. Are other tools reporting such erratic values too?

Are those invalid speeds just a few values always repeating or do they seem totally random?
I might try to add some filter for such invalids, but will also need the HWiNFO Debug File from the machine. Also having a sensor log of various invalid values might be helpful...


----------



## misoonigiri

Hi thanks for reply,
1. I don't have any other tools installed or running, only HWINFO64. I do not have ASUS AI Suite either.
2. I will try going into bios again when I'm home, to see if the hw monitor menu or qfan menu shows fan speeds. If there isn't, what program do you suggest?

The invalid speeds are not just a few repeated values; the figure seems to be always between 20000 and 35000 and only occurs when the rear case fan is at low rpm.
I'll read up on how to obtain the logs you require, and will try capturing them when I get home.

Thanks again!


----------



## Mumak

You might check in BIOS or AI Suite whether it reports such erratic speeds - just to confirm if this is an issue of low-speed measuring.


----------



## misoonigiri

Hi Mumak,
You are absolutely right







, the erratic speeds show up at bios hw monitor too. Sorry, I should have checked earlier before asking here.
I did another fan re-calibration in bios and now all is good.

Erratic speeds,



After re-calibration,



Sorry again for the trouble, and Thanks!


----------



## majnu

anyone having problems downloading the latest installer?

I click on both links and it does nothing


----------



## Mumak

Quote:


> Originally Posted by *majnu*
> 
> anyone having problems downloading the latest installer?
> 
> I click on both links and it does nothing


No issues. Which links and mirrors have you clicked ? If you click the "DOWNLOAD INSTALLER" or "DOWNLOAD PORTABLE" do they expand below? If not, do you have perhaps JavaScript disabled in browser? You might also try to refresh the page...


----------



## molnyi

@Mumak -
HWiNFO doesn't work on my pc. Installed 64 bit version on Windows 7 SP1 Professional 64 bit, all drivers are up to date.

Screenshot_1.png 7k .png file
 It's stuck there - not responding.


----------



## Mumak

Quote:


> Originally Posted by *molnyi*
> 
> @Mumak -
> HWiNFO doesn't work on my pc. Installed 64 bit version on Windows 7 SP1 Professional 64 bit, all drivers are up to date.
> 
> Screenshot_1.png 7k .png file
> It's stuck there - not responding.


Before starting the scan click Settings, then go into the Safety tab and disable "Intel ME Support". Let me know if that helped.


----------



## molnyi

Works like a charm, thanks <3


----------



## arrow0309

Hi, I've recently updated my hw from a Z77 OC Formula & i7 3770K to a Z87 OC Formula and a nice 4790K (@4.8 GHz).
I've been using the hwinfo64 (best in the world) monitoring software since it's early versions, even on gaming osd via RTSS but now I'm noticing the lack of cpu vcore value.
Tried with an older release (5.04):

http://www.xtremeshack.com/photos/20160319145841354142496.jpg
http://www.xtremeshack.com/photos/20160319145841353129845.jpg

And even with the latest 5.22-280, the vcore is still missing.
I've heard something about the Z87 OCF's nuvoton nct6776f but I'm better coming to ask about it here, on the right place.

Thanks


----------



## Mumak

Quote:


> Originally Posted by *arrow0309*
> 
> Hi, I've recently updated my hw from a Z77 OC Formula & i7 3770K to a Z87 OC Formula and a nice 4790K (@4.8 GHz).
> I've been using the hwinfo64 (best in the world) monitoring software since it's early versions, even on gaming osd via RTSS but now I'm noticing the lack of cpu vcore value.
> Tried with an older release (5.04):
> 
> http://www.xtremeshack.com/photos/20160319145841354142496.jpg
> http://www.xtremeshack.com/photos/20160319145841353129845.jpg
> 
> And even with the latest 5.22-280, the vcore is still missing.
> I've heard something about the Z87 OCF's nuvoton nct6776f but I'm better coming to ask about it here, on the right place.
> 
> Thanks


That's because your mainboard cannot monitor Vcore. You can only see the VID value, which is what CPU-Z shows as Core Voltage, however this is not the true Vcore.
Some ASRock 8-series mainboards however allow Vcore monitoring (VIN6 value on your screenshot), but I'm not sure if this might apply to your model too.


----------



## arrow0309

Hmm, installed the AsRock OC Formula's utility, Formula Drive and on the System Info tab I' getting:



Vcore Volt. it's the same value as the vin6.
Sorry for asking but how come you're not sure of this value (real vcore or not) on a motherboard that's 3 years old?
I've noticed that you've changed this vin6 voice to vcore on some other mo-bo's however it remained vin6 on my Z87 OCF









And, if the cpuz and aida64 are both showing me the vid voltage as vcore would the (same) CPU Override Volt from the Formula Drive mean the same thing?

BTW:
I've just checked on the bios of my Z87 OC Formula and getting 1.272v for the vcore volt, the same as the vin6


----------



## Mumak

Quote:


> Originally Posted by *arrow0309*
> 
> Hmm, installed the AsRock OC Formula's utility, Formula Drive and on the System Info tab I' getting:
> 
> 
> 
> Vcore Volt. it's the same value as the vin6.
> Sorry for asking but how come you're not sure of this value (real vcore or not) on a motherboard that's 3 years old?
> I've noticed that you've changed this vin6 voice to vcore on some other mo-bo's however it remained vin6 on my Z87 OCF
> 
> 
> 
> 
> 
> 
> 
> 
> 
> And, if the cpuz and aida64 are both showing me the vid voltage as vcore would the (same) CPU Override Volt from the Formula Drive mean the same thing?
> 
> BTW:
> I've just checked on the bios of my Z87 OC Formula and getting 1.272v for the vcore volt, the same as the vin6


I was not sure because the ASRock 8-series mainboards utilize 2 different SIO/HW monitoring chips and I got this fact confirmed (by ASRock and some users that did tests) only for one of them. Also there are many different models and sometimes I get confusing information.
I'll rename VIN6 to Vcore for your model in the next build.

I have also noticed that your mainboard seems to be capable of monitoring more items using an additional chip. I'd like to have a look at this, but could you please attach the HWiNFO Debug File including sensor data, so I can see more details ?


----------



## arrow0309

Quote:


> Originally Posted by *Mumak*
> 
> I was not sure because the ASRock 8-series mainboards utilize 2 different SIO/HW monitoring chips and I got this fact confirmed (by ASRock and some users that did tests) only for one of them. Also there are many different models and sometimes I get confusing information.
> I'll rename VIN6 to Vcore for your model in the next build.
> 
> I have also noticed that your mainboard seems to be capable of monitoring more items using an additional chip. I'd like to have a look at this, but could you please attach the HWiNFO Debug File including sensor data, so I can see more details ?


Thanks and here are the files you wanted, hope it helps








And let me know please when the next release is out









DESKTOP-95RP5T6.XML 287k .XML file


HWiNFO64.zip 884k .zip file


----------



## Mumak

Quote:


> Originally Posted by *arrow0309*
> 
> Thanks and here are the files you wanted, hope it helps
> 
> 
> 
> 
> 
> 
> 
> 
> And let me know please when the next release is out
> 
> 
> 
> 
> 
> 
> 
> 
> 
> DESKTOP-95RP5T6.XML 287k .XML file


Thanks, and sorry but I need the Debug File too. Here's how to create it: http://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## arrow0309

Done it already, I was just installing the 7-zip


----------



## Mumak

Quote:


> Originally Posted by *arrow0309*
> 
> Done it already, I was just installing the 7-zip


Thanks. That gives me more insight, but I'll need one more dump because that additional device is somehow hidden.
This could be done using the AIDA64 tool, do you know it? The dump can be created using AIDA64 by right-clicking the bottom status bar. If that bar is hidden, you might need to enable it from Menu -> View -> Status Bar. Then choose Sensor Debug and SMBus Dump (Full).


----------



## arrow0309

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *arrow0309*
> 
> Done it already, I was just installing the 7-zip
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks. That gives me more insight, but I'll need one more dump because that additional device is somehow hidden.
> This could be done using the AIDA64 tool, do you know it? The dump can be created using AIDA64 by right-clicking the bottom status bar. If that bar is hidden, you might need to enable it from Menu -> View -> Status Bar. Then choose Sensor Debug and SMBus Dump (Full).
Click to expand...

Here you go:

smbusdump_full.txt 9k .txt file


----------



## Mumak

Thanks. Well, that's really odd since the additional device doesn't seem to be visible at all.
Does the ASRock tool show additional temperatures like PCIE, Motherboard 1-7, PCH, VCCM, etc ? If yes, can you please try to create the dump again while having the ASRock tool running ?


----------



## arrow0309

I tried with the Formula Drive's Multi-Thermal Sensor opened:

http://s23.postimg.org/5lpfrwhyh/Capture.jpg

And created the dump file with aida64 (not the latest, however it's the 5.00 Extreme):

smbusdump_full1.txt 9k .txt file


----------



## Mumak

Thanks. This one is really tricky! The additional monitoring chip (Nuvoton NCT7902) seems to utilize a totally different interface - most probably USB HID. Also this chip is very rare and I haven't seen it on any other mainboard than yours. So a very rare chip + no documents about it... But I can try if you have more patience and can perform more tests.
So the next step would be to use the latest Beta of AIDA64 and try to create: System Debug / USB Dump


----------



## arrow0309

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. This one is really tricky! The additional monitoring chip (Nuvoton NCT7902) seems to utilize a totally different interface - most probably USB HID. Also this chip is very rare and I haven't seen it on any other mainboard than yours. So a very rare chip + no documents about it... But I can try if you have more patience and can perform more tests.
> So the next step would be to use the latest Beta of AIDA64 and try to create: System Debug / USB Dump


No worries, just give me a couple of hours to get back home and I'll get the new (aida64 beta) System Debug for you.


----------



## arrow0309

Sorry for the delay, here's the Usb Dump file you wanted:

usbdump.txt 18k .txt file


Done with the latest aida64 (v. 5.70) but I'm not sure if that helps either.


----------



## Mumak

Thanks, it helps! But still this is going to be tricky, need some time to find out how to communicate with this device...


----------



## arrow0309

OK, thanks!
Just let me know when you'll be out with the new release


----------



## Mumak

This seems to be more tricky than I originally thought .. We have asked ASRock for more information, hope they'll provide it...


----------



## chartiet

@Mumak and others, I'm having an issue where if I have a USB3 drive plugged into my case via the USB3 MoBo header only while HWInfo v5.22 and the previous version sensors are running, the drive will drop out, then come back up instantly. It seems to only happen when the sensors/program are running. If I close out of the program, the drive will stay up and not drop out. I have the particular drive monitors/sensors hidden and turned off in the layout tab, etc. Any ideas? May be a HWInfo issue or something unrelated, but Id figure Id start with most related. Thanks


----------



## Mumak

Is that USB3 device perhaps connected to an ASMedia USB3 controller? I have seen tons of problems with ASMedia drivers including BSODs. If this is the case some have resolved this problem by removing the ASMedia drivers and replacing them with default Microsoft ones.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> Is that USB3 device perhaps connected to an ASMedia USB3 controller? I have seen tons of problems with ASMedia drivers including BSODs. If this is the case some have resolved this problem by removing the ASMedia drivers and replacing them with default Microsoft ones.


Its a Max VII Gene so 99.9% sure, yes, it is lol







Would there be issues with the USB devices on the board and the vanilla MS drivers at all? Where would I find the best particular drivers? Just the ones downloaded through the device manager? Thanks again.

I have also had tons of BSOD's at the beginning but got through that by unchecking certain settings which I cant remember off the top of my head. After each update, I load directly into sensors only...


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> Its a Max VII Gene so 99.9% sure, yes, it is lol
> 
> 
> 
> 
> 
> 
> 
> Would there be issues with the USB devices on the board and the vanilla MS drivers at all? Where would I find the best particular drivers? Just the ones downloaded through the device manager? Thanks again.


AFAIK, those users didn't have any issues with MS driver, some even claimed it worked better for them. Doing a Roll Back Driver should restore the MS driver back.


----------



## chartiet

Do you think only the USB3 ASMedia driver was causing the BSOD's in this particular case?

As I said, Ive had a lot of issues going back many ASMedia driver'd boards with HWInfo and BSOD's solved by unchecking certain settings in the safety tab I think (just cant remember which ones they are/were atm).


----------



## Mumak

Yes, it was the ASMedia driver. It caused BSODs just when being queried for standard information. Some versions caused a BSOD, later ones other issues. So it appeared like they were trying to resolve it, but didn't fully manage it...


----------



## chartiet

Sincerely apologize for being thick, but the ASMedia driver as in the USB3 driver? or other ASMedia drivers like SATA for example?


----------



## arrow0309

Quote:


> Originally Posted by *Mumak*
> 
> This seems to be more tricky than I originally thought .. We have asked ASRock for more information, hope they'll provide it...


That'll be great!
Btw:
Do you think any debug with this utility might help you?


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> Sincerely apologize for being thick, but the ASMedia driver as in the USB3 driver? or other ASMedia drivers like SATA for example?


I have seen problems with both USB and SATA ASMedia drivers.


----------



## Mumak

Quote:


> Originally Posted by *arrow0309*
> 
> That'll be great!
> Btw:
> Do you think any debug with this utility might help you?


I don't think Ray's SIV would help here. It doesn't support that device either.
More useful would be some USB analyzer...
ASRock didn't respond yet


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> ....
> ASRock didn't respond yet


From my experience it might take them up to eight business days to reply. But they do respond.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> I have seen problems with both USB and SATA ASMedia drivers.


Gotcha. I'll roll back the USB drivers. I'm not so sure about ditching the SATA ASMedia drivers. Although, I'm not loosing SATA drives like the USB3 drive and I seem to have gotten through the BSOD's.


----------



## LostParticle

Hey Martin, is this a typo?


Spoiler: Warning: Spoiler!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, is this a typo?
> 
> 
> Spoiler: Warning: Spoiler!


Is Tcas not 10, or the decimal digit a problem ?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Is Tcas not 10, or the decimal digit a problem ?


I'm referring to the decimal digit. The Tcas value is correct.

Also, can you remind me how can I avoid the imprecise Bus Clock monitoring?

Because I get this effect:


Spoiler: Warning: Spoiler!





Constant:





Thank you.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> I have seen problems with both USB and SATA ASMedia drivers.


Here's what I see in device manager;



I'm assuming its the ASMedia XHCI 1.0 Controller I should roll back? Its the only USB controller with ASMedia drivers. The drive appears to be located Bus #0, Target Id 0, LUN 0 while the ASMedia controller is at PCI Bus 3, device 0, func 0. If that makes any sense... Again, its the case ports via USB3 MoBo header if those are any different than the back ports. I haven't tried the back ones and don't any desire to use them for the drive.


----------



## Mumak

Yes, it's that driver - XHCI is the interface for USB 3.0.


----------



## agentx007

Hello.

I would like to know :
Can HWINFO show TMU (Texture Mapping Unit) number, just like it does ROP number now (within GPU describtion) ?

Thank U.


----------



## Mumak

Quote:


> Originally Posted by *agentx007*
> 
> Hello.
> 
> I would like to know :
> Can HWINFO show TMU (Texture Mapping Unit) number, just like it does ROP number now (within GPU describtion) ?
> 
> Thank U.


No, this information is currently not displayed.


----------



## agentx007

Is it possible/feasible to add this info in some future release ?

Thank U for response.


----------



## Mumak

Quote:


> Originally Posted by *agentx007*
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Is it possible/feasible to add this info in some future release ?
> 
> Thank U for response.


Yes







Will be added in the next build.


----------



## LostParticle

Quote:


> Originally Posted by *LostParticle*
> 
> I'm referring to the decimal digit. The Tcas value is correct.
> 
> Also, can you remind me how can I avoid the imprecise Bus Clock monitoring?
> 
> Because I get this effect:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> Constant:
> 
> 
> 
> 
> 
> Thank you.


May I have a response as well, please?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> May I have a response as well, please?


That will be updated in the next build too.


----------



## arrow0309

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *LostParticle*
> 
> May I have a response as well, please?
> 
> 
> 
> That will be updated in the next build too.
Click to expand...

Good








Will this also apply for my Z87 OC Formula & 4790K @4.8GHz?
Look at the max clocks, all of them:

http://cdn.overclock.net/1/14/14b79d6a_20160319145841353129845.jpeg

And it's always been like that with my previous system (Z77 OC Formula & 3770K @4.8GHz) too.









Edit:
Maybe I'm wrong since I was using an older version before, just looked at some recent pics and they seem ok








My bad


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That will be updated in the next build too.


Thank you!

Just to clarify, are you referring to both Bus Clock imprecise monitoring and the Tcas decimal point matters? So, both of them will get fixed in the next build?


----------



## agentx007

Quote:


> Originally Posted by *Mumak*
> 
> Yes
> 
> 
> 
> 
> 
> 
> 
> Will be added in the next build.


Awesome









Thank U.


----------



## Mumak

I meant that I will update the Tcas decimal digit not to be shown.
The imprecise BCLK reporting issue must have been added later. First I suggest to try to disable the "Use HPET" option if you get better precision.
If that won't help, I'm afraid I don't have a fix for that and the only workaround is to disable "Periodic polling".
For Skylake and later CPUs, this should be precise though.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I meant that I will update the Tcas decimal digit not to be shown.
> The imprecise BCLK reporting issue must have been added later. First I suggest to try to disable the "Use HPET" option if you get better precision.
> If that won't help, I'm afraid I don't have a fix for that and the only workaround is to disable "Periodic polling".
> For Skylake and later CPUs, this should be precise though.


Thank you for the clarification, Martin, I'm looking forward to the next build









When you will find some time please explain to me what I will lose if I will disable those two settings you've suggested. I mean, what is the downside, if any, in disabling those?

I will observe the Bus Clock in CPU-Z and in the latest AIDA64 if this one monitors it, I do not recall now. IF it will fluctuate in these as well I will forget it. If it won't I'll call it a day, as well, since you cannot fix it. In my BIOS I have two settings for the BCLK and they are both manually set to 100 MHz. So I think that my Bus Clock is not actually fluctuating for real. The screenshot showing this fluctuation, in my previous post, is from a per-core o/c (x50 x50 x49 x49) so I don't know if this has anything to do with it. I'll check with my other o/c profiles as well, all of which are all-core o/c; I do not recall this happening.

Anyway, thank you again


----------



## Mumak

On CPUs prior to Skylake there's no 100% reliable method to determine what's the actual BCLK - meaning not what has been set, but to measure it with sufficient precision. One needs to use a bit complex timing methods that are not absolutely reliable. There are certain timers used to measure the clock and these can sometimes provide results that are not precise due to the fact that Windows is a multi-tasking environment and sometimes high-priority tasks can interrupt these measurements or influence them.
If you hover the mouse over those settings, you should get more details about their meaning.
If you disable the "Use HPET" option, HWiNFO will use a different timer to measure the BCLK. I think on some systems this can provide more precise data. But you need to test it.
If you disable the "Periodic polling" option, HWiNFO will not constantly measure BCLK - only do this once during startup. Then BCLK will appear fixed during runtime, however it will not catch a possible change in BCLK during runtime.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> Yes, it's that driver - XHCI is the interface for USB 3.0.


I rolled back the driver on that guy and I am still having the same issue. Below is what I see now. Any ideas where to go from here? Thanks


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> I rolled back the driver on that guy and I am still having the same issue. Below is what I see now. Any ideas where to go from here? Thanks


Please enable Debug Mode in HWiNFO, then run the scan as usual. Then close HWiNFO and attach the HWiNFO64.DBG file that was created. And please let me know which drive it is - is it that "Seagate Expansion SCSI device" ?
I'll have a look at that.
Additionally after supplying the DBG file, please try to disable Drive Scan in HWiNFO and let me know if the problem persists.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> Please enable Debug Mode in HWiNFO, then run the scan as usual. Then close HWiNFO and attach the HWiNFO64.DBG file that was created. And please let me know which drive it is - is it that "Seagate Expansion SCSI device" ?
> I'll have a look at that.
> Additionally after supplying the DBG file, please try to disable Drive Scan in HWiNFO and let me know if the problem persists.


It seems to still happen after disabling the Drive Scan function. Attached is the debug file as well as a screen shot of my General tab and before and after Safety tabs. Its the Seagate Expansion SCSI device. Thanks

chartiet_HWiNFO64.DBG.zip 59k .zip file


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> It seems to still happen after disabling the Drive Scan function. Attached is the debug file as well as a screen shot of my General tab and before and after Safety tabs. Its the Seagate Expansion SCSI device. Thanks
> 
> chartiet_HWiNFO64.DBG.zip 59k .zip file


Thanks. So the problem persists also with Drive Scan disabled and in Sensor-only mode? Can you please verify with those two settings ?


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. So the problem persists also with Drive Scan disabled and in Sensor-only mode? Can you please verify with those two settings ?


Ill have to "use it" more with the Drive Scan disabled but the one time it happened this morning was with Drive Scan disabled in Sensor only mode. I only run Sensor only mode. I thought I already had Drive Scan disabled but apparently I hadn't. Perhaps before I recently upgraded to 5.22 it switched back but I doubt it. Either way I'm pretty sure it happens with and without it disabled, but, Ill test more tonight. Any luck with the .dbg? I really appreciate the support.


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> Ill have to "use it" more with the Drive Scan disabled but the one time it happened this morning was with Drive Scan disabled in Sensor only mode. I only run Sensor only mode. I thought I already had Drive Scan disabled but apparently I hadn't. Perhaps before I recently upgraded to 5.22 it switched back but I doubt it. Either way I'm pretty sure it happens with and without it disabled, but, Ill test more tonight. Any luck with the .dbg? I really appreciate the support.


My first idea was that it was caused by Drive Scan, but when you say it still happens with that mode disabled then I thought it might be caused by USB scan.. USB scan is however not performed in Sensor-only mode. So if both these methods are not involved, then I have no clue yet what might be causing it


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> My first idea was that it was caused by Drive Scan, but when you say it still happens with that mode disabled then I thought it might be caused by USB scan.. USB scan is however not performed in Sensor-only mode. So if both these methods are not involved, then I have no clue yet what might be causing it


I tested the drive out some more tonight with Drive Scan disabled. I tested the drive by downloading a large file off the internet (new Nivdia driver) to the drive.

Using the two sets rear USB3 MoBo ports, both with HWInfo running and not running, the drive did not drop in/out.

Using the case ports via USB3 MoBo header with HWInfo running, the drive drops in out almost every time interrupting the file download. With HWinfo not running, the drive behaves better, dropping in/out 25% of the time. I don't know if there if something residual happening with HWInfo when not running that effects the drive behavior or not.

The next step is to completely uninstall HWInfo and test the drive. There is a slight possibility that there may be a issue with the case header itself but I sincerely doubt it. I googled ASUS Max VII Gene USB3 header issues and got some (more than a few) results dealing with ASMedia driver issues in general as well as possible power delivery issues through the header possibly causing the issues. The problem also seemed to effect my USB2 thumb drive as well but not as frequently although I didn't test it as thoroughly before. It may be a MoBo issue with drivers and not a HWInfo issue by itself even though it definitely happens more frequently with HWInfo running. I don't know where to go from here. I hate to waste more of your time chasing ghosts but if you have any more ideas or find anything, Id appreciate it. It may be worth its own thread or a drop in the ASUS support thread. Thanks again.

Edit: The USB2 thumb drive seems to be working fine tonight. I cant get it to act up with HWInfo running like the USB3 drive was an hour or two ago.


----------



## Mumak

Quote:


> Originally Posted by *chartiet*
> 
> I tested the drive out some more tonight with Drive Scan disabled. I tested the drive by downloading a large file off the internet (new Nivdia driver) to the drive.
> 
> Using the two sets rear USB3 MoBo ports, both with HWInfo running and not running, the drive did not drop in/out.
> 
> Using the case ports via USB3 MoBo header with HWInfo running, the drive drops in out almost every time interrupting the file download. With HWinfo not running, the drive behaves better, dropping in/out 25% of the time. I don't know if there if something residual happening with HWInfo when not running that effects the drive behavior or not.
> 
> The next step is to completely uninstall HWInfo and test the drive. There is a slight possibility that there may be a issue with the case header itself but I sincerely doubt it. I googled ASUS Max VII Gene USB3 header issues and got some (more than a few) results dealing with ASMedia driver issues in general as well as possible power delivery issues through the header possibly causing the issues. The problem also seemed to effect my USB2 thumb drive as well but not as frequently although I didn't test it as thoroughly before. It may be a MoBo issue with drivers and not a HWInfo issue by itself even though it definitely happens more frequently with HWInfo running. I don't know where to go from here. I hate to waste more of your time chasing ghosts but if you have any more ideas or find anything, Id appreciate it. It may be worth its own thread or a drop in the ASUS support thread. Thanks again.
> 
> Edit: The USB2 thumb drive seems to be working fine tonight. I cant get it to act up with HWInfo running like the USB3 drive was an hour or two ago.


Well, if the problem happens without HWiNFO then it must be something else. HWiNFO just makes it appear more frequently, but the problem must either be the drivers or the USB3 controller/header.
I'm afraid I don't know which of those exactly might be causing it, but you might try to ask ASUS support.


----------



## chartiet

Quote:


> Originally Posted by *Mumak*
> 
> Well, if the problem happens without HWiNFO then it must be something else. HWiNFO just makes it appear more frequently, but the problem must either be the drivers or the USB3 controller/header.
> I'm afraid I don't know which of those exactly might be causing it, but you might try to ask ASUS support.


Yea, its weird. What makes it a PITA is the intermittentcy of the issue. The only way to 100% rule out HWInfo is to remove it completely and see what happens. I just don't remember it happening prior to installing HWInfo during initial system setup but it could have been coincidence. Once I googled the general issue separate from HWInfo, I started to become skeptical it was HWInfo related. I'm moving into overclocking the system now and need HWInfo for monitoring so I may have to take the issue up with ASUS and see what happens in the mean time. I'll just use the back ports. Again thank you for the support. Having this level of attentiveness for a program like this is awesome.


----------



## misoonigiri

Hi, on my Windows 10 PC, and a few other Windows 7 PCs too, clicking the X at bottom of Sensor window will exit the program.
But on another Windows 10 PC where I recently installed HWINFO64, clicking the X only minimizes to notification tray. More clicks required to exit. I can't seem to find the setting to exit on clicking X?

Thanks!


----------



## Mumak

Quote:


> Originally Posted by *misoonigiri*
> 
> Hi, on my Windows 10 PC, and a few other Windows 7 PCs too, clicking the X at bottom of Sensor window will exit the program.
> But on another Windows 10 PC where I recently installed HWINFO64, clicking the X only minimizes to notification tray. More clicks required to exit. I can't seem to find the setting to exit on clicking X?
> 
> Thanks!


That settings is called "Minimize Sensors instead of closing" and it can be found in the main HWiNFO settings


----------



## misoonigiri

Quote:


> Originally Posted by *Mumak*
> 
> That settings is called "Minimize Sensors instead of closing" and it can be found in the main HWiNFO settings


I could have sworn it was unticked yet it did not exit upon clicking X. Will check that tomorrow!
BTW what is proper procedure when I install stable version, then want to replace with BETA? I think I did it wrongly as I only replaced the .exe file and not .ini file thinking I may lose my settings - likely this can cause potential settings problem like this?
Also, I noticed when I right click on notification tray icon, I sometimes see less options like MAIN, SUMMARY missing when I replaced Stable with new BETA 5.23-2830. I did try replacing BOTH .exe and .ini for this, even reinstalled stable first.

Very sorry if my post is confusing


----------



## Mumak

Quote:


> Originally Posted by *misoonigiri*
> 
> I could have sworn it was unticked yet it did not exit upon clicking X. Will check that tomorrow!
> BTW what is proper procedure when I install stable version, then want to replace with BETA? I think I did it wrongly as I only replaced the .exe file and not .ini file thinking I may lose my settings - likely this can cause potential settings problem like this?
> Also, I noticed when I right click on notification tray icon, I sometimes see less options like MAIN, SUMMARY missing when I replaced Stable with new BETA 5.23-2830. I did try replacing BOTH .exe and .ini for this, even reinstalled stable first.
> 
> Very sorry if my post is confusing


Replacing the EXE is perfectly fine as it won't override your settings (in INI).
The options in tray icon depend on mode you're using - i.e. in Sensors-only mode Summary is not available.


----------



## misoonigiri

Quote:


> Originally Posted by *Mumak*
> 
> Replacing the EXE is perfectly fine as it won't override your settings (in INI).
> The options in tray icon depend on mode you're using - i.e. in Sensors-only mode Summary is not available.


Thanks! Found I need to re-enable Welcome Screen and work out my preferences again from there on...


----------



## alt7

Hello Mumak: Kind of a newbie to this overclocking stuff. Read all the RAVES here about your program and downloaded and installed it. I have been playing around with the settings in the bios. When I first stated using your program the window in the upper right area shows the cores. Originally they were a nice green color. Now they are all bright red. They start out to the left of the graph as almost black and then get progressively redder until bright red. I have been searching for what that means and for some kind of a manual. Can you shed some light on the red graphs and lead me in the direction of an explanation of the screens? Just to clarify I am talking about the little rectangular window that seems to be by itself in the upper right corner and opens automatically when you open your program. It's headed with CPU #0 in the top bar then in the line across that underneath and still at the top it shows - Core - Clock Mhz - ratio. It appears to me the cpu is running at the overclocked speed and not throttling down. All the temps are low to mid 30C. System is a P9X79 with an i7 4930k. I have the BCLK at 110 and the multiplier at 41. Vid Voltage is showing at around 1.1709. Don't know what else to say.


----------



## Mumak

Quote:


> Originally Posted by *alt7*
> 
> Hello Mumak: Kind of a newbie to this overclocking stuff. Read all the RAVES here about your program and downloaded and installed it. I have been playing around with the settings in the bios. When I first stated using your program the window in the upper right area shows the cores. Originally they were a nice green color. Now they are all bright red. They start out to the left of the graph as almost black and then get progressively redder until bright red. I have been searching for what that means and for some kind of a manual. Can you shed some light on the red graphs and lead me in the direction of an explanation of the screens? Just to clarify I am talking about the little rectangular window that seems to be by itself in the upper right corner and opens automatically when you open your program. It's headed with CPU #0 in the top bar then in the line across that underneath and still at the top it shows - Core - Clock Mhz - ratio. It appears to me the cpu is running at the overclocked speed and not throttling down. All the temps are low to mid 30C. System is a P9X79 with an i7 4930k. I have the BCLK at 110 and the multiplier at 41. Vid Voltage is showing at around 1.1709. Don't know what else to say.


Sorry for confusion, it's nothing to worry about. The color of those bars just means:
Green - the actual clock is below the original frequency ( < HFM )
Yellow - it's above HFM, but below the Turbo Maximum Clock
Red - it's above the Turbo clock
If you're overclocking the CPU then you usually will see red bars


----------



## mynm

Hi, I have an r9 380 nitro, and I see that Hwinfo64 is monitoring mvddc voltage, but I'm not sure it's mvddc.

Some people suggest me that it is vddci, becuase gddr5 ram voltage is 1.6v and it is always below 1.2v. And I think that it may be vid.

Are you sure that it is mvddc?

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Hi, I have an r9 380 nitro, and I see that Hwinfo64 is monitoring mvddc voltage, but I'm not sure it's mvddc.
> 
> Some people suggest me that it is vddci, becuase gddr5 ram voltage is 1.6v and it is always below 1.2v. And I think that it may be vid.
> 
> Are you sure that it is mvddc?
> 
> Thanks.


Please post a screenshot showing that sensor. Are there also GPU VRM sensors reported ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Please post a screenshot showing that sensor. Are there also GPU VRM sensors reported ?


Here is the screenshot, there are no GPU VRM sensors:



Thanks.


----------



## Mumak

Hm, that really doesn't look like MVDDC. What is the value of MVDDC reported by HWiNFO in idle and load, is it 0.900 / 1.181 V ?
My guess is that it's indeed VDDCI.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Hm, that really doesn't look like MVDDC. What is the value of MVDDC reported by HWiNFO in idle and load, is it 0.900 / 1.181 V ?
> My guess is that it's indeed VDDCI.


This screenshot is with a bios OC-overvolt, with trixx or AB if you increase or decrease voltages, it isn't affected. Without bios OC or over-undervolt, or with trixx or AB without over-undervolt it is 0.900v in idle and ~1.125-1.130 with load.

It was talked here: http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/400 http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/430.

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> This screenshot is with a bios OC-overvolt, with trixx or AB if you increase or decrease voltages, it isn't affected. Without bios OC or over-undervolt, or with trixx or AB without over-undervolt it is 0.900v in idle and ~1.125-1.130 with load.
> 
> It was talked here: http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/400 http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/430.
> 
> Thanks.


Thanks. I will rename the "GPU Memory Voltage (MVDDC)", "GPU Memory Current" and "GPU Memory Power" to "GPU IO Voltage (VDDCI)", etc. in the next build.
Not sure if this is the correct naming, would "GPU Aux ..." be better perhaps ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I will rename the "GPU Memory Voltage (MVDDC)", "GPU Memory Current" and "GPU Memory Power" to "GPU IO Voltage (VDDCI)", etc. in the next build.
> Not sure if this is the correct naming, would "GPU Aux ..." be better perhaps ?


I don't know how to name it







, perhaps gupsterg or buildzoid know.

But I don't know if it is vddci-aux, in aida64's voltages dump is like VID, but maybe it is wrong. It can be changed in BIOS changing some offsets hex values related to vddgfx voltages which are related to vddc voltages, like you can see here: http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/430#post_25082448.

Thanks.


----------



## gupsterg

@Mumak

IR3567B on Hawaii, loop 1 is GPU VRM (VDDC) loop 2 is GPU AUX (VDDCI). AUX = VDDCI from what I'm aware of and info from reading The Stilt's posts. In Hawaii bios mod thread OP is 2 headings that I made with info for myself and others to ref:-

i) What is VDDCI (aka Aux Voltage)?
ii) How to edit Memory Interface Voltage (VDDCI/AUX Voltage) and associated RAM frequency

IR3567B on Fiji, loop 1 is GPU VRM (VDDC) loop 2 is HBM VRM (MVDDC).

I have never owned a Tonga card







, so my experience of Tonga is from my involvement in the Tonga bios mod thread. I conclude from posts by members that "GPU Memory Voltage (MVDDC)" and "GPU Memory Current" is VDDCI (V/A). Tonga has dynamic VDDCI IMO from:-

i) viewing the stock ROM PowerPlay "Platform Caps" post 405 has a screen shot where I used part of Linux driver to translate PowerPlay (do endian conversion on the yellow background hex).
ii) members posts with HWiNFO monitoring card there is variable VDDCI IMO.

I have not fully researched Tonga due to time limitations from being involved with Hawaii/Fiji bios mod, besides Tonga cards having NCP81022 it can have IR3567B. I recently saw example in Unwinder's thread on Guru3D, post 139 shows an Asus Strix R9 380 4GB with it. NCP81022 AFAIK does VDDC / VDDCI, MVDDC is done by another chip which has no advanced monitoring capability (ref'ing post 416 by Buildzoid).

Me and Buildzoid are merely padawans, the real Jedi Master is @The Stilt for AMD info







.


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> IR3567B on Hawaii, loop 1 is GPU VRM (VDDC) loop 2 is GPU AUX (VDDCI). AUX = VDDCI from what I'm aware of and info from reading The Stilt's posts. In Hawaii bios mod thread OP is 2 headings that I made with info for myself and others to ref:-
> 
> i) What is VDDCI (aka Aux Voltage)?
> ii) How to edit Memory Interface Voltage (VDDCI/AUX Voltage) and associated RAM frequency
> 
> IR3567B on Fiji, loop 1 is GPU VRM (VDDC) loop 2 is HBM VRM (MVDDC).
> 
> I have never owned a Tonga card
> 
> 
> 
> 
> 
> 
> 
> , so my experience of Tonga is from my involvement in the Tonga bios mod thread. I conclude from posts by members that "GPU Memory Voltage (MVDDC)" and "GPU Memory Current" is VDDCI (V/A). Tonga has dynamic VDDCI IMO from:-
> 
> i) viewing the stock ROM PowerPlay "Platform Caps" post 405 has a screen shot where I used part of Linux driver to translate PowerPlay (do endian conversion on the yellow background hex).
> ii) members posts with HWiNFO monitoring card there is variable VDDCI IMO.
> 
> I have not fully researched Tonga due to time limitations from being involved with Hawaii/Fiji bios mod, besides Tonga cards having NCP81022 it can have IR3567B. I recently saw example in Unwinder's thread on Guru3D, post 139 shows an Asus Strix R9 380 4GB with it. NCP81022 AFAIK does VDDC / VDDCI, MVDDC is done by another chip which has no advanced monitoring capability (ref'ing post 416 by Buildzoid).
> 
> Me and Buildzoid are merely padawans, the real Jedi Master is @The Stilt for AMD info
> 
> 
> 
> 
> 
> 
> 
> .


Thanks for the exhausting information !
So for all Hawaii I will rename the 2nd phase to "GPU Aux (VDDCI)".
Based on some reports I got, the NCP81022 on Tonga and Bonaire indeed seem to act dynamic, but since the values reported can go up-to 1.2V, I'm not 100% sure whether it's VDDCI.
Also, I can read the voltages from two sources: I2C VRM devices and internal GPU telemetry data. On Fiji the 2 telemetry sources correlate with 2 VRM loops, but not sure about the NCP81022 (1st telemetry is probably VDDC, the second _might_ be VDDCI).

Perhaps @The Stilt will comment on this too...


----------



## gupsterg

No worries







, always willing to participate in furthering development of HWiNFO







.

IMO the best app for monitoring and my 1st choice







, much







for HWiNFO and your support is PHENOMENAL!







.

Just getting ready a 2nd donation for HWiNFO and would encourage all to make one by Martin Malik's site via the donation button.


----------



## Mumak

Thanks


----------



## alt7

Hello Mumak: I posted a question to you about red vs green bars in the "cores" graph in the upper right corner of your program - post #1152 and you responded at post # 1153. I just discovered something this morning about those bars. I was tinkering and changed my power options from performance to balanced. Two things happened. #1.Those red bars turned green and #2. My voltage dropped at idle from about 1.17 to less than 1 volt. I'm not sure that changes your response but it does possibly explain why the bars changed.


----------



## Mumak

Quote:


> Originally Posted by *alt7*
> 
> Hello Mumak: I posted a question to you about red vs green bars in the "cores" graph in the upper right corner of your program - post #1152 and you responded at post # 1153. I just discovered something this morning about those bars. I was tinkering and changed my power options from performance to balanced. Two things happened. #1.Those red bars turned green and #2. My voltage dropped at idle from about 1.17 to less than 1 volt. I'm not sure that changes your response but it does possibly explain why the bars changed.


Balanced mode will put the CPU in lower P-States when idle (lower clock+VID), so that's what actually happened.
Watch your clocks/multipliers while idle or under load


----------



## mynm

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> IR3567B on Hawaii, loop 1 is GPU VRM (VDDC) loop 2 is GPU AUX (VDDCI). AUX = VDDCI from what I'm aware of and info from reading The Stilt's posts. In Hawaii bios mod thread OP is 2 headings that I made with info for myself and others to ref:-
> 
> i) What is VDDCI (aka Aux Voltage)?
> ii) How to edit Memory Interface Voltage (VDDCI/AUX Voltage) and associated RAM frequency
> 
> IR3567B on Fiji, loop 1 is GPU VRM (VDDC) loop 2 is HBM VRM (MVDDC).
> 
> I have never owned a Tonga card
> 
> 
> 
> 
> 
> 
> 
> , so my experience of Tonga is from my involvement in the Tonga bios mod thread. I conclude from posts by members that "GPU Memory Voltage (MVDDC)" and "GPU Memory Current" is VDDCI (V/A). Tonga has dynamic VDDCI IMO from:-
> 
> i) viewing the stock ROM PowerPlay "Platform Caps" post 405 has a screen shot where I used part of Linux driver to translate PowerPlay (do endian conversion on the yellow background hex).
> ii) members posts with HWiNFO monitoring card there is variable VDDCI IMO.
> 
> I have not fully researched Tonga due to time limitations from being involved with Hawaii/Fiji bios mod, besides Tonga cards having NCP81022 it can have IR3567B. I recently saw example in Unwinder's thread on Guru3D, post 139 shows an Asus Strix R9 380 4GB with it. NCP81022 AFAIK does VDDC / VDDCI, MVDDC is done by another chip which has no advanced monitoring capability (ref'ing post 416 by Buildzoid).
> 
> Me and Buildzoid are merely padawans, the real Jedi Master is @The Stilt for AMD info
> 
> 
> 
> 
> 
> 
> 
> .


Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the exhausting information !
> So for all Hawaii I will rename the 2nd phase to "GPU Aux (VDDCI)".
> Based on some reports I got, the NCP81022 on Tonga and Bonaire indeed seem to act dynamic, but since the values reported can go up-to 1.2V, I'm not 100% sure whether it's VDDCI.
> Also, I can read the voltages from two sources: I2C VRM devices and internal GPU telemetry data. On Fiji the 2 telemetry sources correlate with 2 VRM loops, but not sure about the NCP81022 (1st telemetry is probably VDDC, the second _might_ be VDDCI).
> 
> Perhaps @The Stilt will comment on this too...


It can go higher than 1.2v, for example here (this is a 285) http://www.overclock.net/t/1563409/software-for-r9-285-bios-edit/370#post_24994778:, you can see on the screenshot http://cdn.overclock.net/2/23/236f61b2_bios.png the way he had mod the bios, and that Hwinfo is showing two gpu voltages and the mvddc with a max of 1.263v.

I think that the first GPU voltage is vddgfx (Table 2), vddc is vddc (Table 1), and mvddc is aida64 vid (like you can see in the first spoiler). Same of these three values are related between then.

The problem is that if mvvdc is vddci, going over 1.2v is dangerous. And the question is, if it is a vid, is going over 1.2v dangerous?. This is the main problem when OCing by BIOS, and with AfterBurner with PowerPlay Support.


----------



## Mumak

I'm not sure, but my guess is that the MVDDC currently shown is not the VID, as this comes from internal telemetry. It would be quite odd if that would measure the VID requests...


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> I'm not sure, but my guess is that the MVDDC currently shown is not the VID, as this comes from internal telemetry. It would be quite odd if that would measure the VID requests...


Thanks, this is strange a vddci of 1.26v is very high, it may break gpu, and it isn't. Like gupsterg said maybe The Stilt or Unwinder knows what is it.


----------



## gupsterg

I agree for VDDCI to be that high would be GPU killing. It definitely is not MVDDC. Then it does seem to fit VDDGFX, which then confuses me as I would think VDDC==VDDGFX. The CAC records within those tables also confuses me. I will try to make a translated screenie of Tonga & Fiji PP VDDC/VDDGFX sections this weekend.

The PowerPlay between Tonga/Fiji is so similar and we see Fiji PP is translated within Tonga pptable.h of Linux driver.

IIRC Tonga registers dumps do show VDDGFX? but Fiji does not.

As much as confused by all this I'm also intrigued by it







, would be good to get to the bottom of it







.


----------



## The Stilt

On Bonaire, Hawaii and Tonga based cards the second voltage controlled by the same controller as VDDC is always VDDCI, no matter which controller (IR, OnSemi) is used. This is because these cards use SVI2 and VDDC & VDDCI are controlled through SVI2. On Fiji where VDDCI doesn't exist, the secondary voltage on this controller is MVDDC (HBM). Bonaire is the first ASIC to use SVI2.

I've checked on Bonaire / Tobago and HWInfo 5.24 indeed labels VDDCI wrong on these cards (as MVDDC). The MVDDC on these cards is fixed and the controller has no data interface to read the voltage.


----------



## Mumak

Quote:


> Originally Posted by *The Stilt*
> 
> On Bonaire, Hawaii and Tonga based cards the second voltage controlled by the same controller as VDDC is always VDDCI, no matter which controller (IR, OnSemi) is used. This is because these cards use SVI2 and VDDC & VDDCI are controlled through SVI2. On Fiji where VDDCI doesn't exist, the secondary voltage on this controller is MVDDC (HBM). Bonaire is the first ASIC to use SVI2.
> 
> I've checked on Bonaire / Tobago and HWInfo 5.24 indeed labels VDDCI wrong on these cards (as MVDDC). The MVDDC on these cards is fixed and the controller has no data interface to read the voltage.


Thanks, that makes perfect sense to me ! The telemetry info I use is for SVI2, so it must be VDDCI then.
I have changed the naming, just haven't released a new public Beta build yet.
For those who can't wait, here's an intermediate build of HWiNFO64: http://www.hwinfo.com/beta/hw64_525_2852.zip


----------



## mynm

Quote:


> Originally Posted by *gupsterg*
> 
> I agree for VDDCI to be that high would be GPU killing. It definitely is not MVDDC. Then it does seem to fit VDDGFX, which then confuses me as I would think VDDC==VDDGFX. The CAC records within those tables also confuses me. I will try to make a translated screenie of Tonga & Fiji PP VDDC/VDDGFX sections this weekend.
> 
> The PowerPlay between Tonga/Fiji is so similar and we see Fiji PP is translated within Tonga pptable.h of Linux driver.
> 
> IIRC Tonga registers dumps do show VDDGFX? but Fiji does not.
> 
> As much as confused by all this I'm also intrigued by it
> 
> 
> 
> 
> 
> 
> 
> , would be good to get to the bottom of it
> 
> 
> 
> 
> 
> 
> 
> .


Quote:


> Originally Posted by *The Stilt*
> 
> On Bonaire, Hawaii and Tonga based cards the second voltage controlled by the same controller as VDDC is always VDDCI, no matter which controller (IR, OnSemi) is used. This is because these cards use SVI2 and VDDC & VDDCI are controlled through SVI2. On Fiji where VDDCI doesn't exist, the secondary voltage on this controller is MVDDC (HBM). Bonaire is the first ASIC to use SVI2.
> 
> I've checked on Bonaire / Tobago and HWInfo 5.24 indeed labels VDDCI wrong on these cards (as MVDDC). The MVDDC on these cards is fixed and the controller has no data interface to read the voltage.


Quote:


> Originally Posted by *Mumak*
> 
> Thanks, that makes perfect sense to me ! The telemetry info I use is for SVI2, so it must be VDDCI then.
> I have changed the naming, just haven't released a new public Beta build yet.
> For those who can't wait, here's an intermediate build of HWiNFO64: http://www.hwinfo.com/beta/hw64_525_2852.zip


Thanks to all.

So it is vddci in your opinion. Is it dangerous going over 1.2v vddci?. If it is dangerous, is dangerous OCing by BIOS without chaning usvddcoffsets in PowerPlayTable, and with AfterBurner with PowerPlay Support.
Quote:


> Originally Posted by *gupsterg*
> 
> IIRC Tonga registers dumps do show VDDGFX? but Fiji does not.


Yes, it is showing vddgfx.
Quote:


> Originally Posted by *Mumak*
> 
> For those who can't wait, here's an intermediate build of HWiNFO64: http://www.hwinfo.com/beta/hw64_525_2852.zip


Thanks







. Now I see GPU core voltage (VDDC) and GPU aux voltage (VDDCI), but I don't see GPU voltage like in 285 screenshot.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> . Now I see GPU core voltage (VDDC) and GPU aux voltage (VDDCI), but I don't see GPU voltage like in 285 screenshot.


Which exact GPU voltage you don't see now? Isn't it the voltage from NCP81022 ?
Can you post a screenshot of both GPU sensors using the latest build ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Which exact GPU voltage you don't see now? Isn't it the voltage from NCP81022 ?
> Can you post a screenshot of both GPU sensors using the latest build ?


I only have an 380, the 285 is of another one.

I only see two voltages.



285 was showing three: http://cdn.overclock.net/2/23/236f61b2_bios.png.

Thanks.


----------



## gupsterg

@The Stilt

+rep and thanks for your time







.

@Mumak

The card that mynm is referring to is a Gigabyte R9 285 owned by @Ansau.


Spoiler: marked screenie







@mynm

I think unless Mumak gets a debug file from Ansau it maybe difficult to know what's going on.


----------



## Mumak

I believe the "GPU Voltage" on the 285 screenshot is the output of the GPU Core VRM (read via I2C). That item is by default shown under the respective VRM sensor, but has been moved by the user to the above sensor


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> I believe the "GPU Voltage" on the 285 screenshot is the output of the GPU Core VRM (read via I2C). That item is by default shown under the respective VRM sensor, but has been moved by the user to the above sensor


Ok thanks, I don't see VRM sensors, so I can't see that voltage.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Ok thanks, I don't see VRM sensors, so I can't see that voltage.


That depends on whether your GPU has a Digital PWM, if it doesn't then it cannot monitor the VRM values.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> That depends on whether your GPU has a Digital PWM, if it doesn't then it cannot monitor the VRM values.


Thanks. I don't know if it has a Digital PWM. Is this gpu: http://cxzoid.blogspot.com.es/search/label/R9%20380.

Aida64 SMBus dump is:


Spoiler: Warning: Spoiler!



Code:



Code:


------[ AIDA64 Extreme v5.70.3800 ]------

------[ Microsoft Windows 10 Pro 10.0.10586.218 (64-bit) ]------

------[ Video Adapters ]------

Sapphire Radeon R9 380 [1002-6939 / 174B-E308]

------[ Video Driver ]------

aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25

------[ ATI I2C Device GPU #1 / B02-D37 ]------

  0000  E0 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E  ................
  0010  0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E  ................
  0020  1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E  . !"#$%&'()*+,-.
  0030  2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E  /0123456789:;<=>
  0040  3F 40 41 00 43 44 45 46 47 48 49 4A 4B 4C 4D 4E  [email protected]
  0050  4F 50 51 52 53 54 55 56 00 58 59 5A 5B 5C 5D 00  OPQRSTUV.XYZ[\].
  0060  5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 00  _`abcdefghijklm.
  0070  6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 00 7E  opqrstuvwxyz{|.~
  0080  7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E  ...............
  0090  8F 90 91 92 00 94 95 96 97 98 99 9A 9B 9C 9D 00  ................
  00A0  9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE  ................
  00B0  AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE  ................
  00C0  BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 00 CB CC CD CE  ................
  00D0  CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE  ................
  00E0  DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE  ................
  00F0  EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE  ................

------[ ATI I2C Device GPU #1 / B02-D37 ]------

  0000  6DFF 6D00 6D01 6D02 6D03 6D04 6D05 6D06 6D07 6D08 6D09 6D0A 6D0B 6D0C 6D0D 6D0E 
  0010  6D0F 6D10 6D11 6D12 6D13 6D14 6D00 6D16 6D17 6D18 6D00 6D1A 6D1B 6D1C 6D1D 6D1E 
  0020  6D1F 6D20 6D21 6D22 6D23 6D24 6D25 6D26 6D27 6D28 6D29 6D2A 6D2B 6D2C 6D2D 6D2E 
  0030  6D2F 6D30 6D31 6D32 6D33 6D34 6D35 6D36 6D37 6D38 6D39 6D3A 6D3B 6D3C 6D3D 6D3E 
  0040  6D3F 6D40 6D41 6D42 6D43 6D44 6D45 6D46 6D47 6D48 6D49 6D4A 6D4B 6D4C 6D4D 6D4E 
  0050  6D4F 6D50 6D00 6D52 6D53 6D54 6D55 6D56 6D57 6D58 6D59 6D5A 6D5B 6D5C 6D5D 6D5E 
  0060  6D5F 6D60 6D61 6D62 6D63 6D64 6D65 6D66 6D67 6D68 6D69 6D6A 6D6B 6D6C 6D6D 6D6E 
  0070  6D6F 6D70 6D71 6D72 6D73 6D74 6D75 6D76 6D77 6D78 6D79 6D7A 6D7B 6D7C 6D7D 6D7E 
  0080  6D7F 6D80 6D81 6D82 6D83 6D84 6D85 6D86 6D87 6D88 6D89 6D8A 6D8B 6D8C 6D8D 6D8E 
  0090  6D8F 6D00 6D91 6D92 6D93 6D94 6D95 6D96 6D97 6D98 6D99 6D9A 6D9B 6D9C 6D9D 6D9E 
  00A0  6D9F 6DA0 6DA1 6DA2 6DA3 6DA4 6DA5 6DA6 6DA7 6DA8 6DA9 6DAA 6DAB 6DAC 6DAD 6DAE 
  00B0  6DAF 6DB0 6DB1 6DB2 6D00 6DB4 6DB5 6DB6 6DB7 6DB8 6DB9 6DBA 6DBB 6DBC 6DBD 6D00 
  00C0  6DBF 6DC0 6DC1 6DC2 6DC3 6DC4 6DC5 6DC6 6DC7 6DC8 6D00 6DCA 6DCB 6DCC 6DCD 6DCE 
  00D0  6DCF 6DD0 6DD1 6DD2 6DD3 6DD4 6DD5 6DD6 6DD7 6DD8 6DD9 6DDA 6DDB 6DDC 6DDD 6DDE 
  00E0  6DDF 6DE0 6DE1 6DE2 6DE3 6D00 6DE5 6DE6 6DE7 6DE8 6DE9 6D00 6DEB 6DEC 6DED 6DEE 
  00F0  6DEF 6DF0 6DF1 6DF2 6DF3 6DF4 6DF5 6DF6 6DF7 6DF8 6DF9 6DFA 6DFB 6DFC 6DFD 6DFE

------[ ATI I2C Device GPU #1 / B02-D3A ]------

  0000  B4 F8 B1 E4 1C 00 00 00 43 BE 43 00 00 00 00 00  ........C.C.....
  0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0040  80 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  00F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

------[ ATI I2C Device GPU #1 / B02-D3A ]------

  0000  6DB4 6DF8 6DB1 6DE4 6D1C 6D00 6D00 6D00 6D43 6DBE 6D43 6D00 6D00 6D00 6D00 6D00 
  0010  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0020  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0030  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0040  6D80 6D00 6D10 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0050  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0060  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0070  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0080  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  0090  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00A0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00B0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00C0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00D0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00E0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00F0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00

------[ ATI I2C Device GPU #1 / B02-D50 ]------

  0000  00 FF FF FF FF FF FF 00 1E 6D DA 58 01 01 01 01  .........m.X....
  0010  01 15 01 03 80 33 1D 78 EA C6 65 A0 59 58 9D 27  .....3.x..e.YX.'
  0020  0E 50 54 21 08 00 B3 00 81 80 81 40 71 40 01 01  [email protected]@..
  0030  01 01 01 01 01 01 02 3A 80 18 71 38 2D 40 58 2C  .......:[email protected],
  0040  45 00 FE 22 11 00 00 1E 00 00 00 FD 00 38 3D 1E  E..".........8=.
  0050  53 0F 00 0A 20 20 20 20 20 20 00 00 00 FC 00 49  S...      .....I
  0060  50 53 32 33 34 0A 20 20 20 20 20 20 00 00 00 FF  PS234.      ....
  0070  00 0A 20 20 20 20 20 20 20 20 20 20 20 20 01 1D  ..            ..
  0080  02 03 1D F1 4A 90 04 03 01 14 12 05 1F 10 13 23  ....J..........#
  0090  09 07 07 83 01 00 00 65 03 0C 00 10 00 02 3A 80  .......e......:.
  00A0  18 71 38 2D 40 58 2C 45 00 FE 22 11 00 00 1E 01  [email protected],E..".....
  00B0  1D 80 18 71 1C 16 20 58 2C 25 00 FE 22 11 00 00  ...q.. X,%.."...
  00C0  9E 01 1D 00 72 51 D0 1E 20 6E 28 55 00 FE 22 11  ....rQ.. n(U..".
  00D0  00 00 1E 8C 0A D0 8A 20 E0 2D 10 10 3E 96 00 FE  ....... .-..>...
  00E0  22 11 00 00 18 00 00 00 00 00 00 00 00 00 00 00  "...............
  00F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E6  ................

------[ ATI I2C Device GPU #1 / B02-D50 ]------

  0000  6D00 6DFF 6DFF 6DFF 6DFF 6DFF 6DFF 6D00 6D1E 6D6D 6DDA 6D58 6D01 6D01 6D01 6D01 
  0010  6D01 6D15 6D01 6D03 6D80 6D33 6D1D 6D78 6DEA 6DC6 6D65 6DA0 6D59 6D58 6D9D 6D27 
  0020  6D0E 6D50 6D54 6D21 6D08 6D00 6DB3 6D00 6D81 6D80 6D81 6D40 6D71 6D40 6D01 6D01 
  0030  6D01 6D01 6D01 6D01 6D01 6D01 6D02 6D3A 6D80 6D18 6D71 6D38 6D2D 6D40 6D58 6D2C 
  0040  6D45 6D00 6DFE 6D22 6D11 6D00 6D00 6D1E 6D00 6D00 6D00 6DFD 6D00 6D38 6D3D 6D1E 
  0050  6D53 6D0F 6D00 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D00 6D00 6D00 6DFC 6D00 6D49 
  0060  6D50 6D53 6D32 6D33 6D34 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D00 6D00 6D00 6DFF 
  0070  6D00 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D01 6D1D 
  0080  6D02 6D03 6D1D 6DF1 6D4A 6D90 6D04 6D03 6D01 6D14 6D12 6D05 6D1F 6D10 6D13 6D23 
  0090  6D09 6D07 6D07 6D83 6D01 6D00 6D00 6D65 6D03 6D0C 6D00 6D10 6D00 6D02 6D3A 6D80 
  00A0  6D18 6D71 6D38 6D2D 6D40 6D58 6D2C 6D45 6D00 6DFE 6D22 6D11 6D00 6D00 6D1E 6D01 
  00B0  6D1D 6D80 6D18 6D71 6D1C 6D16 6D20 6D58 6D2C 6D25 6D00 6DFE 6D22 6D11 6D00 6D00 
  00C0  6D9E 6D01 6D1D 6D00 6D72 6D51 6DD0 6D1E 6D20 6D6E 6D28 6D55 6D00 6DFE 6D22 6D11 
  00D0  6D00 6D00 6D1E 6D8C 6D0A 6DD0 6D8A 6D20 6DE0 6D2D 6D10 6D10 6D3E 6D96 6D00 6DFE 
  00E0  6D22 6D11 6D00 6D00 6D18 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 
  00F0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6DE6

------[ ATI I2C Device GPU #1 / B06-D24 ]------

  0000  FF 80 17 7F FF FF FF FF FF FF FF FF FF FF FF FF  ...............
  0010  00 FF FF FF FF FF FF FF FF B0 FF FF FF FF FF FF  ................
  0020  22 00 FF FF 00 18 A8 FF FF FF FF FF FF FF FF FF  "...............
  0030  FF FF FF FF FF FF FF FF 01 00 FF FF FF FF FF FF  ................
  0040  FF FF FF FF FF FF FF FF FF FF 64 FF FF FF FF 55  ..........d....U
  0050  FF 46 00 64 FF 10 FF FF FF FF FF FF FF FF FF FF  .F.d............
  0060  FF FF FF FF FF FF FF FF 2C FF FF FF FF FF FF FF  ........,.......
  0070  FF FF FF FF FF FF FF FF 00 00 00 00 00 00 FF FF  ................
  0080  FF FF FF FF FF FF FF FF E8 FF FF 3F F0 00 FF FF  ...........?....
  0090  FF FF FF FF FF FF 5C FF FF 1A 22 03 FF FF FF FF  ......\...".....
  00A0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
  00B0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
  00C0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
  00D0  00 01 00 03 50 02 00 FF FF FF 01 FF FF FF FF FF  ....P...........
  00E0  FF 00 00 02 03 03 00 3D FF FF FF FF FF FF FF FF  .......=........
  00F0  FF FF FF 68 FF FF FF 0A BC 9C FF 07 FF 0F FF FF  ...h............

------[ ATI I2C Device GPU #1 / B06-D24 ]------

  0000  FFFF 2F80 7E17 FF7F FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  0010  6F00 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 4CB0 FFFF FFFF FFFF FFFF FFFF FFFF 
  0020  6022 0000 FFFF FFFF 0000 0018 00A8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  0030  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0001 0000 FFFF FFFF FFFF FFFF FFFF FFFF 
  0040  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0064 FFFF FFFF FFFF FFFF 0055 
  0050  FFFF 0046 0000 0064 FFFF 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  0060  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 012C FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  0070  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FB00 0000 2D00 4600 5000 3B00 FFFF FFFF 
  0080  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF D2E8 FFFF FFFF 013F A2F0 0000 FFFF FFFF 
  0090  FFFF FFFF FFFF FFFF FFFF FFFF A365 FFFF FFFF 001A 1022 8103 FFFF FFFF FFFF FFFF 
  00A0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  00B0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  00C0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  00D0  E200 8E01 3400 5603 BA51 2C02 9F00 FFFF FFFF FFFF 6201 FFFF FFFF FFFF FFFF FFFF 
  00E0  FFFF 6800 D500 B002 A103 CA03 7E00 003D FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 
  00F0  FFFF FFFF FFFF 0368 FFFF FFFF FFFF 810A F5BC F29C FFFF 5807 FFFF 1D0F FFFF FFFF

------[ Chips Found ]------

GPU1-B02-D3A: ***** Unknown Device *****
GPU1-B02-D50: EDID
GPU1-B06-D24: ***** Unknown Device *****

Total   :  152.4 sec
GPU1-B00:    4.8 sec
GPU1-B01:    4.8 sec
GPU1-B02:   53.2 sec
GPU1-B03:    4.8 sec
GPU1-B04:   36.2 sec
GPU1-B05:   36.1 sec
GPU1-B06:    5.7 sec
GPU1-B07:    4.8 sec


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Thanks. I don't know if it has a Digital PWM. Is this gpu: http://cxzoid.blogspot.com.es/search/label/R9%20380.
> 
> Aida64 SMBus dump is:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> Code:
> 
> 
> 
> Code:
> 
> 
> ------[ AIDA64 Extreme v5.70.3800 ]------
> 
> ------[ Microsoft Windows 10 Pro 10.0.10586.218 (64-bit) ]------
> 
> ------[ Video Adapters ]------
> 
> Sapphire Radeon R9 380 [1002-6939 / 174B-E308]
> 
> ------[ Video Driver ]------
> 
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||aticfx64||8.17.10.1452|||amdxc64||8.18.10.0118|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||aticfx32||8.17.10.1452|||amdxc32||8.18.10.0118|||atiumd64||9.14.10.01183|||atidxx64||8.17.10.0661|||atidxx64||8.17.10.0661|||atiumdag||9.14.10.01183 - AMD Radeon Software Crimson 16.3 Hotfix|||atidxx32||8.17.10.0661|||atidxx32||8.17.10.0661|||atiumdva||8.14.10.0546|||atiumd6a||8.14.10.0546|||atitmm64||6.14.11.25
> 
> ------[ ATI I2C Device GPU #1 / B02-D37 ]------
> 
> 0000  E0 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E  ................
> 0010  0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E  ................
> 0020  1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E  . !"#$%&'()*+,-.
> 0030  2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E  /0123456789:;<=>
> 0040  3F 40 41 00 43 44 45 46 47 48 49 4A 4B 4C 4D 4E  [email protected]
> 0050  4F 50 51 52 53 54 55 56 00 58 59 5A 5B 5C 5D 00  OPQRSTUV.XYZ[\].
> 0060  5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 00  _`abcdefghijklm.
> 0070  6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 00 7E  opqrstuvwxyz{|.~
> 0080  7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E  ...............
> 0090  8F 90 91 92 00 94 95 96 97 98 99 9A 9B 9C 9D 00  ................
> 00A0  9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE  ................
> 00B0  AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE  ................
> 00C0  BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 00 CB CC CD CE  ................
> 00D0  CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE  ................
> 00E0  DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE  ................
> 00F0  EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE  ................
> 
> ------[ ATI I2C Device GPU #1 / B02-D37 ]------
> 
> 0000  6DFF 6D00 6D01 6D02 6D03 6D04 6D05 6D06 6D07 6D08 6D09 6D0A 6D0B 6D0C 6D0D 6D0E
> 0010  6D0F 6D10 6D11 6D12 6D13 6D14 6D00 6D16 6D17 6D18 6D00 6D1A 6D1B 6D1C 6D1D 6D1E
> 0020  6D1F 6D20 6D21 6D22 6D23 6D24 6D25 6D26 6D27 6D28 6D29 6D2A 6D2B 6D2C 6D2D 6D2E
> 0030  6D2F 6D30 6D31 6D32 6D33 6D34 6D35 6D36 6D37 6D38 6D39 6D3A 6D3B 6D3C 6D3D 6D3E
> 0040  6D3F 6D40 6D41 6D42 6D43 6D44 6D45 6D46 6D47 6D48 6D49 6D4A 6D4B 6D4C 6D4D 6D4E
> 0050  6D4F 6D50 6D00 6D52 6D53 6D54 6D55 6D56 6D57 6D58 6D59 6D5A 6D5B 6D5C 6D5D 6D5E
> 0060  6D5F 6D60 6D61 6D62 6D63 6D64 6D65 6D66 6D67 6D68 6D69 6D6A 6D6B 6D6C 6D6D 6D6E
> 0070  6D6F 6D70 6D71 6D72 6D73 6D74 6D75 6D76 6D77 6D78 6D79 6D7A 6D7B 6D7C 6D7D 6D7E
> 0080  6D7F 6D80 6D81 6D82 6D83 6D84 6D85 6D86 6D87 6D88 6D89 6D8A 6D8B 6D8C 6D8D 6D8E
> 0090  6D8F 6D00 6D91 6D92 6D93 6D94 6D95 6D96 6D97 6D98 6D99 6D9A 6D9B 6D9C 6D9D 6D9E
> 00A0  6D9F 6DA0 6DA1 6DA2 6DA3 6DA4 6DA5 6DA6 6DA7 6DA8 6DA9 6DAA 6DAB 6DAC 6DAD 6DAE
> 00B0  6DAF 6DB0 6DB1 6DB2 6D00 6DB4 6DB5 6DB6 6DB7 6DB8 6DB9 6DBA 6DBB 6DBC 6DBD 6D00
> 00C0  6DBF 6DC0 6DC1 6DC2 6DC3 6DC4 6DC5 6DC6 6DC7 6DC8 6D00 6DCA 6DCB 6DCC 6DCD 6DCE
> 00D0  6DCF 6DD0 6DD1 6DD2 6DD3 6DD4 6DD5 6DD6 6DD7 6DD8 6DD9 6DDA 6DDB 6DDC 6DDD 6DDE
> 00E0  6DDF 6DE0 6DE1 6DE2 6DE3 6D00 6DE5 6DE6 6DE7 6DE8 6DE9 6D00 6DEB 6DEC 6DED 6DEE
> 00F0  6DEF 6DF0 6DF1 6DF2 6DF3 6DF4 6DF5 6DF6 6DF7 6DF8 6DF9 6DFA 6DFB 6DFC 6DFD 6DFE
> 
> ------[ ATI I2C Device GPU #1 / B02-D3A ]------
> 
> 0000  B4 F8 B1 E4 1C 00 00 00 43 BE 43 00 00 00 00 00  ........C.C.....
> 0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0040  80 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0080  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 0090  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00C0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00D0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 
> ------[ ATI I2C Device GPU #1 / B02-D3A ]------
> 
> 0000  6DB4 6DF8 6DB1 6DE4 6D1C 6D00 6D00 6D00 6D43 6DBE 6D43 6D00 6D00 6D00 6D00 6D00
> 0010  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0020  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0030  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0040  6D80 6D00 6D10 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0050  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0060  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0070  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0080  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 0090  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00A0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00B0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00C0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00D0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00E0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00F0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 
> ------[ ATI I2C Device GPU #1 / B02-D50 ]------
> 
> 0000  00 FF FF FF FF FF FF 00 1E 6D DA 58 01 01 01 01  .........m.X....
> 0010  01 15 01 03 80 33 1D 78 EA C6 65 A0 59 58 9D 27  .....3.x..e.YX.'
> 0020  0E 50 54 21 08 00 B3 00 81 80 81 40 71 40 01 01  [email protected]@..
> 0030  01 01 01 01 01 01 02 3A 80 18 71 38 2D 40 58 2C  .......:[email protected],
> 0040  45 00 FE 22 11 00 00 1E 00 00 00 FD 00 38 3D 1E  E..".........8=.
> 0050  53 0F 00 0A 20 20 20 20 20 20 00 00 00 FC 00 49  S...      .....I
> 0060  50 53 32 33 34 0A 20 20 20 20 20 20 00 00 00 FF  PS234.      ....
> 0070  00 0A 20 20 20 20 20 20 20 20 20 20 20 20 01 1D  ..            ..
> 0080  02 03 1D F1 4A 90 04 03 01 14 12 05 1F 10 13 23  ....J..........#
> 0090  09 07 07 83 01 00 00 65 03 0C 00 10 00 02 3A 80  .......e......:.
> 00A0  18 71 38 2D 40 58 2C 45 00 FE 22 11 00 00 1E 01  [email protected],E..".....
> 00B0  1D 80 18 71 1C 16 20 58 2C 25 00 FE 22 11 00 00  ...q.. X,%.."...
> 00C0  9E 01 1D 00 72 51 D0 1E 20 6E 28 55 00 FE 22 11  ....rQ.. n(U..".
> 00D0  00 00 1E 8C 0A D0 8A 20 E0 2D 10 10 3E 96 00 FE  ....... .-..>...
> 00E0  22 11 00 00 18 00 00 00 00 00 00 00 00 00 00 00  "...............
> 00F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E6  ................
> 
> ------[ ATI I2C Device GPU #1 / B02-D50 ]------
> 
> 0000  6D00 6DFF 6DFF 6DFF 6DFF 6DFF 6DFF 6D00 6D1E 6D6D 6DDA 6D58 6D01 6D01 6D01 6D01
> 0010  6D01 6D15 6D01 6D03 6D80 6D33 6D1D 6D78 6DEA 6DC6 6D65 6DA0 6D59 6D58 6D9D 6D27
> 0020  6D0E 6D50 6D54 6D21 6D08 6D00 6DB3 6D00 6D81 6D80 6D81 6D40 6D71 6D40 6D01 6D01
> 0030  6D01 6D01 6D01 6D01 6D01 6D01 6D02 6D3A 6D80 6D18 6D71 6D38 6D2D 6D40 6D58 6D2C
> 0040  6D45 6D00 6DFE 6D22 6D11 6D00 6D00 6D1E 6D00 6D00 6D00 6DFD 6D00 6D38 6D3D 6D1E
> 0050  6D53 6D0F 6D00 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D00 6D00 6D00 6DFC 6D00 6D49
> 0060  6D50 6D53 6D32 6D33 6D34 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D00 6D00 6D00 6DFF
> 0070  6D00 6D0A 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D20 6D01 6D1D
> 0080  6D02 6D03 6D1D 6DF1 6D4A 6D90 6D04 6D03 6D01 6D14 6D12 6D05 6D1F 6D10 6D13 6D23
> 0090  6D09 6D07 6D07 6D83 6D01 6D00 6D00 6D65 6D03 6D0C 6D00 6D10 6D00 6D02 6D3A 6D80
> 00A0  6D18 6D71 6D38 6D2D 6D40 6D58 6D2C 6D45 6D00 6DFE 6D22 6D11 6D00 6D00 6D1E 6D01
> 00B0  6D1D 6D80 6D18 6D71 6D1C 6D16 6D20 6D58 6D2C 6D25 6D00 6DFE 6D22 6D11 6D00 6D00
> 00C0  6D9E 6D01 6D1D 6D00 6D72 6D51 6DD0 6D1E 6D20 6D6E 6D28 6D55 6D00 6DFE 6D22 6D11
> 00D0  6D00 6D00 6D1E 6D8C 6D0A 6DD0 6D8A 6D20 6DE0 6D2D 6D10 6D10 6D3E 6D96 6D00 6DFE
> 00E0  6D22 6D11 6D00 6D00 6D18 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00
> 00F0  6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6D00 6DE6
> 
> ------[ ATI I2C Device GPU #1 / B06-D24 ]------
> 
> 0000  FF 80 17 7F FF FF FF FF FF FF FF FF FF FF FF FF  ...............
> 0010  00 FF FF FF FF FF FF FF FF B0 FF FF FF FF FF FF  ................
> 0020  22 00 FF FF 00 18 A8 FF FF FF FF FF FF FF FF FF  "...............
> 0030  FF FF FF FF FF FF FF FF 01 00 FF FF FF FF FF FF  ................
> 0040  FF FF FF FF FF FF FF FF FF FF 64 FF FF FF FF 55  ..........d....U
> 0050  FF 46 00 64 FF 10 FF FF FF FF FF FF FF FF FF FF  .F.d............
> 0060  FF FF FF FF FF FF FF FF 2C FF FF FF FF FF FF FF  ........,.......
> 0070  FF FF FF FF FF FF FF FF 00 00 00 00 00 00 FF FF  ................
> 0080  FF FF FF FF FF FF FF FF E8 FF FF 3F F0 00 FF FF  ...........?....
> 0090  FF FF FF FF FF FF 5C FF FF 1A 22 03 FF FF FF FF  ......\...".....
> 00A0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
> 00B0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
> 00C0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ................
> 00D0  00 01 00 03 50 02 00 FF FF FF 01 FF FF FF FF FF  ....P...........
> 00E0  FF 00 00 02 03 03 00 3D FF FF FF FF FF FF FF FF  .......=........
> 00F0  FF FF FF 68 FF FF FF 0A BC 9C FF 07 FF 0F FF FF  ...h............
> 
> ------[ ATI I2C Device GPU #1 / B06-D24 ]------
> 
> 0000  FFFF 2F80 7E17 FF7F FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 0010  6F00 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 4CB0 FFFF FFFF FFFF FFFF FFFF FFFF
> 0020  6022 0000 FFFF FFFF 0000 0018 00A8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 0030  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0001 0000 FFFF FFFF FFFF FFFF FFFF FFFF
> 0040  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0064 FFFF FFFF FFFF FFFF 0055
> 0050  FFFF 0046 0000 0064 FFFF 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 0060  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 012C FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 0070  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FB00 0000 2D00 4600 5000 3B00 FFFF FFFF
> 0080  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF D2E8 FFFF FFFF 013F A2F0 0000 FFFF FFFF
> 0090  FFFF FFFF FFFF FFFF FFFF FFFF A365 FFFF FFFF 001A 1022 8103 FFFF FFFF FFFF FFFF
> 00A0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 00B0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 00C0  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 00D0  E200 8E01 3400 5603 BA51 2C02 9F00 FFFF FFFF FFFF 6201 FFFF FFFF FFFF FFFF FFFF
> 00E0  FFFF 6800 D500 B002 A103 CA03 7E00 003D FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
> 00F0  FFFF FFFF FFFF 0368 FFFF FFFF FFFF 810A F5BC F29C FFFF 5807 FFFF 1D0F FFFF FFFF
> 
> ------[ Chips Found ]------
> 
> GPU1-B02-D3A: ***** Unknown Device *****
> GPU1-B02-D50: EDID
> GPU1-B06-D24: ***** Unknown Device *****
> 
> Total   :  152.4 sec
> GPU1-B00:    4.8 sec
> GPU1-B01:    4.8 sec
> GPU1-B02:   53.2 sec
> GPU1-B03:    4.8 sec
> GPU1-B04:   36.2 sec
> GPU1-B05:   36.1 sec
> GPU1-B06:    5.7 sec
> GPU1-B07:    4.8 sec


I can see the On Semi NCP81022 in the dump. This should be recognized by HWiNFO and you should see another GPU sensor beneath the main GPU one.
EDIT: Wait - this is probably not recognized.. I'll post a new build in a minute


----------



## Mumak

@mynm: try this build: www.hwinfo.com/beta/hw64_525_2853.zip
and let me know if you see a new sensor. If not, please post the HWiNFO Debug File.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> @mynm: try this build: www.hwinfo.com/beta/hw64_525_2853.zip
> and let me know if you see a new sensor. If not, please post the HWiNFO Debug File.


Yes, I see the new sensor. Thank you very much


----------



## LostParticle

Hey Martin, thanks for the latest version









I've observed a nice new feature when running my Hero VII, until a couple of days ago. "Experimental reporting of CPU current/power for some later ASUS mainboards."
Can you provide that for the ASRock motherboards, as well?
Can I help you, with my ASRock Z97 OC Formula, and IF so, how?
Finally, what does this value monitor exactly?

Thank you


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, thanks for the latest version
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I've observed a nice new feature when running my Hero VII, until a couple of days ago. "Experimental reporting of CPU current/power for some later ASUS mainboards."
> Can you provide that for the ASRock motherboards, as well?
> Can I help you, with my ASRock Z97 OC Formula, and IF so, how?
> Finally, what does this value monitor exactly?
> 
> Thank you


No, this is an ASUS-specific feature that's present only on some ASUS models and no others.
The implementation is proprietary, but I believe it monitors the VRIN current (on Haswell boards) or Vcore rail (Skylake). The advantage of this is that it can monitor whole CPU power consumption (HSW) when SVID is disabled (when OCing >125 MHz BCLK). The disadvantage is, that the current value reported is only integer, so no fine-grained reporting.


----------



## gupsterg

Working great on my Asus Maximus VII Ranger as well (done a few lengthy runs of [email protected])







, many thanks for this new reading







.

If I take the % by which vcore is lower than vccin and apply to new reading watts it's very close to CPU package power reading, so when SVID is disabled and I have no CPU package power reading it's handy as an approximation.


----------



## zednor

Is it normal to show 10c difference between highest core and cpu package????My CPU is i7 5820k and mobo MSI X99A Mpower(Nuvoton NCT6792D).At idle i get 30c core temp but 41c cpu package temp.Have i done something wrong?


----------



## Mumak

I have seen such a difference in the past, but I don't know why is that. It seems that either of those sensors is using a wrong offset.
30 C at idle seems more reasonable to me in case you have a good cooler.


----------



## zednor

Yea i got a Noctua NH-D15 so it is normal to get 30.It never goes above 65 though while core is 58 at max load with 27c ambient.Maybe its just the socket that gets hot?


----------



## Mumak

No, the socket cannot get so hot.
"CPU Package" temperature should represent a 256ms average of the hottest temperature among all sensors in the CPU.
My assumption is that this temperature doesn't properly utilize the Tj,max offset.


----------



## zednor

Quote:


> Originally Posted by *Mumak*
> 
> No, the socket cannot get so hot.
> "CPU Package" temperature should represent a 256ms average of the hottest temperature among all sensors in the CPU.
> My assumption is that this temperature doesn't properly utilize the Tj,max offset.


Can i give you a dump from HWinfo or do something so we can check it maybe?


----------



## Mumak

Quote:


> Originally Posted by *zednor*
> 
> Can i give you a dump from HWinfo or do something so we can check it maybe?


I'm afraid that won't help to determine which of those values is really correct.


----------



## Cakewalk_S

IS CPU Package power a better read to determine CPU power draw or would IA Cores Power be better?


----------



## Mumak

Yes, the "CPU Package Power" should be the total CPU power consumption. IA Cores Power accounts only for the x86 cores, so "CPU Package Power" ~ "IA Cores Power" + "IGPU power" + SA/uncore + all the other components in CPU.
But note, that those values do not work properly in case SVID is disabled (used commonly when OCing >125 MHz BCLK).


----------



## Cakewalk_S

Quote:


> Originally Posted by *Mumak*
> 
> Yes, the CPU Package Power should be much closer to total CPU power consumption.
> But note, that those values do not work properly in case SVID is disabled (used commonly when OCing >125 MHz BCLK).


So CPU Package Power would be good in determining how well the CPU cooler is doing by cooling the watts the CPU is pulling? I would imagine this wouldn't take into consideration total system consumption when looking at just CPU stress due to additional power draw from the memory and actual motherboard?

I need a kill-a-watt meter...


----------



## Mumak

"CPU Package Power" accounts only for CPU power - more precisely it's the current drawn by the CPU multiplied by actual voltage.
I don't think this is a good indicator of cooling, CPU Core/Package temperatures are the ideal indicator for that. Though as a secondary indicator to assess how much power (under a given load) is being cooled it might be useful.


----------



## dmfree88

I am a little confused I am fairly new to Intel but I noticed there is not actual turbo settings for the clock. I thought that with intel you set a main core clock and a turbo core clock if turbo is on. On this motherboard if i set turbo to off the core remains at stock 4.0ghz. If turbo is on then whatever I set all cores (or single cores) to is what it sets to. Sometimes however it will boost up to 4.9+ghz and I also see the bus clock jump to as high as 102.3 which of course increases clock of ram which always is reflected but it does not always reflect the bus clock increase in the CPU clocks as shown here at 101.3 bus is what it went to which it reflects the jump in the ram and pci-e clock but not in the uncore or the core:



I am not sure why it bumps it up or how to control turbo? Little confused and wondering if this is normal? Any help appreciated







. (build in signature, Intel overclocker)


----------



## LostParticle

Hey Martin, I'm facing something similar, meaning (anyway) I'd like to ask why my Bus + PCIe Clocks often derive from 100 MHz. I've explicitly set them at 100, in the BIOS. *Screenshot* taken a couple of hours ago. And of course, CPU Spread Spectrum is disabled. IF this is a software inaccuracy, please explain why it cannot get fixed (_because I assume that if it could get easily fixed you would have already done so_).

I'm also aware that disabling Periodic Polling would result in reading the Bus Clock only once and thus always keep it at 100 MHz. What I would like to know though is IF my BCLK + PCIe does actually fluctuate or not... Can you answer this for the i7-4790K?

Thank you.

PS: IF it helps, I'm telling you that in the screenshot my system is running a per-core OC.


----------



## Mumak

On all CPUs before Skylake, the BCLK is measured using software methods - there's no dedicated hardware logic that would measure it independent and then read by software. So it can happen that occasionally this measurement doesn't read precise data. This is because Windows is a multitasking system and if some other applications take a lot of resources this can have influence on HWiNFO relying on precise timing while measuring this clock.
This is different with Skylake, which finally allows hardware-assisted much more precise reading of BCLK (independent of other software).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> On all CPUs before Skylake, the BCLK is measured using software methods - there's no dedicated hardware logic that would measure it independent and then read by software. So it can happen that occasionally this measurement doesn't read precise data. This is because Windows is a multitasking system and if some other applications take a lot of resources this can have influence on HWiNFO relying on precise timing while measuring this clock.
> This is different with Skylake, which finally allows hardware-assisted much more precise reading of BCLK (independent of other software).


Thank you, Martin!

So, what I understand for my i7-4790K is that Intel is not providing an appropriate method for accurate BCLK detection / measurement and so it is not HWiNFO's fault for what we (occasionally) observe. I also perceive that if BCLK is explicitly set to 100 MHz in the BIOS, this "glitch" can be easily ignored and, IF inconvenient, Periodic Polling can be always disabled.

Keep up the good work!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thank you, Martin!
> 
> So, what I understand for my i7-4790K is that Intel is not providing an appropriate method for accurate BCLK detection / measurement and so it is not HWiNFO's fault for what we (occasionally) observe. I also perceive that if BCLK is explicitly set to 100 MHz in the BIOS, this "glitch" can be easily ignored and, IF inconvenient, Periodic Polling can be always disabled.
> 
> Keep up the good work!


Yes, exactly.


----------



## LostParticle

Quote:


> Originally Posted by *bluej511*
> 
> It is quite accurate however just like any software for monitoring its not totally accurate. However should always be taken with a grain of salt, we don't know how accurate the sensors themselves are or the tolerances.
> 
> VID shows accurately as 1.189 but vcore is actually 1.200 and thats the one i follow as i can measure with a dmm, intel stress test shows my voltage core as VID so in between programs it gets confusing and annoying.
> 
> Nothing beats actual measurement but it is what it is lol. For example, one of my VRMs in ALL programs shows as 19°C in a 23-24°C room so yea haha.


Sure, sure, as I already said, you can always create your own laboratory bench and connect your Home computer to all kinds of instruments to accurately monitor Voltages, Temperatures and whatever else you desire.









Me, I have measured the Voltages on my ASRock Z97 OC Formula with my DMM and I have found them equal to what HWiNFO64 was showing, at that time.









As for that VRM of yours, which ALL the programs show it at 19 C, blah-blah, perhaps it is your motherboard's specific sensor which is defected. Have you considered that?









You can always ask here, though









Good Luck -- Bye - Bye.


----------



## dmfree88

My extreme4 shows Auxillary usually at 0c but sometimes randomly jumps as high as 125c, Auxtin2 might be ambient temp it seems to just sit at 25c, haven't monitored it close enough but the auxtin3 sensor sits between 105c-107c

Basically this motherboard only has a motherboard temp and voltage sensors. All the other temp sensors mentioned above seem to be faulty. So I will just turn it up till it smokes then back it off a couple MHZ


----------



## Mumak

Quote:


> Originally Posted by *dmfree88*
> 
> My extreme4 shows Auxillary usually at 0c but sometimes randomly jumps as high as 125c, Auxtin2 might be ambient temp it seems to just sit at 25c, haven't monitored it close enough but the auxtin3 sensor sits between 105c-107c
> 
> Basically this motherboard only has a motherboard temp and voltage sensors. All the other temp sensors mentioned above seem to be faulty. So I will just turn it up till it smokes then back it off a couple MHZ


Auxiliary and auxtin3 seem not to be connected, so they return invalid values. You might compare with ASRock tool if there's some correlation between values reported.


----------



## dmfree88

There is it seems that there are no Aux temps on the Extreme4 at all. Auxtin2 still at 25 even with motherboard at 20. I noticed the Vcore is showing invalid and too low of values. It shows normal in Asrock A-Tuning but in hwinfo it is going all the way down to 0.000 and idles around 0.1-0.4. I would assume minimum value is never 0.000. Not sure what is happening here I swear it worked fine yesterday. Seems to work fine under load but now not showing proper idle vcore.


----------



## Mumak

Quote:


> Originally Posted by *dmfree88*
> 
> There is it seems that there are no Aux temps on the Extreme4 at all. Auxtin2 still at 25 even with motherboard at 20. I noticed the Vcore is showing invalid and too low of values. It shows normal in Asrock A-Tuning but in hwinfo it is going all the way down to 0.000 and idles around 0.1-0.4. I would assume minimum value is never 0.000. Not sure what is happening here I swear it worked fine yesterday. Seems to work fine under load but now not showing proper idle vcore.


It's common that the measured Vcore on Haswell-based systems is very low when idle (deep low-power states). That seems to be due to the FIVR (Fully Integrated Voltage Regulator).
Thus a lot of boards report VID instead of Vcore, which might be in your case as well. Try to compare VID in HWiNFO with Vcore in A-Tuning.


----------



## dmfree88

hey there you go. Should have thought of that. Thanks for the information. I feel much more informed now. Love hwinfo thanks for all you do!


----------



## Derp

HWiNFO's new memory error tracker was reporting errors on a stock 380x. I initially thought it might just be an error with HWiNFO but I kept lowering the memory clocks by 10MHz each time and the errors started shrinking. I had to drop the memory speed from 1425 to 1350 for the errors to stop showing up.

AMD sent me this card as a replacement after the catalyst fan speed issue. And by replacement I mean they made me pay to send a card to a different country.

Did AMD really send me a card pulled from a bin that couldn't pass quality control at stock speeds?


----------



## dmfree88

Suggestion to make an additional checkbox on the alerts page to shutdown PC if value exceeds XX. When selected would need to force de-select on "display warning window" (this causes PC to not shutdown) and maybe add an additional box for shutdown timer (or force to 0). For me I have been creating a BAT file or using the "run file" selection and running shutdown.exe with arguments "-s -f -t 00". It seems like this would be a nice safety feature to have built in and would save me some time trying to teach people how to do it. For overnight stresstesting and folding I always recommend to setup hwinfo to force shutdown in case of fan (or pump if watercooling) failure. Hope to maybe see this feature implemented for easier use.

Been a long time user of HWinfo and very impressed with how well you keep up with it. You are also always very helpful and I appreciate that. Thanks for everything you do! Hope to see more updates in the future with more features







.

Oh one more thought is if we could make the spacing smaller on the sensor squares. It would be nice to shrink font and have the table shrink with it but it seems like the table hits a minimum size and wont get smaller. Trying to cram all the sensors I use on a 1080p screen just isn't happening







. Small thoughts, again great job on the program and thanks again for all you do!


----------



## dmfree88

Another idea is to turn this thread into a overclock club. You can add a cool signature (like the ones in my signature) and people will put it in their signatures if they support you (which everyone does here that I have seen) which will then link back to the first page of this post. If you add links to download hwinfo in the first post and a little bit of info about it (including how to donate to you guys for the cause) then I would guess it would grow even further in popularity here. Just a thought







.

By the way I noticed the latest beta update removed the aux sensors that I mentioned were pointless on the extreme4. I just want to point out to everyone here that this guy really listens. That was fast update and removal of pointless sensors. Great job!


----------



## Mumak

I'll put the shutdown option into my list, but since this is currently possible via the shutdown command, it won't have a high priority to implement.
The latest HWiNFO Beta allows you to change fonts in the sensor screen








Thanks for the suggestion for overclock club. But I'm not sure how exactly to do that. Any special requirements ? I cannot edit the first post anymore, probably too old.


----------



## dmfree88

Not that I am aware of I think it is more just a flare thing. That sucks you can't edit the post. Oh well. I did change the font and colors which is awesome!


----------



## i2CY

Sorry this will probably be a poor question but i need to ask it

CPU Graph, I have no Overclock applied, however there is no fluctuation in the CPU lvl, rather the bar never moves, they all stay at constant yellow - 3897

Turbo is 3900
CPU HFM is 3500

My CPU iH80 cooler is only keeping the CPU at 43*C on balanced mode, which i know off the top of my head i have had it at 32*c - 36*c.

Is there something in my mobo bio keeping my CPU amped up all the time, or an app in win10 keeping it going?

Task manager is staying 6% CPU usage at idle.

let me know


if more info is required.

Cheers.

Sorry just a basic brake down on the way the graph works, i'll trouble shoot the CPU Usage myself.


----------



## Mumak

Yes, it looks like something is keeping the CPU at highest clock.
Try to close the summary window and check the clock in sensors.
It might be an aggressive turbo setting in BIOS, when a minuscule load can trigger turbo.


----------



## Bold Eagle

Had to sub - curious about my vCore here as CPU-Z and HWMon are showing 1.272 but HWinfo is showing 1.3511:


----------



## LostParticle

What happens if you scroll down a bit?


----------



## Bold Eagle

Quote:


> Originally Posted by *LostParticle*
> 
> What happens if you scroll down a bit?


I just did a ninja edit as I wanted to compare CPU-Z with HWMon with HWInfo.


----------



## Mumak

Quote:


> Originally Posted by *Bold Eagle*
> 
> Had to sub - curious about my vCore here as CPU-Z and HWMon are showing 1.272 but HWinfo is showing 1.3511:


1.3511V is the VID. Vcore should be displayed in the sensors window, which is not well visible on the screenshot.


----------



## LostParticle

Hey Martin, just got a notification to update to the latest beta, version 5.33.2915, but when I'm visiting FOSSHUB as I always do, to get it, I do not see the HWiNFO64 Beta of this version. Only the HWiNFO32 version is there. Any thoughts?

Take care


----------



## Mumak

There's currently a problem at FossHub, I hope it will be resolved in a few minutes.
Use the Primary backup link meanwhile.


----------



## Bold Eagle

Quote:


> Originally Posted by *Mumak*
> 
> 1.3511V is the VID. Vcore should be displayed in the sensors window, which is not well visible on the screenshot.


Thanks for that just found the values and they are corresponding with CPU-Z - I then had to go and search VID vs vCore and it all makes sense now.

Ninja Edit: Worse dyslexia for quite a while....


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> There's currently a problem at FossHub, I hope it will be resolved in a few minutes.
> Use the Primary backup link meanwhile.


Okay, got it from Primany, thanks









Can you please tell me what am I missing, since I always keep both of my monitors at 125% Custom scalling level [on Win 10 Pro]?


Spoiler: Warning: Spoiler!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, got it from Primany, thanks
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Can you please tell me what am I missing, since I always keep both of my monitors at 125% Custom scalling level [on Win 10 Pro]?
> 
> 
> Spoiler: Warning: Spoiler!


The full text is: "Logging Separator (CSV):"
I'll enlarge the space, so it fits...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> The full text is: "Logging Separator (CSV):"
> I'll enlarge the space, so it fits...


Oh, thank you!









Since you'll get into the trouble, fix this little thing, as well










Spoiler: Warning: Spoiler!







OFF-TOPIC PS:


Spoiler: Warning: Spoiler!



Remember the other day when I've PM-ed you about a Linux [Mint] monitoring tool? A, ha, ha... Still struggling, Conky has been suggested but I've probably have to take a Degree on OSes in order to set it up, so momentarily I'm fixed with *i7z*, to be able to monitor my CPU, at least... No worries! And all this for what? Just because nobody really knows what Windows 10 phones back to Mama! No problemo in having a new OS keeping me busy and...at least *some others are mad with this situation*, as well!...


----------



## IF6WAS9

Ever since switching to GTX1080, I haven't been able to open HWINFO64. It just gets stuck during video adapter detection. I tried ticking/un-ticking settings related to waking gpus, different drivers, and have recently done a clean install of Windows 10 and it still won't open.

I scanned the last couple of months in this thread and didn't see anyone else report this issue. Is this a known issue with the latest Nvidia cards?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Oh, thank you!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Since you'll get into the trouble, fix this little thing, as well
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> Will do
> 
> 
> 
> 
> 
> 
> 
> 
> 
> OFF-TOPIC PS:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> Remember the other day when I've PM-ed you about a Linux [Mint] monitoring tool? A, ha, ha... Still struggling, Conky has been suggested but I've probably have to take a Degree on OSes in order to set it up, so momentarily I'm fixed with *i7z*, to be able to monitor my CPU, at least... No worries! And all this for what? Just because nobody really knows what Windows 10 phones back to Mama! No problemo in having a new OS keeping me busy and...at least *some others are mad with this situation*, as well!...


I hope CNIL will win. I am using Win10, but with several tweaks (my own scripts to disable and uninstall a lot of stuff) + OOSU10. I never used any of their apps or store, not even having an account there


----------



## Mumak

Quote:


> Originally Posted by *IF6WAS9*
> 
> Ever since switching to GTX1080, I haven't been able to open HWINFO64. It just gets stuck during video adapter detection. I tried ticking/un-ticking settings related to waking gpus, different drivers, and have recently done a clean install of Windows 10 and it still won't open.
> 
> I scanned the last couple of months in this thread and didn't see anyone else report this issue. Is this a known issue with the latest Nvidia cards?


Do you have a single GPU, or using SLI? I had some reports that when SLI is enabled and a certain display configuration is used with R368 or later drivers, the NVML init can hang: http://www.hwinfo.com/forum/Thread-Freeze-Detecting-Video-Adapter-s
It's definitively a bug in NVIDIA drivers.
Try to grab the latest HWiNFO Beta build and add the "NvmlSupport=0" setting into HWiNFO64.INI as described on that forum.
Please let me know the result...


----------



## IF6WAS9

Yes, I had SLI. I took the second card out last night and just tried to open HWINFO64 immediately after posting and now it works. I was going to edit my post to say that it seems to be SLI related, but you beat me to the punch (thanks for the quick response). When I get around to putting the second card back in, I'll try the add the "NvmlSupport=0" setting to the INI.

Thanks again. Among other things, I love that this program reports cpu vcore correctly instead of other programs that only report cpu vid.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I hope CNIL will win. I am using Win10, but with several tweaks (my own scripts to disable and uninstall a lot of stuff) + OOSU10. I never used any of their apps or store, not even having an account there


OFF-TOPIC


Spoiler: Warning: Spoiler!



Yes, I hope they will win, too!! Great that you're dealing with that stuff! I do the same as you, in my primary OS, but I'm using W10Privacy. Give it a try, if you wish








I used my second SSD to participate in the Technical Preview (Insider) program, and there I had an account and I was testing it. No other programs were installed (besides CCleaner and HWiNFO64). From all the Apps I just kept Calculator. No other App worthed it, for me. IF they won't change, I'll head towards *Tails*, after I'll get the hang of Mint. I won't expect any monitoring tool like HWiNFO, there, hahaha...Thanks!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> OFF-TOPIC
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> Yes, I hope they will win, too!! Great that you're dealing with that stuff! I do the same as you, in my primary OS, but I'm using W10Privacy. Give it a try, if you wish
> 
> 
> 
> 
> 
> 
> 
> 
> I used my second SSD to participate in the Technical Preview (Insider) program, and there I had an account and I was testing it. No other programs were installed (besides CCleaner and HWiNFO64). From all the Apps I just kept Calculator. No other App worthed it, for me. IF they won't change, I'll head towards *Tails*, after I'll get the hang of Mint. I won't expect any monitoring tool like HWiNFO, there, hahaha...Thanks!


Oh yes, actually I kept the Calculator only, but there are some things I don't like - it loads too slow and doesn't keep the number entered when I switch between Dec/Hex. So I copied the good old one from WinXP








The idea of making HWiNFO for Linux is still in my head, but it would be a really huge effort - several months of intensive porting and testing... Also I guess the GUI could be problematic because of the various Linux flavors...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Oh yes, actually I kept the Calculator only, but there are some things I don't like - it loads too slow and doesn't keep the number entered when I switch between Dec/Hex. So I copied the good old one from WinXP


OFF TOPIC


Spoiler: Warning: Spoiler!



I've never encountered such an issue (because I never had to use it







); the only irritating matter I've faced was that it did not always open in the foreground, something I've fixed *with this Registry Edit*.



Quote:


> Originally Posted by *Mumak*
> 
> The idea of making HWiNFO for Linux is still in my head, but it would be a really huge effort - several months of intensive porting and testing... Also I guess the GUI could be problematic because of the various Linux flavors...


Oh, that would be GREAT!! The Ubuntu community would Welcome it! In a recent thread I've opened, to cope with my Mint inquiries, I've praised HWiNFO for its wealth of information, wishing there could be a Linux equivalent. Here's what someone told me:
Quote:


> As far as the wealth of values hwinfo64 monitors, I believe almost all of the information available in that tool is probably available in sysfs, by default. Obviously this isn't very useful to the end-user, but it is there. For example, cat /proc/cpuinfo will tell you more about your CPU than you can possibly care about. `lspci` `lsusb` `lshw` and `dmidecode` can tell you more about the PCI, USB and other hardware devices, and dmidecode can tell you everything about your ram. Unfortunately nobody has really wrapped all of these up into a truly usable tool for actively monitoring the information. Usually its a passive probe and print of the data.


*source*

Many would appreciate it, I think!


----------



## dmfree88

Interesting idea would be some form of a PC crash log. The idea I had for this is a constantly running 1 minute log file (maybe adjustable in settings) that deletes older data as it goes. If at any time hwinfo crashes without being shutdown normally (through pc shutdown or closing the program) it could then start on the next minute of the log file and keep the previous information recorded. It would then be a running crashdump that shows you the day and time of any PC crashes and a 1 minute sensor log of that time. Would be interesting to go back and look at your overclocking crashes and whatever else that may have happened

Not sure how much use this would have but I would assume it would assist in diagnosis of issues with crashing and would also make for an interesting feature. Not having to run a log file all the time if you are looking for like an overnight stability test for example it would be nice if it only records the time around when/if it crashes so you don't have the 4+ hours of information when you only want the 1 minute.

I also don't want to run my log file constantly but hwinfo is always on so if it were to have this feature I could then go back and see a crash even though full logging isn't activated.


----------



## LostParticle

Hey Martin, just thought to ask you:

- How come and HWiNFO64 does not monitor C-States like, for example, Real Temp does? Or, am I missing something?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, just thought to ask you:
> 
> - How come and HWiNFO64 does not monitor C-States like, for example, Real Temp does? Or, am I missing something?


I'm working on that right now.
However a per-core C-State residency reporting on systems with many cores will result in lots of entries in the sensors screen.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm working on that right now.
> However a per-core C-State residency reporting on systems with many cores will result in lots of entries in the sensors screen.


VERY good news!









My personal and subjective opinion: it is better a feature to be there and the user to Hide - Disable it than the feature being missing...
(and this comes from me, who has already one entire monitor (my Dell) dedicated to HWiNFO64, and with this new feature I will have to reorder-rearrange everything and it, most probably, still won't fit!...)


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> VERY good news!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> My personal and subjective opinion: it is better a feature to be there and the user to Hide - Disable it than the feature being missing...
> (and this comes from me, who has already one entire monitor (my Dell) dedicated to HWiNFO64, and with this new feature I will have to reorder-rearrange everything and it, most probably, still won't fit!...)


Enjoy build 2922


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Enjoy build 2922


Hey Martin!

Thank you for this latest build!









A couple of things:

1) I would suggest you, if you like, to remove the Average readings from the following values:
Performance Limit Reasons
Memory Timings
Core # Thermal Throttling
Package/Ring Thermal Throttling

2) Please check this out:


Spoiler: Warning: Spoiler!







3) Now, the most important matter for me!...
As you've probably observed from my many screenshots in this thread, I am always keeping a very neat HWiNFO64 Sensor window, and your tool always starts on Windows start-up, and monitors my system for the entire time it is powered on. The recent addition of the C-State Residency, wholeheartedly Welcomed of course, has... messed up my layout, a bit... So, while I can totally accept and live with the new side-bar that has appeared on the right side of my Sensor's panel, I cannot understand and I cannot fix the bar that has appeared at the bottom! I have renamed the values, I have also widened my entire Sensor panel, as well as the columns in the first "table" but...each time I save and re-open HWiNFO64 that bar at the bottom is still there! Have a look:


Spoiler: Warning: Spoiler!







I am always-always, even since Windows 7, using a Custom scaling level of 125% in both my monitors. (see my sig_rig).

Is there anything I can do to make that bar at the bottom go away?

Thank you!


----------



## Mumak

OK, I'll remove those average values, they indeed don't make much sense. Also will fix the text size for "ms", though not sure what you meant what's wrong with the "Show values" on the screenshot.

As for the scroll bar at the bottom, that appeared because of the vertical scroll bar (because there are more entries in that list). Can you remove/hide some entries in the right pane, or make the entire window wider ?
EDIT: You might also try to adjust the list column widths, which are preserved, so that the entire text fits in without the horizontal scroll bar.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, I'll remove those average values, they indeed don't make much sense. Also will fix the text size for "ms", though not sure what you meant what's wrong with the "Show values" on the screenshot.
> 
> As for the scroll bar at the bottom, that appeared because of the vertical scroll bar (because there are more entries in that list). Can you remove/hide some entries in the right pane, or make the entire window wider ?
> EDIT: You might also try to adjust the list column widths, which are preserved, so that the entire text fits in without the horizontal scroll bar.


When it comes to the "Show values" pointed in my screenshot, perhaps it is just my idea but I think that the "s" at the end of each word is a bit cut? I am not sure, perhaps it's just my idea. IF you can, give it a pixel or two more, otherwise leave it as is.

With the scrollbar appearing at the bottom... Shouldn't this appear only if the width of the text is bigger than the window or the column size is set? I mean, the right scrollbar is there to indicate that there are values down below but the bottom scrollbar? What does it indicate when the entire text has already been fit?

Unfortunately, the ONLY thing that seems to work = to eliminate the bottom scrollbar, is the following:


Spoiler: Warning: Spoiler!







- Do you observe the space where I put the arrows? On two "tables" this gap appears, on the third it does not appear! This is not looking good
















Everything else I have (already) tried, your suggestions I have already tried, do not work. It does not remember them. In the following screenshot I have widened both the entire Sensor panel, as well as the individual list column widths, where the arrows show:


Spoiler: Warning: Spoiler!







When I set it the bottom bar disappears. I then save by closing it. As soon as HWINFO64 is opened again, the bar at the bottom appears. It does not remember my setting.

PS: Yes, I know that if I will Hide some values the problem will be fixed, but the point is that I wouldn't like to hide these values. I would just like to hide the bottom scrollbar.


----------



## Mumak

Scrollbars are shown automatically by the Windows GUI depending on size of the area.
When you have the proper column widths set without a horizontal scrollbar and you restart HWiNFO, they should appear as before. So this might be some issue. I'll check that...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Scrollbars are shown automatically by the Windows GUI depending on size of the area.
> When you have the proper column widths set without a horizontal scrollbar and you restart HWiNFO, they should appear as before. So this might be some issue. I'll check that...


Okay, I see. Please, check it out. I should also inform you that long time ago I have set my Sensor panel the way you see it. Since then I always export HWiNFO settings, the .REG file, on my desktop, then I delete the program's Registry entry, I get the new version, check it out for new features, and finally I apply my settings (the .REG file) again.

Do you think that if I would re-design my Sensor panel entirely - a bit of a PITA - the horizontal scrollbar would not appear when set accordingly?

Personally, I believe that there must be some small bug in the program due to that gap appearing in two tables but not on the third one. (see previous screenshot)

Thank you, please check it out!








Please fix it so that it will remember the user's settings and make the gap in those two tables disappear.


----------



## Mumak

Well, so the problem is that only column widths of the first pane (most left) are preserved and all the other panes use the same widths.
So it's currently not possible to have individual columns widths for all panes.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, so the problem is that only column widths of the first pane (most left) are preserved and all the other panes use the same widths.
> So it's currently not possible to have individual columns widths for all panes.


Sorry Martin, I do not fully understand you. I will try to express myself as simply as possible:

- I want to monitor more values than my screen can handle.
- So, I will have a vertical scrollbar! No problem! It indicates me that there are more values down below.
- Why should I have a horizontal scrollbar, as well?! My width is fixed - everything fits! Why the horizontal scrollbar? Can you make it disappear?
- When I make the entire Sensor panel wider the bottom scrollbar disappears BUT this creates gaps! *I show them with red arrows*. Can you make these gaps disappear?

Thank you!
















PS: I cannot be sure but I do not think that "_...all the other panes use the same widths_" because wouldn't then these gaps appear on the rightmost "table", as well? Dunno.


----------



## Mumak

Those gaps appear because when you make the window wider, you're making more space for the last pane, so that the vertical scroll bar fits in.
But the widow size is divided evenly between all lists, so that's why in other lists those gaps appear, while in the last list with the vertical scroll bar this gap is used to fit the scroll bar.
What's important determining the space used in a pane (list) are the particular column widths. And as I explained above, only the first list's column widths are preserved by HWiNFO.
I'm working on preserving column widths for all panes/lists. If that will work, you can adjust the widths on the most right list so that you don't see the horizontal scroll bar and this setting should be well preserved after next start.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Those gaps appear because when you make the window wider, you're making more space for the last pane, so that the vertical scroll bar fits in.
> But the widow size is divided evenly between all lists, so that's why in other lists those gaps appear, while in the last list with the vertical scroll bar this gap is used to fit the scroll bar.
> What's important determining the space used in a pane (list) are the particular column widths. And as I explained above, only the first list's column widths are preserved by HWiNFO.
> I'm working on preserving column widths for all panes/lists. If that will work, you can adjust the widths on the most right list so that you don't see the horizontal scroll bar and this setting should be well preserved after next start.


I see! Okay, now I understand you. The gap is there but it's used for the vertical scrollbar. Okay... So the ONLY thing I can do, for the time being, is to Hide values, like my Hard Drive's sensors, so that the new C-State Residency will fit.

It is GREAT that you're working on preserving column widths for all panes/lists!! Have I read that correctly? That would be really useful!

One last suggestion from me:

HWiNFO64 is offering LOTS of monitoring values, right now! I have no idea how difficult this could be but would you consider offering the user a custom Sensor panel, which would run together (at the same time) with the main Sensor window? I am thinking of it as an empty panel in which the user could drag & drop any sensor would desire and keep it on his second (or main) monitor. Like in my case, I would have my Sensors as I used to, and I would place all the C-State Residency in a new panel, on my primary monitor, to observe them for as much as I would want to. Similarly, I could place my Memory Timings in that independent Sensor window, post a screenshot (with my stress-test running and all the rest of the values monitored), and then close it.

Is this too much?

Thank you - GENUINELY looking forward to preserving [independent] column widths for all panes/lists!!


----------



## Mumak

OK, try this build: www.hwinfo.com/beta/hw64_533_2923.zip
You should now be able to individually adjust column widths of all lists and they should be properly saved & restored. This should resolve your problem.

The other idea sounds interesting. But indeed, it's a lot of work, so i'm afraid not in a near future.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, try this build: www.hwinfo.com/beta/hw64_533_2923.zip
> You should now be able to individually adjust column widths of all lists and they should be properly saved & restored. This should resolve your problem.
> 
> The other idea sounds interesting. But indeed, it's a lot of work, so i'm afraid not in a near future.


All right!!














That was FAST!









And it works great, thank you!!

For the sake of the example:


Spoiler: Warning: Spoiler!







My current HWiNFO64!









Spoiler: Warning: Spoiler!







Just to clarify something, since it's a new feature: when I see, for example, an Average of 84% - 90% of Core # C7 Residency does this mean that 84 - 90 percent of the time my cores sleep in this deep state?









Thank you also for considering that other option! With the wealth of the Sensors HWiNFO64 can monitor it would be really handy! There is no monitor (screen), I think, that could host all of the important Sensors... I hide almost everything of my GPU because I do not game and still I'm starting to not have enough space.

Keep up the great work you do, man!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Just to clarify something, since it's a new feature: when I see, for example, an Average of 84% - 90% of Core # C7 Residency does this mean that 84 - 90 percent of the time my cores sleep in this deep state?


Yes


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes


Okay, thanks!
Please allow me one last question, the last one, I promise!









I'm not liking the new scrollbar -not used to it- so I am trying to figure out which values from my SSD drives I could hide so that the available number of free lines I have left, will fit everything. Please, according to your opinion, which of the following values are considered the most important to monitor?



Shown are all the values monitored from my SSD. I have kept only Read, Write and Total Activity. Are these the most important ones?

Currently:


Spoiler: Warning: Spoiler!







Thank you!


----------



## LostParticle

@Mumak, another idea-suggestion to consider is to give the option to make the background of the Sensor panel transparent and to (auto) hide the title and bottom bars, as well


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak, another idea-suggestion to consider is to give the option to make the background of the Sensor panel transparent and to (auto) hide the title and bottom bars, as well


Interesting idea..


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Interesting idea..


Yeap, check out *how some people have it* with plain good ol' AIDA64 OSD -- background set to transparent







Similarly could be set with HWiNFO64, Current list only, background transparent.

Do you agree with the Disk Drive monitoring values above? Are they the most important ones?


----------



## majdung

Help me !
Why AUXTIN1 very hot








What's Auxtin1 ?
Tks for reply !


----------



## deepor

When something is named "aux", it is usually some extra sensor without a real name. The "aux" is short for "auxiliary".

The only thing you can know from that name is that there's a sensor somewhere. What exactly it is depends on the motherboard. It could also be that the temperature you see reported is not the correct value. Sometimes values have to be changed to get the correct temperature, like for example multiplying with a factor or adding a base value. It might not really be 100°C.

You should go and see if there's a thread in the Intel motherboard forum about your board, and ask the people there what they think.


----------



## majdung

Tks bro for reply !

All 's normal but I worry '' AUXTIN temp '' because I don't know it


----------



## gupsterg

@mumak

Read this a few days ago:-
Quote:


> GPU-Z claims to report how much VRAM the GPU actually uses, but there's a significant caveat to this metric. GPU-Z doesn't actually report how much VRAM the GPU is actually using - instead, it reports the amount of VRAM that a game has requested. We spoke to Nvidia's Brandon Bell on this topic, who told us the following: "None of the GPU tools on the market report memory usage correctly, whether it's GPU-Z, Afterburner, Precision, etc. They all report the amount of memory requested by the GPU, not the actual memory usage. Cards will larger memory will request more memory, but that doesn't mean that they actually use it. They simply request it because the memory is available."


Quote from.

I have yet to compare what GPU-Z reports on VRAM usage vs HWiNFO, but wanted to ask you is HWiNFO doing the same as GPU-Z? (ie VRAM request and not actual usage)


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> Read this a few days ago:-
> Quote from.
> 
> I have yet to compare what GPU-Z reports on VRAM usage vs HWiNFO, but wanted to ask you is HWiNFO doing the same as GPU-Z? (ie VRAM request and not actual usage)


Yes, for NVIDIA I believe both GPU-Z and HWiNFO report the same memory load values. We use the NVAPI interface to gather this information.
In HWiNFO this is called "GPU Memory Allocated", which also denotes that it's the amount of memory allocated, not really used.
If NVIDIA feels that users might need to know the amount of memory really used, it's completely in their hands to extend their API with such information.


----------



## gupsterg

Cheers







, + rep.

And on AMD?


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> And on AMD?


AMD doesn't offer reporting of GPU Memory Usage via their API (ADL) at all.
I have tried to get the required information from AMD (and other sources), but it seems that there are no hardware counters that would be reporting such information. So we're left in the dark







and currently the only available memory usage monitoring is via DirectX private API which of course covers DX applications only.AFAIK there's no tool (including internal AMD ones) that would report true memory usage on AMD GPUs.


----------



## gupsterg

WOW & OMG







, many thanks for this information (+rep).

So am I correct in thinking only AMD / nVidia internal depts would know how relevant the data we view in monitoring tools for end users is in context of actual VRAM used? (caveat being a) they have tools b) do testing as such).


----------



## LostParticle

Hey Martin,

The recent posts made me reset my HWiNFO64 to monitor my GPU, a bit, JUST out of curiosity, because besides its temperature and the PCIe Link Speed, I never monitor anything else on my GPU. My GPU is show in my sig_rig.

So, I took the following screenshot (on idle):



I see two values: Allocated Memory and Memory Usage (%). What does Memory Usage show? Does it show the percentage of the Allocated memory used, or does it show the percentage of the total available RAM of my GPU, that is used?

Never before bothered to monitor these values, always hide them, so pardon me if I made a naive question.

Thank you!


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> WOW & OMG
> 
> 
> 
> 
> 
> 
> 
> 
> , many thanks for this information (+rep).
> 
> So am I correct in thinking only AMD / nVidia internal depts would know how relevant the data we view in monitoring tools for end users is in context of actual VRAM used? (caveat being a) they have tools b) do testing as such).


Yes, I guess so. Only they have real insight. And that's true for lots of other information.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I see two values: Allocated Memory and Memory Usage (%). What does Memory Usage show? Does it show the percentage of the Allocated memory used, or does it show the percentage of the total available RAM of my GPU, that is used?


It shows the percentage of allocated GPU memory (allocated / total).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It shows the percentage of allocated GPU memory (allocated / total).


Thought so, thank you Martin, +REP!









Quote:


> Originally Posted by *Mumak*
> 
> Yes, I guess so. Only they have real insight. And that's true for lots of other information.


Personally, I am fully aware of this, and I'm grabbing the opportunity to underline something:

- Whenever HWiNFO64 is presenting an erratic / arbitrary value or it cannot monitor a value it is 99.99% the manufacturer's fault! It is INTEL, AMD, NVIDIA and the various motherboard manufacturers those who should be blamed for not providing accurate information and reliable access to it!

Unless you live inside a Laboratory, HWiNFO64 is (by far) the best monitoring tool, available!

Just my personal opinion.

Thank you.


----------



## Mumak

Thank you








There's a lot of data that can be monitored which could provide useful information, but most of this is kept secret and known only to particular design teams. And often the information that we can monitor is not properly described by manufacturers or not reliable.


----------



## gupsterg

@mumak

I was reading this (author's site).

So are you able to implement EvictAllocation Events counter?
Quote:


> Originally Posted by *LostParticle*
> 
> Unless you live inside a Laboratory, HWiNFO64 is (by far) the best monitoring tool, available!


I concur







, I have never seen such an approachable and dedicated author of freeware. I would urge members that have never donated $ and use the program on a regular basis to support the author via donations on his site.


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> I was reading this (author's site).


HWiNFO uses the same NvAPI_GPU_GetMemoryInfo function as mentioned there to report memory load information.
The other possible methods via DxgKrnl are DirectX-dependant and won't cover other interfaces like Vulkan, CUDA, etc.


----------



## gupsterg

I'm asking if :-
Quote:


> So are you able to implement EvictAllocation Events counter?


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> I'm asking if :-


I might be, but I don't see much sense in that.


----------



## LostParticle

@Mumak, thanks for the latest version, 5.34.2930, works great but... why are the Package C2 & C3, and Core# C7 states missing? A screenshot of how it was can be seen *on this post of mine*.

Also, now when I go to download the tool, it downloads automatically. I am not taken on the page to select the version any more.

*EDIT:* sorry about this,







, I was on Optimized Defaults due to the clean installation of Windows 10 and there, not all C States are enabled. As soon as I loaded one of my OC profiles, all of them appeared in the tool again!

Thank you!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak, thanks for the latest version, 5.34.2930, works great but... why are the Package C2 & C3, and Core# C7 states missing? A screenshot of how it was can be seen *on this post of mine*.
> 
> Also, now when I go to download the tool, it downloads automatically. I am not taken on the page to select the version any more.
> 
> *EDIT:* sorry about this,
> 
> 
> 
> 
> 
> 
> 
> , I was on Optimized Defaults due to the clean installation of Windows 10 and there, not all C States are enabled. As soon as I loaded one of my OC profiles, all of them appeared in the tool again!
> 
> Thank you!


I haven't changed anything in reporting of those states in the final build. It possible that those counters are stopped (0) and thus not shown. Can you check with other tool if they show up? Also attaching the DBG file might help.

Not sure from which page you downloaded before, but if it was FossHub, then it's currently disabled because of a problem on that site. Should be back in a few days...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I haven't changed anything in reporting of those states in the final build. It possible that those counters are stopped (0) and thus not shown. Can you check with other tool if they show up? Also attaching the DBG file might help.
> 
> Not sure from which page you downloaded before, but if it was FossHub, then it's currently disabled because of a problem on that site. Should be back in a few days...


Yeap, everything works great, as I already posted in the Edit of the post you quoted








Sorry for the inconvenience


----------



## Mumak

A Facebook page for HWiNFO has been launched: https://www.facebook.com/HWiNFO64
Feel free to share/like


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> A Facebook page for HWiNFO has been launched: https://www.facebook.com/HWiNFO64
> Feel free to share/like


Pretty nice!









I would definitely subscribe but I have quit Facebook six years ago.


----------



## mynm

Hi, I see in this NCP81022 datasheet: http://media.digikey.com/pdf/Data%20Sheets/ON%20Semiconductor%20PDFs/NCP81022.pdf , that register E7 is core VID for my r9 380, the only problem I see is that it is going to 0 when voltage offset is negative.

Coudl you include this reading at Hwinfo?

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Hi, I see in this NCP81022 datasheet: http://media.digikey.com/pdf/Data%20Sheets/ON%20Semiconductor%20PDFs/NCP81022.pdf , that register E7 is core VID for my r9 380, the only problem I see is that it is going to 0 when voltage offset is negative.
> 
> Coudl you include this reading at Hwinfo?
> 
> Thanks.


Isn't the currently reported "GPU Voltage" value sufficient ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Isn't the currently reported "GPU Voltage" value sufficient ?


Well







, but VID is usefull to see the diference between bios set voltage and real voltage.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Well
> 
> 
> 
> 
> 
> 
> 
> , but VID is usefull to see the diference between bios set voltage and real voltage.


OK, I'll add that value in the next build








I'm also still not sure whether my GPU Voltage formula for NCP81022 is correct, might need to adjust that too.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> OK, I'll add that value in the next build
> 
> 
> 
> 
> 
> 
> 
> 
> I'm also still not sure whether my GPU Voltage formula for NCP81022 is correct, might need to adjust that too.


Thank you very much


----------



## LostParticle

Hi Martin

Thank you for the latest beta!









Two things I have observed:
1) The new icons, next to the Sensor labels, have ruined my customization by adding an extra line (or something) on each table, I have three, making the side scroll bars appear... The only way I've found to resolve this was to hide one empty line on each of my tables. I had them there though to distinguish things... Here's how it looks like now:

The red arrows show where the empty lines were.


Spoiler: Warning: Spoiler!







Can you not make them the same size as the previous ones?

2) I knew that if I make some changes, like hiding a value, this does not get saved if I press Esc. Now when I hide a value, it remains hidden even if I will use Esc to close the program. Has something changed?

Thanks.


----------



## Mumak

Hmm, size of those icons is still the same (16x16 for default 100% scaling). Are you maybe using custom display (Hi-DPI) scaling in Windows?


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Hmm, size of those icons is still the same (16x16 for default 100% scaling). Are you maybe using custom display (Hi-DPI) scaling in Windows?


Oh yes! On both of my monitors, see sig_rig, I am always using a Custom scaling Level of 125. It has always been like this, in my system, even on Windows 7. Otherwise everything looks minuscule!
HWiNFO always opens on my Dell monitor.

Why?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Oh yes! On both of my monitors, see sig_rig, I am always using a Custom scaling Level of 125. It has always been like this, in my system, even on Windows 7. Otherwise everything looks minuscule!
> HWiNFO always opens on my Dell monitor.
> 
> Why?


That explains it








In the last build I updated several GUI items (including icons) to properly handle display scaling. Before, the icons were always the same size, so if a high scaling was used those items would be too small (they wouldn't scale with the rest of items). Now the icons are properly scaled and that caused a bit larger list size. This is how it should look like, so I suggest you update your layout


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That explains it
> 
> 
> 
> 
> 
> 
> 
> 
> In the last build I updated several GUI items (including icons) to properly handle display scaling. Before, the icons were always the same size, so if a high scaling was used those items would be too small (they wouldn't scale with the rest of items). Now the icons are properly scaled and that caused a bit larger list size. This is how it should look like, so I suggest you update your layout


Okay, I understand, I'll see what I can do. By the way, I monitor a value called "CPU GT Cores (Graphics)". Do I really need to monitor this one, since I am using a discrete GPU?

What about the Esc button? When I hide a value and then close using Esc, should the value reappear when I open HWiNFO again or not?

Thank you


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, I understand, I'll see what I can do. By the way, I monitor a value called "CPU GT Cores (Graphics)". Do I really need to monitor this one, since I am using a discrete GPU?
> 
> What about the Esc button? When I hide a value and then close using Esc, should the value reappear when I open HWiNFO again or not?
> 
> Thank you


Sorry, I can't reproduce that. When I exit via Esc, the action is not saved, so that item is not hidden on next start.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Sorry, I can't reproduce that. When I exit via Esc, the action is not saved, so that item is not hidden on next start.


Yes, you are right, 'Esc' is working as it is supposed to: no change is saved. This morning I have tested it again, dunno what happened last night.

Thank you


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> OK, I'll add that value in the next build
> 
> 
> 
> 
> 
> 
> 
> 
> I'm also still not sure whether my GPU Voltage formula for NCP81022 is correct, might need to adjust that too.


OK, I see now the VID, it isn't working if you are using - or + voltage offsets, but it is useful for doing some tests







.
And I see that now GPU Voltage for NCP81022 is changed and is more or less the same as GPU core Voltage (VDDC). what is the difference between them?

Thank you very much


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> OK, I see now the VID, it isn't working if you are using - or + voltage offsets, but it is useful for doing some tests
> 
> 
> 
> 
> 
> 
> 
> .
> And I see that now GPU Voltage for NCP81022 is changed and is more or less the same as GPU core Voltage (VDDC). what is the difference between them?
> 
> Thank you very much


Yes, I have adjusted the GPU Voltage of this VRM as I found a bug in the formula used before.
I believe it should be pretty similar to the VDDC reported, because I think the VDDC is the GPU's own measurement (telemetry) of the VRM voltage.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Yes, I have adjusted the GPU Voltage of this VRM as I found a bug in the formula used before.
> I believe it should be pretty similar to the VDDC reported, because I think the VDDC is the GPU's own measurement (telemetry) of the VRM voltage.


OK, thank you very much again.


----------



## prickly007

I'm trying to identify what a few temperature readings on my Asus Hero Alpha (Nuvoton NCT6793D) correspond to. Reading earlier posts led me to conclude Temp4 and Temp5, which never vary from 17C, are invalid values, while T1 shows the same reading, at both idle and load, as the Motherboard temperature.

Any idea what T2 might be? At idle it reads anywhere from 24.0 to 26.0 C and, when playing playing Witcher 3, rises to the low 30s C. Ambient temp is c.20 C.

HWINFO already shows readings for VRM and PCH temps.


----------



## LostParticle

Hey Martin, thanks for the latest beta, v5.37-2977, but I am not able to view "What's New", anywhere! On the site, https://www.hwinfo.com, the News area is (almost) empty...


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, thanks for the latest beta, v5.37-2977, but I am not able to view "What's New", anywhere! On the site, https://www.hwinfo.com, the News area is (almost) empty...


Thanks for letting me know. Not sure what exactly happened, but it's fixed.


----------



## Cakewalk_S

@Mumak, have you included all support for the new ASUS Z170i pro gaming board? It seems the VCCIO and VCCSA voltages are very incorrectly reported. I don't have access to it right now but the voltages are like 0.225v in HWINFO but in bios they're 1.201v...


----------



## Mumak

Quote:


> Originally Posted by *Cakewalk_S*
> 
> @Mumak, have you included all support for the new ASUS Z170i pro gaming board? It seems the VCCIO and VCCSA voltages are very incorrectly reported. I don't have access to it right now but the voltages are like 0.225v in HWINFO but in bios they're 1.201v...


Yes, it should be properly supported. But I'd need to get the HWiNFO Debug File and exact information about erratic values (including correct values).

EDIT: I have checked the code and indeed, it seems that some values were not properly reported for this model: VCCSA and CPU VCCIO were wrong, PCH Core and CPU iGPU missing. I'll try to fix this in the next build.


----------



## Face2Face

Quote:


> Originally Posted by *Mumak*


Hi Mumak,

I have a question regarding HWinfo and Intel SoCs. I have a handful of Intel compute sticks, and I use your program to monitor them. The Bay Trail and Cherry Trail model have a sensor for CPU Package power. What does CPU package power include? Is that the GPU as well? I also noticed my Core m3 compute stick also has a setting for total system power, but the others do not. Is that option limited to the model or type of SoC? Thank you!

EDIT:

Okay, from what I can tell the IA Cores Power is the Actual CPU power usage and the GT Cores Power is the HD Graphics usage. So the CPU package power is a combination of them both... Is that correct?


----------



## Mumak

Quote:


> Originally Posted by *Face2Face*
> 
> Hi Mumak,
> 
> I have a question regarding HWinfo and Intel SoCs. I have a handful of Intel compute sticks, and I use your program to monitor them. The Bay Trail and Cherry Trail model have a sensor for CPU Package power. What does CPU package power include? Is that the GPU as well? I also noticed my Core m3 compute stick also has a setting for total system power, but the others do not. Is that option limited to the model or type of SoC? Thank you!


Yes, the CPU Package Power should include iGPU as well.
Not sure what total system power setting you mean - is that reported by HWiNFO somewhere? Or is that rather some limit in BIOS?


----------



## Face2Face

Quote:


> Originally Posted by *Mumak*
> 
> Yes, the CPU Package Power should include iGPU as well.
> Not sure what total system power setting you mean - is that reported by HWiNFO somewhere? Or is that rather some limit in BIOS?


I edited my post above, but I'm pretty sure the IA is the CPU power usage, while the GT is the iGPU power usage. Also, the total system power is something the M3 had as an option when I used HWinfo64. It's odd, but I enabled it and this is what it looks like in the OSD:






BTW, I love your program and use it in my testing all of the time. Great job!!


----------



## Mumak

Quote:


> Originally Posted by *Face2Face*
> 
> I edited my post above, but I'm pretty sure the IA is the CPU power usage, while the GT is the iGPU power usage. Also, the total system power is something the M3 had as an option when I used HWinfo64. It's odd, but I enabled it and this is what it looks like in the OSD:
> 
> 
> 
> 
> 
> 
> BTW, I love your program and use it in my testing all of the time. Great job!!


Yeah, IA Cores means the x86/CPU cores part of the whole CPU package.
The "Total System Power" value is available only on some Skylake-based CPUs.


----------



## Face2Face

Quote:


> Originally Posted by *Mumak*
> 
> Yeah, IA Cores means the x86/CPU cores part of the whole CPU package.
> The "Total System Power" value is available only on some Skylake-based CPUs.


Great!! Thank you for your answer. Keep up the good work!


----------



## Mumak

Quote:


> Originally Posted by *Face2Face*
> 
> Great!! Thank you for your answer. Keep up the good work!


You're welcome


----------



## LostParticle

Hey Martin, I'm grabbing the opportunity to ask you a question, as well:

-What does Power (POUT) represent? What does this sensor show?

After the recent posts I have renamed my package power:



Thank you!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, I'm grabbing the opportunity to ask you a question, as well:
> 
> -What does Power (POUT) represent? What does this sensor show?
> 
> After the recent posts I have renamed my package power:
> 
> 
> 
> Thank you!


I assume the Power (POUT) value was originally under the VRM sensor. Those sensors can measure the current and voltage (and thus power as well) at both - the input and output side of the VRM. Usually the input side is connected to PSU and output to the particular rail. Thus the output/input ratio determines the VRM efficiency (loss by the VRM).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I assume the Power (POUT) value was originally under the VRM sensor. Those sensors can measure the current and voltage (and thus power as well) at both - the input and output side of the VRM. Usually the input side is connected to PSU and output to the particular rail. Thus the output/input ratio determines the VRM efficiency (loss by the VRM).


I restored HWiNFO64 to its original state and, after leaving my PC for a couple of minutes on idle, I've run my favorite stress test. Here are the results:



Does your answer still apply?

If so, what would be a more appropriate (informative) label for this value, and most importantly, what does a high value indicate? Is it better to see a high value there, is it better to see a lower value, like the lower the better, or... something else?

Thank you


----------



## deepor

The number is supposed to be the power use of your CPU. It is reported by a sensor in the VRM area that's next to your CPU on the board. The VRM takes in 12V from the PSU and transforms it into the voltage the CPU wants to take in which is 1.6 to 1.7V for you. I'm guessing the 200W number you see is wrong and too high, but that's what the sensor reports so it isn't HWINFO's fault.


----------



## LostParticle

Thank you for your reply, @deepor

@Mumak, do you agree with this? Do you disagree? Should I rename this sensor, currently called Power (POUT), to something like "CPU Power consumption", for example? When said that this "is supposed to be the power use of your CPU" does this refer to the CPU Package = Cores + iGPU? Or something else?

Looking forward to your reply, thank you.

PS_1 : when I said above that I've run my favorite stress test a bit, I was referring to the x264 Stability Test v2.06.

PS_2 : I've run the stress test again right now, for a few seconds, and I was watching my Kill A Watt Meter, in which I have my entire system connected, see sig_rig (without the chassis fans). The meter was showing around 250W and Power (POUT) was indicating 200W. So, I assume the sensor is functioning properly.


----------



## Mumak

Well, I'm not sure. At the first look it looked like an invalid readout (200W is too much for the CPU). Those ISL VRMs are a bit odd wrt monitoring...
VOUT=1.605, IOUT=63A, that should give ~101W POUT (=VOUT*IOUT), but the VRM says twice so much...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, I'm not sure. At the first look it looked like an invalid readout (200W is too much for the CPU). Those ISL VRMs are a bit odd wrt monitoring...
> VOUT=1.605, IOUT=63A, that should give ~101W POUT (=VOUT*IOUT), but the VRM says twice so much...


I see...!

So, you mean that there is an error, somewhere?!

What would you like me to do?

Should I restore HWiNFO at its default state, reboot, leave my PC on idle for a minute or two, and then run the stress test, and send you the debug file?


----------



## Mumak

Probably a problem in VRM reporting, but I don't think I can do anything about that. Restoring HWiNFO or rebooting won't help.
You might try different load levels (from idle to full) when the power reported is more-less stabilized and compare it with the meter at wall. But this will likely only help to understand the difference.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Probably a problem in VRM reporting, but I don't think I can do anything about that. Restoring HWiNFO or rebooting won't help.
> You might try different load levels (from idle to full) when the power reported is more-less stabilized and compare it with the meter at wall. But this will likely only help to understand the difference.


Okay...IF there's nothing that can be done about it, I'll let it be.

Do you think that the fact that I'm using Adaptive VCore (and cache V) might have something to do with it?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Do you think that the fact that I'm using Adaptive VCore (and cache V) might have something to do with it?


No, I don't think so.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> No, I don't think so.


Okay.

I'm returning to this issue because I'd like to clarify something: this erroneous readout is a problem of my motherboard then? So, this specific sensor on my motherboard is faulty? Would you suggest that perhaps I should ask ASRock Technical Support for the correct way to monitor this sensor? And what about the other value(s), like Current (IOUT), do they seem correct to you?

Finally, can there possibly be a setting in the BIOS that interferes with this?

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay.
> 
> I'm returning to this issue because I'd like to clarify something: this erroneous readout is a problem of my motherboard then? So, this specific sensor on my motherboard is faulty? Would you suggest that perhaps I should ask ASRock Technical Support for the correct way to monitor this sensor? And what about the other value(s), like Current (IOUT), do they seem correct to you?
> 
> Finally, can there possibly be a setting in the BIOS that interferes with this?
> 
> Thanks.


I think it's by design. So just ignore those values.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think it's by design. So just ignore those values.


Well... okay, yeah... I mean, if I will just ignore it, no big deal but... do you mean that this is specific to the Intel Z97 chipset? I do not recall right now IF on my ASUS Hero VII it is the same. When you say to ignore those value*s* are you referring to the Current (IOUT), as well?! And why not just divide Power (POUT) by 2 or 1.9, for example, to get a more accurate readout?


----------



## Mumak

Hm, how about dividing by 3.1415926353 ? Or Planck's constant ?
It's a matter of the ISL VRM only. Because its datasheet doesn't precisely say how to convert POUT, I could adjust it only in case someone would perform tests that would prove the POUT is always twice as much as expected. This can be done at various stabilized power levels either by measuring power at wall and checking the difference, or by checking IOUT*VOUT and compare with POUT at various levels.
So if you can do such tests, I'll check the results and act depending on that.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> It's a matter of the ISL VRM only. Because its datasheet doesn't precisely say how to convert POUT, I could adjust it only in case someone would perform tests that would prove the POUT is always twice as much as expected. This can be done *at various stabilized power levels* either by measuring power at wall and checking the difference, or by checking IOUT*VOUT and compare with POUT *at various levels*.
> So if you can do such tests, I'll check the results and act depending on that.


If you will guide me step by step, and if you think that I could do such tests with my computer and my my Kill A Watt Meter only, I could try it. On my meter on the wall, by the way, I have connected my entire system - and not just my tower (chassis) - as I already said. So, it shows the power consumption of my two monitors and my modem/router, as well.

So, if you will tell me EXACTLY what to do, I could do it.

For example, what do you mean with the bold text, above? Which programs should I run and for how long? Or, you mean something completely different?


----------



## Mumak

OK, the trick is to get a more-less stable reading of IOUT or POUT, which doesn't fluctuate much. I'd start with idle, then try various CPU loads, up-to full load. But I'm sorry, I don't know which tool to use to get such levels. I guess you know a few such tools, which can put different load on just one core or all, so try and see what happens. Perhaps you might also try fixed voltage to see if you can get different power levels.
For each of those steps (various load levels) write down the VCCIN (under mainboard), IOUT, VOUT, POUT and wall power values. I'll then try to make sense of it and see if there's a correlation - like POUT is always twice as much as expected and needs to be adjusted in HWiNFO.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> OK, the trick is to get a more-less stable reading of IOUT or POUT, which doesn't fluctuate much. I'd start with idle, then try various CPU loads, up-to full load. But I'm sorry, I don't know which tool to use to get such levels. I guess you know a few such tools, which can put different load on just one core or all, so try and see what happens. Perhaps you might also try fixed voltage to see if you can get different power levels.
> For each of those steps (various load levels) write down the VCCIN (under mainboard), IOUT, VOUT, POUT and wall power values. I'll then try to make sense of it and see if there's a correlation - like POUT is always twice as much as expected and needs to be adjusted in HWiNFO.


Okay. Here is what I will do:

1) I will clear CMOS and Load Optimized Defaults.
2) I will restore HWiNFO64 to its original state, and only perhaps move some sections closer to each other simply because I won't be able to take screenshots otherwise.
3) I will then monitor for 10 minutes on idle (= not touching my computer at all).
4) Then I will run the following stress tests: x264 Stability Test v2.06, Prime95 latest version and CPU-Z bench test, for five (5) minutes, each. As soon as each test will reach 5 minutes, I will take a screenshot. Then I will reset HWiNFO64 and start the new stress test.

Then I will post the results.

Do you agree with this method?

And does it make sense to observe my meter on the wall, since my two monitors and the router (and my chassis, of course) are connected to it?
Note: I could, of course, power off both my monitors and the router during the stress tests!

Thank you!


----------



## Mumak

I think it's not needed to reset CMOS, nor reset HWiNFO. Just make sure you can get various power levels (loads). Perhaps if there would some tool that can load only one core, or load at let's say 50% (or other intermediate levels) stable. I know there's an Intel tool called TAT that can do this, but it's available under NDA only.
You also don't need to wait so long (10 mins), I guess if you get more-less stable readouts for ~30 seconds, it should be enough.
You can watch the wall readout as long as the only thing that changes is the CPU load - so for example you don't switch one of the monitors off during test, etc.
What I need to know is the difference in readouts during various CPU load conditions (and thus varios POUT values).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think it's not needed to reset CMOS, nor reset HWiNFO. Just make sure you can get various power levels (loads). Perhaps if there would some tool that can load only one core, or load at let's say 50% (or other intermediate levels) stable. I know there's an Intel tool called TAT that can do this, but it's available under NDA only.
> You also don't need to wait so long (10 mins), I guess if you get more-less stable readouts for ~30 seconds, it should be enough.
> You can watch the wall readout as long as the only thing that changes is the CPU load - so for example you don't switch one of the monitors off during test, etc.
> What I need to know is the difference in readouts during various CPU load conditions (and thus varios POUT values).


Okay, I understand. I will reset CMOS and Load Optimized Defaults, anyway. I will run each test for two minutes then.

When it comes to loading one core, will it be OK if I will set the Affinity to 2 threads, in the Task Manager? Or, set just one core Active, in the BIOS?
When it comes to setting 50% steady load, on all four cores, I don't know how to do that. I think Real Temp had such a setting? Does this have to do with on-demand clock modulation?


----------



## LostParticle

Okay, I've cleared CMOS, loaded optimized defaults, then my XMP ram profile. I've disabled, like always, Intel Virtualization Technology and Intel Smart Connect, on-board audio and the ASMedia sata controller.

Then I've hidden the unnecessary values and run my tests, each one for approx. two minutes. I've rebooted after the end of each test.

Here are the results:


Spoiler: Warning: Spoiler!











One core active, [was] set in the BIOS.

Finally, I've also reduced the Clock Modulation to 50% using Real Temp, and run the same blend test with Prime95:


Spoiler: Warning: Spoiler!







And here is the last one, with the clock modulation set at 25% :


Spoiler: Warning: Spoiler!







@Mumak, if you require something more, let me know.

Thank you.

PS: by the way, Martin, on the last screenshot, where the on-demand clock modulation is set at 25%, and my processor functions at 27% utilization = 1.04 GHz, as shown in my Task Manager, why is HWiNFO64 showing x42 core ratio and approx. 4.200 MHz clocks?


----------



## Mumak

Thanks for the test and results @LostParticle !
So it really looks like the POUT value should be divided by 2, then it seems to give proper results.
I'll update HWiNFO to reflect this.


----------



## LostParticle

Thank you and I sincerely hope you are right in regard to the division by two! Please verify it!









Please, also, read my last post again because I have just updated it.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thank you and I sincerely hope you are right in regard to the division by two! Please verify it!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Please, also, read my last post again because I have just updated it.


Yes, I believe I'm right about the division. In fact, because the ISL datasheet didn't properly describe values like POUT, I felt it needs to be multiplied by 2. But after running this test, it proved that I was wrong.
WRT On-demand Clock Modulation, I believe the real CPU frequency doesn't change, it's only modulated.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, I believe I'm right about the division. In fact, because the ISL datasheet didn't properly describe values like POUT, I felt it needs to be multiplied by 2. But after running this test, it proved that I was wrong.
> WRT On-demand Clock Modulation, *I believe the real CPU frequency doesn't change, it's only modulated*.


Okay Martin, I'm looking forward to the next build then!










When it comes to the clock modulation, I respect your point of view but... rationality says that a monitoring tool should always present the current state of a system. Like the Task Manager, itself, does!

In fact, you could consider incorporating this nice little feature Real Temp offers, where you can actually set the clock modulation, so that we won't have to download/search other tools to accomplish it.

Thanks again, keep up the good work!


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I assume the Power (POUT) value was originally under the VRM sensor. Those sensors can measure the current and voltage (and thus power as well) at both - the input and output side of the VRM. Usually the input side is connected to PSU and output to the particular rail. Thus the output/input ratio determines the VRM efficiency (loss by the VRM).


Hey Martin,

Thanks for the latest beta which treats the Power (POUT) issue; it works fine now on my system!









I would like to ask you, though, for a more indicative name (label) for this Power (POUT) value. To what should I rename it so that it will become more understandable?

Now, I have quoted a previous message of yours, however I do not fully understand the name (label) I could give it.

What is your opinion?

Also, I do not understand how it works. For example, right now I have Power (POUT) = 18 W. What does this mean, exactly?

*Here is a screenshot* showing the default position of this value (in the previous beta version).

Thank you


----------



## deepor

The value is basically the power use of the CPU. It's reported by a sensor that is monitoring the parts of the board that are transforming the 12 volt direct-current electricity from the PSU to the voltage that the CPU wants to have. Those parts are called "VRM = voltage regulator module" and are sitting somewhere on the board between the CPU socket and the 8-pin CPU power connector. They know about input and output voltage, and output current. That's why they can guess the power use (because voltage multiplied with current is power). You should name it however you want it as the name is for you. I would use something like "VRM power output".


----------



## LostParticle

Quote:


> Originally Posted by *deepor*
> 
> The value is basically the power use of the CPU. It's reported by a sensor that is monitoring the parts of the board that are transforming the 12 volt direct-current electricity from the PSU to the voltage that the CPU wants to have. Those parts are called "VRM = voltage regulator module" and are sitting somewhere on the board between the CPU socket and the 8-pin CPU power connector. They know about input and output voltage, and output current. That's why they can guess the power use (because voltage multiplied with current is power). You should name it however you want it as the name is for you. I would use something like "VRM power output".


Okay, thank you again deepor, and +REP to you this time for your contribution.

Two more questions:

1) I have another sensor, originally called "CPU Package Power", which I have renamed to "(CPU + iGPU) Package Power", and this one I believe is basically the power use of the CPU. Am I wrong?

2) Okay, I will rename Power (POUT) to "VRM Power Output". Can you please tell me, is there a "best", an efficient, value for this sensor? I mean, for example, I know that my Core Max temp is better to stay as low as possible! Is there something similar that can be said about this Power (POUT)?

I hope you understand me.









Thank you.

@Mumak, your contribution is always welcomed, however besides that, here's what I have just observed:



On the latest beta the Average of the On-Demand Clock Modulation turns to red color font, without me ever having set it to do so (of course). After a little while it turns back to color black, and now it's red again.

Have a look, please, thanks.


----------



## Mumak

The POUT value under ISL6367.. sensor is the power measured by VRM which provides voltage to the CPU, more precisely the VCCIN rail. So it's the power consumed by this rail.
"CPU Package Power" is measured by the CPU itself and it should cover the power consumed by the whole CPU package, though Intel doesn't say exactly what's all included.
Note, that CPUs usually take multiple voltage rails for different domains. Haswell family is an exception because of the FIVR, thus the CPU is supplied via VCCIN.

Thanks for the observation on "On-Demand Clock Modulation", I will fix that.


----------



## LostParticle

Hey Martin, just letting you know about this, as well











Spoiler: Warning: Spoiler!



Custom Scaling Level = 125%


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, just letting you know about this, as well
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> Custom Scaling Level = 125%


Thanks, will be fixed...


----------



## orlfman

hey! this probably has been asked before but wondering..... what's the difference between "gpu core power" and "gpu chip power?" i'm assuming gpu core power just shows power be drawn by the gpu core itself and chip power is the entire card? like memory, auxiliary, and core?

i've noticed both showing completely different results. with core showing higher wattage.


thanks!


----------



## Mumak

Yes, "GPU Core Power" shows the power consumed by the core rail of the GPU only, so it doesn't include the consumption of other components in the chip.
"GPU Chip Power" should show the estimated consumption of the entire GPU chip - so this is Core Power + Memory Controller power (VDDCI) + additional logic. Note, that the additional items might not always be truly measured as the GPU doesn't really monitor power consumption of all its rails. So for some models the VDDCI and additional logic consumption is rather estimated based on known parameters (this should be a more-less accurate estimation).
Also note that if the GPU workload fluctuates frequently you might see discrepancies in these values due to instantaneous peaks. The "GPU Core Power" shows an instantaneous value, while "GPU Chip Power" uses a little averaging over a very short period of time to flatten reporting of such peaks. Depending on workload scenario, it might be better to compare the average values rather than current.


----------



## orlfman

Quote:


> Originally Posted by *Mumak*
> 
> Yes, "GPU Core Power" shows the power consumed by the core rail of the GPU only, so it doesn't include the consumption of other components in the chip.
> "GPU Chip Power" should show the estimated consumption of the entire GPU chip - so this is Core Power + Memory Controller power (VDDCI) + additional logic. Note, that the additional items might not always be truly measured as the GPU doesn't really monitor power consumption of all its rails. So for some models the VDDCI and additional logic consumption is rather estimated based on known parameters (this should be a more-less accurate estimation).
> Also note that if the GPU workload fluctuates frequently you might see discrepancies in these values due to instantaneous peaks. The "GPU Core Power" shows an instantaneous value, while "GPU Chip Power" uses a little averaging over a very short period of time to flatten reporting of such peaks. Depending on workload scenario, it might be better to compare the average values rather than current.


thanks so much for the clarification


----------



## gupsterg

@Mumak

+rep for latest update in HWiNFO.

I have a glitch where HBM clock is reported as 550MHz when it's 545MHz in ROM, I've reset HWiNFO to defaults, etc. Any input you can give be appreciated







.


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> +rep for latest update in HWiNFO.
> 
> I have a glitch where HBM clock is reported as 550MHz when it's 545MHz in ROM, I've reset HWiNFO to defaults, etc. Any input you can give be appreciated
> 
> 
> 
> 
> 
> 
> 
> .


I have changed reporting of HBM clock in later versions and this works with a granularity of 50 MHz only. Was HBM clock reported correct with earlier HWiNFO versions ?
It would also be helpful if you could attach the HWiNFO Debug File so I can see further details.


----------



## gupsterg

Last version I used prior to this version was v5.32.2900, which was correct. I can try the other versions in between the 2 if you like? I only updated to newer as saw this new GPU power feature and wanted to try it







.



I can do debug, but I think maybe waste of time, as you have posted you've changed the granularity to 50MHz so 545 would show up as 550 IMO. Is there a reason to granularity change? ie you've gained new info on HBM clocking?


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> I can do debug, but I think maybe waste of time, as you have posted you've changed the granularity to 50MHz so 545 would show up as 550 IMO. Is there a reason to granularity change? ie you've gained new info on HBM clocking?


Yes, I found some more information on detecting HBM clock, but it seems the method is not working properly and might need an adjustment.
Please attach the Debug File from the latest version - that might tell me if I can fix the new method, or will have to revert to the original one.


----------



## gupsterg

Cheers







.

HWiNFO64_debug.zip 64k .zip file


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> Cheers
> 
> 
> 
> 
> 
> 
> 
> .
> 
> HWiNFO64_debug.zip 64k .zip file


Hm, I get an error when I try to download that file...


----------



## gupsterg

I think it's something up with the forum, had this with attachments for a day or so, gotta report it.

Try this link on my GD.

The ROM I'm using is just 1 HBM clock profile (ie stock with clock change only).


----------



## Mumak

Thanks. I'll revert back to the original method until I find a fix for the new one.


----------



## gupsterg

Cheers







.


----------



## orlfman

so... i built a x99 rig to mess around with. paired up, originally a 6800k, but now a 6850k with a gigabyte x99 ultra gaming. yesterday i updated its bios to the latest stable f5. today i updated it to its latest beta bios, f6a, since it improved memory compatibility.

well yesterday with the 6800k on f5 i noticed vcore would randomly drop to 0 volts for a split second or randomly display 2.0 volts for a split second. temperature 4 would randomly display 0c, 87c, or -87c for a split second.

well today i swapped out the 6800k for a 6850k since i want to mess around with my crossfire 480's in 16x x 16x and updated the bios to f6a. since updating tp f6a vcore now shows a solid 0.108 volts...

i disabled turbo boost all together, manually set multiplier to 36, disabled all cstates, disabled intel speedstep (EIST), and set vcore voltage to "normal" with a 0.00 offset since i'm running it at stock. bios shows a vcore of 1.138 volts. cpu-z shows the same. aida64 shows 1.147 volts and gigabytes system viewer shows 1.147 volts as well.

with both 6800k and 6850k all those things where disabled.

so i really don't know which one is showing a correct value. i'm inclined to believe my bios and gigabytes own system viewer (and aida64 since it shows the same). i remember reading that cpu-z only shows vid not vcore. i know GB system viewer shows a little higher vcore than bios but i've noticed over the years vcore is typically a little higher in windows than in bios.

could a bios update cause the sensors to miss read? could the sensors be faulty or is hwinfo reading them incorrectly?


----------



## Mumak

You're right, the Vcore value reported by HWiNFO doesn't seem to be valid. I'll adjust this in the next HWiNFO build.
I'm not even sure if this board can monitor the Vcore rail at all, my guess is that the BIOS and GIGABYTE tool report VID instead of Vcore and the other tools might do as well. Can you please check the VID values reported by HWiNFO if they are same as the Vcore values reported by other tools ?

EDIT: Just got confirmation, that AIDA64 reports VID as Vcore there, so I assume all others too.


----------



## orlfman

Quote:


> Originally Posted by *Mumak*
> 
> You're right, the Vcore value reported by HWiNFO doesn't seem to be valid. I'll adjust this in the next HWiNFO build.
> I'm not even sure if this board can monitor the Vcore rail at all, my guess is that the BIOS and GIGABYTE tool report VID instead of Vcore and the other tools might do as well. Can you please check the VID values reported by HWiNFO if they are same as the Vcore values reported by other tools ?
> 
> EDIT: Just got confirmation, that AIDA64 reports VID as Vcore there, so I assume all others too.


yeah i checked the vids hwinfo reports and it matches the values shown by cpu-z and aida64.


----------



## Arctucas

A question; with respect to VCore, under the column heading of Maximum, is the reported value not the highest value seen during the time the HWiNFO window is open?


----------



## Mumak

Quote:


> Originally Posted by *Arctucas*
> 
> A question; with respect to VCore, under the column heading of Maximum, is the reported value not the highest value seen during the time the HWiNFO window is open?


Yes, it is.


----------



## LostParticle

Hi Martin









Thank you for the latest version!

Is it monitoring the health of my Samsung SSD correctly?


Spoiler: Warning: Spoiler!







Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you for the latest version!
> 
> Is it monitoring the health of my Samsung SSD correctly?
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> Thank you.


I think so. I have checked several Samsung drives and came to the conclusion that for determining Drive Health, one should use the Wear Leveling Count (B1 attribute) instead, so I made this change in the last version.
Problem is that Samsung Magician doesn't show exact health percentage. But you might try some other tools like HD Sentinel, HDD Guardian or GSmartControl to get another opinion. I'd be interested in the results you get...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think so. I have checked several Samsung drives and came to the conclusion that for determining Drive Health, one should use the Wear Leveling Count (B1 attribute) instead, so I made this change in the last version.
> Problem is that Samsung Magician doesn't show exact health percentage. But you might try some other tools like HD Sentinel, HDD Guardian or GSmartControl to get another opinion. I'd be interested in the results you get...


Ah, I see... I do not have much of an idea on these matters, I just asked you because I've observed that 96% value on the current build. I'm actually hiding these values on my everyday monitoring with HWiNFO.

I've checked that B1 attribute in Samsumg Magician (Smart table) and it says 96, as well. Here's what the programs you suggested show:


Spoiler: Warning: Spoiler!







So, it is monitoring the health correctly. Anyway, my current main OS drive is the brand new Samsung EVO shown. The SanDisk is used for Win 10 TP builds and the Samsung Pro is running Linux Mint 18, just for the fun of it.

Should I worry about the 96% of Samsung Pro's health and the 97% of SanDisk's health, you think? I'd like to keep them for another year.

Thank you


----------



## Mumak

Thanks, so HD Sentinel confirms what HWiNFO shows now.
I think 96% is still very good and no need to worry.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks, so HD Sentinel confirms what HWiNFO shows now.
> I think 96% is still very good and no need to worry.


Thank you, keep up the excellent work you're doing, and Merry Christmas to you and your family!


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thank you, keep up the excellent work you're doing, and Merry Christmas to you and your family!


Thank you and Merry Christmas to you too (and all other users of HWiNFO







).


----------



## The Sandman

Hey Martin, great work you do here. Truly appreciate it









Can you share *any* info on the newer WHEA (CPU cache errors) feature recently added? (AMD rig)
Seems odd to me while stressing a new OC with IBT AVX and it passes, I "sometimes" find a small number of Cache1 + 2 errors. Is this feature reliable (as in showing instability) and what is it reading/telling me? System is listed in rig sig.

Also wanted to ask for myself, on my CHV-Z is either set of sensors (ROG or ITE) preferred over the other? I see a difference of 10c on my CPU socket temp between the two headers. For voltage I can use the mobo Probelt points to verify but temps becomes a guessing game.


----------



## Mumak

Quote:


> Originally Posted by *The Sandman*
> 
> Hey Martin, great work you do here. Truly appreciate it
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Can you share *any* info on the newer WHEA (CPU cache errors) feature recently added? (AMD rig)
> Seems odd to me while stressing a new OC with IBT AVX and it passes, I "sometimes" find a small number of Cache1 + 2 errors. Is this feature reliable (as in showing instability) and what is it reading/telling me? System is listed in rig sig.


WHEA reporting should be very accurate. If you see errors there, you might also check the Windows Event Viewer for details: Application and Service Logs - Microsoft - Windows - Kernel-WHEA - Errors.
WHEA errors can always be considered serious and in your case the CPU Cache errors seem to be triggered as a CPU correctable Machine-Check errors (MCA). If this happens on an overclocked system, I think you went too far or use some settings that make the system not stable.
Quote:


> Originally Posted by *The Sandman*
> 
> Also wanted to ask for myself, on my CHV-Z is either set of sensors (ROG or ITE) preferred over the other? I see a difference of 10c on my CPU socket temp between the two headers. For voltage I can use the mobo Probelt points to verify but temps becomes a guessing game.


Correct CPU socket temperature in your case should be the one listed under the ITE sensor, which you might confirm with ASUS AISuite. There should be no CPU temperature listed under the ROG sensor. Do you see such there ?


----------



## The Sandman

Quote:


> Originally Posted by *Mumak*
> 
> WHEA reporting should be very accurate. If you see errors there, you might also check the Windows Event Viewer for details: Application and Service Logs - Microsoft - Windows - Kernel-WHEA - Errors.
> WHEA errors can always be considered serious and in your case the CPU Cache errors seem to be triggered as a CPU correctable Machine-Check errors (MCA). If this happens on an overclocked system, I think you went too far or use some settings that make the system not stable.
> Correct CPU socket temperature in your case should be the one listed under the ITE sensor, which you might confirm with ASUS AISuite. There should be no CPU temperature listed under the ROG sensor. Do you see such there ?


Thank you very much for the explanation.

Yes I've seen socket temp on both headers in my CHIV-F (back in the day) and this CHV-Z.
ROG header original value labeled "T0"


Spoiler: Warning: Spoiler!







ITE header originally CPU as shown


Spoiler: Warning: Spoiler!







I remember reading way back when the CHV-F was first released (late 2010) a member had claimed the ROG header was the one to use at that point. I believe he said he posted in HWInfo forum of the time.
From that point on I just took it for granted things had not changed. Thoughts?

I'll use my OC OS/SSD and DL AI suite (as much as i hate it). That drive is due to be re-imaged soon anyway. I'll compare the socket values and go from there.
The reason I brought this up is there is a 10c difference when under load, everyday use very close to the same.


----------



## Mumak

Well, lots of values under the ROG header on your screenshot were renamed by you, so they are not the original labels shown by HWiNFO. You can check this by trying to rename them again, then HWiNFO should show the original name too.
So the "CPU Socket" label (and some others) is what you believed to be, but it's most probably not correct. Only ASUS knows exact meaning of those values, as that's their proprietary stuff.


----------



## The Sandman

Quote:


> Originally Posted by *Mumak*
> 
> Well, lots of values under the ROG header on your screenshot were renamed by you, so they are not the original labels shown by HWiNFO. You can check this by trying to rename them again, then HWiNFO should show the original name too.
> So the "CPU Socket" label (and some others) is what you believed to be, but it's most probably not correct. Only ASUS knows exact meaning of those values, as that's their proprietary stuff.


Sorry, just ninja'd ya and edited my post above.
I'm very aware of all the name changing, it took hours to confirm/organize lol.


----------



## Mumak

Yeah, that's why it HWiNFO calls "T0"







Just a generic name because I don't know to which source that temperature belongs. Might be a sensor somewhere on mainboard, but not close to CPU socket.


----------



## Symbfrk2

Hey there Martin, I believe you are the main programmer of HwInfo, right? I would like to ask you something:

Actually, I am experiencing random lags / periodic freezes in every game. I have been trying to troubleshoot the issue since more than a month now to no avail. Just recently I discovered HwInfo and decided to keep it running to see if it reports anything. I noticed that under the "Performance limit reasons" there is a field called "IA: Graphics Driver" that reports a "Maximum" value of "Yes" after a few minutes of gaming. I wanted to know what does this value means? Could this be the reason behind random lags? And how would I go about having it fixed? This is my last hope for getting rid of random lags. Thankyou!

Here are the core specs of the system if that helps:
Core i7 4790K (stock)
Msi Z97 Gaming 5 (default BIOS settings)
Corsair vengeance 16 GB (XMP Enabled, 2400Mhz)
Corsair 550 watt PSU
No Dedicated GPU (Using iGPU)


----------



## Mumak

Quote:


> Originally Posted by *Symbfrk2*
> 
> Hey there Martin, I believe you are the main programmer of HwInfo, right? I would like to ask you something:
> 
> Actually, I am experiencing random lags / periodic freezes in every game. I have been trying to troubleshoot the issue since more than a month now to no avail. Just recently I discovered HwInfo and decided to keep it running to see if it reports anything. I noticed that under the "Performance limit reasons" there is a field called "IA: Graphics Driver" that reports a "Maximum" value of "Yes" after a few minutes of gaming. I wanted to know what does this value means? Could this be the reason behind random lags? And how would I go about having it fixed? This is my last hope for getting rid of random lags. Thankyou!
> 
> Here are the core specs of the system if that helps:
> Core i7 4790K (stock)
> Msi Z97 Gaming 5 (default BIOS settings)
> Corsair vengeance 16 GB (XMP Enabled, 2400Mhz)
> Corsair 550 watt PSU
> No Dedicated GPU (Using iGPU)


Yes, I am.
That flag means the CPU frequency was reduced below the operating system request due to Processor Graphics driver override. But I don't think it is the reason behind those lags.
Such lags can have several different reasons and it's not easy to diagnose.
Perhaps you could try to enable sensor logging and then examine the status when lags occurred.
Another option might be to use RTSS (RIVA Tuner Statistics Server, which is a part of MSI Afterburner, or a separate package) to show HWiNFO values on OSD in game and follow the state right when it's happening. There's a guide here on OCN how to configure it: http://www.overclock.net/t/1229915/how-to-cpu-and-gpu-usage-along-with-fps-in-game

EDIT: I have just realized that I missed that you don't have a dedicated GPU and instead rely only on iGPU. Are you sure that iGPU can cope with those games? In such case the mentioned Performance Limiting Reason might be the cause of reduced CPU performance.


----------



## The Sandman

Quote:


> Originally Posted by *Mumak*
> 
> Yeah, that's why it HWiNFO calls "T0"
> 
> 
> 
> 
> 
> 
> 
> Just a generic name because I don't know to which source that temperature belongs. Might be a sensor somewhere on mainboard, but not close to CPU socket.


Awesome, that explains things. Thank you for your help and time! (+Rep for all you do here)


----------



## Symbfrk2

Thanks for the quick and detailed response, I will try the RTSS thing tomorrow. And yes, I think iGPU can cope with the games I am playing because I mostly play "League of Legends" and "Overwatch" and both, especially league, require fairly low graphics power to run at 60+ FPS (lowest settings 720p). It lags the same way in both games.

The lag is slight and intermittent in nature. Basically the screen either stutters or freezes for less than a second (200ms maybe) every now and then, however the sound remains constant instead of getting stucked. Then it becomes smooth again like nothing happened. This lag started happening after I Installed a new CPU cooler. The computer was running perfectly fine before, albeit it was underclocked to 4.0Ghz with vCore @1.0 because the stock heat sink couldn't keep the temperatures reasonable. After adding CPU cooler, I resetted the BIOS settings to remove the underclock. Since then its having this issue.

So now I have 2 questions:

1) Could it be that I have somehow damaged my CPU ever so slightly while installing the cooler? It took some force to have it mounted but not too much. Its a cryorig H7. I have tried reseating it 2x times but no use. I ran stress tests including AIDA64, IntelBurnTest and Prime95 numerous times and the computer passed all of them with mid 70 temperatures... but I am not sure...

2) Is there a way to prevent the "IA:Graphics Driver" from going to "Yes" state? I mean this is not normal, right? So there must be a way to fix it.


----------



## Mumak

I don't think it's possible to damage the CPU in such a way. 70 C is a good temperature, check how much it is while running the games.
That performance limiting reason is not something wrong, I believe it happens because the iGPU demands more power, so it reduces CPU clock to remain within power envelope of the entire CPU package.
Perhaps the BIOS reset resulted in some other settings disabled that reduce the performance or have other effect. I'd suggest to check them again, or try again with undeclocking if the problem persists. If it works underclocked try to raise the clock/voltage and see what happens while watching system status.


----------



## LostParticle

Hey Martin, I've just observed that on the latest beta, v5.43-3065, when I reset HWiNFO64 from the clock icon on the bottom right corner, the total DL & UP values are not (re)set to zero. Shouldn't they reset to a zero value, as well? I think so, can you please check it out?









Thank you









EDIT: I've just observed that even if I will close and reopen the tool these values do not reset to zero! I have closed it four times, both from the X button on the top and the bottom right corners, and after reopening it, it was still showing me an amount of MB in download and upload totals...It was not showing zero.


----------



## Caos

Hi, I have an asus x99 strix, but hwinfo64 does not detect the vcore of the cpu. Why?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hey Martin, I've just observed that on the latest beta, v5.43-3065, when I reset HWiNFO64 from the clock icon on the bottom right corner, the total DL & UP values are not (re)set to zero. Shouldn't they reset to a zero value, as well? I think so, can you please check it out?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> 
> 
> EDIT: I've just observed that even if I will close and reopen the tool these values do not reset to zero! I have closed it four times, both from the X button on the top and the bottom right corners, and after reopening it, it was still showing me an amount of MB in download and upload totals...It was not showing zero.


Yes, those values come straight from network statistics and cannot be reset via HWiNFO.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Hi, I have an asus x99 strix, but hwinfo64 does not detect the vcore of the cpu. Why?


AFAIK this mainboard is not able to really monitor Vcore. Even ASUS own tools report the CPU VID (which is also available in HWiNFO) as Vcore.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, those values come straight from network statistics and cannot be reset via HWiNFO.


I see, what do you mean from the Network statistics? Like from the Task Manager or, what?

From what I have seen these values currently reset only after rebooting. I am fairly certain though that in the past, perhaps quite some time ago, I could reset those values. Has something changed?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> I see, what do you mean from the Network statistics? Like from the Task Manager or, what?
> 
> From what I have seen these values currently reset only after rebooting. I am fairly certain though that in the past, perhaps quite some time ago, I could reset those values. Has something changed?
> 
> Thank you.


Nothing has changed here, so I don't think you were ever able to reset them via HWiNFO.


----------



## LostParticle

Hey Martin, I have observed something today and it is puzzling me, so please read carefully, I hope you will be able to help me









In my system I have three SSDs. Two Samsung and one SanDisk (system fully shown in my sig_rig). On my SanDisk I install and test the Windows 10 Insider builds. Yesterday Microsoft released the ISO for the 15025 preview build, so today I have clean-installed it. I removed (disconnected) the other two (Samsung) SSDs from my system and I left only my SanDisk and performed the clean installation.

After completing it I got the latest version of HWiNFO64. I expanded it in three tables, closed it, rebooted and then I have just renamed the Read Activity, Write Activity, Total Activity and Drive Temperature to "... SanDisk". So, for example instead of "Read Activity" I renamed it to "Read Activity SanDisk". Similarly, for the others I mention. I rebooted, checked it out, all good!

Then I have plugged in my other two SSDs, the Samsungs. Of course, I have cleared CMOS and Loaded Optimazed Defaults, to perform this action.

When I booted back into Windows 10 15025 TP build though, so in my SanDisk SSD, I observed that the values I have renamed were now appearing under my Samsung's values! And additionally, the Drive temperature custom label was gone.

It looks like this:



- Why are the values that I renamed, and belong to my SanDisk drive for sure (since it was the ONLY drive connected to my system when I renamed them), so why are they appearing under my Samsung 850 EVO's table of values?


----------



## Mumak

This is because such custom sensor settings are bound to a particular sensor index (i.e. instance index depending on detection order), not a specific unique device ID. So if the order of sensor items in system changes (which is not likely to happen), it might cause such discrepancy.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> This is because such custom sensor settings are bound to a particular sensor index (i.e. instance index depending on detection order), not a specific unique device ID. So if the order of sensor items in system changes (which is not likely to happen), it might cause such discrepancy.


Oh, okay, I see... I thought that all these activities (Read, Write, Total, Temperature, etc) were tight to each device's (disk's) unique ID.

Anyway, no problem for me, I just applied the backed up settings I already have from my primary OS, where I constantly run HWiNFO64. I have verified that my SSDs are monitored correctly by giving them some load (AS SSD Benchmark), from both operating systems, on both of them. They are monitored appropriately.

Personally, I think that the order of the Sensors is very likely to change, in HWiNFO64. It offers lots of values, impossible to fit in its Sensor window, and many dislike scroll-bars. So the values will get Hidden, Renamed, Reordered, etc. At least from those who value System Monitoring, an imperative task for all overclockers, but even for those who run at stock. Just my opinion









Anyway, thank you


----------



## Mumak

In the next build, I will add shaded rows, that should improve appearance.
Of course the user will have an option to disable it.
Here a preview:


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> In the next build, I will add shaded rows, that should improve appearance.
> Of course the user will have an option to disable it.
> Here a preview:
> 
> 
> Spoiler: Warning: Spoiler!


Nice, nice!

Personally, I have resolved this long time ago by applying bold font type to the headers of different sections:


Spoiler: Warning: Spoiler!







Above is HWiNFO running on my secondary monitor, my 23" Dell, at its recommended resolution: 1920 x 1080

But even if I would have another 24" monitor, like my primary one (HP), I would still not be able to fit anything more. Here is the program maximized on my 24" screen, at its recommended resolution: 1920 x 1200


Spoiler: Warning: Spoiler!







As it can be seen, I can add another table but... I cannot see the Averages anymore, scroll-bars appear at the bottom...

So, I have to hide lots of values.

I always run both of my monitors at 125% custom scaling level otherwise everything, text, icons, everything, is minuscule.

Looking forward to the next build!









PS: I am not a gamer but in the RARE case I will play a game, all I have to do is recall to start RivaTuner before HWiNFO64, and then I automatically get this, as soon as the game starts:


Spoiler: Warning: Spoiler!


----------



## Aenra

Hello and the obligatory thanks for this software.

Edit: found what i was looking for.

Suggestion: I know we live in the era of multiple windows, multiple sources all simultaneously demanding our focus and so on (because somehow more is always better), but it would perhaps be nicer if things were a bit more.. organized and/or logically ordered. No offense, just my honest opinion.

Why would you have some voltages in one UI, while keeping the rest in a second, separate one? :s

I honestly see no sense to it.. anyway, ignore post. Only took me a couple of hours, but what the hell, got where i wanted to


----------



## LostParticle

Hey









I just got the latest beta and observed, first hand, what you meant with the new Row Shading feature. In my system it looks like this:


Spoiler: Warning: Spoiler!







My personal and subjective opinion is that the Shading should be applied on the "Headers" only and not "in turn", throughout all the rows. Also, observe please that on empty rows that happen to be shaded the gray shade does not expand to the entire line, it is white in the beginning of the line.

I know this feature can be disabled, I just write my personal opinion.

Thanks


----------



## Mumak

Yeah, I think some users will like only shading of sensor headers, while some others might prefer an uniform shading of all entries including headers. I guess this will require more options to satisfy all..
I will check extending of the shades to icon area...


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yeah, I think some users will like only shading of sensor headers, while some others might prefer an uniform shading of all entries including headers. I guess this will require more options to satisfy all..
> I will check extending of the shades to icon area...


1) Do not extend shading to the icon area, please, IF what you mean by that is that the icons will get covered by gray shade. I think only the empty rows should get fully shaded: from one side to the their other side. The icons look fine the way they are now.

2) A better option, IF you have the time + the pleasure, would be the ability to set a custom background color (and not just gray), for any row the user would desire. Personally, I will most probably keep it "simple and white" but I'm just saying the better option -- personal opinion, of course.

3) In a PM, some time ago, I've suggested you to add the ability of multiple Sensor panels, if you recall. I meant, the user to be able to open/use a second Sensor panel and add in it the values he would need to present, like Memory Timings, or any other value. So, to have two or more Sensor panels open at the same time. You replied to me that this requires lots of hard work, and I fully respect that!

Since for me, and the majority of HWiNFO64 users I believe, space is a main issue - I mean, our problem is "Where to fit all these values?" - I thought to suggest you something else: to add the Averages of some important values. Here is a screenshot, HWiFNO64 fully reset:



Is it possible to add a "Core# VID average", for example? Similarly, a "Core# Clock average", a "Core# ratio average", and similarly for the VCore and the C-State residencies, all I have inside the red rectangles?

My idea is that after a user would have established, stabilized and set up, an overclock, perhaps he would then feel content with just the Averages of these values. And not needing to monitor them in full detail. These averages, for example VCore average, would have Current, Min, Max and Average. These would derive from the individual VCore values, in the most accurate manner you decide. Similarly for the rest.

I am suggesting this because the majority of the screenshots I have seen, have lots of hidden values. Everybody hides lots of things due to lack of space - and personally, I hate scroll bars and find them completely inconvenient.

Finally, I think you should remove the Average of Memory clock + ratio.

Thanks for considering my suggestions


----------



## misoonigiri

Hi, with HWIFO64 opened will HDDs be able to spin down? Assuming I have disabled & hidden those sensors related to my HDDs

Thanks


----------



## Mumak

Quote:


> Originally Posted by *misoonigiri*
> 
> Hi, with HWIFO64 opened will HDDs be able to spin down? Assuming I have disabled & hidden those sensors related to my HDDs
> 
> Thanks


Yes, they should.


----------



## misoonigiri

Thanks for clarifying


----------



## BenjiBenjamin12

Quote:


> Originally Posted by *Mumak*
> 
> Hi all,
> 
> I'm the author of HWiNFO/32/64 tools, which I noticed are quite successfully used here.
> I decided to create a thread on this forum to provide support for these tools, listen to your feedback, opinions and ideas.
> Feel free to ask/request/share thoughts about HWiNFO/32/64 here and I hope you enjoy using these tools.
> 
> 
> HWiNFO main site: https://www.hwinfo.com/
> Download HWiNFO: https://www.hwinfo.com/download.php
> HWiNFO forum: https://www.hwinfo.com/forum
> HWiNFO of facebook: https://www.facebook.com/HWiNFO64
> 
> Martin


Hi, thanks for useful links and information. I really appreciate it!


----------



## LostParticle

@Mumak, just out of curiosity:

Does HWiNFO64 show and monitor VCore on the Intel i7-5960X ?
Or it shows only the VID values?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> @Mumak, just out of curiosity:
> 
> Does HWiNFO64 show and monitor VCore on the Intel i7-5960X ?
> Or it shows only the VID values?
> 
> Thank you.


That depends on mainboard whether it's capable to monitor that rail.
But many Haswell-based systems don't seem to properly monitor Vcore (most probably due to FIVR), so even vendors like ASUS even though featuring Vcore monitoring have switched to report VID instead of Vcore.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That depends on mainboard whether it's capable to monitor that rail.
> But many Haswell-based systems don't seem to properly monitor Vcore (most probably due to FIVR), so even vendors like ASUS even though featuring Vcore monitoring have switched to report VID instead of Vcore.


Thank you, Martin

Do you happen to know if the ASUS RAMPAGE V EDITION 10 is capable of monitoring VCore?
I mean, is this motherboard with the i7-5960X able to show VID and VCore values, at the same time, while HWiNFO64 is running?
Like they are both monitored in my system, for example?

ASUS RAMPAGE V EDITION 10 (Nuvoton NCT6791D)


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Thank you, Martin
> 
> Do you happen to know if the ASUS RAMPAGE V EDITION 10 is capable of monitoring VCore?
> I mean, is this motherboard with the i7-5960X able to show VID and VCore values, at the same time, while HWiNFO64 is running?
> Like they are both monitored in my system, for example?
> 
> ASUS RAMPAGE V EDITION 10 (Nuvoton NCT6791D)


That mainboard is exactly like I described above. Initially it seemed to monitor Vcore, but because the values obtained were so erratic, ASUS has switched to report VID as Vcore. I can see this in the BIOS code as well.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That mainboard is exactly like I described above. Initially it seemed to monitor Vcore, but because the values obtained were so erratic, ASUS has switched to report VID as Vcore. I can see this in the BIOS code as well.


Okay, thank you Martin!









Since we are here, when will the next beta become available?


----------



## Mumak

No ETA yet.


----------



## navjack27

Quick questions.

On my PC is it wise to:
Use CPU package temp as the defining CPU temp to monitor
Believe that the CPU power (W) values are good enough to go by
Same above, but my GPU
That this software is basically God
I should just buy (donate to you) this software at this point as a gesture to buy you a beer


----------



## Mumak

Yes, CPU Package temperature is a good indicator - it's a 256ms average of the hottest temperature among all sensors in the CPU.


----------



## jdorje

So, I've got a new bug.

A while ago I hid a bunch of values in hwinfo, coloring others, so that it all fits in one column. This was actually a good long while ago.

But it doesn't work. Every ~2 seconds (appears to alternate with each refresh of the sensors) the hwinfo window will pop back in all the hidden values. Then it'll stay that way for 2 seconds before going back to just the shown values.

The attached screenshot shows both the successful (beautiful even) single-column setup and the fail show-everything-and-hide-it setup. The headings get slightly messed up too in single-column.

My lazy workaround has been to just keep it at two columns. With the second column empty it nonetheless stops showing this behavior.



http://imgur.com/Y8bnK


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> So, I've got a new bug.
> 
> A while ago I hid a bunch of values in hwinfo, coloring others, so that it all fits in one column. This was actually a good long while ago.
> 
> But it doesn't work. Every ~2 seconds (appears to alternate with each refresh of the sensors) the hwinfo window will pop back in all the hidden values. Then it'll stay that way for 2 seconds before going back to just the shown values.
> 
> The attached screenshot shows both the successful (beautiful even) single-column setup and the fail show-everything-and-hide-it setup. The headings get slightly messed up too in single-column.
> 
> My lazy workaround has been to just keep it at two columns. With the second column empty it nonetheless stops showing this behavior.
> 
> 
> 
> http://imgur.com/Y8bnK


This looks like some serious mess.. Not an easy solution for this, as the best method would be to completely Reset Preferences in HWiNFO, but this would cause a loss of all your custom settings. Perhaps you might try to Backup User Settings, then Reset Preferences and restore the saved settings by launching the saved .reg file from 1st step.
If that won't help and you want to keep your settings, then it would require analysis of user settings - either via the saved .reg file, or directly in registry under HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors. I think there will be some glitches in order of items, but not sure how skilled you are to check that. Perhaps you might try to attach that file here and I could have a look at it...


----------



## nosequeponer

hello:

don´t know if this is a bug or something . it´s a CH6 and ryzen 1700x

one strange thing i notice this morning, started w10, HWinfo loaded, and ask if it should use some sensors from the ASUS, i told him yes, and then the system reboot itself, and got stuck with error code refered as "microcode loading"

after a while, i reboot the system and nothing el se happend..

next time hw asked, i told him NO, and it´s working since then


----------



## navjack27

Why are you referring to the software as him. I'm triggered


----------



## gupsterg

Clearly nosequeponer first language is not English. So I don't think we need to highlight the errors in post.


----------



## nosequeponer

Quote:


> Originally Posted by *gupsterg*
> 
> Clearly nosequeponer first language is not English. So I don't think we need to highlight the errors in post.


thanks...

you got it right.. not native in english... so sometimes i make mistakes...


----------



## gupsterg

Not a problem, you carry on and post your issue







.


----------



## Mumak

Quote:


> Originally Posted by *nosequeponer*
> 
> hello:
> 
> don´t know if this is a bug or something . it´s a CH6 and ryzen 1700x
> 
> one strange thing i notice this morning, started w10, HWinfo loaded, and ask if it should use some sensors from the ASUS, i told him yes, and then the system reboot itself, and got stuck with error code refered as "microcode loading"
> 
> after a while, i reboot the system and nothing el se happend..
> 
> next time hw asked, i told him NO, and it´s working since then


Accessing the ASUS EC sensor can very rarely lead to some issues, but those are mostly performance-related. But I have never seen such a serious one.
You would need to repeat the test again, or enable the ASUS EC sensor in the list to check if it's really causing it.
But I think you will not dare to do that test again


----------



## gupsterg

I know @Sgt Bilko has been using HWiNFO for monitoring on his CH6, no idea if he enabled Asus EC. I received my CH6 today, hopefully by the end the evening I will have built the rig. I plan to enable Asus EC as it gave me extra monitoring data on my M7R. Have you had any other reports via your forum Martin of similar issue?

Cheers as always for your great support on HWiNFO







, I plan to donate again as appreciate your efforts.


----------



## nosequeponer

Quote:


> Originally Posted by *Mumak*
> 
> Accessing the ASUS EC sensor can very rarely lead to some issues, but those are mostly performance-related. But I have never seen such a serious one.
> You would need to repeat the test again, or enable the ASUS EC sensor in the list to check if it's really causing it.
> But I think you will not dare to do that test again


so far it´s not the most stable platform on earth to play with... specially with all the bricking problems...

but i think i can try to enable the sensor while the program is running, and see if something happens there, instead of starting the program... and, if nothing strange happens, restart the program..

also, i´m not using the last bios , didn´t have time to flash it

will let you know later


----------



## Sgt Bilko

Quote:


> Originally Posted by *gupsterg*
> 
> I know @Sgt Bilko has been using HWiNFO for monitoring on his CH6, no idea if he enabled Asus EC. I received my CH6 today, hopefully by the end the evening I will have built the rig. I plan to enable Asus EC as it gave me extra monitoring data on my M7R. Have you had any other reports via your forum Martin of similar issue?
> 
> Cheers as always for your great support on HWiNFO
> 
> 
> 
> 
> 
> 
> 
> , I plan to donate again as appreciate your efforts.


Ummm......wut?









I've been using HWiNFO64 since I got Ryzen (Launch day) and no issues with monitoring EC here.

even as I'm typing this It's running in the background with no issues, weird.....


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> I know @Sgt Bilko has been using HWiNFO for monitoring on his CH6, no idea if he enabled Asus EC. I received my CH6 today, hopefully by the end the evening I will have built the rig. I plan to enable Asus EC as it gave me extra monitoring data on my M7R. Have you had any other reports via your forum Martin of similar issue?
> 
> Cheers as always for your great support on HWiNFO
> 
> 
> 
> 
> 
> 
> 
> , I plan to donate again as appreciate your efforts.


No issues reported either and there were really many folks running it on CH6, including guys from AMD and ASUS long before launch.


----------



## Mumak

Quote:


> Originally Posted by *Sgt Bilko*
> 
> Ummm......wut?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I've been using HWiNFO64 since I got Ryzen (Launch day) and no issues with monitoring EC here.
> 
> even as I'm typing this It's running in the background with no issues, weird.....


Thanks for your feedback.


----------



## gupsterg

Quote:


> Originally Posted by *Mumak*
> 
> No issues reported either and there were really many folks running it on CH6, including guys from AMD and ASUS long before launch.


+rep







.

Asus just released the brick fix ROM, some boards have been going into a "Updating ROM" loop/"Auto bricking". So it just maybe some boards/early UEFI bug for what happened to nosequeponer.


----------



## Sgt Bilko

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Sgt Bilko*
> 
> Ummm......wut?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I've been using HWiNFO64 since I got Ryzen (Launch day) and no issues with monitoring EC here.
> 
> even as I'm typing this It's running in the background with no issues, weird.....
> 
> 
> 
> 
> 
> Thanks for your feedback.
Click to expand...

no worries man, love the program, it's an integral part of everything I do


----------



## jdorje

Quote:


> Originally Posted by *Mumak*
> 
> This looks like some serious mess.. Not an easy solution for this, as the best method would be to completely Reset Preferences in HWiNFO, but this would cause a loss of all your custom settings. Perhaps you might try to Backup User Settings, then Reset Preferences and restore the saved settings by launching the saved .reg file from 1st step.
> If that won't help and you want to keep your settings, then it would require analysis of user settings - either via the saved .reg file, or directly in registry under HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors. I think there will be some glitches in order of items, but not sure how skilled you are to check that. Perhaps you might try to attach that file here and I could have a look at it...


Weird. Simply resetting my preferences (which didn't reset the field ordering) does seem to have fixed it. Guess I shoulda tried that before.

There is still a strange issue that the spacing is different when there's two columns versus one. With just one column some of the empty lines between sections are gone.


----------



## Mumak

Quote:


> Originally Posted by *jdorje*
> 
> There is still a strange issue that the spacing is different when there's two columns versus one. With just one column some of the empty lines between sections are gone.


That's really odd. Resetting preferences should clear everything. Try to enable "Fixed order" in sensor settings/layout if that resolves it.


----------



## LostParticle

I reset HWiNFO64 before each beta build after having my "User Settings" saved on my desktop. To fully reset it I always search for the value "HWiNFO64" in my Registry and delete it. I then check the tool on its default state to see if there's anything new, close it and apply my .reg settings file, and re-open it. It's all set back the way I've customized it. I just have to tick / untick "Auto Start" a couple of times, and close / reopen the program respectively, so that it will keep the setting and load on Windows start up, from then onwards.


----------



## nosequeponer

it is working now fine without a problem..

i also update the bios, i was previously using the one that came with the mobo

something weird happend then.... who knows


----------



## gupsterg

Martin I think there is bug in HWiNFO. I did fresh install of Win 7 Pro today and noticed this on Ryzen/X370.


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> Martin I think there is bug in HWiNFO. I did fresh install of Win 7 Pro today and noticed this on Ryzen/X370.


Well, this is really odd, I will need more help from you to find this problem.
When it happens, do all other sensor values stick as well, or only some (VID and CPU clock) ? Can you please check exactly which ones are affected ? Does it happen right after starting HWiNFO, or anytime later ?
It would also be great if you could attach the HWiNFO Debug File when it happens. First try to kill HWiNFO via Task Manager and grab the Debug File, then try again and when it happens try to close HWiNFO and get another DBG file.


----------



## Mumak

(double post)


----------



## LostParticle

Hi Martin









Wanting to contribute - help on this matter, I'd like to bring to your attention another thing mentioned in that thread:
Quote:


> Originally Posted by *MNMadman*
> 
> ...
> 
> HWinfo has another bug as well -- it randomly resets some of the minimums to 0.0, and the Vcore and DRAM maximum can somehow end up at 2.7v.


I do not know if this is an actual bug, I'm just bringing this to your attention, as well









Finally, I don't know IF this really matters but perhaps HWiNFO64 should be reset to its defaults, before any bug checking.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wanting to contribute - help on this matter, I'd like to bring to your attention another thing mentioned in that thread:
> I do not know if this is an actual bug, I'm just bringing this to your attention, as well
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Finally, I don't know IF this really matters but perhaps HWiNFO64 should be reset to its defaults, before any bug checking.


That doesn't seem like a reset, rather an invalid readout. I will need more details about that - which exact system and at least a screenshot of those erratic values.
Such things can happen when the user runs multiple monitoring tools simultaneously which do not cooperate well.


----------



## gupsterg

Quote:


> Originally Posted by *Mumak*
> 
> Well, this is really odd, I will need more help from you to find this problem.
> When it happens, do all other sensor values stick as well, or only some (VID and CPU clock) ? Can you please check exactly which ones are affected ? Does it happen right after starting HWiNFO, or anytime later ?
> It would also be great if you could attach the HWiNFO Debug File when it happens. First try to kill HWiNFO via Task Manager and grab the Debug File, then try again and when it happens try to close HWiNFO and get another DBG file.


Well do this ASAP







, cheers







.


----------



## gupsterg

Quote:


> Originally Posted by *Mumak*
> 
> I just got confirmation regarding the sticky 1.550V VID readout. It's a bug in the SMU (part of the CPU), not a fault of diagnostic tools. Though in OC mode it should be reported OK.
> Shall be fixed later by AMD...


Sorry Martin not done debug files.

What I have found is if I wait about 1min+ after OS load then launch HWiNFO I do not get stuck sensor data, repeatedly tested now. Before I was only waiting about upto 30secs, always stuck data.
Quote:


> Originally Posted by *Mumak*
> 
> I'm still puzzled by the wrong mainboard sensor readouts on CH6 (i.e. 0V, 2.79V).. Would need more help to find why..
> Anyone knows if other ASUS boards or other tools are affected too?


Quote:


> Originally Posted by *gupsterg*
> 
> I have not used any other SW monitoring tool lengthy time, just for quick views at times when was having the sticking data situation. So far I've never seen 2.79V on VCORE via DMM.
> 
> Just did 10 loops of x264 for 3.8GHz ACB @ 1.29375V
> 
> 
> 
> Next 2hrs RB stress mode at same settings.
> 
> 
> 
> Gonna setup 3.9GHz next hopefully, shall I run HWiNFO in debug mode?


Quote:


> Originally Posted by *Mumak*
> 
> Thanks. The 1C, 0.000 and 0.022 V min values seem to be the same problem - invalid readouts.
> Yep, a DBG file might provide some insights.


Will do this now on 3.8GHz profile as believe it is sound OC and another one for when set 3.9GHz.


----------



## gupsterg

@Mumak

Here is DBG from 3.9GHz OC setting.

HWiNFO64_DBG.zip 1774k .zip file




Spoiler: Screenshots at 3/6/10 loops of x264


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> Here is DBG from 3.9GHz OC setting.
> 
> HWiNFO64_DBG.zip 1774k .zip file
> 
> 
> 
> 
> Spoiler: Screenshots at 3/6/10 loops of x264


Thanks!
This looks like something else in the system is interfering with HWiNFO - it does access the ITE SIO chip and switch register access while HWiNFO attempts to read sensor values. And it doesn't play a fair game...
Are you sure there's nothing else running on the system? Could also be some ASUS software like AISuite..


----------



## gupsterg

No problem







. I never use Asus SW, I don't go for any "bloatware", I OC via ROM, my install of OS:-

i) Win 7 Pro SP1 ISO with USB for X370, after install all current updates.
ii) AMD AM4 chipset drivers from AMD site.
iii) WiFi card Intel AC 7260, drivers from Intel site.
iv) Crimson Driver for Fury X from AMD site.

Only "tools" I have are HWiNFO, HWMonitor, CPU-Z and GPU-Z. Exclusively HWiNFO is run when testing. Only installed Origin last night to have quick whirl of SWBF, then installed [email protected], neither is set to run at OS load. No fancy HW setup like RAID, just SSD/HDD on SATA. OS is bare min







.


Spoiler: Warning: Spoiler!






I have G700S mouse so have the Logitech Gaming SW, keyboard is just Cherry MX board 3.0 so no display, etc.


----------



## Mumak

That's really odd, as none of those should be interfering. Theoretically only HWMonitor, but latest versions should have no problem to play fair with HWiNFO and you also said that you don't run it.
Another possibility would be the BIOS. If it does some real-time SIO access it might be the cause.
Can you please try to run HWMonitor for a while and watch Min/Max values if they get erratic too ?


----------



## gupsterg

No problem







. Will use HWmonitor for RealBench 3.9GHz OC stability test now for 2hrs run.

Quick question is AVCC3 the +3.3V rail in HWiNFO?



*** edit ***

Currently HWMonitor is also "iffy" , just look at my Fury X overvolt







.



Will carry on doing full 2hrs.


----------



## Mumak

Thanks, that again confirms that other tools are affected too, including HWMonitor. We will need to check with ASUS.
Yep, AVCC3 is the +3.3V rail.


----------



## gupsterg

Thanks, just read your post in C6H owners thread, I really appreciate you looking at this







.

Just seen the 2.79V volts as well in HWMonitor.



HWMonitor isn't even getting the fan PWM, I know why HWiNFO is my no1 choice!







.


----------



## nosequeponer

regarding vcore readings, got 2 different values, depending on the sensor



1.555 or 1.35

also, on cpuid states 1.352

which one is the correct one??


----------



## gupsterg

@Mumak

Have you seen this info on tCTL?


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> @Mumak
> 
> Have you seen this info on tCTL?


Yep, just checking that and discussing if it's really true


----------



## Mumak

Ryzen Tctl offset:
I was told not to use any offset for the time being. There are ways to alter the offset even further (SenseMi tuning) and some of the ODMs are currently playing with it. So in the end the real offset might be different from what was published by AMD.
If any user feels he needs an offset for Tctl, he can define his own via sensor settings, "Customize values" in HWiNFO.


----------



## gupsterg

Thank you very much Martin







.

On C6H UEFI 0902 and below, Elmor advised to do this:-

Sense MI Skew [Auto]->[Enabled]
Sense MI Offset [Auto]->[272]

His post.

Will link your post in my Ryzen Essential Thread







.


----------



## MNMadman

Just noticed this on the newest beta:

Note the minimum CPU temp...


----------



## LostParticle

Quote:


> Originally Posted by *MNMadman*
> 
> Just noticed this on the newest beta:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> Note the minimum CPU temp...


Are you running HWiNFO64 at the same time with other monitoring tools like AIDA64 or HWMonitor, or even with your motherboard's utilities? IF you do, you should not do so.


----------



## Mumak

Quote:


> Originally Posted by *MNMadman*
> 
> Just noticed this on the newest beta:
> 
> Note the minimum CPU temp...


Yep, there still seems to be an issue on CH6, but don't have a better option from ASUS yet








http://www.overclock.net/t/1624603/rog-crosshair-vi-overclocking-thread/2300#post_25928823


----------



## MNMadman

Quote:


> Originally Posted by *LostParticle*
> 
> Are you running HWiNFO64 at the same time with other monitoring tools like AIDA64 or HWMonitor, or even with your motherboard's utilities? IF you do, you should not do so.


No. I know better. The only ASUS software I have installed is AURA, and I use only HWINFO for monitoring.


----------



## MNMadman

Quote:


> Originally Posted by *Mumak*
> 
> Yep, there still seems to be an issue on CH6, but don't have a better option from ASUS yet


Okay, I'll wait (im)patiently for a fix. Thanks.


----------



## Mumak

We have a 100% solution for the occasional erratic ITE sensor readouts on ASUS CH6








Here an intermediate HWiNFO64 build until a new public Beta is released: www.hwinfo.com/beta/hw64_547_3109.zip


----------



## muffins

hey mumak! any plans to do any support for the gigabyte ax370-gaming 5? here is my hwinfo readout. i'm using the beta 5.47. any ideas which temperature is the motherboards bios cpu temperature sensor and which vcore is the correct vcore sensor? i see two listed with different readings and a bunch of unlabeled "temperature #" ones. and with the cpu(tctl) we should subtract 20 from it correct? i remember hearing amd said that.


----------



## Mumak

Quote:


> Originally Posted by *muffins*
> 
> hey mumak! any plans to do any support for the gigabyte ax370-gaming 5? here is my hwinfo readout. i'm using the beta 5.47. any ideas which temperature is the motherboards bios cpu temperature sensor and which vcore is the correct vcore sensor? i see two listed with different readings and a bunch of unlabeled "temperature #" ones. and with the cpu(tctl) we should subtract 20 from it correct? i remember hearing amd said that.


I'm not yet sure about all sensor values for these GIGABYTE series.
It would be great if you could post a side-by-side screenshot of HWiNFO sensors screen with the GIGABYTE EasyTune tool showing all sensor values. I can then check and adjust better for HWiNFO.

Yes, AMD said that some models need to subtract 20 C from Tctl, but when I examined this in more detail and checked with others from AMD it turned out that the truth is much more complicated and not only CPU, but also system and firmware dependent. So it looks like nobody knows exactly how to get the true temperature yet.


----------



## muffins

Quote:


> Originally Posted by *Mumak*
> 
> I'm not yet sure about all sensor values for these GIGABYTE series.
> It would be great if you could post a side-by-side screenshot of HWiNFO sensors screen with the GIGABYTE EasyTune tool showing all sensor values. I can then check and adjust better for HWiNFO.
> 
> Yes, AMD said that some models need to subtract 20 C from Tctl, but when I examined this in more detail and checked with others from AMD it turned out that the truth is much more complicated and not only CPU, but also system and firmware dependent. So it looks like nobody knows exactly how to get the true temperature yet.


i tried but when i went to load up hwinfo with gigabytes system viewer running my system froze... easytune really didn't show anything. no temperatures while system viewer showed me everything from voltages to temperatures. i also noticed this happening when i went to load up cpu-z when i had hwinfo running as well. seems like some sensor doesn't like being probed twice.


----------



## Mumak

Quote:


> Originally Posted by *muffins*
> 
> i tried but when i went to load up hwinfo with gigabytes system viewer running my system froze... easytune really didn't show anything. no temperatures while system viewer showed me everything from voltages to temperatures. i also noticed this happening when i went to load up cpu-z when i had hwinfo running as well. seems like some sensor doesn't like being probed twice.


OK, then no need for running side-by-side, but a screenshot of system viewer with all sensor values would be also helpful to adjust values in HWiNFO.


----------



## savagebunny

Quote:


> Originally Posted by *Mumak*
> 
> OK, then no need for running side-by-side, but a screenshot of system viewer with all sensor values would be also helpful to adjust alues in HWiNFO.


Would you like some readings for the Biostar X370GT7? For example, CPU-z latest 1.78 and 3109 HWiNFO read vcore as the same. I can provide any debugging for ya since it seems like this isn't a very popular board.


----------



## Mumak

Quote:


> Originally Posted by *savagebunny*
> 
> Would you like some readings for the Biostar X370GT7? For example, CPU-z latest 1.78 and 3109 HWiNFO read vcore as the same. I can provide any debugging for ya since it seems like this isn't a very popular board.


Sure! If possible a side-by-side screenshot with a Biostar tool that shows sensor values (not sure if there's such). If there's no such tool, then a BIOS screenshot showing those values.
Plus HWiNFO Report File + Debug File including sensor data.
That should help me to adjust the sensor values in HWiNFO.


----------



## savagebunny

Quote:


> Originally Posted by *Mumak*
> 
> Sure! If possible a side-by-side screenshot with a Biostar tool that shows sensor values (not sure if there's such). If there's no such tool, then a BIOS screenshot showing those values.
> Plus HWiNFO Report File + Debug File including sensor data.
> That should help me to adjust the sensor values in HWiNFO.


Okie dokie, here we go. 

HWiNFO_LOG_595484_DBG.zip 55k .zip file


----------



## Mumak

Quote:


> Originally Posted by *savagebunny*
> 
> Okie dokie, here we go.
> 
> HWiNFO_LOG_595484_DBG.zip 55k .zip file


Thanks! Most sensor values seem to be already properly showing, I will adjust a few additional ones.
I'm just not sure about the CPU temperature under the BIOSTAR/ITE sensor. "Temperature 1" seems to better correlate with the "CPU Temp" shown in the BIostar tool. What do you think, can you please try to check under different temperatures ?


----------



## savagebunny

Quote:


> Originally Posted by *Mumak*
> 
> Thanks! Most sensor values seem to be already properly showing, I will adjust a few additional ones.
> I'm just not sure about the CPU temperature under the BIOSTAR/ITE sensor. "Temperature 1" seems to better correlate with the "CPU Temp" shown in the BIostar tool. What do you think, can you please try to check under different temperatures ?


Ya, so I actually posted this in the Official Owners thread trying to pin it down, this is under load. I was thinking it was related to VRM's at a glance, but I looked at it closer and seems maybe the CPU socket or some sort? This is still 3109, I only just SS'ed it 2 days ago, but I can provide fresh data.


----------



## Mumak

Quote:


> Originally Posted by *savagebunny*
> 
> Ya, so I actually posted this in the Official Owners thread trying to pin it down, this is under load. I was thinking it was related to VRM's at a glance, but I looked at it closer and seems maybe the CPU socket or some sort? This is still 3109, I only just SS'ed it 2 days ago, but I can provide fresh data.


Well, I think important is what the Biostar tool says. Temperature 1 seems to be definitively the internal temperature, and I assume this is what Biostar calls "CPU". So I will rename this in the next build.
Not sure about the one shown as "CPU" in HWiNFO now. Could be socket, or anything else.. Would be just pure guessing, unless someone tries to freeze various parts of the mainboard and compare the outputs


----------



## savagebunny

Quote:


> Originally Posted by *Mumak*
> 
> Well, I think important is what the Biostar tool says. Temperature 1 seems to be definitively the internal temperature, and I assume this is what Biostar calls "CPU". So I will rename this in the next build.
> Not sure about the one shown as "CPU" in HWiNFO now. Could be socket, or anything else.. Would be just pure guessing, unless someone tries to freeze various parts of the mainboard and compare the outputs


Awesome, good to hear! If I see any new outputs that are weird or new from Biostar I'll let you know. Also, from the debug info, what is TEMP 4,5,6 all at -70, just some fluke?


----------



## Mumak

Quote:


> Originally Posted by *savagebunny*
> 
> Awesome, good to hear! If I see any new outputs that are weird or new from Biostar I'll let you know. Also, from the debug info, what is TEMP 4,5,6 all at -70, just some fluke?


That's an invalid value, most probably a not connected sensor rail. I will remove that from reporting in the next build.


----------



## muffins

Quote:


> Originally Posted by *Mumak*
> 
> OK, then no need for running side-by-side, but a screenshot of system viewer with all sensor values would be also helpful to adjust values in HWiNFO.


no problem! here you go


----------



## Mumak

Quote:


> Originally Posted by *muffins*
> 
> no problem! here you go


Thanks. I think I can adjust some values based on this, especially voltages.
But it's difficult for temperatures/fans. Is there any other sensor monitoring tool able to run side-by-side with GIGABYTE's to create a screenshot ? HWMonitor maybe?


----------



## muffins

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I think I can adjust some values based on this, especially voltages.
> But it's difficult for temperatures/fans. Is there any other sensor monitoring tool able to run side-by-side with GIGABYTE's to create a screenshot ? HWMonitor maybe?


no... its buggy. i just tried loading up siv again but with hwinfo running and this time it opened, but refused to show temperatures and fan information. only voltages.

edit:
and hwmonitor shows practically nothing... it really can't read anything on the motherboard.


----------



## Mumak

Quote:


> Originally Posted by *muffins*
> 
> no... its buggy. i just tried loading up siv again but with hwinfo running and this time it opened, but refused to show temperatures and fan information. only voltages.
> 
> edit:
> and hwmonitor shows practically nothing... it really can't read anything on the motherboard.


I see. You might try to enable Debug Mode in HWiNFO and when you start the GIGABYTE tool and system freezes, reboot it, grab the HWiNFO64.DBG file produced and attach it here. I can then check if I can see something there why it hangs and if it can be fixed somehow.


----------



## Scotty99

Hey buddy, asrocks A tuning just released for x370 boards and is the only program so far that reads my CPU volts correctly, i was told to link you this from the ryzen owners thread:
http://asrock.pc.cdn.bitgravity.com/Utility/A-Tuning/A-Tuning(v3.0.132).zip

Mucho appreciado if you can get it working


----------



## Mumak

Quote:


> Originally Posted by *Scotty99*
> 
> Hey buddy, asrocks A tuning just released for x370 boards and is the only program so far that reads my CPU volts correctly, i was told to link you this from the ryzen owners thread:
> http://asrock.pc.cdn.bitgravity.com/Utility/A-Tuning/A-Tuning(v3.0.132).zip
> 
> Mucho appreciado if you can get it working


Thanks. But besides that I will need some more details from your board. A HWiNFO Report and Debug File including sensor data will be very helpful to add this.


----------



## RS87

Re H110i CPU fan speed sensor: I have done a report in text log and HTML but how do i create a debug file?


----------



## Mumak

Quote:


> Originally Posted by *RS87*
> 
> Re H110i CPU fan speed sensor: I have done a report in text log and HTML but how do i create a debug file?


Please see here for instructions: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## RS87

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *RS87*
> 
> Re H110i CPU fan speed sensor: I have done a report in text log and HTML but how do i create a debug file?
> 
> 
> 
> Please see here for instructions: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
Click to expand...

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *RS87*
> 
> Re H110i CPU fan speed sensor: I have done a report in text log and HTML but how do i create a debug file?
> 
> 
> 
> Please see here for instructions: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
Click to expand...

 ReportandDebug.zip 62k .zip file


I hope this helps.


----------



## Mumak

Quote:


> Originally Posted by *RS87*
> 
> ReportandDebug.zip 62k .zip file
> 
> 
> I hope this helps.


Thanks, but the attached files don't contain sensor data. Please repeat the process and make sure you open the sensors window before closing HWiNFO.


----------



## RS87

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *RS87*
> 
> ReportandDebug.zip 62k .zip file
> 
> 
> I hope this helps.
> 
> 
> 
> Thanks, but the attached files don't contain sensor data. Please repeat the process and make sure you open the sensors window before closing HWiNFO.
Click to expand...

 ReportandDebug.zip 131k .zip file


Feel free to call me stupid if this isn't right!


----------



## Mumak

Quote:


> Originally Posted by *RS87*
> 
> ReportandDebug.zip 131k .zip file
> 
> 
> Feel free to call me stupid if this isn't right!


That's it







And I can see now where the problem is..
Please try this build: www.hwinfo.com/beta/hw64_547_3116.zip
and let me know if you see now a new Corsair sensor with all the data.


----------



## RS87

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *RS87*
> 
> ReportandDebug.zip 131k .zip file
> 
> 
> Feel free to call me stupid if this isn't right!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> That's it
> 
> 
> 
> 
> 
> 
> 
> And I can see now where the problem is..
> Please try this build: www.hwinfo.com/beta/hw64_547_3116.zip
> and let me know if you see now a new Corsair sensor with all the data.
Click to expand...



There it is, nicely at the bottom there (*will move it near the top in a min).









Thank you very much. REP+ for the direct support!









*Is there a way to have more than one column of sensors in the sensors screen? I have to scroll down every single time especially seeing as i have 16 threads. I would like to move the most important ones side by side in the sensors screen. Is this possible?


----------



## Mumak

Quote:


> Originally Posted by *RS87*
> 
> Thank you very much. REP+ for the direct support!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Is there a way to have more than one column of sensors in the sensors screen? I have to scroll down every single time especially seeing as i have 16 threads. I would like to move the most important ones side by side in the sensors screen. Is this possible?


You're welcome.

Sure, just click the blue Expand button at the bottom-left of the window


----------



## RS87

Quote:


> Originally Posted by *Mumak*
> 
> Quote:
> 
> 
> 
> Originally Posted by *RS87*
> 
> Thank you very much. REP+ for the direct support!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Is there a way to have more than one column of sensors in the sensors screen? I have to scroll down every single time especially seeing as i have 16 threads. I would like to move the most important ones side by side in the sensors screen. Is this possible?
> 
> 
> 
> You're welcome.
> 
> Sure, just click the blue Expand button at the bottom-left of the window
Click to expand...

Top man, thanks again!


----------



## SLK

Seems to be an issue with the Gigabyte X370 Gaming 5, on certain loads when loading up HWINFO64, it will hard lock the entire system when scanning the sensors/buses etc.

Windows 10, was my stress testing tools, P95, Heaven, and Cinebench then loaded up HWINFO64 and it hard locks on occasion when it is scanning. Not sure if this is a huge ordeal but thought I'd throw it out there. Happens at 100% stock and Overclocked.


----------



## gupsterg

@RS87

You can order sensors as you want, remove, rename, double click them for a graph to appear, etc.

Take some time exploring it and you will find nothing else comes close to HWiNFO







.


----------



## Mumak

Quote:


> Originally Posted by *SLK*
> 
> Seems to be an issue with the Gigabyte X370 Gaming 5, on certain loads when loading up HWINFO64, it will hard lock the entire system when scanning the sensors/buses etc.
> 
> Windows 10, was my stress testing tools, P95, Heaven, and Cinebench then loaded up HWINFO64 and it hard locks on occasion when it is scanning. Not sure if this is a huge ordeal but thought I'd throw it out there. Happens at 100% stock and Overclocked.


If you attach the HWiNFO Debug File of the lockup I can check why it happens and perhaps disabling some options will help.


----------



## savagebunny

Definalty new values and a bit difference, I'm still running old AEGSA since Biostar still has yet to implement any new BIOS since 3/14. Here are the difference when i first started

*3109*


*3118*


----------



## muffins

Quote:


> Originally Posted by *Mumak*
> 
> I see. You might try to enable Debug Mode in HWiNFO and when you start the GIGABYTE tool and system freezes, reboot it, grab the HWiNFO64.DBG file produced and attach it here. I can then check if I can see something there why it hangs and if it can be fixed somehow.



long story short, today i had a similar hard lock, but this time with ONLY firefox running with five tabs. just basic websites with zero movies, flash, the like. nothing else was running in the background. no monitoring tools. it was the same exact hard lock i had when i tried hwinfo and cpu-z. so after that i got brave again as now i don't think it was the monitoring programs that caused my first one. so i tried hwinfo and siv again and this time both loaded up just fine and siv this time is showing the temps. so i hope it helps!


----------



## Mumak

Quote:


> Originally Posted by *muffins*
> 
> 
> long story short, today i had a similar hard lock, but this time with ONLY firefox running with five tabs. just basic websites with zero movies, flash, the like. nothing else was running in the background. no monitoring tools. it was the same exact hard lock i had when i tried hwinfo and cpu-z. so after that i got brave again as now i don't think it was the monitoring programs that caused my first one. so i tried hwinfo and siv again and this time both loaded up just fine and siv this time is showing the temps. so i hope it helps!


Thanks. I can see that the latest HWiNFO build adjusts properly all sensor value for this board


----------



## onurbulbul

Could someone please tell me what is that "total error" part belove. Does it mean something? Should i care about it?


----------



## MNMadman

Quote:


> Originally Posted by *onurbulbul*
> 
> Could someone please tell me what is that "total error" part belove. Does it mean something? Should i care about it?


That's the number of WHEA (Windows Hardware) errors that your system has generated. You want that number to stay at zero.


----------



## onurbulbul

Quote:


> Originally Posted by *MNMadman*
> 
> That's the number of WHEA (Windows Hardware) errors that your system has generated. You want that number to stay at zero.


I don't know how much more voltage should I give for keeping it zero


----------



## MNMadman

Quote:


> Originally Posted by *onurbulbul*
> 
> I don't know how much more voltage should I give for keeping it zero


Someone else will have to answer that, as I've never had an FX chip. Maybe ask in the Vishera thread.


----------



## mirzet1976

Quote:


> Originally Posted by *onurbulbul*
> 
> I don't know how much more voltage should I give for keeping it zero


Give us more information from the BIOS of the voltages for the CPU, DRAM, CPU - NB ...

http://www.overclock.net/t/1318995/official-fx-8320-fx-8350-vishera-owners-club


----------



## LittleVulpix

@Mumak Hi!

I'm using the latest HWinfo (3126) and I can't figure out which of the values of my ryzen 1800x is the actual cpu temperature, because the Tdie reports 20C lower than Tctl, but the Tctl seems to be more likely. Is there a way to know for sure?


----------



## Mumak

Quote:


> Originally Posted by *LittleVulpix*
> 
> @Mumak Hi!
> 
> I'm using the latest HWinfo (3126) and I can't figure out which of the values of my ryzen 1800x is the actual cpu temperature, because the Tdie reports 20C lower than Tctl, but the Tctl seems to be more likely. Is there a way to know for sure?


This might depend on the Mi Skew setting used. It was discussed several times in this thread.


----------



## LittleVulpix

I tried enabling the sensemi skew and setting it to 272, or leaving it on auto, but it seems to be the same. So I guess nobody really knows how hot my CPU is







that's disconcerting.


----------



## LostParticle

Hey Martin

I'm using Win 10 Pro Creators Update and HWiNFO64 v5.51-3141. I've decided to try the "System tray" feature a bit, so I've add my _Total CPU Usage_ to the system tray. Why does it hide in my Hidden Icon's area? Why isn't it showing on my Taskbar?




I don't know if it has anything to do with it, but my Taskbar settings are: Left location on screen and Auto-Hide the taskbar. I have set it at the bottom [location] though and to "always visible" and still the value is hidden in my hidden icon's menu.

*EDIT*

Nevermind, got it










Spoiler: Warning: Spoiler!


----------



## mynm

Hi, I see a problem with the monitored core clocks shown with an r9 380 with the NCP81022. They are incorrect and not the same shown with Aferburner or gpuz. Even if the min and the max are the same, them could be lower than that. I'm using v5.50-3130. I don't know when this start to happen, but I remenber that it wasn't doing this in the past.

Edited: Othe thing I see is that chip power stops working after using a full screen app. Edited: Or rather after using a full screen app and the use othe a full screen app, or usin a full screen app then goin to the desktop and came back to the app.

Thanks.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Hi, I see a problem with the monitored core clocks shown with an r9 380 with the NCP81022. They are incorrect and not the same shown with Aferburner or gpuz. Even if the min and the max are the same, them could be lower than that. I'm using v5.50-3130. I don't know when this start to happen, but I remenber that it wasn't doing this in the past.
> 
> Edited: Othe thing I see is that chip power stops working after using a full screen app. Edited: Or rather after using a full screen app and the use othe a full screen app, or usin a full screen app then goin to the desktop and came back to the app.
> 
> Thanks.


What is the exact difference between clocks reported? It is possible that other applications report clock values that are averaged over a short period, while HWiNFO reports the most actual values.
If the GPU runs at a constant clock (idle//load), do you see a difference in clock reported too ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> What is the exact difference between clocks reported? It is possible that other applications report clock values that are averaged over a short period, while HWiNFO reports the most actual values.
> If the GPU runs at a constant clock (idle//load), do you see a difference in clock reported too ?


It's like if it reports only the DPM value, the red highlight value is AfterBurner, the green highlight one is Hwinfo:


Spoiler: Warning: Spoiler!









Spoiler: Warning: Spoiler!







Thanks.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Is like if it reports only the DPM value, the red highlight value is AfterBurner, the green highlight one is Hwinfo:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> Thanks.


Is the value AfterBurner reports the same as Radeon Wattman does ?
Please attach a HWiNFO Debug File of those situations and note what was the correct clock (reported either by MSI AB or Wattman). I will then check all details.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Is the value AfterBurner reports the same as Radeon Wattman does ?
> Please attach a HWiNFO Debug File of those situations and note what was the correct clock (reported either by MSI AB or Wattman). I will then check all details.


Wattman report isn't the same as AfterBurner. AfterBurner is reporting the correct clock.

HWiNFO64.zip 328k .zip file


Thanks


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Wattman report isn't the same as AfterBurner. AfterBurner is reporting the correct clock.
> 
> HWiNFO64.zip 328k .zip file
> 
> 
> Thanks


I see heavy clock fluctuations in the Debug File. Would it be possible to create one at stable clock and tell me also what you believe the correct clock was in that case ?
And shouldn't Wattman be correct rather than MSI AB ?


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> I see heavy clock fluctuations in the Debug File. Would it be possible to create one at stable clock and tell me also what you believe the correct clock was in that case ?
> And shouldn't Wattman be correct rather than MSI AB ?


Because Hwinfo is reporting like by steps, the same steps as the DPM cloks and DPM vddc VID. Although Wattman isn't very clear and maybe is right but with a lower polling frequency, I don't know. AB and Hwinfo are using 1000ms polling frequency.

You can se here highlighted that clock is power throttling, but hwinfo only reports three drops to the lower DPM 980mhz although Afterburner reported clock was higher than that:


Spoiler: Warning: Spoiler!







HWiNFO642.zip 180k .zip file


Thanks


----------



## Mumak

I believe both Wattman and MSI AB report clocks that are averaged, so that's why you see intermediate values. Such averaged values are not truly correct, as the clock can change only to preset levels.
HWiNFO on the other hand reports actual values when they were sampled. If you'd use a much higher polling rate in HWiNFO, you'd see more frequent changes.
Not sure which approach is better as both have their advantages/disadvantages. Averaged values better catch frequent changes in clock, while actual values report true clocks at the time of sampling.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> I believe both Wattman and MSI AB report clocks that are averaged, so that's why you see intermediate values. Such averaged values are not truly correct, as the clock can change only to preset levels.
> HWiNFO on the other hand reports actual values when they were sampled. If you'd use a much higher polling rate in HWiNFO, you'd see more frequent changes.
> Not sure which approach is better as both have their advantages/disadvantages. Averaged values better catch frequent changes in clock, while actual values report true clocks at the time of sampling.


Ok thanks for the explanation







, I will test with a 100ms polling frequency. Maybe including both clock measurement cuold be better.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Ok thanks for the explanation
> 
> 
> 
> 
> 
> 
> 
> , I will test with a 100ms polling frequency. Maybe including both clock measurement cuold be better.


Yes, I'm considering either a switch to choose between methods, or to display both values.
Note that if you want to use a too high polling frequency, you might need to disable other unnecessary sensors, which might take longer time to read out (i.e. Disk SMART).


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> Yes, I'm considering either a switch to choose between methods, or to display both values.
> Note that if you want to use a too high polling frequency, you might need to disable other unnecessary sensors, which might take longer time to read out (i.e. Disk SMART).


OK thanks you very much for all


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Ok thanks for the explanation
> 
> 
> 
> 
> 
> 
> 
> , I will test with a 100ms polling frequency. Maybe including both clock measurement cuold be better.


The next build of HWiNFO will add an option to choose between clock/utilization measuring methods: "Prefer AMD ADL"


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> The next build of HWiNFO will add an option to choose between clock/utilization measuring methods: "Prefer AMD ADL"


Perfect, thanks


----------



## Mumak

HWiNFO v5.51-3145 Beta was just released.
@mynm: Check the new option called "Prefer AMD ADL"
@Hequaqua: It should fix your MSI board sensor values (Nuvoton and Richtek)


----------



## Hequaqua

Quote:


> Originally Posted by *Mumak*
> 
> HWiNFO v5.51-3145 Beta was just released.
> @mynm: Check the new option called "Prefer AMD ADL"
> @Hequaqua: It should fix your MSI board sensor values (Nuvoton and Richtek)


Thanks....will give it a try.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> HWiNFO v5.51-3145 Beta was just released.
> @mynm: Check the new option called "Prefer AMD ADL"
> @Hequaqua: It should fix your MSI board sensor values (Nuvoton and Richtek)


Tested and it works, thanks







.

But the problem with the gpu chip power that is blocked after using a full screen game or benchmark going to the desktop and return to full screen, or stop the game and start other persists. Maybe is some thing related to the windows creators update with how it's managing the full screen, I dinn't see this before it.


----------



## Mumak

Quote:


> Originally Posted by *mynm*
> 
> Tested and it works, thanks
> 
> 
> 
> 
> 
> 
> 
> .
> 
> But the problem with the gpu chip power that is blocked after using a full screen game or benchmark going to the desktop and return to full screen, or stop the game and start other persists. Maybe is some thing related to the windows creators update with how it's managing the full screen, I dinn't see this before it.


I believe this is rather a problem of the GPU (SMU) or drivers. I don't think I can do something about this.


----------



## mynm

Quote:


> Originally Posted by *Mumak*
> 
> I believe this is rather a problem of the GPU (SMU) or drivers. I don't think I can do something about this.


Ok thanks.


----------



## XEKong

Is there a night mode switch I am not seeing?


----------



## Clukos

I'm getting system wide hangups while gaming with the latest beta of HWiNFO64. I start the game, everything works and it gets progressively worse, first sign is loss of sound then when I alt tab -> black screen -> system restarts. Tested same settings everywhere in the bios and GPU with and without HWiNFO and it is repeatable and the games work without it just fine and crash the whole system with it on. Love the software, just leaving some feedback









Edit: This is only during gaming. Any other stress situation is fine.


----------



## Mumak

Quote:


> Originally Posted by *Clukos*
> 
> I'm getting system wide hangups while gaming with the latest beta of HWiNFO64. I start the game, everything works and it gets progressively worse, first sign is loss of sound then when I alt tab -> black screen -> system restarts. Tested same settings everywhere in the bios and GPU with and without HWiNFO and it is repeatable and the games work without it just fine and crash the whole system with it on. Love the software, just leaving some feedback
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Edit: This is only during gaming. Any other stress situation is fine.


Well, this is not easy to diagnose. First, I'd suggest to start with disabling monitoring of sensors one by one (hit Del key on a sensor heading) and see which of the sensors is causing this.
Then I could probably give you some advice..


----------



## Clukos

Quote:


> Originally Posted by *Mumak*
> 
> Well, this is not easy to diagnose. First, I'd suggest to start with disabling monitoring of sensors one by one (hit Del key on a sensor heading) and see which of the sensors is causing this.
> Then I could probably give you some advice..


Unfortunately, I don't have the time to do that, but I'm guessing the new drivers from Nvidia have some sort of incompatibility with the latest beta of HWiNFO, I'll try using the non-beta HWiNFO and see how that goes and report back


----------



## Hequaqua

@Mumak

Hi, I'm having a issue with the Beta not reading the Vram correctly on my RX480. The old version does, but the Beta doesn't. It shows the bios speed of 2000mhz. At first I thought it was the driver, rolled back to 17.4.3, no luck. MSI Afterburner and GPU-Z show the OC, but not HWiNFO.

Not a deal breaker, but maybe something you can look into.


----------



## Mumak

Quote:


> Originally Posted by *Hequaqua*
> 
> @Mumak
> 
> Hi, I'm having a issue with the Beta not reading the Vram correctly on my RX480. The old version does, but the Beta doesn't. It shows the bios speed of 2000mhz. At first I thought it was the driver, rolled back to 17.4.3, no luck. MSI Afterburner and GPU-Z show the OC, but not HWiNFO.
> 
> Not a deal breaker, but maybe something you can look into.


Can you please attach Debug File from the version where it worked and the latest Beta ? I will check that.
Also, do you have the "Prefer AMD ADL" option in latest Beta ticked ?


----------



## Clukos

About the instability... Nevermind that. It looks like something on C6H bios or the CPU was causing it. I did reset the CMOS + removed the battery and power for a couple of minutes then reseat the Wraith Spire, used some MX4 on it because the stock thermal paste went bad really quick and it seems like my system is 100% stable once again, with or without HWiNFO. Very weird that the sensors were causing instability beforehand though


----------



## Hequaqua

Thanks. I didn't have that checked.....my bad.


----------



## Mumak

Quote:


> Originally Posted by *Hequaqua*
> 
> Thanks. I didn't have that checked.....my bad.


So with the "Prefer AMD ADL" option checked you get correct memory clock ?


----------



## Hequaqua

Quote:


> Originally Posted by *Mumak*
> 
> So with the "Prefer AMD ADL" option checked you get correct memory clock ?


Correct!


----------



## Spinshot64

I have an issue with temperature reading on my Gigabyte GA-Z170X-Gaming 3 (rev.1.0): when I stress the CPU really hard with Intel burn test, OCCT or Prime95 my Temp 5 values skyrocket steadily soon after I start the test. Could that be a sensor read error or should I be really worried? All my other temp are in kept check.

I guess it's worth mentioning that my brother is experiencing the very same issue on his similar Gigabyte board.


----------



## Mumak

Quote:


> Originally Posted by *Spinshot64*
> 
> I have an issue with temperature reading on my Gigabyte GA-Z170X-Gaming 3 (rev.1.0): when I stress the CPU really hard with Intel burn test, OCCT or Prime95 my Temp 5 values skyrocket steadily soon after I start the test. Could that be a sensor read error or should I be really worried? All my other temp are in kept check.
> 
> I guess it's worth mentioning that my brother is experiencing the very same issue on his similar Gigabyte board.


This temperature is "unofficial" as it's not reported by GIGABYTE tools, so it's not guaranteed to be providing a valid value.
I'm sorry, but only GIGABYTE knows the truth.


----------



## theGucky

Using an ASUS Maximus IX Hero

Well, i have some Temps especially form my ASUS EC Sensors....
T_Sensor2 7°C-8°C
DIMM_2_M_2_1 9°C-11°C
DIMM_2_M_2_2 16°C

Question:
Why the HELL are the EC Temps so low XD
My Ambient Temp is higher then around 20°C...


----------



## Mumak

Quote:


> Originally Posted by *theGucky*
> 
> Using an ASUS Maximus IX Hero
> 
> Well, i have some Temps especially form my ASUS EC Sensors....
> T_Sensor2 7°C-8°C
> DIMM_2_M_2_1 9°C-11°C
> DIMM_2_M_2_2 16°C
> 
> Question:
> Why the HELL are the EC Temps so low XD
> My Ambient Temp is higher then around 20°C...


I think this is because those sensors are not available on your board. Are you sure you have those connected ? Does the BIOS report those values ?


----------



## Caos

Hello, will not cause problems with evga precision? Is that I am wanting to switch to a gtx 1080ti ftw3 and I want to continue using hwinfo64 to monitor my temperatures.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Hello, will not cause problems with evga precision? Is that I am wanting to switch to a gtx 1080ti ftw3 and I want to continue using hwinfo64 to monitor my temperatures.


I'm not aware of any problems with EVGA Precision.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> I'm not aware of any problems with EVGA Precision.


OK, thanks for answering. Is that in the evga forum I am told that I can not use precision in conjunction with hwinfo64, and I do not want to stop using hwinfo64


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> OK, thanks for answering. Is that in the evga forum I am told that I can not use precision in conjunction with hwinfo64, and I do not want to stop using hwinfo64


Can you please give me a link to that forum where it's stated? Any particular reasons given?


----------



## Caos

https://forums.evga.com/Doubts-about-ftw3-m2672475.aspx

I am told it can interfere with evga precision by monitoring temperatures.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> https://forums.evga.com/Doubts-about-ftw3-m2672475.aspx
> 
> I am told it can interfere with evga precision by monitoring temperatures.


Several such tools use synchronization mechanisms to work properly together. I haven't got issues reported with EVGA yet, but I'm not sure how well it supports those mechanism. So you'll try to yourself and see if you get any erratic sensor readouts.


----------



## Hequaqua

@mumak

I had a quick question that hopefully you can answer.

On the sensors for the MSI X370 Krait on AUXTIN it is showing a negative number. Right now at idle it's showing -99.0°.

Also, on VIN14 it shows the voltage at 1.544.

Do you know what those two sensors are reading?

Thanks ahead of time.


----------



## Mumak

Quote:


> Originally Posted by *Hequaqua*
> 
> @Mumak
> 
> I had a quick question that hopefully you can answer.
> 
> On the sensors for the MSI X370 Krait on AUXTIN it is showing a negative number. Right now at idle it's showing -99.0°.
> 
> Also, on VIN14 it shows the voltage at 1.544.
> 
> Do you know what those two sensors are reading?
> 
> Thanks ahead of time.


The temperature must be an invalid readout (not connected sensor). I'm not sure about VIN14 - does the MSI Core Center report a voltage in that range ?


----------



## Hequaqua

Quote:


> Originally Posted by *Mumak*
> 
> The temperature must be an invalid readout (not connected sensor). I'm not sure about VIN14 - does the MSI Core Center report a voltage in that range ?


Here are a couple of screen shots from earlier...same version of HWiNFO.

This one shows a temp of [email protected]:


This one shows the negative [email protected]:


As for the VIN14, I don't see anything showing that number in Command Center. I will install Ryzen Master and see if it reports anything. I will also re-boot and check in there and see if that resets the AUXTIN2 reading.

EDIT: Ryzen Master shows squat. lol I didn't see anything in the bios reflecting the VIN14 voltage(1.544).I'm thinking maybe that is the highest core voltage the bios will let you set. I don't really know though. The AUXTIN2 showed 39.0°C on boot, then went to -98.0°C after being in Windows for a few seconds. Now it's showing -94.0°C. I put a load on the CPU, but it stays right there....lol


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Several such tools use synchronization mechanisms to work properly together. I haven't got issues reported with EVGA yet, but I'm not sure how well it supports those mechanism. So you'll try to yourself and see if you get any erratic sensor readouts.


@Mumak

thanks, When I get the ftw3 I will try the hwinfo64.

When they will support the icx evga system, which has 9 sensors? Gpu-z already supports .. thanks


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> @Mumak
> 
> thanks, When I get the ftw3 I will try the hwinfo64.
> 
> When they will support the icx evga system, which has 9 sensors? Gpu-z already supports .. thanks


I'm working on supporting the ICX, so hopefully soon.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> I'm working on supporting the ICX, so hopefully soon.


wow.. Excellent..


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> wow.. Excellent..


If you get that GPU, I'd love to get a dump from it (Debug File).


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> If you get that GPU, I'd love to get a dump from it (Debug File).


When I get the gpu I will send the (debug file), where I locate that file?


----------



## Mumak

See here: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> See here: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


Ok .. next week I would have the gpu.


----------



## Caos

Hi, I already have evga ftw3. Where are the report files? @Mumak


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Hi, I already have evga ftw3. Where are the report files? @Mumak


Perfect, please check here: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
I need especially the Debug File (DBG).


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Perfect, please check here: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report
> I need especially the Debug File (DBG).


Apologies I express badly ... where do I upload the reports?


----------



## Mumak

You can do it right here. Or send me via e-mail if you prefer that.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> You can do it right here. Or send me via e-mail if you prefer that.


I send you an email. Can you give me your mail address


----------



## Mumak

It's on the welcome screen of HWiNFO or in the about box, or at the bottom of the HWiNFO homepage: www.hwinfo.com


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> It's on the welcome screen of HWiNFO or in the about box, or at the bottom of the HWiNFO homepage: www.hwinfo.com


I just sent it .. thanks.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> I just sent it .. thanks.


Thanks. I have replied to your e-mail with request for more data. I forgot one thing: could you please also attach a screenshot of GPU-Z showing all the extended ICX sensors?


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I have replied to your e-mail with request for more data. I forgot one thing: could you please also attach a screenshot of GPU-Z showing all the extended ICX sensors?


Hello Mumak... Now I send you what you asked for by mail and I passed the screenshot of cpu -z. It will also be possible to see the speed of the fans separately? Because each fan has its own speed.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Hello Mumak... Now I send you what you asked for by mail and I passed the screenshot of cpu -z. It will also be possible to see the speed of the fans separately? Because each fan has its own speed.


Thanks! Is GPU-Z showing fan speeds too? It would be great if you could also attach a screenshot of a tool showing all those values when you made that dump.


----------



## Caos

Send to your email the debug video that you requested.

Only shows the speed of 1 fan.


----------



## Mumak

Thanks. Can you then please post a screenshot of EVGA Precision showing those additional fan speeds?


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. Can you then please post a screenshot of EVGA Precision showing those additional fan speeds?




it's okay? If I need something else let me know


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> 
> 
> it's okay? If I need something else let me know


Thanks. I will add monitoring of all those additional temperatures in the next HWiNFO Beta build, which is scheduled for release tomorrow.
But I don't see any additional fan speeds in EVGA Precision either. So if they can't report it, I doubt it's possible to report individual fan speeds.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. I will add monitoring of all those additional temperatures in the next HWiNFO Beta build, which is scheduled for release tomorrow.
> But I don't see any additional fan speeds in EVGA Precision either. So if they can't report it, I doubt it's possible to report individual fan speeds.


perfect. I hope to try tomorrow .. in the osd you see the three fans.




Right now at 0% because idle is at 0 rpm


----------



## Mumak

OK, then please try to ramp up the other fans, note their actual speeds and create a new dump as before.
Then send me the new dump with the actual fan speeds you observed.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> OK, then please try to ramp up the other fans, note their actual speeds and create a new dump as before.
> Then send me the new dump with the actual fan speeds you observed.


I send to your mail the new dump with the fans running.

Here the image. what do you think?


----------



## Mumak

Perfect







I can see something there, but not 100% sure yet.
Would be great if you could do 2-3 more similar tests at different fan speed levels. And again dump + screenshot showing the actual speeds, so I can make a direct comparison


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Perfect
> 
> 
> 
> 
> 
> 
> 
> I can see something there, but not 100% sure yet.
> Would be great if you could do 2-3 more similar tests at different fan speed levels. And again dump + screenshot showing the actual speeds, so I can make a direct comparison


Here at different speeds. Send to your mail the dumps.


----------



## Mumak

Thanks!
Analyzing this, but the fan speeds seem to be really tricky..


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks!
> Analyzing this, but the fan speeds seem to be really tricky..


Thanks to you for the tremendous work, I hope you can see the speeds separately .. I expect the beta. If you need some information but just let me know.


----------



## Mumak

Well.. it might be helpful if it would be possible to either spin all fans and stop just one of them, then create a new dump. Or opposite - stop all of them and let just 1 spin.
This would be great for each of those fans, so I can identify the proper one inside the bunch of data.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Well.. it might be helpful if it would be possible to either spin all fans and stop just one of them, then create a new dump. Or opposite - stop all of them and let just 1 spin.
> This would be great for each of those fans, so I can identify the proper one inside the bunch of data.


Oh yes i send it now


----------



## Mumak

Thanks. But I also need to know which ones were spinning or stopped.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. But I also need to know which ones were spinning or stopped.


Dump #4
Gpu fan and power fan running
Memory fan off

Dump #5
Gpu fan turned on, power fan and memory fan off

Look at your email


----------



## Mumak

Thanks. Can you please also do:
Power fan ON, rest OFF.
Memory fan ON, rest OFF.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. Can you please also do:
> Power fan ON, rest OFF.
> Memory fan ON, rest OFF.


Ready, Can i look at your email

6powerfan on
7memory fan on


----------



## Mumak

Thanks again !
This is totally strange, I can't seem to find a good correlation to report fan speeds








But it's too late here and I need to sleep now...
Perhaps as the last attempt - please let only one fan spin at a time at a stable speed for a while and note this speed. Do this for all of them and please send me which fan was spinning at which speed.
Too tired now, will check more tomorrow...


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Thanks again !
> This is totally strange, I can't seem to find a good correlation to report fan speeds
> 
> 
> 
> 
> 
> 
> 
> 
> But it's too late here and I need to sleep now...
> Perhaps as the last attempt - please let only one fan spin at a time at a stable speed for a while and note this speed. Do this for all of them and please send me which fan was spinning at which speed.
> Too tired now, will check more tomorrow...


Ok I understand .. now I send one fan at a time to 50%, and analyze tomorrow. Thank you.

sent


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Ok I understand .. now I send one fan at a time to 50%, and analyze tomorrow. Thank you.
> 
> sent


Thanks, but what's the actual RPM when at 50% ?


----------



## Mumak

I have just released v5.53-3165 Beta. iCX temperatures should be OK there, but I'm still not 100% sure about those fans. Please try, compare and let me know the results... If any issues, you can now directly provide HWiNFO Debug Files for analysis.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> I have just released v5.53-3165 Beta. iCX temperatures should be OK there, but I'm still not 100% sure about those fans. Please try, compare and let me know the results... If any issues, you can now directly provide HWiNFO Debug Files for analysis.


Hello Mumak .. excellent .. on arrival at my house I try ..


----------



## Hequaqua

@mumak

In the newest Beta, under where my M.2 temps are, it shows two now. Temp2 always shows 59°C, is this the temp that will make the drive throttle?

I'm not really worried, the temp never goes above 55°C, normally it's right around 45-47°C. Just wanted a bit more clarification.

THX


----------



## Mumak

Quote:


> Originally Posted by *Hequaqua*
> 
> @Mumak
> 
> In the newest Beta, under where my M.2 temps are, it shows two now. Temp2 always shows 59°C, is this the temp that will make the drive throttle?
> 
> I'm not really worried, the temp never goes above 55°C, normally it's right around 45-47°C. Just wanted a bit more clarification.
> 
> THX


I'm sorry, I don't know what exact temperature is that. The NVMe specification doesn't specify any further details, so I think it's up to the vendor where he places the other sensors. Perhaps look at the datasheet of your drive if there is more information..


----------



## Hequaqua

Quote:


> Originally Posted by *Mumak*
> 
> I'm sorry, I don't know what exact temperature is that. The NVMe specification doesn't specify any further details, so I think it's up to the vendor where he places the other sensors. Perhaps look at the datasheet of your drive if there is more information..


Will do! Thx


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> I have just released v5.53-3165 Beta. iCX temperatures should be OK there, but I'm still not 100% sure about those fans. Please try, compare and let me know the results... If any issues, you can now directly provide HWiNFO Debug Files for analysis.


Incredible work .. all sensors are detected, and two fans are correctly detected the gpu and power .. the memory is not detected


----------



## Mumak

Please try this build: www.hwinfo.com/beta/hw64_553_3166.zip
and before launching the scan go into HWiNFO Settings - "SMBus / I2C" and click the "Reset GPU I2C Cache" button.
Please let me know the result.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Please try this build: www.hwinfo.com/beta/hw64_553_3166.zip
> and before launching the scan go into HWiNFO Settings - "SMBus / I2C" and click the "Reset GPU I2C Cache" button.
> Please let me know the result.


Now if you register the 3 sensors .. excellent ..




Another thought, here only accepts up to 30 positions? Can not be added more?
Thank you


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Now if you register the 3 sensors .. excellent ..
> 
> 
> 
> 
> Another thought, here only accepts up to 30 positions? Can not be added more?
> Thank you


Great to hear that it works well now.
Sure, I can extend that to 50 in the next build.


----------



## Caos

Quote:


> Originally Posted by *Mumak*
> 
> Great to hear that it works well now.
> Sure, I can extend that to 50 in the next build.


Excellent, I'll be waiting for the next compilation.
Since they do not enter all the sensors in the OSD, I use it with rivaturner in my games


----------



## Caos

@Mumak.

Thanks for the last update. Already owns the 50 positions







.. could it be possible to add in fan speeds percentage for ftw3?


----------



## yuannan

Repost from r7 owners thread

Guys please help me. Under a stress test or sometimes even normal usage my ALL my voltages dip like crazy for a split second. This includes 12v, 5v, 3.3v, core, soc, and many others. They do dip proportionally and to a common few voltages most of the time and afterwards they spike up a bit so I don't think its just a bug.

I have:

1700 (stock and OC on stable and beta bios)
Asus C 6
Corsair Rm750i, just got a new one via RMA a few days ago.

I not sure what is wrong with my system but Im worried that after a big dip the PSU or motherboard will try to push a bigger voltage to compensate and fry my stuff. This is picked up on OCCT the best as they generate a graph. Ive seen it on hwmoniter and hwinfo.

I left hwmonitor in the background while I watched youtube and it dipped during the hour I left it on as the minimum went to 0.62V.

My logic says its just a bug but Ive tried it stock OC, stable and beta bios and they all do it.

I did get a warning from hwmonitor about some asus chip when I first opened it but that's the only thing I can think of after motherboard vrm failure.

I still got a week or so on my Amazon 30 days return window.

Guys please help...

Could HWMonitor + Asus EC chip cause such massive drops across all my apps?


----------



## GalaxyMaster

I'm having trouble getting the "Toggle OSD Output" hotkey to work. Currently, the hotkey just doesn't do anything. I was expecting it to toggle the "Show on-screen display" setting in RTSS like MSI Afterburner does, but pressing the hotkey doesn't seem to affect that at all. Maybe I'm misunderstanding what that hotkey is supposed to do? I currently have it set to "Ctrl+Insert", but I have tried other hotkeys too.

I've tried multiple versions of HWiNFO64 and RTSS and no combination had the hotkey working.

It's really annoying to have to tab out of my game, open RTSS, enable the OSD and then tab back into my game just to check temperatures or FPS. Any help would be appreciated.


----------



## Hequaqua

I normally just leave AB/RTSS running and set the OSD key in HWiNFO:



HWiNFO:


----------



## mynm

Quote:


> Originally Posted by *mynm*
> 
> Tested and it works, thanks
> 
> 
> 
> 
> 
> 
> 
> .
> 
> But the problem with the gpu chip power that is blocked after using a full screen game or benchmark going to the desktop and return to full screen, or stop the game and start other persists. Maybe is some thing related to the windows creators update with how it's managing the full screen, I dinn't see this before it.


Quote:


> Originally Posted by *Mumak*
> 
> I believe this is rather a problem of the GPU (SMU) or drivers. I don't think I can do something about this.


The problem was a Custom Resolution Utility config I was using.


----------



## bluej511

@Mumak not sure if this has been posted in here, quite a lot of pages.

I've noticed that when i have hwinfo64 running i lose about 20MB/s read speeds on my HDD and around 10MB/s write speeds. I know it makes no difference in most games but was curious if there was a way to get rid of that all together. Guessing it has something to do with your software pinging smart data even though i have my HDD hidden and disabled monitoring.


----------



## Mumak

Quote:


> Originally Posted by *bluej511*
> 
> @Mumak not sure if this has been posted in here, quite a lot of pages.
> 
> I've noticed that when i have hwinfo64 running i lose about 20MB/s read speeds on my HDD and around 10MB/s write speeds. I know it makes no difference in most games but was curious if there was a way to get rid of that all together. Guessing it has something to do with your software pinging smart data even though i have my HDD hidden and disabled monitoring.


Do you maybe have Debug Mode enabled in HWiNFO ?
Besides that and with Drive Scan disabled I don't know what else might be causing this. Perhaps try to disable monitoring of other sensors and see which of them is causing it.


----------



## bluej511

Quote:


> Originally Posted by *Mumak*
> 
> Do you maybe have Debug Mode enabled in HWiNFO ?
> Besides that and with Drive Scan disabled I don't know what else might be causing this. Perhaps try to disable monitoring of other sensors and see which of them is causing it.


I havent checked ill take a look. I usually open up sensors only and not much settings in there. Will take a look give it a shot thank you.


----------



## majnu

where is auto start?
nvm right click from taskbar brings up the menu for settings


----------



## Caos

Quote:


> Originally Posted by *Caos*
> 
> @Mumak.
> 
> Thanks for the last update. Already owns the 50 positions
> 
> 
> 
> 
> 
> 
> 
> 
> .. could it be possible to add in fan speeds percentage for ftw3?


----------



## Mumak

Quote:


> Originally Posted by *Caos*


Is the EVGA tool able to report actual percentage? If the device doesn't do so and I don't know the max fan speed (PWM level), then it's not possible.


----------



## adobepro

Quote:


> Originally Posted by *orlfman*
> 
> so... i built a x99 rig to mess around with. paired up, originally a 6800k, but now a 6850k with a gigabyte x99 ultra gaming. yesterday i updated its bios to the latest stable f5. today i updated it to its latest beta bios, f6a, since it improved memory compatibility.
> 
> well yesterday with the 6800k on f5 i noticed vcore would randomly drop to 0 volts for a split second or randomly display 2.0 volts for a split second. temperature 4 would randomly display 0c, 87c, or -87c for a split second.
> 
> well today i swapped out the 6800k for a 6850k since i want to mess around with my crossfire 480's in 16x x 16x and updated the bios to f6a. since updating tp f6a vcore now shows a solid 0.108 volts...
> 
> i disabled turbo boost all together, manually set multiplier to 36, disabled all cstates, disabled intel speedstep (EIST), and set vcore voltage to "normal" with a 0.00 offset since i'm running it at stock. bios shows a vcore of 1.138 volts. cpu-z shows the same. aida64 shows 1.147 volts and gigabytes system viewer shows 1.147 volts as well.
> 
> with both 6800k and 6850k all those things where disabled.
> 
> so i really don't know which one is showing a correct value. i'm inclined to believe my bios and gigabytes own system viewer (and aida64 since it shows the same). i remember reading that cpu-z only shows vid not vcore. i know GB system viewer shows a little higher vcore than bios but i've noticed over the years vcore is typically a little higher in windows than in bios.
> 
> could a bios update cause the sensors to miss read? could the sensors be faulty or is hwinfo reading them incorrectly?


Hi, I'm getting this too...odd results.



My system
Gigabyte X99-UD3P
6800K, at 3.8GHz and Turbo 4GHz on all cores. Everything Auto Except CPU VRIN Loadline Calibration, which I manually set to: Medium**

My Max VCORE was 2.2 before, but now when I stress test with CPU-Z, I get a max of 1.56 (The prior 2.2 was when in the BIOS I had Auto for CPU VRIN Loadline Calibration -- I set mine to 3 (medium) not sure if that has something to do with it.

** I set that to medium as I was concerned after searching around, that the BIOS may set it to extreme.

This video explains vdroop, but doesn't really go into the settings LLC: 




It looks like if I set my base clock to 3.8 and Turbo to 4.0, I would need to manually manage the vdroop whedn going from idle to full load, can anyone let me know with Gigabyte X99 boards, for what I'm doing, would medium be ok, and if there's anything else I need to set? Basically, I'd be happy if I can keep it at 3.8GHz default with 4.0 Turbo without an over-voltage peak with vdroop.

According to CPU-Z and Aida64, I fluctuate from 1.272 and .775 (but I think that's based on VID, not VCORE) so I have no idea what VCORE is. I used the GB App center, it's "stuck" on 1.267 and never moves no matter what I do. My VRIN is at 1.9...the clocks info on my CPU from the GB app show 0. I can't seem to find anything accurate!

Any help/insight would be greatly appreciated!


----------



## Caos

Thanks for the latest beta version works great. a doubt. The custom colors only activating through the tray can be used? You could not just put the option to change the colors in options / OSDRTSS without activating the tray or graphics? thanks


----------



## Mumak

Quote:


> Originally Posted by *adobepro*
> 
> Hi, I'm getting this too...odd results.
> 
> 
> 
> My system
> Gigabyte X99-UD3P
> 6800K, at 3.8GHz and Turbo 4GHz on all cores. Everything Auto Except CPU VRIN Loadline Calibration, which I manually set to: Medium**
> 
> My Max VCORE was 2.2 before, but now when I stress test with CPU-Z, I get a max of 1.56 (The prior 2.2 was when in the BIOS I had Auto for CPU VRIN Loadline Calibration -- I set mine to 3 (medium) not sure if that has something to do with it.
> 
> ** I set that to medium as I was concerned after searching around, that the BIOS may set it to extreme.
> 
> This video explains vdroop, but doesn't really go into the settings LLC:
> 
> 
> 
> 
> It looks like if I set my base clock to 3.8 and Turbo to 4.0, I would need to manually manage the vdroop whedn going from idle to full load, can anyone let me know with Gigabyte X99 boards, for what I'm doing, would medium be ok, and if there's anything else I need to set? Basically, I'd be happy if I can keep it at 3.8GHz default with 4.0 Turbo without an over-voltage peak with vdroop.
> 
> According to CPU-Z and Aida64, I fluctuate from 1.272 and .775 (but I think that's based on VID, not VCORE) so I have no idea what VCORE is. I used the GB App center, it's "stuck" on 1.267 and never moves no matter what I do. My VRIN is at 1.9...the clocks info on my CPU from the GB app show 0. I can't seem to find anything accurate!
> 
> Any help/insight would be greatly appreciated!


On Haswell-based systems it's difficult to measure correct Vcore, most probably due to the FIVR.
On some systems this works only when not in idle states. So some tools (and BIOSes) report VID instead of Vcore, some others report measured Vcore only if >0.5V, otherwise they report VID.


----------



## Mumak

Quote:


> Originally Posted by *Caos*
> 
> Thanks for the latest beta version works great. a doubt. The custom colors only activating through the tray can be used? You could not just put the option to change the colors in options / OSDRTSS without activating the tray or graphics? thanks


Yes, currently a single color is shared between HWiNFO graphs, tray icons and RTSS items. This shall be changed to individual colors in future.


----------



## adobepro

Quote:


> Originally Posted by *Mumak*
> 
> On Haswell-based systems it's difficult to measure correct Vcore, most probably due to the FIVR.
> On some systems this works only when not in idle states. So some tools (and BIOSes) report VID instead of Vcore, some others report measured Vcore only if >0.5V, otherwise they report VID.


Thanks for the reply. One note, my mistake that I didn't get a chance to correct. I was using CPU-Z's HWMon, not HWInfo. HWInfo looks like it's reporting correct values, and like what you said, it may not actually be the vcore voltage it's reporting, it maybe the VID voltage, so it maybe getting more or less.

My only concern now is that I've set my clock to 38 base, 40 turbo and I don't want a spike in voltage every moment when the CPU enters a C state, downclocking from 4GHz to 1.2GHz, as it seems with my Gigabyte X99-UP3D board, I can't disable LLC, I can only set it to the minimum of Standard, and since these spikes are so quick, apps like HWInfo/Mon can't detect them...say, you go from .775 to 1.35 [+/-.03] for a few picoseconds then back to 1.287, 40x an hour, multiply that by 24/7 use, and a questionable lithography process which I've been reading about in terms of degradation/longevity of the Broadwell-e chips, it's a little concerning when it comes to the longevity of the CPU. Yes, most wont care, they'll get a new chip in a few years, but I don't want Windows 10 and whatever spyware MS comes up with in Win11, so I'm using the last fastest chip that has Win7 driver support and plan to use it for at least 6-8 years like my Q9550/SB 2600...I also plan another build with Ryzen for another purpose soon, since I can get an upgrade path to at least Ryzen 3 and Win7 drivers are available.


----------



## frankenstein406

Hello I'm getting audio corruption on win 7 when I have hard drive monitoring enabled for a toshiba x300 2tb hard drive. Hard drive monitoring seems to be fine for all other drives. Are you aware of any problems with this model hard drive, and hwinfo64? Thanks


----------



## Mumak

Quote:


> Originally Posted by *frankenstein406*
> 
> Hello I'm getting audio corruption on win 7 when I have hard drive monitoring enabled for a toshiba x300 2tb hard drive. Hard drive monitoring seems to be fine for all other drives. Are you aware of any problems with this model hard drive, and hwinfo64? Thanks


You can try to upgrade the storage controller (AHCI) driver to see if that helps. In case this drive is under an ASMedia Controller driver, it might help to replace this driver with the standard Microsoft AHCI driver.


----------



## LostParticle

Hello,

On the latest beta my VCore is not idling to 0.000V, like it used to happen with all the builds of HWiNFO64 so far. My cache voltage still idles at 0.000V but not my VCore anymore.

@Mumak, any ideas?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hello,
> 
> On the latest beta my VCore is not idling to 0.000V, like it used to happen with all the builds of HWiNFO64 so far. My cache voltage still idles at 0.000V but not my VCore anymore.
> 
> @Mumak, any ideas?


Yes, this is an intentional change per recommendation from mainboard vendors, which do the same 'trick'.
On CPUs with FIVR, when Vcore is read < 0.5V then VID is reported instead. This is because Vcore measurement is not reliable in low-power states on such CPUs.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, this is an intentional change per recommendation from mainboard vendors, which do the same 'trick'.
> On CPUs with FIVR, when Vcore is read < 0.5V then VID is reported instead. This is because Vcore measurement is not reliable in low-power states on such CPUs.


I see! Okay, is the cache voltage at 0.0V accurate then?


----------



## Mumak

Not sure about this, but I'd say "no".


----------



## BoredErica

Hello. I am running 7600k w/ z170 Asus Hero. The CPU Package Power reads 11w on Linpack/OCCT load. That seems impossible.

Also, a while back I made a post asking if you would consider having an option that makes it so HWinfo doesn't constantly go to the tray, but instead minimizes like a normal program. How goes it?

Thanks


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Not sure about this, but I'd say "no".


Okay, I understand.

So all of us, with CPUs utilizing FIVR, can we at least trust the Maximum V, or other, values HWiNFO64 is showing?

Thanks for today's build, by the way.


----------



## Mumak

Quote:


> Originally Posted by *Darkwizzie*
> 
> Hello. I am running 7600k w/ z170 Asus Hero. The CPU Package Power reads 11w on Linpack/OCCT load. That seems impossible.
> 
> Also, a while back I made a post asking if you would consider having an option that makes it so HWinfo doesn't constantly go to the tray, but instead minimizes like a normal program. How goes it?
> 
> Thanks


Do you maybe have SVID support disabled in the BIOS ? In that case CPU Power measurement doesn't work properly.

Have you tried the "Minimize Sensors instead of closing" option and clicking on the minimize box (windows top right corner) ?


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, I understand.
> 
> So all of us, with CPUs utilizing FIVR, can we at least trust the Maximum V, or other, values HWiNFO64 is showing?
> 
> Thanks for today's build, by the way.


I'm not familiar how particular mainboards really monitor Vcore, but AFAIK systems with FIVR can monitor Vcore only via a dedicated interface on CPU. This is because Vcore is such case hidden inside the CPU. So I'd say that none of the boards can reliably monitor Vcore (especially in low-power states) because they all rely on the same interface.


----------



## LostParticle

Quote:


> Originally Posted by *Darkwizzie*
> 
> Hello. I am running 7600k w/ z170 Asus Hero. The CPU Package Power reads 11w on Linpack/OCCT load. That seems impossible.
> 
> ...


CPU Package Power never works as long as I have SVID disabled on my Hero (see sig_rig).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I'm not familiar how particular mainboards really monitor Vcore, but AFAIK systems with FIVR can monitor Vcore only via a dedicated interface on CPU. This is because Vcore is such case hidden inside the CPU. So I'd say that none of the boards can reliably monitor Vcore (especially in low-power states) because they all rely on the same interface.


All right, thanks, no worries: numerous times in the past I've measured my motherboard's (ASRock Z97 OC Formula) various voltages using the onboard voltage measurement points , and the VCore, cache V and the rest, were always spot on. Using the same OC profiles I always use, I'm sure the same is valid for my Hero. So, I rest assured.

Thank you.


----------



## BoredErica

> Originally Posted by *Mumak*
> 
> Do you maybe have SVID support disabled in the BIOS ? In that case CPU Power measurement doesn't work properly.
> 
> Have you tried the "Minimize Sensors instead of closing" option and clicking on the minimize box (windows top right corner) ?


Both answers seem to check out.

Thank you!

One weirdness (which doesn't affect me really) is that when I set sensors to update every 1000ms, it seems to update every 2000ms (2 seconds). So for second by second update I need to set 500ms. This applies to all other numbers as well. I'm curious why that may be the case. Something to do with HPET perhaps?


----------



## LostParticle

I've just set "Polling Frequency : Global = 1000 ms" and checked it out, and it works fine on my system. Values which change frequently, like Voltages, appear to take a new value every one second = according to the Run Time indicator (bottom right corner).

@Mumak, to try this feature a bit I've set the Polling frequency to 500 ms. I now observe that the seconds in "Run Time" clock at the bottom right corner run faster... Is this normal?

Now I've set it to 200 ms, and the seconds on the timer run even faster! Is this how it is supposed to work?


----------



## BoredErica

Quote:


> Originally Posted by *LostParticle*
> 
> I've just set "Polling Frequency : Global = 1000 ms" and checked it out, and it works fine on my system. Values which change frequently, like Voltages, appear to take a new value every one second = according to the Run Time indicator (bottom right corner).
> 
> @Mumak, to try this feature a bit I've set the Polling frequency to 500 ms. I now observe that the seconds in "Run Time" clock at the bottom right corner run faster... Is this normal?
> 
> Now I've set it to 200 ms, and the seconds on the timer run even faster! Is this how it is supposed to work?


I feel like some sensor readings update at 1 sec as the fastest speed even if I set sensors to update at 100ms. But the timer on the bottom seem to run normally even if I set update interval to 100ms. But 1000ms -> 2 seconds, etc.

Weird!


----------



## Mumak

SVID is a must for power measuring to work. It allows IMON sampling, which is the base for this.
Quote:


> Originally Posted by *LostParticle*
> 
> I've just set "Polling Frequency : Global = 1000 ms" and checked it out, and it works fine on my system. Values which change frequently, like Voltages, appear to take a new value every one second = according to the Run Time indicator (bottom right corner).
> 
> @Mumak, to try this feature a bit I've set the Polling frequency to 500 ms. I now observe that the seconds in "Run Time" clock at the bottom right corner run faster... Is this normal?
> 
> Now I've set it to 200 ms, and the seconds on the timer run even faster! Is this how it is supposed to work?


Slight differences might occur during refresh intervals due to rounding. Important is that the whole interval displayed is correct. So try to start a stop watch and compare with HWiNFO after a longer interval (min. 10 sec). If these don't match, let me know.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Slight differences might occur during refresh intervals due to rounding. Important is that the whole interval displayed is correct. So try to start a stop watch and compare with HWiNFO after a longer interval (min. 10 sec). If these don't match, let me know.


Yes, I think that it works OK. Check the spoiler for further details.



Spoiler: Warning: Spoiler!



On the latest Win 10 Pro Insider preview, (because on my primary OS I do not keep these Apps), I've run Windows Stopwatch together with the latest HWiNFO64.
Due to being unable to start - reset both Applications at the same time, I first reset HWiNFO64 and then started Windows Stopwatch, located on my primary monitor (whereas HWiNFO64 is placed on my second monitor).
I've set polling at 200 ms and then at 100 ms.
After the Stopwatch reached 10 minutes I pressed PrtScn.




Perhaps one second (or less) has passed between reseting the monitoring tool and starting the Stopwatch. I think that it works correctly, though, up to you @Mumak to investigate / fine tune this further.


----------



## Streetdragon

Volt8 is a temp-sensor and not a voltage. how can i change it? i tried a reinstall, but i have no idea where it saves the settings and all.

Normaly uninstall = delet all.....


----------



## Mumak

Quote:


> Originally Posted by *Streetdragon*
> 
> 
> 
> Volt8 is a temp-sensor and not a voltage. how can i change it? i tried a reinstall, but i have no idea where it saves the settings and all.
> 
> Normaly uninstall = delet all.....


Not sure where that comes from and how it happened, but you might try to do a complete "Reset Preferences" in main HWiNFO settings to restore all settings to original.


----------



## Streetdragon

already tried that. the order and enabled/disabled sensores are still the same


----------



## Mumak

Quote:


> Originally Posted by *Streetdragon*
> 
> already tried that. the order and enabled/disabled sensores are still the same


Have you tried that before launching the scan ? Right after starting HWiNFO, click the Settings button and then click "Reset Preferences".


----------



## Streetdragon

launching the scan? never saw that befor. i will take a look for it and report back


----------



## Mumak

Quote:


> Originally Posted by *Streetdragon*
> 
> launching the scan? never saw that befor. i will take a look for it and report back


When you launch HWiNFO you get an initial window (small welcome screen; unless you use Auto Start with Windows). Then if you press Run, the scan starts. What I meant was to do the reset preferences before clicking the Run button.


----------



## Streetdragon

ahh worked thx! best software ever^^


----------



## Mega Man

Quote:


> Originally Posted by *LostParticle*
> 
> Quote:
> 
> 
> 
> Originally Posted by *Mumak*
> 
> Not sure about this, but I'd say "no".
> 
> 
> 
> Okay, I understand.
> 
> So all of us, with CPUs utilizing FIVR, can we at least trust the Maximum V, or other, values HWiNFO64 is showing?
> 
> Thanks for today's build, by the way.
Click to expand...

Rule 1- if you need such accurate values, don't trust software.

Rule 2- *never* trust software power draw

Rule 3- if in doubt - or even if the values you measure by hand are " spot on " refer back to rule 1 and 2


----------



## Mumak

This is not just about software, we read the information straight from hardware.
There are circuits measuring various parameters (voltages, current) and values that we read from them are also using by components like CPUs, GPUs to enforce power management. So if those circuits don't provide precise data, the rest of the system might be affected as well.
Also note, that for power measuring, usually only the most important rails implement monitoring capabilities, rest of them is estimated based on activity counters or calibrated constants. What software reports is usually used by the system internally as well. It's in the hands of system vendors how accurately they implement monitoring, but often it's limited due to cost factors (BOM).


----------



## Mega Man

Oh I know, the problem is they use a cheap monitoring chips on boards. There is a reason a quality meter costs so much


----------



## orlfman

Hey @Mumak! Wondering if hwinfo can't read the 580's gpu utilization and memory controller load anymore?


as you can see gpu utilization is just stuck at 16% regardless of load... and memory controller load is stuck at 1%. i also noticed with gpu-z memory controller load is stuck at 100%. GPU D3D utilization works though.

I tested this with the latest stable and beta. both behave the same. i'm using the latest radeon drivers. 17.7.1.

edit:
here's a pic to compare to gpu-z. latest version as well.

it too is stuck with 16% gpu utilization but stuck with 100% memory controller load instead of 1% like with hwinfo. wattmans gpu utilization appears to work though it doesn't show memory utilization.


----------



## Mumak

Quote:


> Originally Posted by *orlfman*
> 
> Hey @Mumak! Wondering if hwinfo can't read the 580's gpu utilization and memory controller load anymore?
> 
> 
> as you can see gpu utilization is just stuck at 16% regardless of load... and memory controller load is stuck at 1%. i also noticed with gpu-z memory controller load is stuck at 100%. GPU D3D utilization works though.
> 
> I tested this with the latest stable and beta. both behave the same. i'm using the latest radeon drivers. 17.7.1.
> 
> edit:
> here's a pic to compare to gpu-z. latest version as well.
> 
> it too is stuck with 16% gpu utilization but stuck with 100% memory controller load instead of 1% like with hwinfo. wattmans gpu utilization appears to work though it doesn't show memory utilization.


Please attach the HWiNFO Debug File with sensor data and I will check this problem.


----------



## LostParticle

Hi Martin, thanks for the latest beta (v5.55-3210). Just letting you know that this latest beta introduced a second (additional) CPU Package Sensor, out of nowhere, in my system. I reset the tool, by deleting "HWiNFO64" key from my Registry, and I stressed my system. The average of both "CPU Package" values was the same, although their current values were different, probably due to polling, so I just Hid the new one. Just making you aware of this.

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin, thanks for the latest beta (v5.55-3210). Just letting you know that this latest beta introduced a second (additional) CPU Package Sensor, out of nowhere, in my system. I reset the tool, by deleting "HWiNFO64" key from my Registry, and I stressed my system. The average of both "CPU Package" values was the same, although their current values were different, probably due to polling, so I just Hid the new one. Just making you aware of this.
> 
> Thank you.


Thanks, this was intentional. The thing is that the CPU Package temperature reported under the CPU node seemed to use some offset (~ 5-10 C) on some systems. So I added another readout of the same value, but from a different register and this is what appears now under the DTS node.
On most systems these values should be pretty identical (they both are calculated by the CPU Power Control Unit), but as mentioned on some of them it could be different. And I'm not sure which of these values is correct in this case, I think that the offset applied is to improve cooling efficiency (so a similar 'trick' as AMD does with the Ryzen X-series).


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Thanks, this was intentional. The thing is that the CPU Package temperature reported under the CPU node seemed to use some offset (~ 5-10 C) on some systems. So I added another readout of the same value, but from a different register and this is what appears now under the DTS node.
> On most systems these values should be pretty identical (they both are calculated by the CPU Power Control Unit), but as mentioned on some of them it could be different. And I'm not sure which of these values is correct in this case, I think that the offset applied is to improve cooling efficiency (so a similar 'trick' as AMD does with the Ryzen X-series).


Ah, I see! Thanks for the clarification, glad that I've asked (and not consider it a glitch and forget it). I've unhidden that new value and placed it under my previous CPU Package sensor. I will monitor it a couple of weeks, under various loads, and then decided if I'll keep it or disable it.

Thank you.



Spoiler: Warning: Spoiler!


----------



## Mumak

Is anyone using AMD GPU on Crimson 17.7.2 perhaps seeing problems with system stuttering, mouse lagging when running HWiNFO ?
This seems to be a bug in Crimson 17.7.2., which I have submitted to AMD.
As a temporary workaround disabling monitoring of the "GPU Fan (OD5)" value seems to resolve this problem.


----------



## bluej511

Quote:


> Originally Posted by *Mumak*
> 
> Is anyone using AMD GPU on Crimson 17.7.2 perhaps seeing problems with system stuttering, mouse lagging when running HWiNFO ?
> This seems to be a bug in Crimson 17.7.2., which I have submitted to AMD.
> As a temporary workaround disabling monitoring of the "GPU Fan (OD5)" value seems to resolve this problem.


Ive heard a few complaints as well and seems like 17.7.2 is buggy and has new issues with afterburner as well now. Ive heard the mouse lagging issue but not sure it's while running hwinfo. The thread on this forum and i believe game-debate.com also has people complaining. I unfortunately need to update to my driver soon as i keep getting thread_stuck_in_device_driver blue screens but may just stick 17.7.2.


----------



## AlphaC

Is there a bug with Ryzen chips reading 25 degrees C when SVM mode is enabled?


----------



## herrklisch

Quote:


> Originally Posted by *Mumak*
> 
> Is anyone using AMD GPU on Crimson 17.7.2 perhaps seeing problems with system stuttering, mouse lagging when running HWiNFO ?
> This seems to be a bug in Crimson 17.7.2., which I have submitted to AMD.
> As a temporary workaround disabling monitoring of the "GPU Fan (OD5)" value seems to resolve this problem.


I have that problem. Mouse lag and sutter every time on HWinfo refresh cycle. I even did fresh win10 install today thinking that something is wrong with my windows.
Problem is still active even if I disable OD5 value. When I disable whole GPU monitoring section, problem is gone.


----------



## Mumak

Quote:


> Originally Posted by *herrklisch*
> 
> I have that problem. Mouse lag and sutter every time on HWinfo refresh cycle. I even did fresh win10 install today thinking that something is wrong with my windows.
> Problem is still active even if I disable OD5 value. When I disable whole GPU monitoring section, problem is gone.


Can you please check if there's any other value under the GPU sensor, which requires disabling besides the "GPU Fan (OD5)" ? So leave the GPU sensor section enabled and try to find which values are causing it by disabling them. This is quite important, so that AMD can get detailed information in order to fix it.


----------



## herrklisch

Ok, so I restarted Windows just for testing and to eliminate possible errors. After restart i tried testing and disabling every value under GPU section. Disabling GPU Fan (OD5) is now working as you said, sutter is gone after disabling it. I can leave other values on enabled monitoring, even GPU Fan speed (OD5).


----------



## orlfman

Quote:


> Originally Posted by *Mumak*
> 
> Please attach the HWiNFO Debug File with sensor data and I will check this problem.


hi mumak! sorry, my 1800x had killed itself running at stock so i've been without my main computer for the last two weeks. had to wait until i received my new one from amd and now finally got everything back up and running again. since then i went ahead and did a fresh install of windows with the latest 17.7.2 drivers. i'm unable to attach the debug file here so I uploaded it to my google drive here. i hope it helps. i also encountered a few people on reddit who are experiencing the same.

also, i don't notice the lag you were describing with the latest beta version of hwinfo (555_3220) but i do notice it with cpu-z and gpu-z.


----------



## Mumak

Quote:


> Originally Posted by *orlfman*
> 
> hi mumak! sorry, my 1800x had killed itself running at stock so i've been without my main computer for the last two weeks. had to wait until i received my new one from amd and now finally got everything back up and running again. since then i went ahead and did a fresh install of windows with the latest 17.7.2 drivers. i'm unable to attach the debug file here so I uploaded it to my google drive here. i hope it helps. i also encountered a few people on reddit who are experiencing the same.
> 
> also, i don't notice the lag you were describing with the latest beta version of hwinfo (555_3220) but i do notice it with cpu-z and gpu-z.


Thanks. I will fix GPU Usage in the next build, but don't know how to fix the Memory Controller usage yet.


----------



## LostParticle

Hello Martin,

In the latest version of HWiNFO64 my Override (fixed) VCore does not drop on idle anymore. I always use Adaptive but today I tested the Override (fixed) mode of my ASRock Z97 OC Formula. ALL C-States are enabled in my BIOS, as I always have them. I am using the High Performance power plan in Windows 10 Pro, with Minimum Processor state set to 0%, again as I always do. Well, this time my VCore does not drop on idle.

Here's a screenshot after leaving my PC untouched for approx. 5 minutes. While the Minimum VCore seems to have dropped, I can reassure you that it constantly remained at around the Current values. The Average (VCore) proves this. It just dropped for a fraction of a second, and then returned to the Current values.

In the past, even though I very rarely used Override VCore mode, I definitely recall my VCore dropping on idle in this mode.

What happened now, @Mumak?

Btw, I have 1.220V fixed VCore, set in the BIOS.

Thank you.


----------



## Mumak

This is because I have changed reporting of Vcore per recommendation from multiple mainboard manufacturers: now if Vcore measured is < 0.5V, then VID is reported instead.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> This is because I have changed reporting of Vcore per recommendation from multiple mainboard manufacturers: now if Vcore measured is < 0.5V, then VID is reported instead.


I see... I thought so....

Isn't this a bit misleading, though? Won't the people think that their C-States are not applied or functioning properly, after this? And from where can one get assured that his VCore is idling? From the CPU Package Power sensor? Or the C-State Residency?

Note: Personally, I do not mind because I'm always using Adaptive, and that one does lower on idle.

Thank you.


----------



## ucode

Personally I'd prefer VID on anything with FIVR. The vcore measurement reads low because the voltage is actually being gated off on on so many times that it is integrated by the capacitor filtering on the ADC input to the SIO.

VCore reading even makes less sense on my X99 where the reading is taken on just one physical core, the other cores could be doing something totally different.

As for C-states, just check the residency counters for this.


----------



## VickB

Hey Martin quick question, just noticed that under hwinfo64 v5.56-3230 I'm not getting any VRM monitoring on my new Vega 64 card. Curious as i asked in the owner thread about HBM temperature and he had an entire list of VRM information (including temperatures) that my card does not have. Curious as to why.


----------



## Mumak

Quote:


> Originally Posted by *VickB*
> 
> Hey Martin quick question, just noticed that under hwinfo64 v5.56-3230 I'm not getting any VRM monitoring on my new Vega 64 card. Curious as i asked in the owner thread about HBM temperature and he had an entire list of VRM information (including temperatures) that my card does not have. Curious as to why.


Please post a screenshot of the sensors. Also the HWiNFO Debug File would be very helpful for me to check the details.


----------



## VickB

Quote:


> Originally Posted by *Mumak*
> 
> Please post a screenshot of the sensors. Also the HWiNFO Debug File would be very helpful for me to check the details.


Yea np, let me know how to get the debug file for you and would be happy to. Here's a screenshot.



And heres another member using the mining drivers instead of 17.8.1. Not sure why there's a difference between the 2 for monitoring though a bit odd.


----------



## Mumak

Quote:


> Originally Posted by *VickB*
> 
> Yea np, let me know how to get the debug file for you and would be happy to. Here's a screenshot.
> 
> 
> 
> And heres another member using the mining drivers instead of 17.8.1. Not sure why there's a difference between the 2 for monitoring though a bit odd.


Thanks, I see now what's the issue. It's the GPU card capability - your model doesn't feature a VRM (Digital PWM) capable of monitoring those parameters.
The other user is probably using a custom OEM card model with different PWMs.


----------



## rednow

I have an issue with latest beta versions of HWINFO64 after adding second Vega64 LC to my rig. When I'm starting HWINFO the FIRST Vega starts to run max fan speed and Wattman reports that max gpu temp was exceeded. It happened when gpus are idle or under load - in both cases.
When I had only one Vega there was no problems.
I'm running beta blockchain drivers with HBCC enabled maybe this is a problem.


----------



## Mumak

Quote:


> Originally Posted by *rednow*
> 
> I have an issue with latest beta versions of HWINFO64 after adding second Vega64 LC to my rig. When I'm starting HWINFO the FIRST Vega starts to run max fan speed and Wattman reports that max gpu temp was exceeded. It happened when gpus are idle or under load - in both cases.
> When I had only one Vega there was no problems.
> I'm running beta blockchain drivers with HBCC enabled maybe this is a problem.


Please try to disable "GPU I2C Support" in HWiNFO and let me know if that helps.


----------



## rednow

Quote:


> Originally Posted by *Mumak*
> 
> Please try to disable "GPU I2C Support" in HWiNFO and let me know if that helps.


Yes, think it helps, thanks
By the way, hwinfo64 and gpu-z showing weird total gpu power.
In fact, gpu-z doesn't show it ("-")


----------



## Mumak

Quote:


> Originally Posted by *rednow*
> 
> Yes, think it helps, thanks
> By the way, hwinfo64 and gpu-z showing weird total gpu power.
> In fact, gpu-z doesn't show it ("-")


It seems to be reporting fan RPM instead of GPU Power







This is most probably a driver problem, but to be sure, please use the latest HWiNFO Beta version and attach the HWiNFO Debug File for analysis.


----------



## rednow

Quote:


> Originally Posted by *Mumak*
> 
> It seems to be reporting fan RPM instead of GPU Power
> 
> 
> 
> 
> 
> 
> 
> This is most probably a driver problem, but to be sure, please use the latest HWiNFO Beta version and attach the HWiNFO Debug File for analysis.


Yes, it is beta blockchain drivers. It is latest hw64_557_3250. Gpu-z shows only -. Sorry, I'm afraid of your debug files )) Rebooting the rig is a pain ))


----------



## Mumak

Quote:


> Originally Posted by *rednow*
> 
> Yes, it is beta blockchain drivers. It is latest hw64_557_3250. Gpu-z shows only -. Sorry, I'm afraid of your debug files )) Rebooting the rig is a pain ))


Well, without the Debug File it's hard to tell exactly where the problem is. I could then pass it to AMD for fixing. My last bug report made it also into Crimson release notes


----------



## rednow

Ok, here you are. But AMD stated that blockchain drivers are provided AS IS and will not support it.

HWiNFO64_dbg.zip 84k .zip file


----------



## Mumak

Quote:


> Originally Posted by *rednow*
> 
> Ok, here you are. But AMD stated that blockchain drivers are provided AS IS and will not support it.
> 
> HWiNFO64_dbg.zip 84k .zip file


Thanks, we'll see







bug sent to AMD..


----------



## Korennya

I'm having trouble with hwinfo64 on my Asus c6h. Specifically, aisuite and hwinfo64 won't play nice together. If the two are running simultaneously aisuite will loose control of the fans after about a period of 3-5 mins. Fans run at fixed rpm regardless of temperatures. I also can not manually change the fan rpm by adjusting the curves or using fixed rpm mode. I have to do a full restart for aisuite to gain control. Restarting aisuite isn't good enough. If I stop hwinfo64 from auto loading with windows, aisuite will retain control for hours with out issue.

I have hwinfo64 set to not read the Asus ec sensor. How can I get these to play nice? I use aisuite for fan control and hwinfo for thermal shutdown insurance after having a water line pop on my rig.


----------



## Mumak

Quote:


> Originally Posted by *Korennya*
> 
> I'm having trouble with hwinfo64 on my Asus c6h. Specifically, aisuite and hwinfo64 won't play nice together. If the two are running simultaneously aisuite will loose control of the fans after about a period of 3-5 mins. Fans run at fixed rpm regardless of temperatures. I also can not manually change the fan rpm by adjusting the curves or using fixed rpm mode. I have to do a full restart for aisuite to gain control. Restarting aisuite isn't good enough. If I stop hwinfo64 from auto loading with windows, aisuite will retain control for hours with out issue.
> 
> I have hwinfo64 set to not read the Asus ec sensor. How can I get these to play nice? I use aisuite for fan control and hwinfo for thermal shutdown insurance after having a water line pop on my rig.


I'm afraid there's probably no way how to make this work. These tools cause conflicts when accessing the board functions concurrently.
Most users that I know are staying away from AI Suite due to various problems it's causing, some even don't dare to try to install it


----------



## gupsterg

@Korennya

I would opt to control fans by setting profile in UEFI. Then use HWiNFO as monitoring.

I have done usage of ~48hrs+ continuous this way on C6H and found it to have no issues. I have used non X and X CPU on same board with same fan setup, etc. There is currently a bug on C6H where when using X CPU if you use sleep/resume the temp offset is lost on CPU sensor, making fan profile incorrect. This down to be fixed.

Currently not using C6H but ZE with TR. I'm using a WC loop. I added temp sensors to loop. The chassis fan headers allow differing temp sensor. So fan profile uses loop temp and pump. Again no issues.

I would think C6H would also allow this setup as has a T_SENSOR header.


----------



## Korennya

ThAnks for the reply guys. I guess I'll just use aisuite to dial in the fan curves then set in bios as suggested and then remove aisuite. I already have two temp sensors in the water loop. I don't use them for controlling fans though. I find it's not as effective as basing them off hardware in my setup.

Right now I have a 60mm 360 rad and a 40mm 240 rad cooling 2 1080 and a c6h monoblock. I use fan header on master 1080 to control fans on the 360 rad and the fans on 240 are off CPU temp. Case fans are targeting water temp and mobo temp

Disappointed programs won't work together on this board. They ran fine on my sabertooth 990fx.


----------



## Mumak

Quote:


> Originally Posted by *Korennya*
> 
> Disappointed programs won't work together on this board. They ran fine on my sabertooth 990fx.


Earlier boards had a simpler sensor design, C6H and ZENITH are more complex and the SIO/LPC chip is very sensitive to concurrent access.
It also seems to me the LPC has some flaw there, we needed to develop certain mechanisms with ASUS to at least not collide with the BIOS/EC, but AiSuite doesn't seem to be willing to play nice with others. This might change in the future though, hopefully...


----------



## Korennya

If not running aisuite any longer, is it still recommended to not monitor the Asus ec chip with hwinfo64? The water temp inputs run through that chip, making those headers useless now without aisuite to monitor them.


----------



## Mumak

Quote:


> Originally Posted by *Korennya*
> 
> If not running aisuite any longer, is it still recommended to not monitor the Asus ec chip with hwinfo64? The water temp inputs run through that chip, making those headers useless now without aisuite to monitor them.


I think there should be no problem in such case. But if you don't need to watch those values or experience some hiccups in games, then try to disable it.


----------



## gupsterg

Quote:


> Originally Posted by *Korennya*
> 
> If not running aisuite any longer, is it still recommended to not monitor the Asus ec chip with hwinfo64? The water temp inputs run through that chip, making those headers useless now without aisuite to monitor them.


I have had no issues monitoring ASUS EC on M7R, C6H and ZE.

I have done countless hours of continuous usage when stress testing and [email protected], non issue for me.

Normal usage/gaming I never use monitoring and again when benchmarking.

It is a rare occasion I have monitoring active when normal usage/gaming/benchmarking, if this has a "performance" affect (which I haven't noted) then I discount as I wanted the monitoring data.


----------



## JMTH

Hello, I have been having issues with the ASUS X99-Deluxe ii Motherboard not showing the VCCSA and Cache Voltages. Here is the Debug file and Report. Can you take a look at let me know if this board just doesn't show those voltages please?

Also I have been trying to post in the HWiNFO forum but it refuses to send me the verification email. I have tried about 5 to 6 times.

Thanks in advance!

HWiNFO_10122017.zip 287k .zip file


----------



## Mumak

Quote:


> Originally Posted by *JMTH*
> 
> Hello, I have been having issues with the ASUS X99-Deluxe ii Motherboard not showing the VCCSA and Cache Voltages. Here is the Debug file and Report. Can you take a look at let me know if this board just doesn't show those voltages please?
> 
> Also I have been trying to post in the HWiNFO forum but it refuses to send me the verification email. I have tried about 5 to 6 times.
> 
> Thanks in advance!
> 
> HWiNFO_10122017.zip 287k .zip file


Sorry for the late reply. I checked the dump and both VCCSA and "CPU Cache" read as zero from the SIO/EC. Are these values shown in the BIOS or ASUS AI Suite ?


----------



## JMTH

Quote:


> Originally Posted by *Mumak*
> 
> Sorry for the late reply. I checked the dump and both VCCSA and "CPU Cache" read as zero from the SIO/EC. Are these values shown in the BIOS or ASUS AI Suite ?


It shows the value in the BIOS when its typed in when using Manual mode, but it doesnt show the actual value in AIDA. If you use adaptive/offset modes it just shows 0's in the BIOS, again nothing in AIDA.

I did not install the AI Suite.

Ill get a picture of Manual Mode next reboot I do.

Offset Mode


----------



## Mumak

Quote:


> Originally Posted by *JMTH*
> 
> It shows the value in the BIOS when its typed in when using Manual mode, but it doesnt show the actual value in AIDA. If you use adaptive/offset modes it just shows 0's in the BIOS, again nothing in AIDA.
> 
> I did not install the AI Suite.
> 
> Ill get a picture of Manual Mode next reboot I do.
> 
> Offset Mode


If not even the BIOS shows the actual monitored value (not the setting), then it probably can't be monitored.


----------



## JMTH

Sorry I lied, its not in the Manual mode either!



Do you think there is a driver or something in the AI Suite?


----------



## Mumak

Quote:


> Originally Posted by *JMTH*
> 
> Sorry I lied, its not in the Manual mode either!
> 
> 
> 
> Do you think there is a driver or something in the AI Suite?


I never dared to install AI Suite







, but AFAIK it comes with several drivers and sometimes it's not easy to get rid of them all.


----------



## JMTH

Lol yeah that's why I didn't install it either. Well I have a ticket with Asus, I'll see what, if anything, they say then maybe install it and see what happens. Thanks for looking! I'll post again when I hear back hehe if I hear back.


----------



## Skylinestar

If cache clock is ring clock, why HWiNFO64 report differently?


----------



## Mumak

Quote:


> Originally Posted by *Skylinestar*
> 
> If cache clock is ring clock, why HWiNFO64 report differently?


ASRock seems to base this clock on 100 MHz rather than the actual 133 MHz BCLK (which is what HWiNFO does).


----------



## Skylinestar

Quote:


> Originally Posted by *Mumak*
> 
> ASRock seems to base this clock on 100 MHz rather than the actual 133 MHz BCLK (which is what HWiNFO does).


Surprised to see UEFI report wrongly.


----------



## ssateneth

Ayyyyyyy didnt know you were here too Martin!


----------



## Mr.N00bLaR

On my ASUS X99A/USB3.1 I see two temperatures for what I think the CPU Package temp is. Not sure which one is right. The first underlined item has the core temps plus a cpu package temp. This is always the lower of the two package temps. Under load, it can be as much as 10C lower than the other. The second underling section has the hotter. Which is correct?


----------



## ssateneth

@Mumak would it be possible to relook at threadripper SVI2 TFN sensors? See if there are any more sensors since there are 2 dies? Some of sensors seems mislabeled. 3 of the sensors seem to be SoC Voltage, current, and power, then 3 more seem to be CPU cores voltage, current, and power, then the extra power sensor (SMU) is probably correctly named CPU Package power since it will consistently have the highest power draw under load, but can be less than either of the SVI2 TFN power sensors for whatever reason under idle.

3 of them definately seem linked to SoC because one of the voltages is directly linked to SoC voltage set in BIOS, then if you multiply that voltage sensor by the correct SVI2 TFN current sensor, you get -exactly- one of the power SVI2 TFN power sensors. Then the same goes for the other voltage sensor to match it with the appropriate current and power sensor, leaving the SMU package power sensor


----------



## Mumak

Quote:


> Originally Posted by *Mr.N00bLaR*
> 
> On my ASUS X99A/USB3.1 I see two temperatures for what I think the CPU Package temp is. Not sure which one is right. The first underlined item has the core temps plus a cpu package temp. This is always the lower of the two package temps. Under load, it can be as much as 10C lower than the other. The second underling section has the hotter. Which is correct?


On most systems these values are same, but some others seem to use an offset (probably to compensate fan speeds). Frankly speaking, I'm not 100% sure which of those is correct as Intel doesn't explain this. In my opinion values under the DTS sensor should be correct, as these are considered as reference values.


----------



## Mumak

Quote:


> Originally Posted by *ssateneth*
> 
> @Mumak would it be possible to relook at threadripper SVI2 TFN sensors? See if there are any more sensors since there are 2 dies? Some of sensors seems mislabeled. 3 of the sensors seem to be SoC Voltage, current, and power, then 3 more seem to be CPU cores voltage, current, and power, then the extra power sensor (SMU) is probably correctly named CPU Package power since it will consistently have the highest power draw under load, but can be less than either of the SVI2 TFN power sensors for whatever reason under idle.
> 
> 3 of them definately seem linked to SoC because one of the voltages is directly linked to SoC voltage set in BIOS, then if you multiply that voltage sensor by the correct SVI2 TFN current sensor, you get -exactly- one of the power SVI2 TFN power sensors. Then the same goes for the other voltage sensor to match it with the appropriate current and power sensor, leaving the SMU package power sensor


This telemetry is often not precise and can be misleading as some systems might not be properly calibrated or use system-specific adjustments that cannot be universally determined.
I have already checked this in the past, but couldn't find more sensors to retrieve information. Some of the rails that might be there are just returning 0 values.
Which set do you believe is related to SoC ? I think it's the one under Node #0 sensor and the second TFN set under Node #1 is the core.


----------



## ssateneth

Quote:


> Originally Posted by *Mumak*
> 
> This telemetry is often not precise and can be misleading as some systems might not be properly calibrated or use system-specific adjustments that cannot be universally determined.
> I have already checked this in the past, but couldn't find more sensors to retrieve information. Some of the rails that might be there are just returning 0 values.
> Which set do you believe is related to SoC ? I think it's the one under Node #0 sensor and the second TFN set under Node #1 is the core.


Node #0 has what I believe is SoC volt, current, and power, as well as the correctly labeled (?) package power (SMU) sensor. Node #1 has the correctly labeled (?) CPU Core voltage, current, and power.


----------



## Mumak

Quote:


> Originally Posted by *ssateneth*
> 
> Node #0 has what I believe is SoC volt, current, and power, as well as the correctly labeled (?) package power (SMU) sensor. Node #1 has the correctly labeled (?) CPU Core voltage, current, and power.


I believe you're right. I'm adjusting and testing this now, also current/power reporting which was quite off. But there is still a lot of unknowns (especially the SoC current/power).


----------



## ssateneth

Quote:


> Originally Posted by *Mumak*
> 
> I believe you're right. I'm adjusting and testing this now, also current/power reporting which was quite off. But there is still a lot of unknowns (especially the SoC current/power).


Thanks. Part of why I brought it up to begin with is AM4 chips seem to have some more sensors showing compared to TR4 chips, even though some of them are superfluous. Yknow, for completion sake.


----------



## Mumak

@ssateneth
Please see here regarding the change to TR reporting in latest version:
http://www.overclock.net/t/1636566/asus-rog-zenith-extreme-x399-threadripper-overclocking-support/1450#post_26426249


----------



## BoMbY

Beta Version v5.61-3293 is crashing my Vega 64 hard, a few seconds after start, with AMD drivers 17.11.3 and 17.11.4 at least.

v.5.58-3255 is showing wrong sensor values for Vega, but no crash.

Edit: Now 5.58 did also crash, but after a longer time. May have something to do with AGESA 1.0.7.1 on the C6H, or with the AMD drivers. I'm not sure. But happened so far only with hwinfo64 running.


----------



## Mumak

Quote:


> Originally Posted by *BoMbY*
> 
> Beta Version v5.61-3293 is crashing my Vega 64 hard, a few seconds after start, with AMD drivers 17.11.3 and 17.11.4 at least.
> 
> v.5.58-3255 is showing wrong sensor values for Vega, but no crash.
> 
> Edit: Now 5.58 did also crash, but after a longer time. May have something to do with AGESA 1.0.7.1 on the C6H, or with the AMD drivers. I'm not sure. But happened so far only with hwinfo64 running.


Please see here: http://www.overclock.net/t/1634018/official-vega-frontier-rx-vega-owners-thread/4830#post_26477117


----------



## porschedrifter

Quote:


> Originally Posted by *Mumak*
> 
> Please see here: http://www.overclock.net/t/1634018/official-vega-frontier-rx-vega-owners-thread/4830#post_26477117


Damn! So glad i found this thread and post!! Having this issue for days and pulling my hair out!!!!!!!!!!!!!!!!!!!!
finally!!! lol. I actually just figured out it was HwInfo potentially causing the issue.


----------



## porschedrifter

Quote:


> Originally Posted by *Mumak*
> 
> Don't know if this has been already noticed here, but it seems that AMD has finally unblocked I2C access to VRMs on Vega.
> 
> 
> 
> Not sure if it's since Crimson 17.11.3, but with 17.11.4 it's surely there.
> So now you should be able to see all GPU VRM details in HWiNFO including temperatures for both GPU Core and Memory VRMs.
> Unfortunately some users started to experience crashes here and it happens when HWiNFO tries to access those VRMs via I2C. Some GPUs seems to be affected, some not. Don't know yet why is this..
> If you're experiencing such hard crash during HWiNFO startup, then disable the "GPU I2C Support" option.


is there any benefit from also using the "Prefer AMD ADL" options?


----------



## Mumak

Quote:


> Originally Posted by *porschedrifter*
> 
> is there any benefit from also using the "Prefer AMD ADL" options?


No benefit at all.
It's there only because I was hoping one day AMD will come with reliable I2C support in ADL. But this obviously didn't happen yet.


----------



## LostParticle

Hi Martin,

Why is the GPU Memory clock showing half in HWiNFO64? Is it OK if I will multiply it by 2, in Custom/Customize values/Multiply? Will it work accurately this way?



Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin,
> 
> Why is the GPU Memory clock showing half in HWiNFO64? Is it OK if I will multiply it by 2, in Custom/Customize values/Multiply? Will it work accurately this way?
> 
> 
> 
> Thank you.


Because it showing the real clock in MHz, not the effective DDR one.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Because it showing the real clock in MHz, not the effective DDR one.


Ah, okay, I see... Well, I do not understand exactly what this means (lol), so what interests me is this: Since the official EVGA tool is showing 4000-something, is it OK if I will set this value at 2x ? Will this produce accurate values?

Thank you.

EDIT: Well, MSI Afterburner, as well, shows my Mem clock at around 4000 MHz, so - since I'm not getting a determinate answer - I am setting it at x2 in HWiNFO64, as well.


----------



## LostParticle

Hello (again), what is "GPU Video Clock"?

I know that GPU Clock shows the MHz my video-card is running. What is GPU *video* clock, though?


----------



## Mumak

That's clock of the media engine inside the GPU.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> That's clock of the media engine inside the GPU.


Okay...?

And what does this media engine do? Is it responsible for decoding videos, for example? Or, something else?

Martin, I also have one suggestion and one request, if possible:

Suggestion: Why don't you create a table or a list, where all HWiNFO's sensor values would be defined / explained?








So that you won't have to reply to the many people asking questions about what "this" or "that", does?

Request: after purchasing my new GPU I had to Hide all the C-State Residency values, because otherwise my Sensor's table won't fit my 23" screen... (I don't like scroll-bars). Is it possible to implement an one-row "average" C-State residency sensor?

Thank you.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay...?
> 
> And what does this media engine do? Is it responsible for decoding videos, for example? Or, something else?


Yes, that's it - video/media decoding/encoding.
Quote:


> Originally Posted by *LostParticle*
> 
> Martin, I also have one suggestion and one request, if possible:
> 
> Suggestion: Why don't you create a table or a list, where all HWiNFO's sensor values would be defined / explained?
> 
> 
> 
> 
> 
> 
> 
> 
> So that you won't have to reply to the many people asking questions about what "this" or "that", does?


Such a list would be really huge and sometimes not easy to maintain. I had a plan for more detailed descriptions (i.e. via tooltips), but haven't managed do implement it yet. It would be a huge effort due to the large amount of different sensors on different components. I have some other similar work in progress, but it's still in progress...
Quote:


> Originally Posted by *LostParticle*
> 
> Request: after purchasing my new GPU I had to Hide all the C-State Residency values, because otherwise my Sensor's table won't fit my 23" screen... (I don't like scroll-bars). Is it possible to implement an one-row "average" C-State residency sensor?


I'm sorry, this is not in plan for near future.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Yes, that's it - video/media decoding/encoding.


Okay, another important sensor I should not hide then...
Quote:


> Originally Posted by *Mumak*
> 
> Such a list would be really huge and sometimes not easy to maintain. I had a plan for more detailed descriptions (i.e. via tooltips), but haven't managed do implement it yet. It would be a huge effort due to the large amount of different sensors on different components. I have some other similar work in progress, but it's still in progress...


I understand what you mean, regarding "the large amount of different sensors" (of different components and vendors?)... Perhaps, for each new Sensor you add, make a small note in a .txt file, and later copy and paste it in the list? Anyway, it will be of huge help, when it will be finally finalized.
Quote:


> Originally Posted by *Mumak*
> 
> I'm sorry, this is not in plan for near future.


Ah, too bad, no worries though. I'm not sure if it's even possible / if it could be reliable.
I should dedicate a bigger screen









Thanks a lot


----------



## Hequaqua

Mumak....

Is there any way to save the custom layout?. I would like to save how I have it set up, so when I do a clean install of Windows...I don't have to go through all the readings/layouts/labels/etc.

Thanks ahead of time!


----------



## LostParticle

Quote:


> Originally Posted by *Hequaqua*
> 
> Mumak....
> 
> Is there any way to save the custom layout?. I would like to save how I have it set up, so when I do a clean install of Windows...I don't have to go through all the readings/layouts/labels/etc.
> 
> Thanks ahead of time!


Right-click on HWiNFO icon and open Settings. Then, Backup User Settings.


----------



## Hequaqua

Quote:


> Originally Posted by *LostParticle*
> 
> Right-click on HWiNFO icon and open Settings. Then, Backup User Settings.


Thanks....I'm normally never in that...lol The only I get in there is when he wants me to run the Debug mode...









Thanks!!









+1 Rep


----------



## Mumak

Thanks for responding @LostParticle


----------



## SomebodyOnce

[Suggestion/Request] System time in OSD (RTSS)

Can we please have it? Such simple statistic, people who need it will use it, those who dont want can turn it off. Its useful when you run full screen app with OSD and system clock is not visible.


----------



## LostParticle

Hello Martin,

Here is what I'm currently monitoring with HWiNFO64:



I'd like to ask you something about "Logging". I pressed the "Logging" button and logged my system, for a few minutes. Then I imported the X.csv file that was created into Excel 2016, 64 bit.

1) The import was executed via Excel / Data / (Import) From Text file. Is this correct?

2) In the wizzard, 1st step I set it like this:


Spoiler: Warning: Spoiler!







3) Next wizzard screen, I've set it like this:


Spoiler: Warning: Spoiler!







4) Third wizzard screen, I did not change anything, and after pressing Finish, the file was imported.

Now, I don't know IF I have performed this procedure correctly but when I look at the spreadsheet some values do not make sense:


Spoiler: Warning: Spoiler!







[For example] What does VCore0 = 955 mean?!

Similarly, plenty of other values do not make sense.

Furthermore, when I scroll all the way to the right, after my last monitored value a dense table of values appears!


Spoiler: Warning: Spoiler!







What is going on, then? Am I importing the log file wrongly? Why am I getting all this?
It is the first time I am doing this procedure so please bare with me.

Thank you!


----------



## Hequaqua

Quote:


> Originally Posted by *LostParticle*
> 
> Hello Martin,
> 
> Here is what I'm currently monitoring with HWiNFO64:
> 
> 
> 
> I'd like to ask you something about "Logging". I pressed the "Logging" button and logged my system, for a few minutes. Then I imported the X.csv file that was created into Excel 2016, 64 bit.
> 
> 1) The import was executed via Excel / Data / (Import) From Text file. Is this correct?
> 
> 2) In the wizzard, 1st step I set it like this:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 3) Next wizzard screen, I've set it like this:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> 4) Third wizzard screen, I did not change anything, and after pressing Finish, the file was imported.
> 
> Now, I don't know IF I have performed this procedure correctly but when I look at the spreadsheet some values do not make sense:
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> [For example] What does VCore0 = 955 mean?!
> 
> Similarly, plenty of other values do not make sense.
> 
> Furthermore, when I scroll all the way to the right, after my last monitored value a dense table of values appears!
> 
> 
> Spoiler: Warning: Spoiler!
> 
> 
> 
> 
> 
> 
> 
> What is going on, then? Am I importing the log file wrongly? Why am I getting all this?
> It is the first time I am doing this procedure so please bare with me.
> 
> Thank you!


I just imported to Google Sheets....looks fine to me...









https://docs.google.com/spreadsheets/d/1Nd7fHOCch1blyAdWIPKWJhiMTL1foOuqT6nQVY3BEqA/edit?usp=sharing


----------



## LostParticle

Quote:


> Originally Posted by *Hequaqua*
> 
> I just imported to Google Sheets....looks fine to me...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> https://docs.google.com/spreadsheets/d/1Nd7fHOCch1blyAdWIPKWJhiMTL1foOuqT6nQVY3BEqA/edit?usp=sharing


Yeap, yours looks fine to me, as well.
Mine does not look fine to me, that is why I'm asking @Mumak









PS: the only thing I can suspect is my customization = hiding some values, changing the order of those left and turning some in bold and of different colors. So, I will back-up my settings and restore HWiNFO64 at its default, and re-check.

*EDIT:* Nope, I have tried it, it is exactly the same as I describe in my previous post.


----------



## Hequaqua

Quote:


> Originally Posted by *LostParticle*
> 
> Yeap, yours looks fine to me, as well.
> Mine does not look fine to me, that is why I'm asking Martin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> PS: the only thing I can suspect is my customization = hiding some values, changing the order of those left and turning some in bold and of different colors. So, I will back-up my settings and restore HWiNFO64 at its default, and re-check.
> 
> *EDIT:* Nope, I have tried it, it is exactly the same as I describe in my previous post.


My layout is customized with hidden values and colors:


----------



## LostParticle

Okay, let's see what @Mumak will have to suggest me.
Perhaps I'm doing something wrong during the Importing procedure...


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, let's see what @Mumak will have to suggest me.
> Perhaps I'm doing something wrong during the Importing procedure...


I think this is because you're using comma as the decimal separator and Excel expects comma as the delimiter between values. Try to change this either in HWiNFO or in Excel if possible.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> I think this is because you're using comma as the decimal separator and Excel expects comma as the delimiter between values. Try to change this either in HWiNFO or in Excel if possible.


Hi Martin, thanks for your reply!

Well...the only value I can actually change is the "Logging Separotor (CSV)" in HWiNFO64, which currently defaults at comma. Should I change that, you suggest? IF so, in what should I set it?

I cannot possibly change anything else, nor in HWiNFO neither in Excel, because I am on the Metric System of Measurement, in which comma is the decimal separator and period is the thousands separator.


----------



## Mumak

Quote:


> Originally Posted by *LostParticle*
> 
> Hi Martin, thanks for your reply!
> 
> Well...the only value I can actually change is the "Logging Separotor (CSV)" in HWiNFO64, which currently defaults at comma. Should I change that, you suggest? IF so, in what should I set it?
> 
> I cannot possibly change anything else, nor in HWiNFO neither in Excel, because I am on the Metric System of Measurement, in which comma is the decimal separator and period is the thousands separator.


Well, in that case you can try to change the "Logging Separotor (CSV)" in HWiNFO so that Excel will recognize it as the delimiter. But as I said, if you use comma as decimal separator and also CSV delimiter then it causes a mixup of values for Excel which you can already see in the import settings.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> Well, in that case you can try to change the "Logging Separotor (CSV)" in HWiNFO so that Excel will recognize it as the delimiter. But as I said, if you use comma as decimal separator and also CSV delimiter then it causes a mixup of values for Excel which you can already see in the import settings.


Okay, I understand that and you're most probably right -- I haven't tested it, yet. But what should I use for CSV then? Space (to press the space bar)? Tab (to press Tab)? Something else?


----------



## LostParticle

Quote:


> Originally Posted by *LostParticle*
> 
> Okay, I understand that and you're most probably right -- I haven't tested it, yet. But what should I use for CSV then? Space (to press the space bar)? Tab (to press Tab)? Something else?


Okay, I have resolved this issue by setting semicolon ( ; ) as my CSV separator! Now it seems to work, no time to check this further right now, but it seems to work!









Thank you!











Spoiler: Warning: Spoiler!







PS: Actually, the CSV file does not require any importing procedure! Simply double-clicking it opens it in Excel, ready for further processing!


----------



## Mumak

You're welcome.


----------



## gupsterg

Using v5.70-3300, not forcing GPU i2c, got VR temps







.



Wasn't there past few days. Fresh OS W10C FCU ISO, only used stated version of HWiNFO and AMD Chipset driver v17.40 and Video driver v17.12.1. RX VEGA 64 VBIOS with reg mods only for clocks, voltages and powerlimit. These were sensors I had on other HWiNFO with v17.11.4 intially and only when I reset GPU i2c cache did I see the other lot of GPU VR sensors.

Cheers







.


----------



## Mumak

Quote:


> Originally Posted by *gupsterg*
> 
> Using v5.70-3300, not forcing GPU i2c, got VR temps
> 
> 
> 
> 
> 
> 
> 
> .
> 
> 
> 
> Wasn't there past few days. Fresh OS W10C FCU ISO, only used stated version of HWiNFO and AMD Chipset driver v17.40 and Video driver v17.12.1. RX VEGA 64 VBIOS with reg mods only for clocks, voltages and powerlimit. These were sensors I had on other HWiNFO with v17.11.4 intially and only when I reset GPU i2c cache did I see the other lot of GPU VR sensors.
> 
> Cheers
> 
> 
> 
> 
> 
> 
> 
> .


GPU VR VDDC and GPU VR MVDD temperatures are read via a different way, not directly via I2C. So if you see them now it seems AMD has finally added reporting of these values in their drivers (or new SMC firmware).


----------



## gupsterg

I suspected this was another way, thanks for the confirmation







.

Labels are correct? I believe so. If I don't load GPU, when water temp in loop rises from CPU load, GPU VR rises same as GPU core temp.


----------



## LostParticle

@Mumak

Hi Martin,

Recently, due to my new GPU, I've started to monitor (as well) the following values, placed inside the red rectangle:



I have removed my SSDs' monitoring to be able to place those, there.

Now... The reason of this post is, do these values really have any importance? And most importantly, is there anything I can do about it (about what they are showing)?

*I quote*
Quote:


> vRel = Reliability. Indicating performance is limited by voltage reliability.
> VOp = Operating. Indicating performance is limited by max operating voltage(Hardware Limit).
> Pwr = Power. Indicating performance is limited by total power limit.
> Thrm = Thermal. Indicating performance is limited by temperature limit.
> Util = Utilization. Indicating performance is limited by GPU utilization.


Okay... So, when for example, I see "Reliability Voltage" turning to "Yes", in HWiNFO64 during a SuperPosition benchmark, what does that mean, and most importantly what can I do about it?
Similarly for all the rest of those values!

Do you have any answers, Martin?
Or should I just hide them and restore my SSDs' monitoring there?

Thank you.


----------



## MNMadman

vRel -- GPU voltage isn't reliable (maybe can't hold voltage while loaded?). Hardware problem? Replace card? Or maybe just lower the voltage?
vOp -- GPU hitting the hardware limit for maximum voltage. Mod card for higher voltage or just accept the limit like most of us do.
Pwr -- GPU hitting the maximum power in watts. Use modded vBIOS with higher power limit or just accept the limit like most of us do.
Thrm -- GPU hitting the thermal limit and throttling. Use better cooling (higher fan speed, liquid cooling, etc.).
Util -- GPU utilization is too high. Lower the in-game/benchmark settings?


----------



## LostParticle

Quote:


> Originally Posted by *MNMadman*
> 
> vRel -- GPU voltage isn't reliable (maybe can't hold voltage while loaded?). Hardware problem? Replace card? Or maybe just lower the voltage?
> vOp -- GPU hitting the hardware limit for maximum voltage. Mod card for higher voltage or just accept the limit like most of us do.
> Pwr -- GPU hitting the maximum power in watts. Use modded vBIOS with higher power limit or just accept the limit like most of us do.
> Thrm -- GPU hitting the thermal limit and throttling. Use better cooling (higher fan speed, liquid cooling, etc.).
> Util -- GPU utilization is too high. Lower the in-game/benchmark settings?


@Mumak, what is your opinion about all this? Is he right?

When it comes to Power, Thermal and Max Operating voltage limits I agree and actually, I knew what they mean already.
When it comes to Utilization you've explained this to me, already, in a PM:
Quote:


> The Utilization reason means just that there's not enough load on the GPU to run at the highest state.


When it comes to Reliability voltage, I do not know. Even at stock when benchmarking my GPU hits this limit = value turning to "Yes". Not constantly but it keeps that value for quite some time, during the bench.


----------



## gupsterg

Vrel is what nVidia deems as voltage limit that GPU can sustain for reliable operation for longevity. The card is not having reliability issues on voltage supply.

Vop AFAIK is to allow AIBs to set a Vmax which is above what Vrel is set to, to allow end user voltage increase above Vrel limit (only certain nVidia cards have had this enabled from what I have read).

Util AFAIK shows when driver is limiting utilization to keep card in lower state. For example here my rig had CPU only loaded, so GPU perf.cap is keeping it in limited utilization state (save power, etc).



Now if you see below screenie you can see it does not occur at high MHz/loads.



Dunno if it can occur at highers states, so GPU does not exceed other limits due to utilization, not seen it in tests I did when had a GTX 1080.


----------



## LostParticle

Quote:


> Originally Posted by *gupsterg*
> 
> Vrel is what nVidia deems as voltage limit that GPU can sustain for reliable operation for longevity. The card is not having reliability issues on voltage supply.
> 
> ...


Thanks for your reply, I am staying at Reliability Voltage because this is the only one I'm having difficulty to perceive. All the rest of them I understand, more or less, what they mean.

So when, for example, I run SuperPosition at stock GPU settings, why is Reliability Voltage turning to "Yes", in HWiNFO64? This tells me that Vrel is a "performance limit" for me. It does not stay there all the time during the bench but it stays at "Yes", quite some time. The card runs at stock. What is the meaning, exactly, of this and what can I do about it?

The reason I am asking all these questions is because I am trying to understand *if there is any usefulness* in monitoring these GPU Performance Limit values, in HWiNFO64, on a permanent basis. My Sensor table has limited space, I do not like scroll-bars! I had my three SSDs' Read, Write and Total values there, and I removed them to place these GPU Limit factors. As I realize, though, they are not of any realistic usefulness or, perhaps, they are of a very limited...


----------



## Mumak

Sorry for the late response, it's close to Christmas here, a lot of other things around... plus some issues in family and daughter is sick, she's hitting the thermal limit of 41 C, lying next to me here.. Applying some cooling measures, I have only one hand to write









So power, thermal limits should be clarified - the GPU is hitting those limits and thus needs to reduce performance. Utilization has already been explained too. Voltages were most probably best explained by gup, I don't have a better clarification on this. Perhaps some NV forums contain more details.

Merry Christmas to all (and sorry for being so brief) !


----------



## gupsterg

Merry Christmas Martin







, hope your daughter gets well soon







.

@LostParticle

Some of these "caps" have been around for a while. You may find reading launch reviews of when say nVidia boost 1.0, 2.0 and 3.0 were introduced to a GPU to gain further insight.


----------



## LostParticle

Quote:


> Originally Posted by *Mumak*
> 
> ... plus some issues in family and daughter is sick, she's hitting the thermal limit of 41 C, lying next to me here..


What?! OMG, Martin, I am SO sorry!! Please, call your GP ASAP, and also consider (seriously) taking her to the hospital!! She will most probably need injections of some kind! I am really sorry!
















When it comes to these values, I will most probably (like 99,99%) remove them, hide them, and bring my SSDs' values back there. Since my GPU at stock already presents some Performance Limits, like all similar GPUs do, and I cannot realistically do anything about it, there is no reason to occupy space on my Sensor Table.

I'll read further about what Reliability Voltage really means, I'll also read again the posts here, I might ask about it further again, but honestly I think I'll just forget it.

@gupsterg, thank you for the very nice GIF, I think I get it now!









Thank you and Merry Christmas to you all!


----------



## Mumak

Thanks, we already visited the doctor, she got medications and is also taking antibiotics. It's tonsillitis, needs just a few days to get better. Until then we need to cope with high fever, etc..


----------



## agentx007

Hello.
First : I hope daughter is better.

Second :
Is it possible to add under "Features" support for CMPXCHG16b ("CompareExchange 128"), LAHF/SAHF (in 64-bit) and PrefetchW ?
Those three are the necessary one to have Windows 8.1 x64/Windows 10 support.
Example screenshot showing those instructions :


http://imgur.com/YHiDhqs

 (program used in cmd is CoreInfo : LINK)

Also : "DEP" feature basicly means XD-bit/NX-bit support - right ?

Thank you.
Happy New Year


----------



## Mumak

All those features are listed in the main HWiNFO window (with tree on left side). The summary window has limited space available, so I prefer to show only most important information there.
Yes, DEP means XD/NX.


----------



## Streetdragon

my hwinfo gatget resetet itself one more time now. all settings are gone.

Maybe there is a problem with multi screen setups. normaly i just let the secound screen on standby and disable it in windows (windows+P)
now i unpluged the screen from power. startet my rig and the settings are gone.. now i need hours to reconfig them.. my backup from the gatget settings are to old too...


----------



## Mumak

Quote:


> Originally Posted by *Streetdragon*
> 
> my hwinfo gatget resetet itself one more time now. all settings are gone.
> 
> Maybe there is a problem with multi screen setups. normaly i just let the secound screen on standby and disable it in windows (windows+P)
> now i unpluged the screen from power. startet my rig and the settings are gone.. now i need hours to reconfig them.. my backup from the gatget settings are to old too...


Which gadget are you using, HWiNFOMonitor ?


----------



## Streetdragon

Quote:


> Originally Posted by *Mumak*
> 
> Which gadget are you using, HWiNFOMonitor ?


yep


----------



## Mumak

Quote:


> Originally Posted by *Streetdragon*
> 
> yep


HWiNFOMonitor is a separate application developed by another guy, please post related questions here: https://www.hwinfo.com/forum/Forum-HWiNFOMonitor


----------



## ae00711

copy'n'paste from a thread I made over at OCAU:
Quote:


> I was doing a bit of video transcoding using HandBrake (DVD to H264) and noticed my CPU usage sky high (normal for the task). Wanted to check CPU temps.. first I tried core temp..mm..some cores were sitting dam close to 100C.. tried realtemp, same reading... starting looking for alternatice apps to read temp.. installed HWiNFO64, ran it and hit the 'sensor' button at top............. instant restart. Nothing has ever brought my rig to a halt like this, nothing.
> 
> Not only that, at POST, get this message: uncorrectable ECC error detected at CPU01/DIMM3B, press F1 to resume (which I did)
> 
> Get back into windows. That was fun! Let's do it again! Instant restart, this time ECC error at CPU01/DIMM2A
> 
> windows had to 'repair' itself (boot SSD), now finally back into windows.
> 
> soooo.. questions:
> 
> 1) anyone else with this issue?
> 2) recommended temp app?
> 3) how do I test that my ECC RAM is functioning / 100% ?
> 
> I'm also thinking it's time to re-do the thermal paste.
> 
> specs, if needed:
> 
> 2x Intel Xeon X5687 (s1366)
> SuperMicro X8DTi mobo
> 12x 4GB Samsung DDR3-1333 ECC+REG
> Samsung 850 Evo 500GB bott+apps
> 
> let me know if other hardware is needed to be known


question more specific to this thread: why is hwinfo64 so evil with my system?


----------



## Mumak

Quote:


> Originally Posted by *ae00711*
> 
> copy'n'paste from a thread I made over at OCAU:
> question more specific to this thread: why is hwinfo64 so evil with my system?


This is certainly not intentional. HWiNFO might be accessing some devices, which go into panic mode when they are accessed, even for read.
Some Supermicro board have such issues. It would be great if you could run HWiNFO in Debug Mode and after the reboot send me the HWiNFO64.DBG file created. I can then analyze it and try to fix the problem.


----------



## ae00711

HWiNFO64.txt 726k .txt file


I had to rename the file extension for it to allow upload!

of course this isn't intentional!








I'd be interested to see what you can make of it!


----------



## l Nuke l

Is there anyway to monitor CPU power (not CPU PACKAGE) and CPU current in hwinfo64? With CPU SVID Support enabled hwinfo64 is able to read CPU power but with SVID disabled the only way I have found to monitor cpu power wattage and current is with aida64. See pic below.


----------



## Mumak

Quote:


> Originally Posted by *l Nuke l*
> 
> Is there anyway to monitor CPU power (not CPU PACKAGE) and CPU current in hwinfo64? With CPU SVID Support enabled hwinfo64 is able to read CPU power but with SVID disabled the only way I have found to monitor cpu power wattage and current is with aida64. See pic below.


With SVID disabled, the CPU cannot monitor its own power consumption, because the interface responsible for this is disabled.
I see that you're not overclocking the BCLK, so there's no sense in disabling SVID. That's recommended only for BCLK > 150 MHz.
That additional CPU Current/Power value is not very accurate. Anyway, I will add this in the next (Beta) build.


----------



## l Nuke l

Quote:


> Originally Posted by *Mumak*
> 
> With SVID disabled, the CPU cannot monitor its own power consumption, because the interface responsible for this is disabled.
> I see that you're not overclocking the BCLK, so there's no sense in disabling SVID. That's recommended only for BCLK > 150 MHz.
> That additional CPU Current/Power value is not very accurate. Anyway, I will add this in the next (Beta) build.


but aida64 can still monitor it even tho svid is disabled. Top right of my screenshot shows this. Would love for hwinfo64 to show it too as i prefer it to aida64.


----------



## Mumak

Quote:


> Originally Posted by *ae00711*
> 
> HWiNFO64.txt 726k .txt file
> 
> 
> I had to rename the file extension for it to allow upload!
> 
> of course this isn't intentional!
> 
> 
> 
> 
> 
> 
> 
> 
> I'd be interested to see what you can make of it!


Thanks. We will need to do a small exercise








Before launching the scan, please click Settings and select the "SMBus / I2C" tab. In the "SMBus Device Exclusion" list please tick the box belonging to 2F (so row 2x / column xE).
Then please try to run HWiNFO and let me know if it still crashes.
If that didn't help, please do the same with box belonging to 2E.
Waiting for your results...


----------



## Mumak

Quote:


> Originally Posted by *l Nuke l*
> 
> but aida64 can still monitor it even tho svid is disabled. Top right of my screenshot shows this. Would love for hwinfo64 to show it too as i prefer it to aida64.


Yes, they use a different method when SVID is disabled (I assume it's showing only integer numbers for the current). I will add this too.


----------



## l Nuke l

Quote:


> Originally Posted by *Mumak*
> 
> Yes, they use a different method when SVID is disabled (I assume it's showing only integer numbers for the current). I will add this too.


Thanks man! Yes currrent is only shown in integer numbers.


----------



## ae00711

Quote:


> Originally Posted by *Mumak*
> 
> Thanks. We will need to do a small exercise
> 
> 
> 
> 
> 
> 
> 
> 
> Before launching the scan, please click Settings and select the "SMBus / I2C" tab. In the "SMBus Device Exclusion" list please tick the box belonging to 2F (so row 2x / column xE).


this did the trick!







worked without crashing!


----------



## Mumak

Quote:


> Originally Posted by *ae00711*
> 
> this did the trick!
> 
> 
> 
> 
> 
> 
> 
> worked without crashing!


Thanks for the feedback. So it was 2F that needed disabling, right ? I will do this automatically in HWiNFO for your board.


----------



## ae00711

Quote:


> Originally Posted by *Mumak*
> 
> Thanks for the feedback. So it was 2F that needed disabling, right ? I will do this automatically in HWiNFO for your board.


correct!

i have other SuperMicro 'X8' (dual s1366) mobos, would you like me to test on them as well? cause if they all have the same issue, you may as well make it default for that maker/series

also, I did not disable debug mode, not sure if that is noteworthy


----------



## Mumak

Quote:


> Originally Posted by *ae00711*
> 
> correct!
> 
> i have other SuperMicro 'X8' (dual s1366) mobos, would you like me to test on them as well? cause if they all have the same issue, you may as well make it default for that maker/series
> 
> also, I did not disable debug mode, not sure if that is noteworthy


Yes, it would be great to test other Supermicro boards too. They might fail at different address(es).
It's recommended to disable Debug Mode for normal usage. It's useful only to get the dumps for me and HWiNFO can run significantly slower when it's enabled.


----------



## ae00711

Quote:


> Originally Posted by *Mumak*
> 
> Yes, it would be great to test other Supermicro boards too. They might fail at different address(es).
> It's recommended to disable Debug Mode for normal usage. It's useful only to get the dumps for me and HWiNFO can run significantly slower when it's enabled.


ok, I'll

a) test again on my main rig with debug disabled
b) test on my other boards


----------



## ae00711

ok, ran tests, here are results etc:

rig1: supermicro, single socket 1366, X8STE - X58+ICH10R: no problems - kinda expected, it's desktop chipset, not server like my dual sockets

rig2: supermicro, dual sucket s1366, X8DTE: first run was via RDP - hard lock. second run was at terminal, ran no problems; third ran was at terminal - hard lock. I then ran it two more times but with 2F disabled, both runs went well

rig3: supermicro, dual socket s1366, X8DTH: run three times: once via RDP, twice at terminal, all runs went well, I did not have to disable 2F, there were no hard locks.

I also tested on my rig again, with debug not enabled and it went well.

Did you want me to test on a supermicro dual socket s771 mobo?


----------



## Mumak

ae00711 said:


> ok, ran tests, here are results etc:
> 
> rig1: supermicro, single socket 1366, X8STE - X58+ICH10R: no problems - kinda expected, it's desktop chipset, not server like my dual sockets
> 
> rig2: supermicro, dual sucket s1366, X8DTE: first run was via RDP - hard lock. second run was at terminal, ran no problems; third ran was at terminal - hard lock. I then ran it two more times but with 2F disabled, both runs went well
> 
> rig3: supermicro, dual socket s1366, X8DTH: run three times: once via RDP, twice at terminal, all runs went well, I did not have to disable 2F, there were no hard locks.
> 
> I also tested on my rig again, with debug not enabled and it went well.
> 
> Did you want me to test on a supermicro dual socket s771 mobo?


Thanks for the feedback. So I'll disable 0x2F on X8DTE by default too.
Any other tests are welcome


----------



## ae00711

Mumak said:


> Thanks for the feedback. So I'll disable 0x2F on X8DTE by default too.
> Any other tests are welcome


ok, tested on supermicro X7DCL-i dual s771.. twice by RDP, once at terminal, all went well, no hard locks, no need to do anything imo!


----------



## Mumak

ae00711 said:


> ok, tested on supermicro X7DCL-i dual s771.. twice by RDP, once at terminal, all went well, no hard locks, no need to do anything imo!


Thanks for the test. The new build 3330 should automatically disable access to those problematic devices on models you had problems with.


----------



## l Nuke l

Thanks for adding cpu power and current monitoring when svid is disabled into the new update!!! You the man! +rep!


----------



## Mumak

l Nuke l said:


> Thanks for adding cpu power and current monitoring when svid is disabled into the new update!!! You the man! +rep!


You're welcome


----------



## Hequaqua

Hey Mumak, a couple of quick questions.

Why does HWiNFO64 show two temps readings for the Samsung 960 Evo(NVMe)? Could one be the chips and the other the controller?

I talked to someone at Samsung, they had no clue, and suggested I speak to the author of the software I'm using. They seemed a bit clueless...lmao

I've tried other software, but they only show the one temp reading. 

Here are a couple of screen shots:



Spoiler

















Spoiler

















Spoiler















I've also attached the Debug file.


----------



## Mumak

Hequaqua said:


> Hey Mumak, a couple of quick questions.
> 
> Why does HWiNFO64 show two temps readings for the Samsung 960 Evo(NVMe)? Could one be the chips and the other the controller?
> 
> I talked to someone at Samsung, they had no clue, and suggested I speak to the author of the software I'm using. They seemed a bit clueless...lmao
> 
> I've tried other software, but they only show the one temp reading.
> 
> Here are a couple of screen shots:
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> I've also attached the Debug file.


Well, all those temperatures are part of the NVMe standard, so they should know what it is. Perhaps that person didn't have the right knowledge. HWiNFO just shows what the firmware reports.
You can read more about this mystery here: https://www.hwinfo.com/forum/Thread-Drive-Temperature-2-on-Samsung-960-Evo


----------



## Hequaqua

Mumak said:


> Well, all those temperatures are part of the NVMe standard, so they should know what it is. Perhaps that person didn't have the right knowledge. HWiNFO just shows what the firmware reports.
> You can read more about this mystery here: https://www.hwinfo.com/forum/Thread-Drive-Temperature-2-on-Samsung-960-Evo


Thank you sir!

I talked to several at Samsung...none of them were certain of much really.


----------



## Mumak

Point them to the NVMe Specification - SMART / Health Information Log - [203:202] Temperature Sensor 2


----------



## Scotty99

Hmmm i dont have the cpu power and current monitoring on the latest version (5.7.2 i think). Under asus EC sensor its just cpu optional readings and a couple other that i forget, i have the strix-e board. The current readings under CPU package are all goofy too, says 3w at idle and only goes up to like 11w no matter what program is running.


----------



## Mumak

Scotty99 said:


> Hmmm i dont have the cpu power and current monitoring on the latest version (5.7.2 i think). Under asus EC sensor its just cpu optional readings and a couple other that i forget, i have the strix-e board. The current readings under CPU package are all goofy too, says 3w at idle and only goes up to like 11w no matter what program is running.


Please attach the HWiNFO Debug File and I will check why you don't see the power readouts under ASUS EC.
The CPU Package power is not valid because you most probably have SVID support disabled in BIOS. When this is disabled CPU internal current/power measurement cannot work. There's no reason to disable SVID if you're not running with BCLK>150 MHz


----------



## Scotty99

Mumak said:


> Please attach the HWiNFO Debug File and I will check why you don't see the power readouts under ASUS EC.
> The CPU Package power is not valid because you most probably have SVID support disabled in BIOS. When this is disabled CPU internal current/power measurement cannot work. There's no reason to disable SVID if you're not running with BCLK>150 MHz


Ya figured the current readings was because i was using manual voltage.

Not sure how to do debug file, this what you need?


----------



## Mumak

Thanks. I will add reporting of CPU Current/Power for your mainboard via the ASUS EC sensor in the next build.


----------



## LostParticle

@Mumak

Hello Martin, two questions please:

1) Why is HWiNFO64, v5.72-3333, showing BIOS Date: 19/01/2017, on the System Summary, when on my motherboard's web page the Date is 13/12/2017? Is your tool showing the correct date?










2) On the same [Summary] window I see μCU : 23
Indeed, I have injected Intel microcode 23 on this beta BIOS I am currently running. Is your tool showing the BIOS microcode, though, or is it showing the [Intel] microcode Windows 10 loads, after each boot? 

( what I know is that it shows the BIOS microcode, just want to confirm it )


Thank you.


----------



## LostParticle

@Mumak, have you seen my post above? The only reason I'm asking and mentioning you again is because I had problems posting it, and I'm not sure what's going on...

Thanks!


----------



## Mumak

delete


----------



## Mumak

LostParticle said:


> @Mumak
> 
> Hello Martin, two questions please:
> 
> 1) Why is HWiNFO64, v5.72-3333, showing BIOS Date: 19/01/2017, on the System Summary, when on my motherboard's web page the Date is 13/12/2017? Is your tool showing the correct date?
> 
> View attachment 79449
> 
> 
> 
> 2) On the same [Summary] window I see μCU : 23
> Indeed, I have injected Intel microcode 23 on this beta BIOS I am currently running. Is your tool showing the BIOS microcode, though, or is it showing the [Intel] microcode Windows 10 loads, after each boot?
> 
> ( what I know is that it shows the BIOS microcode, just want to confirm it )
> 
> 
> Thank you.


HWiNFO shows the date which is reported by the BIOS. It's possible that it doesn't contain a valid value, check under the Motherboard - SMBIOS DMI section for more details.
As for Microcode update, HWiNFO shows the revision which is currently loaded into the CPU and active.


----------



## Mumak

delete


----------



## Mumak

Yeah, I have problems replying and posting as well.. sorry for those double-posts


----------



## LostParticle

Mumak said:


> HWiNFO shows the date which is reported by the BIOS. It's possible that it doesn't contain a valid value, check under the Motherboard - SMBIOS DMI section for more details.
> As for Microcode update, HWiNFO shows the revision which is currently loaded into the CPU and active.



Thanks Martin. I'm looking at SMBIOS DMI section right now, sorry no screenshot this time, and it says the same date: 19/01/2017.
Is it possible, you think, that ASRock forgot to change the date on this beta BIOS? I mean, that the erroneous date is coming from them?

I have read, in another forum, another user with a different setup reporting erroneous BIOS date, in HWiNFO64. *You can read this post*.


Thank you.


----------



## Mumak

LostParticle said:


> Thanks Martin. I'm looking at SMBIOS DMI section right now, sorry no screenshot this time, and it says the same date: 19/01/2017.
> Is it possible, you think, that ASRock forgot to change the date on this beta BIOS? I mean, that the erroneous date is coming from them?
> Thank you.


Definitely, they are responsible for filling the correct date value.


----------



## LostParticle

Mumak said:


> Definitely, they are responsible for filling the correct date value.



Okay, thanks for confirming it, I trust you 

I'm just pulling your attention on the link I posted in my previous post, regarding another person, with a completely different setup, also showing HWiNFO64 not reporting the correct BIOS date. Personally, I have no problem with this. It might be, though, that you could have a look at it.


----------



## Mumak

Well, actually there's also another method to detect the BIOS date, but that one is even more outdated and AFAIK UEFI BIOSes don't contain a valid date there.
So the only reliable method is SMBIOS DMI and in all cases the BIOS/system vendor is responsible for filling a valid date there.
You can try any other tool to check the BIOS data and see what it reports.

EDIT: I have downloaded the 1.90A version of your BIOS image and check it. There are several date entries in the BIOS, but they all are: 01/19/2017


----------



## Scotty99

Nice the new version monitors power draw on the strix-f. I am wondering tho, what is with the warning about monitoring the asus sensor? Is there really a chance it heats things up?


----------



## Mumak

Scotty99 said:


> Nice the new version monitors power draw on the strix-f. I am wondering tho, what is with the warning about monitoring the asus sensor? Is there really a chance it heats things up?


Heating for sure not  Sometimes can cause some delays or higher system load, but usually there are no problems with that. Lots of folks use it 24/7 without issues.


----------



## Scotty99

Mumak said:


> Heating for sure not  Sometimes can cause some delays or higher system load, but usually there are no problems with that. Lots of folks use it 24/7 without issues.


Nice, i think ill just leave it on then 

As an aside im amazed how efficient the 8700k is at idle. Even with a manual voltage overclock its 8-12w of draw with a game open in the background and a twitch stream going. I think my ryzen 1700 was at least double to maybe triple that.


----------



## Scotty99

Anyone else having issues with the new version? It sits on detecting CPU 0 until i force close it, worked fine for two days. Reinstall did not fix.


----------



## MNMadman

Scotty99 said:


> Anyone else having issues with the new version? It sits on detecting CPU 0 until i force close it, worked fine for two days. Reinstall did not fix.


I'm using the newest non-Beta version with no issues (well ... no startup issues anyway) on *Heatripper Threadkiller*.

My only issues are having inaccurate VRM temps while the CPU is under stress test load (RealBench v2.56, Y-Cruncher, etc.). I often get -95ºC minimums and 380ºC maximums. Normal programs and games cause no issues.


----------



## LostParticle

I'm using v5.74-3363, no problems at all.


----------



## Mumak

Scotty99 said:


> Anyone else having issues with the new version? It sits on detecting CPU 0 until i force close it, worked fine for two days. Reinstall did not fix.


Please attach the HWiNFO Debug File after killing the hung process. I will analyze what's going on there...


----------



## Scotty99

A restart seems to have fixed it, has not had a hangup yet.


----------



## MNMadman

@Mumak

I have a Threadripper CPU. In HWiNFO64 I see that it has:

CPU [#0] Node #0: AMD Ryzen Threadripper 1950X: Enhanced
CPU [#0] Node #1: AMD Ryzen Threadripper 1950X: Enhanced

And a set of Tctl and Tdie temps for each. At idle they are usually the same but under stress test load they can be up 6ºC off (that's the biggest difference I've seen since I started paying attention to it), with Node #0 usually being hotter when that happens.

Is this reading the temps from each die of the Threadripper?


----------



## ssateneth

yes


----------



## SomebodyOnce

*[BUG] The symbol "/" "slash" does not display in OSD*

The symbol "/" "slash" 
Solidus Unicode number: U+002F
Does not display in OSD when entered in Custom Label for Custom Unit fields.
When i enter it in Custom Label or Unit field it can be typed in but it wont shop up on OSD.


----------



## LostParticle

Hey guys, Martin ( @Mumak ), I've decided to give HWiNFO Monitor [gadget] a try but it does not open on my system, Win 10 Pro. Does this require HWiNFO64 installer? I am using the portable version of HWiNFO64. Does the gadget work with the portable?

I've enabled reporting to Gadget and a couple of values but I do not see anything. Nothing opens, only the Sensor windows, as usual.

?


----------



## Mumak

SomebodyOnce said:


> The symbol "/" "slash"
> Solidus Unicode number: U+002F
> Does not display in OSD when entered in Custom Label for Custom Unit fields.
> When i enter it in Custom Label or Unit field it can be typed in but it wont shop up on OSD.


Sorry, but I cannot reproduce this problem, it works for me without issues.
Try to enter the character and not UNICODE, but standard ANSI.


----------



## LostParticle

Hey, @Mumak, you missed my post!


----------



## Mumak

The HWiNFOMonitor is a 3-rd party gadget, check here for support: https://www.hwinfo.com/forum/Forum-HWiNFOMonitor
Also note, that this requires Sidebar Gadget support in Windows, which has been removed since Windows 8. So you'll also need some 3-rd party gadget support, i.e. http://8gadgetpack.net


----------



## ThrashZone

HI,
I was wondering why hwinfo didn't list a vrm temp on x99 ?
Only shows pch :/


----------



## LostParticle

Mumak said:


> The HWiNFOMonitor is a 3-rd party gadget, check here for support: https://www.hwinfo.com/forum/Forum-HWiNFOMonitor
> Also note, that this requires Sidebar Gadget support in Windows, which has been removed since Windows 8. So you'll also need some 3-rd party gadget support, i.e. http://8gadgetpack.net


Ah, I see! It requires that 3-rd party gadget support?! No way, no thank you!
What about that other gadget, the HWiNFO Sidebar Gadget?
Does that one require third party crap, as well?
I downloaded that one, too, placed it inside HWiNFO64 folder, enabled report to gadget in Settings, but nothing happens...

?

Note: I am always using the Portable version. I am not using the installer (of HWiNFO64)


----------



## Mumak

ThrashZone said:


> HI,
> I was wondering why hwinfo didn't list a vrm temp on x99 ?
> Only shows pch :/


Is that the SABERTOOTH X99 ? AFAIK this board cannot monitor VRM temperature.


----------



## Mumak

LostParticle said:


> Ah, I see! It requires that 3-rd party gadget support?! No way, no thank you!
> What about that other gadget, the HWiNFO Sidebar Gadget?
> Does that one require third party crap, as well?
> I downloaded that one, too, placed it inside HWiNFO64 folder, enabled report to gadget in Settings, but nothing happens...
> 
> ?
> 
> Note: I am always using the Portable version. I am not using the installer (of HWiNFO64)


Any Gadget will require 3-rd party support to show Sidebar Gadgets on Windows 8 and later.
As an alternative you might try the Rainmeter plugin (which will require Rainmeter). More info about that on the HWiNFO forum as well.


----------



## ThrashZone

Mumak said:


> Is that the SABERTOOTH X99 ? AFAIK this board cannot monitor VRM temperature.


Hi,
Thanks I suppose pch will have to be close enough seems they are similar in temp on x299 :/


----------



## Mumak

ThrashZone said:


> Hi,
> Thanks I suppose pch will have to be close enough seems they are similar in temp on x299 :/


No, such relation must be just coincidental. Especially during high CPU load the VRM temperature might be much higher.


----------



## gupsterg

Just updated to v5.79-3390, seems to be getting none of the mobo monitoring data on ASUS ROG ZE. Reset prefs and order, was all AOK on v5.79-3385 and earlier. User error here perhaps?



Spoiler


----------



## Mumak

Check here about this problem and let me know if that helps: https://www.hwinfo.com/forum/Thread...-1950x-x399-Asus-ZE-Mboard?pid=17686#pid17686


----------



## gammagoat

Mumak, is there any chance that the missing VRM sensor on Hero X wifi is actually being reported as T2?

I can't think of a component that will be as hot as this reading that isn't already reported appropriately, i.e. PCH, mobo temp, ect.

I am seeing that T1 is scaling in heat with cpu load as just about everything else except the level of heat is what I would expect from VRM.

If not, then do you know what T2 is?


----------



## Mumak

gammagoat said:


> Mumak, is there any chance that the missing VRM sensor on Hero X wifi is actually being reported as T2?
> 
> I can't think of a component that will be as hot as this reading that isn't already reported appropriately, i.e. PCH, mobo temp, ect.
> 
> I am seeing that T1 is scaling in heat with cpu load as just about everything else except the level of heat is what I would expect from VRM.
> 
> If not, then do you know what T2 is?


Sorry, I don't know what that sensor is measuring, it might not be giving a valid value at all. Any thoughts @elmor ?


----------



## elmor

gammagoat said:


> Mumak, is there any chance that the missing VRM sensor on Hero X wifi is actually being reported as T2?
> 
> I can't think of a component that will be as hot as this reading that isn't already reported appropriately, i.e. PCH, mobo temp, ect.
> 
> I am seeing that T1 is scaling in heat with cpu load as just about everything else except the level of heat is what I would expect from VRM.
> 
> If not, then do you know what T2 is?


Shouldn't be VRM temp. Can you screenshot and show where you're reading "T2"? And what kind of temps are you see idle/load?


----------



## gammagoat

elmor said:


> Shouldn't be VRM temp. Can you screenshot and show where you're reading "T2"? And what kind of temps are you see idle/load?


Here is what I have. The change in temps on this sensor are rapid and much higher than any other, excepting cores. Load OCCT small fft.


----------



## Mumak

It could be the CPU socket (external) temperature. VRM temperature changes and usually not so rapid.


----------



## muffins

hi mumak! i noticed the gigabyte x470 gaming 7 doesn't have correct listings for temps / voltages so here is a screenshot i took with siv and hwinfo running at the same time. i also don't think hwinfo atm is able to even report the motherboard soc voltage as i can't find any comparable voltage to it.. outside of ryzen's soc voltage reading of course.


----------



## Mumak

muffins said:


> hi mumak! i noticed the gigabyte x470 gaming 7 doesn't have correct listings for temps / voltages so here is a screenshot i took with siv and hwinfo running at the same time. i also don't think hwinfo atm is able to even report the motherboard soc voltage as i can't find any comparable voltage to it.. outside of ryzen's soc voltage reading of course.


Thanks for the data, I will adjust sensor values in the next build. Can you please also attach the HWiNFO Debug File for further details, I will check if I can see something related to the SoC voltage there.


----------



## muffins

Mumak said:


> Thanks for the data, I will adjust sensor values in the next build. Can you please also attach the HWiNFO Debug File for further details, I will check if I can see something related to the SoC voltage there.


no problem! i attached the debug file in a zip file as "DBG format is not allowed."


----------



## Mumak

Thanks. Please try this build: www.hwinfo.com/beta/hwi64_583_3421.zip
and let me know if all sensor values are OK now.


----------



## muffins

Mumak said:


> Thanks. Please try this build: www.hwinfo.com/beta/hwi64_583_3421.zip
> and let me know if all sensor values are OK now.


just tested it and all looks good so far. thanks mumak for the awesome work!


----------



## Scotty99

Is anyone else getting wonky readings from the kraken coolers section in hwinfo? When i first boot the PC up it shows 150,000 rpm and 156c liquid temps, i have always gotten weird readings from the CPU fan because of the kraken but never the actual section that shows kraken pump speeds/liquid temp etc.


----------



## Mumak

Scotty99 said:


> Is anyone else getting wonky readings from the kraken coolers section in hwinfo? When i first boot the PC up it shows 150,000 rpm and 156c liquid temps, i have always gotten weird readings from the CPU fan because of the kraken but never the actual section that shows kraken pump speeds/liquid temp etc.


Please attach the HWiNFO Debug File for analysis.


----------



## Scotty99

Mumak said:


> Please attach the HWiNFO Debug File for analysis.


I tried getting to the settings section and i couldnt haha, a reinstall seems to have fixed the wonky readings from the kraken


----------



## gupsterg

gupsterg said:


> Just updated to v5.79-3390, seems to be getting none of the mobo monitoring data on ASUS ROG ZE. Reset prefs and order, was all AOK on v5.79-3385 and earlier. User error here perhaps?
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> View attachment 130257
> 
> 
> View attachment 130265
> 
> 
> 
> 
> 
> 
> Mumak said:
> 
> 
> 
> Check here about this problem and let me know if that helps: https://www.hwinfo.com/forum/Thread...-1950x-x399-Asus-ZE-Mboard?pid=17686#pid17686
Click to expand...

Cheers for swift reply :thumb: . I sorta got busy and never checked in again on forum  . I reverted back to v5.79-3385 at the time and later releases been fine  (so far   ).

Thank you as always for your support and indispensable application :thumb:.


----------



## Mumak

gupsterg said:


> Cheers for swift reply :thumb: . I sorta got busy and never checked in again on forum  . I reverted back to v5.79-3385 at the time and later releases been fine  (so far   ).
> 
> Thank you as always for your support and indispensable application :thumb:.


Thanks gup and welcome back aryzen


----------



## Hequaqua

Hey Martin,

Getting some odd readings on the Asus ROG X470 Strix Gaming F board.

Voltages(3.3v/5v/12v), and something looks a bit off on the wattage numbers for the CPU+SoC. 

Debug Attached Build 5.82-3410

View attachment 191385


----------



## Mumak

Hequaqua said:


> Hey Martin,
> 
> Getting some odd readings on the Asus ROG X470 Strix Gaming F board.
> 
> Voltages(3.3v/5v/12v), and something looks a bit off on the wattage numbers for the CPU+SoC.
> 
> Debug Attached Build 5.82-3410
> 
> View attachment 191385


Try the latest Beta build v5.83, that should support the mainboard properly.


----------



## Hequaqua

Mumak said:


> Try the latest Beta build v5.83, that should support the mainboard properly.


Will do....Thanks!


----------



## Scotty99

Anyone know how to fix the "one value hidden" message at the top? Ive never hid anything to my knowledge.


----------



## Mumak

Sensor settings - Layout - Hidden items


----------



## Hequaqua

@Mumak

I have the Gigabute X470 Aorus Gaming 7. It came with two temp probes that I can use via the headers on the motherboard. I can see EC_Temp2 in HWiNFO64 but not EC_Temp1. I don't have it hidden. It does show in the bios though.


----------



## Mumak

Hequaqua said:


> @Mumak
> 
> I have the Gigabute X470 Aorus Gaming 7. It came with two temp probes that I can use via the headers on the motherboard. I can see EC_Temp2 in HWiNFO64 but not EC_Temp1. I don't have it hidden. It does show in the bios though.



Is it possible that EC_TEMP1 is in fact the "VSOC MOS" value shown in HWiNFO ?
I will need 2 things to check this:
1. A screenshot of HWiNFO and GIGABYTE tool side-by-side, so that I can see both ITE sensors in HWiNFO.
2. As usual - the HWiNFO Debug File with senor data.


----------



## Hequaqua

Mumak said:


> Is it possible that EC_TEMP1 is in fact the "VSOC MOS" value shown in HWiNFO ?
> I will need 2 things to check this:
> 1. A screenshot of HWiNFO and GIGABYTE tool side-by-side, so that I can see both ITE sensors in HWiNFO.
> 2. As usual - the HWiNFO Debug File with senor data.


I think you are correct with the EC_Temp1 being listed as the VSOC MOS in HWiNFO. I can put the probe between my fingers and the temps move up fairly quickly. I then placed the probe on a cold can...and they drop as well.

Gigabyte Tool? I'm not sure what you are referring to.

Thx


----------



## Mumak

Hequaqua said:


> I think you are correct with the EC_Temp1 being listed as the VSOC MOS in HWiNFO. I can put the probe between my fingers and the temps move up fairly quickly. I then placed the probe on a cold can...and they drop as well.
> 
> Gigabyte Tool? I'm not sure what you are referring to.
> 
> Thx


There's a GIGABYTE System Info tool for Windows that should be showing temperatures. I wanted to see such a side-by-side screenshot to match values in HWiNFO.
Is EC_TEMP2 value shown as "Temperature 2" under the IT8792E sensor in HWiNFO perhaps?


----------



## Hequaqua

OK...you are talking about the SIV tool perhaps?

Yes, EC_Temp2 is under the IT8792E, the other one VSOC MOS is under IT8686.

I will install the SIV tool and see what it shows....

Thx 

EDIT: I've installed the SIV tool....it shows up in the AppCenter, but will not launch. I'm not sure why. The RGBFusion app launches just fine.


----------



## Mumak

Yes, I meant the GIGABYTE SIV tool.
But I think the info you provided already is sufficient to properly assign both EC_TEMPs in HWiNFO. Will be fixed in the next Beta build.


----------



## Hequaqua

Mumak said:


> Yes, I meant the GIGABYTE SIV tool.
> But I think the info you provided already is sufficient to properly assign both EC_TEMPs in HWiNFO. Will be fixed in the next Beta build.


Here is the image you wanted....got SIV to work finally. For whatever reason, OCN won't let me attach the debug file.










Yes, I relabeled the reading in HWiNFO...

Thanks


----------



## Mumak

Hequaqua said:


> Here is the image you wanted....got SIV to work finally. For whatever reason, OCN won't let me attach the debug file.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yes, I relabeled the reading in HWiNFO...
> 
> Thanks


Thanks!
EDIT: And thanks for your donation! Just noticed it


----------



## Hequaqua

Mumak said:


> Thanks!
> EDIT: And thanks for your donation! Just noticed it


YW Man....you do so much for the whole community. It's not much....but every little bit helps. :thumb:

EDIT: Might be enough for a cup of coffee to keep ya and working....lmao


----------



## Mumak

Yeah, I need a lot of coffee


----------



## mikochu

@Mumak,

I've been using the 3460 beta with my C7H without issue until the latest 0702 bios revision came out. Now, HWInfo causes something on my system to hard shutdown, requiring me to cycle the psu power switch to reboot. Should I go back to the non-beta?

Thanks,
Mike


----------



## Mumak

I don't think that going back will help. Does the shutdown happen every time you start HWiNFO, or after a while? Did the sensor layout in HWiNFO change with the 0702 BIOS ?


----------



## mikochu

Mumak said:


> I don't think that going back will help. Does the shutdown happen every time you start HWiNFO, or after a while? Did the sensor layout in HWiNFO change with the 0702 BIOS ?


It might've just been instability with my memory settings, but it seemed to happen when HWinfo was running, along with the CorsairService. I just installed 3465 and I'll see how it fares.

Thanks,
Mike


----------



## Mumak

I don't recommend to run Corsair Link with any other monitoring software. They refuse to play nice with other tools when it comes to accessing their devices.


----------



## chakku

@Mumak has anyone reported an issue with HWiNFO hanging when reading S.M.A.R.T from an SSD? For me it gets stuck there for about 5-10minutes until it eventually loads, if I try to force quit it will be stuck and nothing will get rid of it without a reboot. I'm not sure when this started happening for me, but was definitely happening on the previous 0702 C7H BIOS and now the latest 0804. 

I did get a new NVMe SSD (970 PRO) which is what is being read when the software hangs (S.M.A.R.T #1) but I didn't have this issue when I first got the SSD, it only started happening recently, possibly in one of the latest beta builds. Am currently on v5.85-3465 with no success.


----------



## Mumak

chakku said:


> @Mumak has anyone reported an issue with HWiNFO hanging when reading S.M.A.R.T from an SSD? For me it gets stuck there for about 5-10minutes until it eventually loads, if I try to force quit it will be stuck and nothing will get rid of it without a reboot. I'm not sure when this started happening for me, but was definitely happening on the previous 0702 C7H BIOS and now the latest 0804.
> 
> I did get a new NVMe SSD (970 PRO) which is what is being read when the software hangs (S.M.A.R.T #1) but I didn't have this issue when I first got the SSD, it only started happening recently, possibly in one of the latest beta builds. Am currently on v5.85-3465 with no success.


Are you perhaps using StoreMI ?


----------



## porschedrifter

Hey guys, does anyone know if it's safe upon installing a new version to have it not write over the .ini file? It's the quickest way to install without overwriting your custom settings, but never was sure if this was ill advised.


----------



## chakku

Mumak said:


> Are you perhaps using StoreMI ?


Yes I am, with a secondary SATA SSD and HDD.


----------



## Mumak

chakku said:


> Yes I am, with a secondary SATA SSD and HDD.


Then that's the reason. StoreMI drivers have been observed to cause such issues. I have already notified AMD about this.


----------



## Mumak

porschedrifter said:


> Hey guys, does anyone know if it's safe upon installing a new version to have it not write over the .ini file? It's the quickest way to install without overwriting your custom settings, but never was sure if this was ill advised.


Yes, completely safe. It will preserve your global settings.


----------



## chakku

Mumak said:


> Then that's the reason. StoreMI drivers have been observed to cause such issues. I have already notified AMD about this.


Ah okay thank you for clarifying, I'll look into removing it from the list of sensors being read from when I get home.


----------



## Hunched

Hello.
Have you ever considered creating fan control software?
For someone wanting to control their case fans based off of GPU temperatures their options are SpeedFan and Argus Monitor and thats it. I don't think anything else exists with the functionality.
SpeedFan hasn't been updated in 2 years and no longer works in any games using BattlEye anticheat as the SpeedFan driver is now blocked.
Myself I would just use Argus Monitor like everyone else who used SpeedFan but for some reason it just crashes for me and I don't think I'm going to be able to figure out why.

I'm not a software developer at all but with HWinfo it seems like you would already have a lot of the work done for such a project?
Thanks

SpeedFan is depreciating and all its users are going to need something to replace it with sooner or later


----------



## Mumak

Hunched said:


> Hello.
> Have you ever considered creating fan control software?
> For someone wanting to control their case fans based off of GPU temperatures their options are SpeedFan and Argus Monitor and thats it. I don't think anything else exists with the functionality.
> SpeedFan hasn't been updated in 2 years and no longer works in any games using BattlEye anticheat as the SpeedFan driver is now blocked.
> Myself I would just use Argus Monitor like everyone else who used SpeedFan but for some reason it just crashes for me and I don't think I'm going to be able to figure out why.
> 
> I'm not a software developer at all but with HWinfo it seems like you would already have a lot of the work done for such a project?
> Thanks
> 
> SpeedFan is depreciating and all its users are going to need something to replace it with sooner or later


Though? Yes.. But decided I won't go this way in near future.
Currently HWiNFO offers a very simple fan control only for a few very specific systems, which no one else is able to control fans. But I have no plans to extend this in near future.


----------



## LostParticle

@Mumak

Hey Martin, how is it going? 
Hope you're well.

I got this laptop back in May, 2018
Can we do something about the Uncore VID?

Thanks man.


----------



## Mumak

That's a completely invalid value, will be removed in the next build.


----------



## porschedrifter

@*Mumak* any thoughts or comments on this? Is there a setting in HWinfo that will stop the conflicts in the CH6 bios stopping the fans?



direct link to post: https://www.overclock.net/forum/11-...vi-overclocking-thread-1279.html#post27607104





elmor said:


> *BIOS/AGESA update*
> 
> There are issues with the newer AGESA versions which requires additional patching, QVL and user advisories. The current plan is to base next release on 1.0.0.6 which is not yet available from AMD/AMI. Hopefully it will be ready end of September or early October.
> 
> *SIO/Fan issues summary*
> 
> - Caused by software accessing the SIO for temp/voltage/fan readings
> - AIDA64/AiSuite/CPU-Z/HWInfo/SIV are all affected to various degrees
> - Without any monitoring software running, the fans should work as expected
> - The fix is to let the monitoring software rely on an ACPI WMI BIOS interface for safe access
> - The current ACPI WMI implementation still has issues, I'm waiting for a fully working beta BIOS
> - After a fully working BIOS with ACPI WMI is released, all monitoring software is required to use the new interface
> - If a monitoring software is not using the new interface, it will still cause issues
> 
> 
> 
> 
> Are you running any monitoring software in the background, like AiSuite/AIDA64/HWInfo/CPU-Z? Without software monitoring, these issues should not happen. I believe this is the same old problem.
> 
> 
> 
> 
> 
> 
> 
> Thanks, we're fine
> 
> 
> 
> Fan control ramping up/down
> - I'd have to test and see this for myself, not able to do so until October.
> 
> ROG LED disabling case power LED
> - I believe this was part of the stealth mode implementation. It's a matter of preference, not sure it will be changed.
> 
> AMLI error
> - Are you running any monitoring software when this error occurs? Does it happen if you don't use one?
> 
> 
> 
> Can someone else verify this happens?


----------



## Mumak

porschedrifter said:


> @*Mumak* any thoughts or comments on this? Is there a setting in HWinfo that will stop the conflicts in the CH6 bios stopping the fans?
> 
> 
> 
> direct link to post: https://www.overclock.net/forum/11-...vi-overclocking-thread-1279.html#post27607104


Latest HWiNFO versions support the new ACPI WMI BIOS interface, you just need to wait for a BIOS update from ASUS that will support this too. Once available, those issues should be resolved.


----------



## porschedrifter

Thanks buddy


----------



## diggiddi

Is anyone else having an issue with this program crashing PC ? Consistently with the last few editions
System just freezes up after a while
Intel i7 5775c 4.0ghz
Asus z97deluxe
32gb gskill trident x 2400


----------



## mattliston

Just wanted to dart in here and say this program found yet another piece of faulty hardware, saving time and energy.


Thank the logging ability!


Quite handy for finding out information on a computer that was appearing to randomly shutdown or blackscreeen. The SLI'd 770's were the victim of scrutiny, until we noticed the 12volt rail was sagging quite badly.


It is amazing at how resilient the AMD FX chips (fx6300 in my brothers case) was at running in such a terrible power environment. Swapping the PSU out for a known good one restored peace once again.


----------



## rluker5

diggiddi said:


> Is anyone else having an issue with this program crashing PC ? Consistently with the last few editions
> System just freezes up after a while
> Intel i7 5775c 4.0ghz
> Asus z97deluxe
> 32gb gskill trident x 2400


I'm not having issues on anything. Just updated it on my 4770k htpc and am using version 5.88-3510 right now on my 5775c (L5 in sig) gaming rig. Hwinfo64 works well on all of the stuff I've tried it on.
My guess is you have some hidden conflict with some other software brought about by a windows update. I'm up to date on windows. But I have noticed that aisuite3 on my daughter's (Lea2) rig is incompatible with updated windows (the popup overlay in particular but might be more), but a more limited version of aisuite works fine with my htpc in my sig. Even though they are both from the same Haswell era.
Turbotop had an overlay that started freezing anything I had it on after a windows feature update.


----------



## Mumak

diggiddi said:


> Is anyone else having an issue with this program crashing PC ? Consistently with the last few editions
> System just freezes up after a while
> Intel i7 5775c 4.0ghz
> Asus z97deluxe
> 32gb gskill trident x 2400


Please attach the HWiNFO Debug File after the freeze as described here and I'll analyze it: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## Mumak

mattliston said:


> Just wanted to dart in here and say this program found yet another piece of faulty hardware, saving time and energy.
> 
> 
> Thank the logging ability!
> 
> 
> Quite handy for finding out information on a computer that was appearing to randomly shutdown or blackscreeen. The SLI'd 770's were the victim of scrutiny, until we noticed the 12volt rail was sagging quite badly.
> 
> 
> It is amazing at how resilient the AMD FX chips (fx6300 in my brothers case) was at running in such a terrible power environment. Swapping the PSU out for a known good one restored peace once again.


Thanks  Glad to hear that it's useful.


----------



## diggiddi

Mumak said:


> Please attach the HWiNFO Debug File after the freeze as described here and I'll analyze it: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


Where is it located?


----------



## Mumak

diggiddi said:


> Where is it located?


Check the link in my post above.


----------



## MNMadman

@Mumak

Any way to get HWiNFO to recognize Asynchronous mode in the Asus Crosshair VII Hero board? That's where the RAM and PCIe have a different BCLK speed than the CPU's BCLK. It only shows the "main" RAM and PCIe BCLK right now.


----------



## Mumak

MNMadman said:


> @Mumak
> 
> Any way to get HWiNFO to recognize Asynchronous mode in the Asus Crosshair VII Hero board? That's where the RAM and PCIe have a different BCLK speed than the CPU's BCLK. It only shows the "main" RAM and PCIe BCLK right now.


Sorry, it's not possible to report this clock accurately. We have spent a lot of time with ASUS and AMD trying to find a way, but it's not possible.


----------



## LostParticle

Mumak said:


> That's a completely invalid value, will be removed in the next build.


Invalid Cache Voltage removed already, thank you.

My question now is, does my system have a Cache V and also V-Core sensors? Or not?
Specs in post #1816 

Thank you.


----------



## Mumak

LostParticle said:


> Invalid Cache Voltage removed already, thank you.
> 
> My question now is, does my system have a Cache V and also V-Core sensors? Or not?
> Specs in post #1816
> 
> Thank you.


I don't think that HP notebook can measure such values. I'm not even sure if I ever saw a notebook having such sensors.


----------



## mattliston

Hi.


Is there any way to prevent a portable version from using settings from an installed version of hwinfo?
I just opened up a freshly downloaded portable copy, and it pulled ALL my settings from my installed version, matching it.


----------



## mattliston

I did a simple graph change just now, and the portable version saved it on close, and opening my installed to disk version just showed the change, telling me both versions are trying to use the same spot for settings saving


EDIT I have just realized my "installed version" is yet another portable.


This still has me wondering how 2 different portable copies talk to each other, rather than saving their own settings in a INI file or such, in their own directories.


Would be awesome to have this seperation!!


-Matt


----------



## NeoReaper

Hey Mumak! Firstly gotta say, awesome program! It is and most likely will be the only monitoring tool I'll ever need for my system!
I have one small request for the RX480/580 series and that is if you can add a sensor for the Memory Controller on the GPU? Its pretty much the only sensor that I can't see inside HWinfo.
Thanks!


----------



## mattliston

I thought I saw a memory controller output on hwinfo back when I had my rx480 8gb.


Perhaps I am remembering memory load %, or memory error counter, or something similar?


----------



## Mumak

mattliston said:


> I did a simple graph change just now, and the portable version saved it on close, and opening my installed to disk version just showed the change, telling me both versions are trying to use the same spot for settings saving
> 
> 
> EDIT I have just realized my "installed version" is yet another portable.
> 
> 
> This still has me wondering how 2 different portable copies talk to each other, rather than saving their own settings in a INI file or such, in their own directories.
> 
> 
> Would be awesome to have this seperation!!
> 
> 
> -Matt


This is because only portable settings are stored in the INI file, while others (like screen positions, sensors appearance, etc.) which are mostly machine-specific are saved in the system registry.
Most users use a single copy of HWiNFO on one machine, not sure what's the reason for using different versions on the same system.
You can disable the "Remember Preferences" option in main settings to avoid preserving settings in registry.


----------



## Mumak

NeoReaper said:


> Hey Mumak! Firstly gotta say, awesome program! It is and most likely will be the only monitoring tool I'll ever need for my system!
> I have one small request for the RX480/580 series and that is if you can add a sensor for the Memory Controller on the GPU? Its pretty much the only sensor that I can't see inside HWinfo.
> Thanks!


What exactly should such sensor report, Memory Controller Utilization or GPU memory used?


----------



## NeoReaper

The memory controller utilisation.


----------



## Mumak

NeoReaper said:


> The memory controller utilisation.


Such a counter is available on AMD GPUs, but it usually doesn't provide valid numbers (it's either always 0, or invalid).
Have you seen such sensor in any other tool also showing correct usage?


----------



## NeoReaper

I have always gone by GPU-Z to provide these numbers in the past


----------



## chakku

@Mumak any update on the bug with StoreMI causing the sensor launch to hang for a bit?


----------



## deepor

I noticed the sensor window's reset button is not wiping the "GPU memory errors" entry on AMD GPUs. I don't know if this is a bug or not. I guess the reset button is really only just wiping the values in the 'minimum' and 'maximum' columns of all entries, and for the "memory error" entry there's then still the 'current' column with a value. This behavior could be seen as correct. Personally, I would like the reset button to set that memory error count to zero.

Now that I think about how things might work behind the scenes, the "WHEA" entry is perhaps also behaving the same?


----------



## Mumak

NeoReaper said:


> I have always gone by GPU-Z to provide these numbers in the past


And does it show a valid value for the Memory Controller usage? Can you post a screenshot?


----------



## Mumak

chakku said:


> @Mumak any update on the bug with StoreMI causing the sensor launch to hang for a bit?


Not yet. I'm still waiting for AMD to fix this.


----------



## Mumak

deepor said:


> I noticed the sensor window's reset button is not wiping the "GPU memory errors" entry on AMD GPUs. I don't know if this is a bug or not. I guess the reset button is really only just wiping the values in the 'minimum' and 'maximum' columns of all entries, and for the "memory error" entry there's then still the 'current' column with a value. This behavior could be seen as correct. Personally, I would like the reset button to set that memory error count to zero.
> 
> Now that I think about how things might work behind the scenes, the "WHEA" entry is perhaps also behaving the same?


Yes, the reset button clears only min/max values. There are also other values that remain like amount of data transferred by a Drive.


----------



## bmgjet

Any plans to ever pull info for UPS's

Id be more then happy to share all the info I got for my Liebert one since I had to write my own software for since the software that came with it would eat 3gb of ram per day with a memory leak.


----------



## Mumak

bmgjet said:


> Any plans to ever pull info for UPS's
> 
> Id be more then happy to share all the info I got for my Liebert one since I had to write my own software for since the software that came with it would eat 3gb of ram per day with a memory leak.


Many UPS with standard HID implementation should be already supported by HWiNFO. What is your UPS USB VID&PID ?


----------



## bmgjet

When I call.
MessageBox.Show(device[0].ProductID.ToString() + ", " + device[0].VendorID.ToString());

Output is 

20833, 1637

Which I believe would be
0x665, 0x5161


----------



## Mumak

bmgjet said:


> When I call.
> MessageBox.Show(device[0].ProductID.ToString() + ", " + device[0].VendorID.ToString());
> 
> Output is
> 
> 20833, 1637
> 
> Which I believe would be
> 0x665, 0x5161


Please attach the HWiNFO Debug File with sensor data, I will need to analyze that.


----------



## bmgjet

Got instructions for debug file or txt report with everything ticked work?


----------



## Mumak

see here: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## Mumak

bmgjet said:


> Got instructions for debug file or txt report with everything ticked work?


Please try this build: www.hwinfo.com/beta/hwi64_589_3536.zip and let me know if it shows the PSU in sensors now.


----------



## bmgjet

Still not showing in the sensors or any info on it.
Under USB ports tho it shows as cypress USB to Serial now instead of just Generic HID device.


----------



## Mumak

bmgjet said:


> Still not showing in the sensors or any info on it.
> Under USB ports tho it shows as cypress USB to Serial now instead of just Generic HID device.


Thanks. Then it looks like this model doesn't use the standard HID interface and might need special support. Unfortunately I don't have information how to support it.


----------



## bmgjet

You send it a byte over serial and it responds.

Here is a list of commands that are generic for a few brands.
https://networkupstools.org/protocols/voltronic.html

So youd just really need to keep polling the command
QGS

And it will feed you back.
Input voltage
Input frequency (Hz)
Output voltage
Output frequency (Hz)
Output current (Ampère)
Load level (%)
Battery voltage (Volt) [or VV.VV]
UPS temperature (° Celsius) 

Iv basically just set it up like

request = new byte[] { 0x51, 0x47, 0x53, 0x0D, 0x00, 0x00, 0x00, 0x00 }

Send request every 1000ms
parse responce and display on UI

Then the next useful command is.
QBV

Which gives you back.
Battery voltage
Number of batteries (that make a battery pack)
Number of battery packs in parallel
Battery capacity (%)
Remaining backup time (minutes)


----------



## Mumak

Thanks. Give me a few minutes and I will try to implement that and give you a new test build.


----------



## Mumak

OK, so I implemented this, but really not sure if it's going to work as I don't have direct access to such a UPS..
Please try this build: www.hwinfo.com/beta/hwi64_589_3537.zip
and attach a new Debug File so I can analyze it..


----------



## bmgjet

debug file


----------



## Mumak

Thanks. Do you see a new sensor called UPS? If yes, can you check if it's monitoring is perhaps disabled?


----------



## bmgjet

I see a sensor called UPS but everything under it is blank.
Its enabled, Nothing hidden.


----------



## Mumak

OK, I think I found the bug. Please try this: www.hwinfo.com/beta/hwi64_589_3538.zip
and attach a new Debug File.


----------



## bmgjet

attached, still only shows sensor name but no readings.


----------



## Mumak

oook.. sorry, not easy to work on something like this without direct access..
another bug fixed, please again the with this: www.hwinfo.com/beta/hwi64_589_3539.zip


----------



## bmgjet

Still same.
Id there a remote sensor plugin api. Might be easier for me to just write something external


----------



## Mumak

For you it appears the same, but internally there's some progress..
Now I sent "QGS\r" to the device, but it replied with an Error - Invalid parameter. Any idea what could be causing this perhaps?


----------



## Mumak

One thing to make sure.. what is the device name that you open when you communicate with it? It is "\\.\COMx" ?


----------



## bmgjet

Dont open it under a name, Im just using the HID.Net and HID.Win32 references in C#.
Then Open the UPS like.



Code:


IDevice[] device = DeviceFactory.Enumerate(0x665, 0x5161);

                if (device.Length < 1)
                {
                    //No UPS found!
                    return false;
                }

                if (device.Length > 1)
                    MessageBox.Show("Warning: " + device.Length.ToString() + " UPS found. Will only use first device.");

                BMGUPS = device[0];
                
                if (BMGUPS is Hid.Win32.Win32DeviceSet)
                {
                    Hid.Win32.Win32DeviceSet deviceSet = (Hid.Win32.Win32DeviceSet)BMGUPS;

                    System.Collections.Generic.List<Hid.Win32.Win32Device> deviceList =
                        new System.Collections.Generic.List<Hid.Win32.Win32Device>(deviceSet.UnallocatedDevices);

                    foreach (Hid.Win32.Win32Device winDevice in deviceList)
                    {
                        switch (winDevice.OutputLength)
                        {
                            case 9:
                                deviceSet.AddDevice(0x00, winDevice);
                                break;

                            default:
                                winDevice.Dispose();
                                break;
                        }
                    }
                }

                return true;

Then im sending and recieving info using this command.



Code:


            public string Getinfo(byte[] request)
            {
            
                    if (BMGUPS != null)
                    {

                    try
                    {
                        byte[] response;
                        response = BMGUPS.WriteRead(0x00, request);

                        string Input = "";

                        //parse all 6x8 = 48 bytes
                        for (int j = 1; j <= 7; j++)
                        {
                            for (int i = 0; i <= 7; i++)
                            {
                                Input = Input + Convert.ToChar(response[i]).ToString();
                            }
                            if (j != 40)
                                BMGUPS.Read(0x00, response); //read next byte (except when last already received)
                        }
                        if (Input == "(NAK")
                        { return "Unsupported Command"; }
                        else
                        {
                            return Input;
                        }
                    }
                    catch { }
                }
                return "Bad Command";
            }

And here is list of commands that work with mine.



Code:


 * Command List
                    //byte[] request = new byte[] { 0x51, 0x4C, 0x44, 0x4C, 0x0D, 0x00, 0x00, 0x00 }; //Last Min/Max Load               ****QLDL 
                    //byte[] request = new byte[] { 0x51, 0x46, 0x53, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //Fault Status                    ****QFS
                    //byte[] request = new byte[] { 0x51, 0x42, 0x59, 0x56, 0x0D, 0x8E, 0x18, 0x06 }; //BYPass Mode Limits V            ****QBYV
                    //byte[] request = new byte[] { 0x51, 0x42, 0x59, 0x46, 0x0D, 0x00, 0x00, 0x00 }; //BYPass Mode Limits F            ****QBYF
                    //byte[] request = new byte[] { 0x51, 0x48, 0x45, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //ECO Mode Limits                 ****QHE
                    //byte[] request = new byte[] { 0x51, 0x4D, 0x4F, 0x44, 0x0D, 0x00, 0x00, 0x00 }; //Operation Mode                  ****QMOD     
                    //byte[] request = new byte[] { 0x51, 0x57, 0x53, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //Warning Status                  ****QWS
                    //byte[] request = new byte[] { 0x51, 0x53, 0x4B, 0x31, 0x0D, 0x00, 0x00, 0x00 }; //Outlet status                    ^QSKx (x = outlet number)
                    //byte[] request = new byte[] { 0x51, 0x50, 0x49, 0x00, 0x00, 0x00, 0x00, 0x00 }; //Protocol in use                 ****QPI
                    //byte[] request = new byte[] { 0x51, 0x47, 0x53, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //Full Info String 12 byte        ****QGS
                    //byte[] request = new byte[] { 0x51, 0x4D, 0x44, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //model info                      ****QMD
                    //byte[] request = new byte[] { 0x51, 0x49, 0x44, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //Serial Number                   ****QID
                    //byte[] request = new byte[] { 0x51, 0x52, 0x49, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //rating                          ****QRI
                    //byte[] request = new byte[] { 0x51, 0x42, 0x56, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //battery info                    ****QBV
                    //byte[] request = new byte[] { 0x51, 0x56, 0x46, 0x57, 0x0D, 0x00, 0x00, 0x00 }; //firmware version                ****QVFW
                    //byte[] request = new byte[] { 0x51, 0x46, 0x4C, 0x41, 0x47, 0x0D, 0x00, 0x00 }; //QFLAG                           ****QFLAG
                    //byte[] request = new byte[] { 0x50, 0x45, 0x41, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //UPS ALARM ON???                 ****PEA
                    //byte[] request = new byte[] { 0x50, 0x44, 0x41, 0x0D, 0x00, 0x00, 0x00, 0x00 }; //UPS ALARM OFF???                ****PDA


----------



## Mumak

Thanks. How many bytes do you write as command, always 8 (including the 0 padding), or it depends on string length ?


----------



## bmgjet

Always 8 with padding.


----------



## Mumak

OK, then let's give it a try with 8 bytes: www.hwinfo.com/beta/hwi64_589_3540.zip


----------



## bmgjet

Attached


----------



## bmgjet

Here is a simple example program. Can send you the source if that makes it more easier for you.
Includes references to HID.net.dll and HID.Win32.dll



Code:


using System;
using System.Windows.Forms;
using Hid;

namespace UPS_Demo
{
    public partial class Form1 : Form
    {
        private bool UPSOpen = false;
        IDevice UPS_D;
        public Form1()
        {
            InitializeComponent();
        }

        //connect button
        private void button2_Click(object sender, EventArgs e)
        {
            UPSOpen = Open();
        }

        public bool Open()
        {

            // Connect to VID PID on USB with HID
            IDevice[] device = DeviceFactory.Enumerate(0x665, 0x5161);

            //Device too short throw error
            if (device.Length < 1)
            {
                MessageBox.Show("No UPS found!");
                return false;
            }

            //Found more then 1
            if (device.Length > 1)
                MessageBox.Show("Warning: " + device.Length.ToString() + " UPS found. Will only use first device.");

            //Set as first found device
            UPS_D = device[0];

            //HID magic
            if (UPS_D is Hid.Win32.Win32DeviceSet)
            {
                Hid.Win32.Win32DeviceSet deviceSet = (Hid.Win32.Win32DeviceSet)UPS_D;

                System.Collections.Generic.List<Hid.Win32.Win32Device> deviceList =
                    new System.Collections.Generic.List<Hid.Win32.Win32Device>(deviceSet.UnallocatedDevices);

                foreach (Hid.Win32.Win32Device winDevice in deviceList)
                {
                    switch (winDevice.OutputLength)
                    {
                        //Expected result for sucessful connect
                        case 9:
                            deviceSet.AddDevice(0x00, winDevice);
                            MessageBox.Show("Connected");
                            break;

                        default:
                            winDevice.Dispose();
                            break;
                    }
                }
            }

            return true;
        }
        //Full length reply packet
        public string PacketFormat1(byte[] request)
        {

            if (UPS_D != null)
            {

                try
                {
                    byte[] response;
                    response = UPS_D.WriteRead(0x00, request);





                    string Input = "";

                    for (int j = 1; j <= 6; j++)
                    {
                        for (int i = 0; i <= 7; i++)
                        {
                            Input = Input + Convert.ToChar(response[i]).ToString();

                        }
                        if (j != 6)
                            UPS_D.Read(0x00, response);
                    }
                    // NAK is error either unsupported command or polling to quickly
               
                    if (Input == "(NAK")
                    { return "Unsupported Command"; }
                    else
                    {
                        return Input;
                    }
                }
                catch { }
            }
            return "Bad Command";
        }

        //Half length reply packet
        public string PacketFormat2(byte[] request)
        {

            if (UPS_D != null)
            {

                try
                {
                    byte[] response;
                    response = UPS_D.WriteRead(0x00, request);

                    string Input = "";

                    for (int j = 1; j <= 3; j++)
                    {
                        for (int i = 0; i <= 7; i++)
                        {
                            Input = Input + Convert.ToChar(response[i]).ToString();
                        }
                        if (j != 3)
                            UPS_D.Read(0x00, response); //read next byte (except when last already received)
                    }
                    if (Input == "(NAK")
                    { return "Unsupported Command"; }
                    else
                    {
                        return Input;
                    }
                }
                catch { }
            }
            return "Bad Command";
        }
        

        //UPS Info Button
        private void button1_Click(object sender, EventArgs e)
        {
            //UPS most important info string full size packet
            byte[] request = new byte[] { 0x51, 0x31, 0x0D, 0x00, 0x00, 0x00, 0x00, 0x00 };
            textBox1.Text = textBox1.Text + Environment.NewLine + PacketFormat1(request);

        }

        //Battery Info Button
        private void button3_Click(object sender, EventArgs e)
        {
            //Batter info half size packet
            byte[] request = new byte[] { 0x51, 0x42, 0x56, 0x0D, 0x00, 0x00, 0x00, 0x00 };
            textBox1.Text = textBox1.Text + Environment.NewLine + PacketFormat2(request);
        }

        //Model info Button
        private void button4_Click(object sender, EventArgs e)
        {
            //model name full size packet
            byte[] request = new byte[] { 0x51, 0x4D, 0x44, 0x0D, 0x00, 0x00, 0x00, 0x00 };
            textBox1.Text = textBox1.Text + Environment.NewLine + PacketFormat1(request);
        }
    }
}

And screen shot is the output of each button pressed in order.


----------



## Cyph3r

Just a heads up - on my new Z390 Maximus XI Hero board, the CPU package power does not seem to be read correctly (even on the latest beta version). Package power always reads around 11w, sometimes dips to 8w or 3w but never goes any higher even under extreme load.


----------



## Mumak

bmgjet said:


> Attached


Thanks. Write seems to have worked now, I will need to adjust reading the result. Give me some time..


----------



## Mumak

Cyph3r said:


> Just a heads up - on my new Z390 Maximus XI Hero board, the CPU package power does not seem to be read correctly (even on the latest beta version). Package power always reads around 11w, sometimes dips to 8w or 3w but never goes any higher even under extreme load.


Is SVID support enabled in BIOS?


----------



## bmgjet

Mumak said:


> Thanks. Write seems to have worked now, I will need to adjust reading the result. Give me some time..


Here is a example of how I parse the results.
Not the nicest way to go about it but gets it all into usable varaiables.

So id call QGS.
It returns the string.



Code:


(237.5 237.3 229.9 015 50.0 2.28 17.2 00000001

Then I run that string though this.



Code:


  public void ParseString(string Input)
        {
               float ACVoltage = float.Parse(Input.Substring(1, 3)) + float.Parse(Input.Substring(5, 1)) / 10;
                float DCVoltage = float.Parse(Input.Substring(13, 3)) + float.Parse(Input.Substring(17, 1)) / 10;
                float Load = System.Int32.Parse(Input.Substring(19, 3));
                float Frequency = float.Parse(Input.Substring(23, 2)) + float.Parse(Input.Substring(26, 1)) / 10;

                //Each battery has 6 Cell (Then depending on UPS config will have so many batterys in Series as well My case its got 6 in series. for 82V at full charge
                //If you call the battery info it tells you how many batterys are in series.

                float CellVoltage = float.Parse(Input.Substring(28, 4)) * 6 * 6;
                float Temperature = float.Parse(Input.Substring(33, 2)) + float.Parse(Input.Substring(36, 1)) / 10; ;
            
        }


----------



## Mumak

bmgjet said:


> Attached


Please try again with this: www.hwinfo.com/beta/hwi64_589_3541.zip


----------



## bmgjet

attached


----------



## Mumak

How many bytes do you read during each read operation? I tried to read by 1 byte, but the device replied that it's not valid.
Or should I read by 8 bytes always?


----------



## Mumak

Let's give it a try with 8 byte reads: www.hwinfo.com/beta/hwi64_589_3542.zip


----------



## bmgjet

Im not sure.
This is the bit responsable for handling that and the HID libary does the rest.
Looking at it, it loops 8 times.
And then the 6 times loop is because if you call that command it will give you a different line 6 times.



Code:


byte[] response;
                    response = UPS_D.WriteRead(0x00, request);
                    string Input = "";

                    for (int j = 1; j <= 6; j++)
                    {
                        for (int i = 0; i <= 7; i++)
                        {
                            Input = Input + Convert.ToChar(response[i]).ToString();

                        }
                        if (j != 6)
                            UPS_D.Read(0x00, response);
                    }


Or if it would aid you I can set up a remote desktop at some point.
Would have to work out a time and create a seperate user if you wanted to play with direct hardware access.
Times zones might be a bit of a issue tho, Its 10.22PM here at the moment lol.


----------



## bmgjet

attached beta 589_3542


----------



## Mumak

Thanks for the offer. Will have to figure out somehow, here it's 11:51am, but I'll be out most of the weekend.
I don't understand what happened, but now the device refuses writes again. I haven't changed anything and still doing 8-byte writes and now receiving 8-byte packets too. But it fails the writes...


----------



## bmgjet

Have you got me a list of versions you want me to run in order.
Ill do a full restart between version to rule out any old commands upsetting it.

Also do you have a perfered more direct way you want to contact.
Im going to have to start deleting old attachments since im getting close to attachment limit.


----------



## ThrashZone

Hi,
Sorry if someone has asked already 
But you show 2 cpu temp package listings which one is most accurate there seems to be a 5-10c difference at times 
One is listed with all the Tj max stuff and the other is listed with PPO.


----------



## Mumak

ThrashZone said:


> Hi,
> Sorry if someone has asked already
> But you show 2 cpu temp package listings which one is most accurate there seems to be a 5-10c difference at times
> One is listed with all the Tj max stuff and the other is listed with PPO.


Well, I'm not sure about this as Intel never clarified this. But my guess is that the one under the DTS heading should be more accurate as this is considered as sort of 'reference'.


----------



## ThrashZone

Hi,
Well that would be the lower reading for sure which I just got a 83c reading on it and 90c on the enhanced section one :/

Same 90c on PPO.


----------



## majnu

Is there a way to get previous versions? I do not like the new interface in the latest version and that I cannot minimize the UI


----------



## Mumak

majnu said:


> Is there a way to get previous versions? I do not like the new interface in the latest version and that I cannot minimize the UI


There were no changes in such GUI in the latest version, so I doubt an older version will fix this.
Anyway, check here: https://www.fosshub.com/HWiNFO-old.html


----------



## b.walker36

I use the standalone version and whenver I change the text size it reverts next time. Is there any way to make it stick?


----------



## Mumak

b.walker36 said:


> I use the standalone version and whenver I change the text size it reverts next time. Is there any way to make it stick?


How do you close HWiNFO, with the blue X in sensors window?
Do you have the "Remember Preferences" option enabled in main settings of HWiNFO?


----------



## ThrashZone

Hi,
Text size is remembered for me on the newest stand alone version and all previous versions too.

On another note 
On a asus x299 prime deluxe what is VTT reading ?
Seems like it is cache I looked at siv64 and they showed the same reading min and max as VTT showed 

Otherwise there is no cache/ mesh reading for my board.


----------



## Mumak

ThrashZone said:


> Hi,
> Text size is remembered for me on the newest stand alone version and all previous versions too.
> 
> On another note
> On a asus x299 prime deluxe what is VTT reading ?
> Seems like it is cache I looked at siv64 and they showed the same reading min and max as VTT showed
> 
> Otherwise there is no cache/ mesh reading for my board.


VTT is a generic sensor readout, which on your mainboard most probably just reflects some floating or invalid value.


----------



## ThrashZone

Hi,
All I get is a mesh/ llc clock reading and not voltage for it while siv64 shows a cache voltage 

So why doesn't hwinfo show a cache voltage ?


----------



## Mumak

ThrashZone said:


> Hi,
> All I get is a mesh/ llc clock reading and not voltage for it while siv64 shows a cache voltage
> 
> So why doesn't hwinfo show a cache voltage ?


I'm not aware that your board would be capable of monitoring cache voltage and I think the BIOS doesn't show it either.
SIV is probably just assuming that this value (shown as VTT) is the cache voltage. Are you able to verify if this is true?


----------



## ThrashZone

Hi,
I'll try a manual voltage and see what both read 
I usually use adaptive +0.050 and turbo +0.150 which will make it vary.

Back in a few I'm on win-7 atm.


----------



## ThrashZone

Mumak said:


> I'm not aware that your board would be capable of monitoring cache voltage and I think the BIOS doesn't show it either.
> SIV is probably just assuming that this value (shown as VTT) is the cache voltage. Are you able to verify if this is true?


Hi,
Set cache at 1.0v manual mode nothing is showing that value :/


----------



## Mumak

So that value us just bogus and SIV is not right here.


----------



## ThrashZone

Hi,
Yeah I'm really hating asus and it's crappy sensors


----------



## Jpmboy

VIN9 VCache in SIV is VTT


----------



## majnu

Mumak said:


> There were no changes in such GUI in the latest version, so I doubt an older version will fix this.
> Anyway, check here: https://www.fosshub.com/HWiNFO-old.html


This is what the latest version shows when I click on it. No sensor info and no way to minimize.


----------



## Mumak

majnu said:


> This is what the latest version shows when I click on it. No sensor info and no way to minimize.


Right after starting HWiNFO, what is selected in the welcome screen - isn't it "Summary-only" perhaps ?


----------



## majnu

Mumak said:


> Right after starting HWiNFO, what is selected in the welcome screen - isn't it "Summary-only" perhaps ?


Nope, I have sensors only.


----------



## Mumak

Try to click "Reset Preferences" and delete the HWiNFO64.INI file if that will help.


----------



## majnu

Mumak said:


> Try to click "Reset Preferences" and delete the HWiNFO64.INI file if that will help.


I tried reset preferences previously and it didn't work. Deleting the HWiNFO64 configuration file however did. Thank you


----------



## ObscureEmpyre

Hoping this is the right area to ask this question. Does anyone know which sensor I should be monitoring for the actual vcore on a Gigabyte Z390 Aorus Master? I've heard IT8792E is more representative of the actual vcore than IT8688E. Also, IR35201 seems more indicative of vdroop. If anyone can answer, please let me know. Thank you.


----------



## Mumak

ObscureEmpyre said:


> Hoping this is the right area to ask this question. Does anyone know which sensor I should be monitoring for the actual vcore on a Gigabyte Z390 Aorus Master? I've heard IT8792E is more representative of the actual vcore than IT8688E. Also, IR35201 seems more indicative of vdroop. If anyone can answer, please let me know. Thank you.


VR VOUT of the IR35201 sensor is the direct readout from the VR, so that should provide the most accurate value.


----------



## ObscureEmpyre

Mumak said:


> VR VOUT of the IR35201 sensor is the direct readout from the VR, so that should provide the most accurate value.


Thanks. That's what I was thinking after several hours of stress testing with Prime95.


----------



## Mumak

Attention  We have a new unprecedented feature since v5.93-3610 Beta: Universal VR temperature monitoring for Haswell and later CPUs
This allows monitoring of VRM temperature also on boards which don't feature dedicated VRM sensors via their SIO/LPC hardware monitors. Values are read straight from the VRM (no mainboard-specific tweaks).
These new temperature(s) are available under the CPU sensor as "VR VCC Temperature (SVID)", "VR VCCIN Temperature (SVID)", "VR VCCSA Temperature (SVID)", etc.
Requirements are:
- Intel Haswell or later CPU (some Haswell or U/Y systems might not support well)
- SVID-compliant VRM supporting Temperature ADC (most do)
- SVID support enabled (sorry, extreme OCers, but this is required)

Release notes: https://www.hwinfo.com/forum/Thread-HWiNFO-v5-93-3610-Beta-released


----------



## encrypted11

There might be a bug with CPU PLLs OC (PLL bandwidth) reading twice the actual value on Z390 Asus boards.

PLL Bandwidth 4 (typically 1.15V) is read as 2.3V.


----------



## Mumak

encrypted11 said:


> There might be a bug with CPU PLLs OC (PLL bandwidth) reading twice the actual value on Z390 Asus boards.
> 
> PLL Bandwidth 4 (typically 1.15V) is read as 2.3V.


Which mainboard is that?


----------



## encrypted11

Maximus XI Gene


----------



## Mumak

encrypted11 said:


> Maximus XI Gene


I have checked the data and HWiNFO should be correctly multiplying the value by 2, so not sure why it's different for you.
Can you please attach the HWiNFO Debug File with sensor data for analysis?


----------



## encrypted11

Yes it is multiplying the value by 2.

So the actual value of PLL Bandwidth is supposed to be doubled as per comment by NickSihih?

https://community.hwbot.org/topic/155133-asrock-z170m-ocf-funhouse/?do=findComment&comment=435147


----------



## Zfast4y0u

Mumak said:


> In case of SMART causing such lag, this is a problem of the storage driver. Some versions of Intel RST drivers are know to cause such (and some other) issues. Intel is aware of this, but IDK when they will fix this.
> Quote: Originally Posted by *Arni90*
> 
> On my sig rig it was SMART monitoring, thanks for letting me know so I don't have to configure the program without knowing what to disable


hi mumak, got a question regarding latest hw info version and added features

https://www.hwinfo.com/version-history/

i have maximus x hero motherboard that dosent have vrm sensor officially... today i updated hwinfo and saw this new sensor pop out of nowhere, im starting to think it might actually be vrm sensor feature that you added?

VR VCC Temperature (SVID)

this correctly shows vrm temp of motherboard now, no?


----------



## Mumak

Zfast4y0u said:


> hi mumak, got a question regarding latest hw info version and added features
> 
> https://www.hwinfo.com/version-history/
> 
> i have maximus x hero motherboard that dosent have vrm sensor officially... today i updated hwinfo and saw this new sensor pop out of nowhere, im starting to think it might actually be vrm sensor feature that you added?
> 
> VR VCC Temperature (SVID)
> 
> this correctly shows vrm temp of motherboard now, no?


Yes, this is a new feature independent of board design as described here: https://www.overclock.net/forum/21-...ial-hwinfo-32-64-thread-191.html#post27763584


----------



## Zfast4y0u

so this reading is 100% accurate? if yes, thanks a lot, i have my doubts cause on prime95, 8700k at stock, vrm temp was just 51c...

wont spam here anymore, hw info is the best.

u did better job then asus ever will. god damn, now im happy, finally can monitor my vrm temp. CORRECTLY.


----------



## Mumak

Zfast4y0u said:


> so this reading is 100% accurate? if yes, thanks a lot, i have my doubts cause on prime95, 8700k at stock, vrm temp was just 51c...
> 
> wont spam here anymore, hw info is the best.
> 
> u did better job then asus ever will. god damn, now im happy, finally can monitor my vrm temp. CORRECTLY.


The value is as accurate as accurate the sensor in the VRM is. And I think that should be quite accurate, but only the VRM designer knows this exactly.


----------



## gammagoat

Good grief!

So I had this sensor VR VCC Temperature (SVID) saw that it was pretty toasty at 106c, shut down added a fan and rebooted and poof now its gone.

Any way to get it back?


----------



## Mumak

gammagoat said:


> Good grief!
> 
> So I had this sensor VR VCC Temperature (SVID) saw that it was pretty toasty at 106c, shut down added a fan and rebooted and poof now its gone.
> 
> Any way to get it back?


That's odd, I would need to see the HWiNFO Debug File to check why. Do you have SVID Support enabled in BIOS?


----------



## gammagoat

Mumak said:


> That's odd, I would need to see the HWiNFO Debug File to check why. Do you have SVID Support enabled in BIOS?


Svid is support is enabled.

This Site won't let me upload DBG. file?


----------



## Mumak

gammagoat said:


> Svid is support is enabled.
> 
> This Site won't let me upload DBG. file?


Try to compress it (ZIP, 7z, etc.)


----------



## ThrashZone

Hi,
Is there a difference between auto and enabled on svid support ?


----------



## Mumak

ThrashZone said:


> Hi,
> Is there a difference between auto and enabled on svid support ?


Not sure, best is to consult mainboard documentation/BIOS help. I assume Auto might disable SVID under certain extreme OC, i.e. when BCLK > 150 MHz.


----------



## Zfast4y0u

Mumak said:


> Not sure, best is to consult mainboard documentation/BIOS help. I assume Auto might disable SVID under certain extreme OC, i.e. when BCLK > 150 MHz.


hi again, just wanna report one strange issue that i have with this vrm sensor, i have rivatuner statistic server, msi afterburner and hw info configured to autostart with windows. when everything loads up, the vrm sensor is not there, i was restarting hw info trying to get it show up again without luck, at the end, i turned off all other monitoring programs and then tried to start hw info again, and then it shows up just fine, there is some kind of conflict with msi afterburner and hw info now seams. hw info must start first for sensor to show up and then u can start msi afterburner, which sucks since i must start it now manually if i want to have my vrm sensor :/


edit: actually conflict is with riva tuner, now confirmed.


----------



## Mumak

Zfast4y0u said:


> hi again, just wanna report one strange issue that i have with this vrm sensor, i have rivatuner statistic server, msi afterburner and hw info configured to autostart with windows. when everything loads up, the vrm sensor is not there, i was restarting hw info trying to get it show up again without luck, at the end, i turned off all other monitoring programs and then tried to start hw info again, and then it shows up just fine, there is some kind of conflict with msi afterburner and hw info now seams. hw info must start first for sensor to show up and then u can start msi afterburner, which sucks since i must start it now manually if i want to have my vrm sensor :/
> 
> 
> edit: actually conflict is with riva tuner, now confirmed.


Hm, that's interesting and it's hard for me to imagine how RIVA Tuner could affect this. Would be great if you could attach the HWiNFO DBG file of a run when it fails to detect the VRM sensor for analysis.


----------



## Zfast4y0u

when msi afterburner or riva tuner both start before hw info, sensor wont show up ever. even sometime when just hw info is running, and everything else is turned off, something is not right.


this is debug file with msi afterburner and rivatuner starting before hw info ( startup )


----------



## gammagoat

Here is my debug.


----------



## Mumak

Thanks guys. I see that internally HWiNFO properly detects the sensor and reads values from it, so the problem is probably just showing it.
Are you perhaps using custom sensor order layout? In that case the sensor might appear at the bottom of the list. Try to click "Restore Original Order" or enable "Fixed order" in sensor settings.

Merry Christmas to all !


----------



## Zfast4y0u

Mumak said:


> Thanks guys. I see that internally HWiNFO properly detects the sensor and reads values from it, so the problem is probably just showing it.
> Are you perhaps using custom sensor order layout? In that case the sensor might appear at the bottom of the list. Try to click "Restore Original Order" or enable "Fixed order" in sensor settings.
> 
> Merry Christmas to all !


im using costume layout and its configured to show in try icon area ( near clock ), thing is missing, its not in hw info list anywhere, and its not in hidden values also. i did change its name, from standard one, to ''Mobo VRM''


----------



## Mumak

Zfast4y0u said:


> im using costume layout and its configured to show in try icon area ( near clock ), thing is missing, its not in hw info list anywhere, and its not in hidden values also. i did change its name, from standard one, to ''Mobo VRM''


Try the above mentioned options if that will help. Note that it might cause loosing a custom sensor order.


----------



## Zfast4y0u

Mumak said:


> Try the above mentioned options if that will help. Note that it might cause loosing a custom sensor order.


yes i know. it seams when i enable fixed order, it works, loaded the sensor three times in row after restart of pc. thing is, when this sensor first time showed up, by default new sensors end up on bottom of the list and not in tab where they should originally belong. seams that create some kind of issue ( i had this sensor under asus EC maximus x hero ) , i just reverted layout to my costume one but with small change, i put this vrm sensor where it should be by default ( like in fixed order ), under intel core bla bla enchanced tab. just restarted the pc 2x and it works fine now.


----------



## Mumak

Zfast4y0u said:


> yes i know. it seams when i enable fixed order, it works, loaded the sensor three times in row after restart of pc. thing is, when this sensor first time showed up, by default new sensors end up on bottom of the list and not in tab where they should originally belong. seams that create some kind of issue ( i had this sensor under asus EC maximus x hero ) , i just reverted layout to my costume one but with small change, i put this vrm sensor where it should be by default ( like in fixed order ), under intel core bla bla enchanced tab. just restarted the pc 2x and it works fine now.


That's because when you use custom order of sensor items and a new entry appears, HWiNFO looses track of the original order and doesn't know where to put the new entry (sensor-reading bindings are no longer used in this case).
I'm glad that it's resolved now.


----------



## Zfast4y0u

dobble post


----------



## Zfast4y0u

Mumak said:


> That's because when you use custom order of sensor items and a new entry appears, HWiNFO looses track of the original order and doesn't know where to put the new entry (sensor-reading bindings are no longer used in this case).
> I'm glad that it's resolved now.


Me too, thanks on the help. Looking forward for gpu vram temp monitoring btw


----------



## gammagoat

Fixed on my end also, thanks Mumak.


----------



## Sazyk

Hi, i don't now if it is normal, but HwInfo says VR VCC Temperature (SVID is enables) is around 80ºc. I have 7700k with an Asus z270 TUF mark II. Is that the VRM temp?


----------



## LostParticle

Hello again, Martin

Latest HWiNFO64 here, v.6.00-3620, reset to its defaults, no hidden values. I do not see any VRM temps for my laptop, does it not support it?


----------



## Jspinks020

I don't know..one of them actually looked right. This one does too one after CPU..VR MOS...says it gets up to like 54-55c in cb heavy load....sounds about right man. Don't even need cooled...that's actually pretty cool. None issue and that is a good sink on there.


----------



## Mumak

Sazyk said:


> Hi, i don't now if it is normal, but HwInfo says VR VCC Temperature (SVID is enables) is around 80ºc. I have 7700k with an Asus z270 TUF mark II. Is that the VRM temp?


Yes, it is.


----------



## Mumak

LostParticle said:


> Hello again, Martin
> 
> Latest HWiNFO64 here, v.6.00-3620, reset to its defaults, no hidden values. I do not see any VRM temps for my laptop, does it not support it?


The VRM might not feature a thermal sensor. If you attach the HWiNFO Debug File, I can check that.


----------



## LostParticle

Mumak said:


> The VRM might not feature a thermal sensor. If you attach the HWiNFO Debug File, I can check that.


Please, have a look. Thanks


----------



## Mumak

LostParticle said:


> Please, have a look. Thanks


Confirmed, this VRM isn't capable of monitoring the temperature.


----------



## EarlZ

I have a Gigabyte Z390 Master and I will be using the thermal probes very soon, under which sensor/label does it show up on HWinfo?


----------



## Mumak

EarlZ said:


> I have a Gigabyte Z390 Master and I will be using the thermal probes very soon, under which sensor/label does it show up on HWinfo?


If you mean the new VRM temperature, then it's under the extended CPU sensor as "VR VCC Temperature (SVID)".


----------



## EarlZ

Mumak said:


> If you mean the new VRM temperature, then it's under the extended CPU sensor as "VR VCC Temperature (SVID)".


Sorry if my question was a bit unclear, I was referring to the two temperature probes that came with the motherboard.


----------



## guitarmageddon88

Side note for the latest version, it shuts off the light on my msi gaming x trio 2080 as soon as I open "sensors." Kind of an annoyance, guess it doesn't like mystic light software? I'll keep using an old version of hw info for a while. Unless I'm missing something ?


----------



## Mumak

guitarmageddon88 said:


> Side note for the latest version, it shuts off the light on my msi gaming x trio 2080 as soon as I open "sensors." Kind of an annoyance, guess it doesn't like mystic light software? I'll keep using an old version of hw info for a while. Unless I'm missing something ?


Please attach the HWiNFO Debug File of the system, so I can check how to fix it.


----------



## Mumak

EarlZ said:


> Sorry if my question was a bit unclear, I was referring to the two temperature probes that came with the motherboard.


Sorry, but which exact probes do you mean, how are they called by GIGABYTE or their software? Is that the EC_TEMP1/2 ?


----------



## guitarmageddon88

Mumak said:


> Please attach the HWiNFO Debug File of the system, so I can check how to fix it.


Okay sure I can send that. how do I get that? And should I uninstall this older version and go back to the new one that exhibited that behavior?


----------



## EarlZ

Mumak said:


> Sorry, but which exact probes do you mean, how are they called by GIGABYTE or their software? Is that the EC_TEMP1/2 ?


Yes, thats the EC_TEMP1/2


----------



## Mumak

guitarmageddon88 said:


> Okay sure I can send that. how do I get that? And should I uninstall this older version and go back to the new one that exhibited that behavior?


No need to uninstall the previous version, just install the new over it. See here how to create the Debug File: https://www.hwinfo.com/forum/Thread-IMPORTANT-Read-this-before-submitting-a-report


----------



## Mumak

EarlZ said:


> Yes, thats the EC_TEMP1/2


Those will be show as such under the mainboard (ITE) sensors.


----------



## guitarmageddon88

Mumak said:


> Please attach the HWiNFO Debug File of the system, so I can check how to fix it.


Here you go. Let me know if the link doesnt work
https://drive.google.com/file/d/1O6pr9rGVSpouFPoExPZNOTLk7pu7Og71/view?usp=sharing


----------



## Mumak

guitarmageddon88 said:


> Here you go. Let me know if the link doesnt work
> https://drive.google.com/file/d/1O6pr9rGVSpouFPoExPZNOTLk7pu7Og71/view?usp=sharing


Thanks, but please use the latest version and also open the sensors window, so that the dump will contain sensor data as well.


----------



## Timur Born

Hello. This is what I wrote in another thread about the "OUT" sensors on the Gigabyte Aorus Master as being measured by HWInfo:

"Without Speedshift the increases in voltages correspond to increases in frequency (as determined by the active Windows power profile). Because of this I suspect that Speedshift increases frequency in intervals too short for HWinfo to measure even at 100 ms polling rate. This is still rather strange, because both the VR VOUT voltage and current are measured to increase by HWinfo even while the multiplier doesn't budge a bit."

"Indeed, HWinfo is not able to keep up with CPU frequency changes. You need to disable HPET (and maybe bus-clock based CPU measurements, but that comes with drawbacks) in its "Safety" options in order to get a better picture of frequency changes. Or use Throttlestop to measure CPU multipliers more accurately and have them line up with VR VOUT measurements.

Still the question remains why VR VOUT differs so considerably from the other sensors measurements during "idle" phases?!"

"I measured wattage at the wall and based on that I suspect that the "OUT" measurements done by HWinfo are mostly useless. Either the polling rate is too low or the averaging is too coarse.

During idle times POUT (in combination with VOUT and IOUT) suggest over 20 watts average load - with peaks over 40 watts - at Speedshift 0% compared to less than 1 watt average at Speedshift 100%.

The real difference at the wall is much closer to what "CPU Package Power" measures, aka more like 2 - 4 watts higher average draw at 0% compared to 100% during Idle.

Turning off C-states pushes this to even more dramatic differences. Idle wattage according to POUT is around 35 watts at Speedshift 0% compared to less than 1 watt at Speedshift 100%. So 15 watts more compared to using C-states... not! Because according to the wall meter the difference is less than 2 watts, not 15 watts.

No idea what those "OUT" numbers are meant to measure, but I suggest to take these with a big grain of salt."


----------



## Mumak

VR VOUT values report the values on output side of VRM, so what is provided to the CPU. Accuracy of those values depends on how the VRM measures it, HWiNFO only reports what the VRM measures.
Of course it's not possible to capture in real-time the actual values, as during transient states parameters can change thousands of times per second and no software is capable to accurately catch, evaluate and report with such a frequency.


----------



## ThrashZone

Hi,
Any disadvantages to the stand alone verses the installer ?
I use the stand alone usually and I notice if I delete the desktop shortcut and put a new from a newer version it shows what I had not monitored in red X's


----------



## Mumak

ThrashZone said:


> Hi,
> Any disadvantages to the stand alone verses the installer ?
> I use the stand alone usually and I notice if I delete the desktop shortcut and put a new from a newer version it shows what I had not monitored in red X's


There should be no disadvantages. Red X's mean that monitoring of such value is disabled. You can enable that anytime by hitting the Ins key over such value.


----------



## ThrashZone

Hi,
Yes but how does the newer version know the items were disabled ?


----------



## Mumak

ThrashZone said:


> Hi,
> Yes but how does the newer version know the items were disabled ?


Such user settings are preserved across versions.


----------



## Timur Born

Mumak said:


> VR VOUT values report the values on output side of VRM, so what is provided to the CPU. Accuracy of those values depends on how the VRM measures it, HWiNFO only reports what the VRM measures.
> Of course it's not possible to capture in real-time the actual values, as during transient states parameters can change thousands of times per second and no software is capable to accurately catch, evaluate and report with such a frequency.


The problem is that HWinfo does not catch most (or any) of the changes even at 100 ms, especially CPU multiplier may not change at all when HPET is enabled in Safety preferences. So this is a problem of HWinfo mostly.

Concerning "OUT" (VOUT, IOUT, POUT) sensors specifically, I don't know enough about them to judge where the culprit lies, but during idle times the values reported are off considerably (like POUT reporting over 30 watts more usage when the real increase is 2 watts). Are VOUT, IOUT and POUT all reported by the VRM or is one derived/calculated from the others?


----------



## Mumak

Timur Born said:


> The problem is that HWinfo does not catch most (or any) of the changes even at 100 ms, especially CPU multiplier may not change at all when HPET is enabled in Safety preferences. So this is a problem of HWinfo mostly.
> 
> Concerning "OUT" (VOUT, IOUT, POUT) sensors specifically, I don't know enough about them to judge where the culprit lies, but during idle times the values reported are off considerably (like POUT reporting over 30 watts more usage when the real increase is 2 watts). Are VOUT, IOUT and POUT all reported by the VRM or is one derived/calculated from the others?


All are reported by the VRM.
Try to disable monitoring of all sensors that you don't need (including their headings) if that will improve the output.


----------



## mattliston

go into settings and make sure the values you want to visually change for you, are set with 2 or 3 decimal places.


My FSB clock does not deviate from 200mhz until I set it to read 2 decimal places, then it works like a champ!!


----------



## Timur Born

Does hiding of a sensor/heading also automatically disable monitoring?


----------



## Mumak

Timur Born said:


> Does hiding of a sensor/heading also automatically disable monitoring?


Yes.


----------



## Timur Born

Thanks and happy new year.

I did a BIOS update and hide/unhide several sensors. Now the CPU multiplier is updated much more frequently even with the HPET option being enabled.


----------



## Mumak

Happy New Year to all!


----------



## guitarmageddon88

Mumak said:


> Thanks, but please use the latest version and also open the sensors window, so that the dump will contain sensor data as well.


https://drive.google.com/file/d/1fwJzHq5zBL1wXcuBmCxwdN3DIJ_2xtmV/view?usp=sharing

Here you go, does that work? What I did was I started my computer as normal, then I opened the hwinfo. After that ,I then entered sensors after which my lighting on the gpu shut off. I then exited sensors and enabled lighting via mystic light once again. I opened sensors another time, after which the lighting shutoff. Exited sensors a third time ,but went back in without re-enabling lighting. Closed program

Hopefully that gives a few iterations of what the logs could look like. This was the newest version btw


----------



## Mumak

guitarmageddon88 said:


> https://drive.google.com/file/d/1fwJzHq5zBL1wXcuBmCxwdN3DIJ_2xtmV/view?usp=sharing
> 
> Here you go, does that work? What I did was I started my computer as normal, then I opened the hwinfo. After that ,I then entered sensors after which my lighting on the gpu shut off. I then exited sensors and enabled lighting via mystic light once again. I opened sensors another time, after which the lighting shutoff. Exited sensors a third time ,but went back in without re-enabling lighting. Closed program
> 
> Hopefully that gives a few iterations of what the logs could look like. This was the newest version btw


Thanks for the file.
Please try the following - in settings of HWiNFO choose the SMBus / I2C tab and disable the "GPU I2C Support" option. Will that solve the problem?


----------



## guitarmageddon88

Mumak said:


> Thanks for the file.
> Please try the following - in settings of HWiNFO choose the SMBus / I2C tab and disable the "GPU I2C Support" option. Will that solve the problem?


Worked like a charm! Did that change something to minimize hwinfo features in any way? Looks the same to me so far.


----------



## Mumak

guitarmageddon88 said:


> Worked like a charm! Did that change something to minimize hwinfo features in any way? Looks the same to me so far.


For your GPU it doesn't disable any features, but for some other it might cause loss of GPU VRM or additional sensors if present.
That option disabled the entire GPU I2C support. I'd like to narrow down this to an exact device, would you be willing to make a test in the hunt for this?


----------



## guitarmageddon88

Mumak said:


> For your GPU it doesn't disable any features, but for some other it might cause loss of GPU VRM or additional sensors if present.
> That option disabled the entire GPU I2C support. I'd like to narrow down this to an exact device, would you be willing to make a test in the hunt for this?


Sure thing. Need another test?


----------



## Mumak

guitarmageddon88 said:


> Sure thing. Need another test?


Well, it would be required to determine which address the RGB device is using to skip it by default, but such test would be probably too complicated for a user.
I will try to find some way how to do this on my side, but certainly the next HWiNFO build will add some workaround for this issue.


----------



## Rapidian

*CPU/AIO/Chassis fans stops working on Asus ROG B450-I Gaming*

I've been having a sporadic problem on the following system, in which, all the fans STOP working! That is the CPU, AIO, and Chassis fans! I've experienced this while in games when I notice the frame rate drops. When I check the temp with HWiNFO64, the CPU is thermal throttling (85C). This condition is unacceptable in a motherboard. Has anyone else had this experience with Asus?

*System*:
- Asus ROG B450-I Gaming motherboard
- AMD 2700X processor
- G.Skill F4-3200C14D-16GFX memory kit
- Noctua NH-U12S SE-AM4 heatsink cooler (hooked up to CPU header)
- Noctua NF-F12 PWM (rear outflow chassis fan, hooked up to AIO header)
- Fractal Design Dynamic Series fans GP-12/GP-14 (front intake chassis fan) 
- Fractal Design Nano S case (came with above 2 fans)
- EVGA SuperNOVA 750 G3 power supply

Now, I've noticed several threads on this topic (none here in overclocker.net), but none totally solve the problem. 
- https://rog.asus.com/forum/showthre...rime-X470-Pro&p=720878&mode=linear#post720878
- https://rog.asus.com/forum/showthre...nsors-failing-Fans-on-Max-speed-problem/page5
- https://rog.asus.com/forum/showthread.php?93421-AiO-Header-and-CPU-Fan-headers-shut-down/page5
- https://forums.aida64.com/topic/398...rolling-issues-asus-crosshair-vi-hero/?page=3

The plausible cause appears to be the embedded controller ITE IT8665E. I'm wondering if it's true: software is polling too often (either AIDA64 or HWiNFO64) and causing the chip to shutdown the fans. Or overheat? I've seen that HWiNFO64 does have support to disable the WMI interface for some Asus motherboards. 

v5.92 Nov-21-2018
- Added workaround for ASUS ROG STRIX B450/X470 boards with buggy WMI implementation.

I'm using v6.0 and it's still happening. @Mumak, is there something not supported on Asus B450-I Gaming Mobo?

The solution appears to stop running HWiNFO64 at Windows startup. And I guess MSI Afterburner as well which displays fans as well.


----------



## Mumak

Rapidian said:


> I've been having a sporadic problem on the following system, in which, all the fans STOP working! That is the CPU, AIO, and Chassis fans! I've experienced this while in games when I notice the frame rate drops. When I check the temp with HWiNFO64, the CPU is thermal throttling (85C). This condition is unacceptable in a motherboard. Has anyone else had this experience with Asus?
> 
> *System*:
> - Asus ROG B450-I Gaming motherboard
> - AMD 2700X processor
> - G.Skill F4-3200C14D-16GFX memory kit
> - Noctua NH-U12S SE-AM4 heatsink cooler (hooked up to CPU header)
> - Noctua NF-F12 PWM (rear outflow chassis fan, hooked up to AIO header)
> - Fractal Design Dynamic Series fans GP-12/GP-14 (front intake chassis fan)
> - Fractal Design Nano S case (came with above 2 fans)
> - EVGA SuperNOVA 750 G3 power supply
> 
> Now, I've noticed several threads on this topic (none here in overclocker.net), but none totally solve the problem.
> - https://rog.asus.com/forum/showthre...rime-X470-Pro&p=720878&mode=linear#post720878
> - https://rog.asus.com/forum/showthre...nsors-failing-Fans-on-Max-speed-problem/page5
> - https://rog.asus.com/forum/showthread.php?93421-AiO-Header-and-CPU-Fan-headers-shut-down/page5
> - https://forums.aida64.com/topic/398...rolling-issues-asus-crosshair-vi-hero/?page=3
> 
> The plausible cause appears to be the embedded controller ITE IT8665E. I'm wondering if it's true: software is polling too often (either AIDA64 or HWiNFO64) and causing the chip to shutdown the fans. Or overheat? I've seen that HWiNFO64 does have support to disable the WMI interface for some Asus motherboards.
> 
> v5.92 Nov-21-2018
> - Added workaround for ASUS ROG STRIX B450/X470 boards with buggy WMI implementation.
> 
> I'm using v6.0 and it's still happening. @Mumak, is there something not supported on Asus B450-I Gaming Mobo?
> 
> The solution appears to stop running HWiNFO64 at Windows startup. And I guess MSI Afterburner as well which displays fans as well.


This problem is known for a long time and has been happening on some ASUS Ryzen mainboards.
As you assumed it's the SIO (ITE) chip, but not because of a high polling frequency, but a conflict when multiple clients try to access that chip. That's why ASUS came with the WMI sensor alternative, which was supposed to fix this. Unfortunately their implementation has been buggy in lots of BIOSes, so it either didn't properly resolve the problem, or caused crashing of client applications. The workaround in HWiNFO was to prevent this crashing, so HWiNFO won't use WMI on such BIOSes, which is a pita. I was expecting ASUS to fix this, so that we can use WMI and avoid those conflicts, but I'm not sure about the status of a particular boards/BIOS. So I recommend to upgrade to the latest BIOS and see whether the problem persists. Ideally you should see a different layout of the mainboard sensor, which would indicate WMI is used instead of the problematic direct SIO access.


----------



## gupsterg

Currently only C6H/C7H/ZE have working ASUS WMI. So far all other mobo owners I have seen do not have feature as HWINFO heading of ASUS WMI is not there for them.


----------



## umeng2002

I've heard of the fan issue to, but I haven't experienced it. The oddest thing with my Asus board is that the DC controlled fans will go to 100% sometimes after I change something in the BIOS unrelated to fans; although restarting the system fixes it. All I can say, is that Asus is off my list of next mobo purchases from what I've heard people say about their X470 boards. I guessed out of thin air that those issues might be related to RGB control, so I just turned that off in the BIOS.


----------



## Rapidian

Mumak said:


> So I recommend to upgrade to the latest BIOS and see whether the problem persists. Ideally you should see a different layout of the mainboard sensor, which would indicate WMI is used instead of the problematic direct SIO access.


I'm on the latest bios for that board. It's 1201 and has a date of 12/21. Nothing later... Here's to waiting...


----------



## Rapidian

umeng2002;27800360All I can say said:


> I don't have RGB on either and it occurred. I do not even have the Asus aisuite nor aura software installed in Windows. Aura caused kept eating CPU time. Wasted. I want performance and not being.


----------



## Mumak

Rapidian said:


> I don't have RGB on either and it occurred. I do not even have the Asus aisuite nor aura software installed in Windows. Aura caused kept eating CPU time. Wasted. I want performance and not being.


Try to disable monitoring of the ITE sensor in HWiNFO (hit the Del key over the sensor heading) and see if that will change something.


----------



## gupsterg

Rapidian said:


> I'm on the latest bios for that board. It's 1201 and has a date of 12/21. Nothing later... Here's to waiting...


Check if you have this heading in HWINFO.



Spoiler














If you do then UEFI/board has ASUS WMI.

The fix is two fold, you need UEFI with correct implementation and SW using it.

You'll see in that screenie I have OC'd 2700X on 3600MHz C15 1T running P95 v28.10b1 8K 4096K 12GB for 12hrs. That was with 2x CPU-Z v1.87.0 and HWINFO, I have zero issues on Super IO chip.

Latest HWINFO, CPU-Z, AIDA64 and SIV I have used and not ran into issues. Some other software like even ASUS's own can send board wacko.

Even on C6H/ZE, owned since launch, always used onboard headers to control all fans, etc, even without ASUS WMI I had very little issues. As ran without a lot of the crap'o'ola OS OC/monitoring/RGB/Fan control SW, etc and set up UEFI as needed.

The programs which I knew were borked for use on with/without ASUS WMI you need to run not with other SW that may access Super IO chip. I would also say do a repost after using the SW, the chip is reinitialised an you won't encounter issue.

It sucked it took ASUS over a year to roll it out on C6H, even though they were aware. ZE got it later, luckily C7H got it pretty quick.


----------



## Rapidian

gupsterg said:


> Check if you have this heading in HWINFO.
> 
> If you do then UEFI/board has ASUS WMI.
> 
> The fix is two fold, you need UEFI with correct implementation and SW using it.


 @gupsterg, as I'm sure you know, CH7 has a different chipset (X470) than my board B450, but I thought they used the same SuperIO chip. Mine looks like this.



Spoiler














This problem is intermittent. It does not always occur. I've had it happen maybe 3-4 times. Once was actually when I ran the Asus Aisuite to "configure" which tests the fans. All stopped and never started backup. It was then I decided to not use *any* Asus software. Aura is buggy as well (had a ~7% cpu load at all times) and screwed up my initial CineBench scoring. 

I'm not clear that the Asus B450-I contains the correct fix in HWiNFO64 yet. I'm doing as @Mumak said; disabling the IT8665E section. I'm also disabling the ASUS EC as HWiINFO64 advised. However, that sofware is the only thing which actually monitors my fans in Windows 10. I've no idea what the speed is except by "sound".

All I can do is try, play some games and see if this problem occurs again. I'm interested in whether I should explore other fan controllers. I really do want the Mobo to support this. I've opened an issue with Asus but support has not been helpful with useful solutions. Reading had got me onto this software and that chip as a plausible cause to the problem.

Open to suggestion. Thanks for writing back. BTW, what is that software you have which displays the RAM voltage? I'm curious to check in the OS what I have set.


----------



## gupsterg

Yes all ASUS AM4/sTR4 use SIO as ITE IT8665E.

From your screenshot (as suspected) the UEFI does not have ASUS WMI implementation.

As stated before 1st and foremost UEFI has to have correct implementation. Secondly software used that may interact with SIO must use the implementation. If either 2 are not in place you will have sporadic issues, especially if you use things like AURA, Ai Suite and other SW that do not even have ASUS WMI.

HWINFO, AIDA64, SIV and CPU-Z have what they should have in the context of C6H, C7H and ZE. I do believe fixes to them recognise other ASUS boards if they have ASUS WMI in UEFI.

If you use a fan controller which has it's own PWM signal to give fans you will not experience issues regardless if UEFI/SW has ASUS WMI fix.

VDIMM HWINFO/AIDA64/SIV and any other SW that supports the C6H/C7H/ZE gives me it. Not had other boards, so if not there I suspect not exposed, it may also be under ASUS EC which you have disabled looking at screenie.

If you use just HWINFO and do not use any ASUS SW mentioned. Avoid running AIDA64, CPU-Z, SIV and HWINFO concurrently you shouldn't have issue. That is what I did prior to implementation, if you do then as stated before, do do a repost, so SIO is reinitialised.

I'll drop [email protected] a PM, I can not promise anything as I have nothing to do with ASUS other than as a user.


----------



## Half Life

*VR VCC Temperature VS VRM MOS Temperature*

After 1 hour Prime 95 with AVX I have 

VR VCC Temperature: 90 C
VRM MOS Temperature: 71 C

Which temperatue ist important? Both temperatures or only the VRM MOS temperature?


I have:
- Gigabyte Z390 Aorus 
- Core i9 9900k
- bequiet! Silent Loop 360
- Multicore Enhancement: On
- XMP Profile: On
- Not manually overclocked
- computer housing open


----------



## Mumak

Half Life said:


> After 1 hour Prime 95 with AVX I have
> 
> VR VCC Temperature: 90 C
> VRM MOS Temperature: 71 C
> 
> Which temperatue ist important? Both temperatures or only the VRM MOS temperature?
> 
> 
> I have:
> - Gigabyte Z390 Aorus
> - Core i9 9900k
> - bequiet! Silent Loop 360
> - Multicore Enhancement: On
> - XMP Profile: On
> - Not manually overclocked
> - computer housing open


This is a known "feature" of later GIGABYTE boards - their VR MOS sensors report unrealistically low temperatures for the VRM, most probably their sensors are not close enough the VRM circuits or they apply some magic negative offset to real values measured.
VR VCC is the real (internal) VRM temperature.


----------



## Half Life

Your Answer is very helpful.
thx a lot!


----------



## ThrashZone

Hi,
Looked back quite a ways didn't see so sorry if I already asked 
But Temp 3 what is that on x99 sabertooth 

X299 temp 3 shows half what x99 is showing I have basically the same custom loops x2 on both systems 

Seems way out of line temp wise someone on ROG forum asked too his was 100c on a Rampage V Extreme mine is a tad lower but I haven't really done any benchmarks or anything


----------



## Mumak

ThrashZone said:


> Hi,
> Looked back quite a ways didn't see so sorry if I already asked
> But Temp 3 what is that on x99 sabertooth
> 
> X299 temp 3 shows half what x99 is showing I have basically the same custom loops x2 on both systems
> 
> Seems way out of line temp wise someone on ROG forum asked too his was 100c on a Rampage V Extreme mine is a tad lower but I haven't really done any benchmarks or anything


Sorry, I don't know what exactly that represents. It's an unofficial readout and I don't have any further details about it, so it might be completely invalid as well.


----------



## ThrashZone

Hi,
Thank you for the quick reply :thumb:


----------



## jfriend00

*How do you create this multi-column view in HWINFO64?*

How do you create the multi-column view in HWINFO64 as shown in this post:

https://www.overclock.net/forum/21-...cial-hwinfo-32-64-thread-36.html#post27133649


----------



## Hequaqua

jfriend00 said:


> How do you create the multi-column view in HWINFO64 as shown in this post:
> 
> https://www.overclock.net/forum/21-...cial-hwinfo-32-64-thread-36.html#post27133649


Use the buttons highlighted in red:


----------



## Timur Born

Hello everyone.

Is this really what the mainboard reports? Because Gigabyte's own Easytune software does not catch these drops to zero (0) and the fans definitively do not stop spinning when HWinfo reports zero rpm.

It mostly only happens for some time and then no more drops to zero are reported (maybe until a restart). For example, everything that came after this screenshot did not see any drops reported. Screenshot was done a 1s poll rate.


----------



## Mumak

Well, that might also be some glitch in reading fan speeds. It could be caused by a collision when using multiple monitoring tools at once. Can you try to run only HWiNFO if you observe the same?


----------



## Timur Born

Usually HWinfo runs on its own when this happens. I only ran EasyTune for comparison.


----------



## RichKnecht

The latest version of HWInfo would not properly show voltages (12V rail, DRAM, vccin) or fan/water pump speed. So, I tried the new Beta version (using it now) and everything looks good except vccin. It is set to 1.95 in bios and shows 2.596 in HWInfo. Board is the new Rampage Extreme Omega.


----------



## Mumak

RichKnecht said:


> The latest version of HWInfo would not properly show voltages (12V rail, DRAM, vccin) or fan/water pump speed. So, I tried the new Beta version (using it now) and everything looks good except vccin. It is set to 1.95 in bios and shows 2.596 in HWInfo. Board is the new Rampage Extreme Omega.


Which latest Beta are you running? VCCIN should be showing properly since v6.01-3660


----------



## RichKnecht

Mumak said:


> Which latest Beta are you running? VCCIN should be showing properly since v6.01-3660


Yes, you are correct! Didn't notice the new version. Now if I can only get it to start with Windows like 6.00 did, I'd be all set.


----------



## Mumak

RichKnecht said:


> Yes, you are correct! Didn't notice the new version. Now if I can only get it to start with Windows like 6.00 did, I'd be all set.


Just copy the files from Beta package to where your 6.00 is installed (default "C:\Program Files\HWiNFO64") and all should be well


----------



## ChucRupts

Rapidian said:


> @gupsterg, as I'm sure you know, CH7 has a different chipset (X470) than my board B450, but I thought they used the same SuperIO chip. Mine looks like this.
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> View attachment 245898
> 
> 
> 
> 
> This problem is intermittent. It does not always occur. I've had it happen maybe 3-4 times. Once was actually when I ran the Asus Aisuite to "configure" which tests the fans. All stopped and never started backup. It was then I decided to not use *any* Asus software. Aura is buggy as well (had a ~7% cpu load at all times) and screwed up my initial CineBench scoring.
> 
> I'm not clear that the Asus B450-I contains the correct fix in HWiNFO64 yet. I'm doing as @Mumak said; disabling the IT8665E section. I'm also disabling the ASUS EC as HWiINFO64 advised. However, that sofware is the only thing which actually monitors my fans in Windows 10. I've no idea what the speed is except by "sound".
> 
> All I can do is try, play some games and see if this problem occurs again. I'm interested in whether I should explore other fan controllers. I really do want the Mobo to support this. I've opened an issue with Asus but support has not been helpful with useful solutions. Reading had got me onto this software and that chip as a plausible cause to the problem.
> 
> Open to suggestion. Thanks for writing back. BTW, what is that software you have which displays the RAM voltage? I'm curious to check in the OS what I have set.


I have my system about two weeks and until then I had no problems. After installing some JAVA applications yesterday, I started to have this same problem as you. Can you tell me if the problem was solved by disabling the IT8665E section?
I'll try today to see if it solves the problem here.

sorry for my bad english.

System:
- Asus ROG B450-I Gaming motherboard
- AMD 2700X processor
- Corsair Vengeance LPX 16GB 3200MHz C16 memory kit
- Wraith Prism Cooler
- NZXT h200 standard fans
-Nvidia Gigabyte GTX 1060 G1 Gaming 6Gb
- Corsair CX 500 power supply
- Bios 1201


----------



## ThrashZone

Hi,
There's been quite a bit of chatter about tj max being increased on skylake-x and 5-10c higher temp reading because of it 
Micro code 49 from 50 seems to reset the tj max back to 105c from 110c there for dropping temps that much and back to normal 
https://rog.asus.com/forum/showthread.php?107841-Rog-rampage-vi-extreme-omega/page26#post761644

Question why would hwinfo go by tj max or is it and not by actual temps 
I get sensors are what you read just trying to understand why temps rise with tj max since it's just a max not an actual temp.


----------



## deepor

ThrashZone said:


> Hi,
> There's been quite a bit of chatter about tj max being increased on skylake-x and 5-10c higher temp reading because of it
> Micro code 49 from 50 seems to reset the tj max back to 105c from 110c there for dropping temps that much and back to normal
> https://rog.asus.com/forum/showthread.php?107841-Rog-rampage-vi-extreme-omega/page26#post761644
> 
> Question why would hwinfo go by tj max or is it and not by actual temps
> I get sensors are what you read just trying to understand why temps rise with tj max since it's just a max not an actual temp.



The numbers you can read out of the CPU are the distance to TjMax. For example, you don't get a sensor reading like "35" if the core is at 35°C, instead you get a reading "70". Your program then has to know that the CPU's TjMax is 105°C, and then it can calculate "105-70=35" to get to 35°C.

Here's a link to the documentation for the Intel CPU temperature sensor driver in the Linux kernel:

https://www.kernel.org/doc/Documentation/hwmon/coretemp

There's this sentence in there trying to explain this:

"Temperature is measured in degrees Celsius and measurement resolution is 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because *the actual value of temperature register is in fact a delta from TjMax*."


----------



## ThrashZone

Hi,
One would hope temperatures would be a more straight forward reading process and would not go by tj max at all except for what it is a fail safe temp :/

I usually remove all the tj max listing personally.


----------



## Mumak

Tj,max is important for the CPU. It doesn't care much about how cold/hot it's running, just about the distance to the maximum temperature when engaging throttling is required.


----------



## ThrashZone

Hi,
Tj max to me is just a number I want to stay below by mostly 20c 
So I'm more interested in accuracy before that number.


----------



## fycum

@Mumak
Hi, my pc 6600k+z170a (not overlock) vr vcc is 86c, what is problem? are these values correct? more than 86c? can you help me?


----------



## Mumak

fycum said:


> @Mumak
> Hi, my pc 6600k+z170a (not overlock) vr vcc is 86c, what is problem? are these values correct? more than 86c? can you help me?


Yes, that should be correct. Check cooling of the voltage regulator.


----------



## fycum

im using thermaltake nic f4, how can I check it, All values except vr vcc seem normal, vr vcc value would be a problem for me?


----------



## fycum

Mumak said:


> Yes, that should be correct. Check cooling of the voltage regulator.


im using thermaltake nic f4, how can I check it, All values except vr vcc seem normal, vr vcc value would be a problem for me?


----------



## Mumak

fycum said:


> im using thermaltake nic f4, how can I check it, All values except vr vcc seem normal, vr vcc value would be a problem for me?


That's the CPU cooler I assume, voltage regulator is a different circuit on mainboard. 85 C for VR is quite OK, but I assume that's in idle. Check value under a few minutes of high load.


----------



## fycum

Mumak said:


> That's the CPU cooler I assume, voltage regulator is a different circuit on mainboard. 85 C for VR is quite OK, but I assume that's in idle. Check value under a few minutes of high load.


okey I just got it, I did a prime95 stress test for 5 minutes max vrm temp 91c. gaming test for 5 minutes max 86c.


----------



## fycum

@Mumak
hi, temp3 and temp4 do not change, always the same, what are these?


----------



## Mumak

Most probably invalid values from not connected generic sensor inputs.


----------



## fycum

Mumak said:


> Most probably invalid values from not connected generic sensor inputs.


thx for help. kind regards


----------



## Noah Rozov

Hello, Mumak!
I have some odd values on gpu memory clock since ver.5.84 and now in 6.02








Plus 6.02 added VR VCC Temperature (SVID) and it's kinda worrying me








I tried touching vrm heatsinks and it's literally nowhere near warm even, so is it showing false readings based on that?


----------



## Mumak

GPU Memory clock reported by HWiNFO is the true clock in MHz, while Afterburner reports the effective clock (4 times higher). 1312 * 4 = 5248 MHz.
VR VCC temperature is reported straight by the VRM, so it might be some issue with its thermal diode. If it's faulty and this value reaches a critical point, it might cause throttling due to issuing of VR thermal alert by the VRM.


----------



## Noah Rozov

Thank you for the explanation, Mumak! 
One last thing, how much trustworthy in theory can be tactile check? And in your experience, have you maybe gathered some average data on vrm temps of z170(a) chipset? It's just there weren't any vrm sensor info (on my mobo by default) and some HWiNFO versions back, so I'm kinda curious about how to act, sell the mobo or figure out some kolkhoz cooling


----------



## Mumak

Sorry, I don't have average data, but >80 C in idle is quite high. Reporting of this VRM temperature has been added only in later HWiNFO versions - it's read straight from the VRM.
I already had a few similar reports of too high VRM temperatures, then users measured VRM temperature using an infrared thermometer, but they were nowhere close to the value reported.


----------



## Timur Born

Is it possible to enable the "Average" column for thermal throttling/limiting measurements? I am aware that there is only Yes/No readings, but I would like to know if two of my cores and the ring average on No or Yes, as they keep switching on certain stress loads and TJmax settings. This would allow me to make better choices for voltages and temps.


----------



## Mumak

Timur Born said:


> Is it possible to enable the "Average" column for thermal throttling/limiting measurements? I am aware that there is only Yes/No readings, but I would like to know if two of my cores and the ring average on No or Yes, as they keep switching on certain stress loads and TJmax settings. This would allow me to make better choices for voltages and temps.


Average value would be a very inaccurate indicator here. Why not enable logging and then process the results? You can use the "LogViewer for HWiNFO" for example.


----------



## ThrashZone

Hi,
Last beta reads asus x299 tuf mark 2 cache/ mesh finally

Looking now at an older build 6.00-3620 atm on win-7
It shows
MC1-MC0 voltage (VCCP) looks like the cache/ mesh voltage at 2700MHz is reading 0.895v which is pretty similar to what the beta shows on win-10.

Only issue on the beta it was showing weird fluctuations with Bus clock and PCI-e clock both min 100.0 min and max 102... like cpu strap was not set to 100 or if memory BLCK was added or something :/
Someone else said the same thing about clock frequency changing 
https://www.overclock.net/forum/27905840-post2592.html


----------



## Mumak

Not sure on which CPU is that, but in case of Skylake-X there's a problem with measuring the correct BCLK, especially when the system is under high load.
Skylake Desktop/Mobile CPUs can report BCLK pretty accurately, but not the -X parts. There one needs to use certain measuring techniques, which are not very accurate.
If you want to avoid fluctuations on BCLK, disable the "Periodic polling" option in "CPU Clock Measurement" settings in HWiNFO.


----------



## ThrashZone

Hi,
I wear my system spec's on my sleeve/ signature so yes 7900x

Any comment on the first part 
These two entries are they mesh/ cache voltage where as the new beta names it mesh/ cache but only one listing for my board ?


> Looking now at an older build 6.00-3620 atm on win-7
> It shows
> MC1-MC0 voltage (VCCP) looks like the cache/ mesh voltage at 2700MHz is reading 0.895v which is pretty similar to what the beta shows on win-10.


My x299 prime deluxe I returned/ rma'ed never showed any voltage for mesh/ cache which I already reported a while back this mark 2 does :/

Thanks for the workaround on the polling I'll try that it's just weird and a new thing in the betas it's never done it before in prior hwinfo builds.


----------



## Mumak

ThrashZone said:


> Hi,
> I wear my system spec's on my sleeve/ signature so yes 7900x
> 
> Any comment on the first part
> These two entries are they mesh/ cache voltage where as the new beta names it mesh/ cache but only one listing for my board ?
> 
> 
> My x299 prime deluxe I returned/ rma'ed never showed any voltage for mesh/ cache which I already reported a while back this mark 2 does :/
> 
> Thanks for the workaround on the polling I'll try that it's just weird and a new thing in the betas it's never done it before in prior hwinfo builds.


MC0/1 is the Memory Controller voltage available only in later HWiNFO versions and only on SKX CPUs.


----------



## ThrashZone

Mumak said:


> MC0/1 is the Memory Controller voltage available only in later HWiNFO versions and only on SKX CPUs.


Hi,
Thank you like I said those two voltages never showed up on my other board only the new mark 2 showed them :/
That silly prime deluxe really was a piece of high dollar junk I'm glad I finally bit the bullet and returned it and saved 200.us.


----------



## Mumak

ThrashZone said:


> Hi,
> Thank you like I said those two voltages never showed up on my other board only the new mark 2 showed them :/
> That silly prime deluxe really was a piece of high dollar junk I'm glad I finally bit the bullet and returned it and saved 200.us.


Those values should be independent from mainboard model.


----------



## ThrashZone

Mumak said:


> Not sure on which CPU is that, but in case of Skylake-X there's a problem with measuring the correct BCLK, especially when the system is under high load.
> Skylake Desktop/Mobile CPUs can report BCLK pretty accurately, but not the -X parts. There one needs to use certain measuring techniques, which are not very accurate.
> *If you want to avoid fluctuations on BCLK, disable the "Periodic polling" option in "CPU Clock Measurement" settings in HWiNFO*.


Hi,
Sorry all I see is global polling :/


----------



## ssateneth

ThrashZone said:


> Hi,
> Sorry all I see is global polling :/


----------



## ssateneth

Do you need any data from ASUS ROG MAXIMUS XI APEX Z390 motherboard?


----------



## ThrashZone

Hi,
I run sensors only so the tabs are much different also use stand alone not installer version.

Okay got it popped setting on the sensors only page and boom :thumb:


----------



## Mumak

ssateneth said:


> Do you need any data from ASUS ROG MAXIMUS XI APEX Z390 motherboard?


Thanks for the offer, sure it might be useful.



ThrashZone said:


> Hi,
> I run sensors only so the tabs are much different also use stand alone not installer version.
> 
> Okay got it popped setting on the sensors only page and boom :thumb:


The Periodic Polling option is in the main settings of HWiNFO, which can be accessed right after start by pressing the Settings button. In case you're running in Sensors-only mode without showing the initial dialog, you can get there by right-clicking the HWiNFO icon in tray (notification area).


----------



## ssateneth

Here's a copy of system report and debug file. I don't see anything sticking out like a sore thumb, though I already did hide a lot of sensors that were not of interest (smart, c states, network traffic, perf limit reasons, etc)

https://mega.nz/#!N5QijC6L!EXk0qsKTNQV0jdAwc-Z_e5kbmmhflHJ_9wSiaoa7R50


----------



## Mumak

Thanks!


----------



## porschedrifter

Mumak said:


> That's a completely invalid value, will be removed in the next build.



So does anyone know if monitoring HDD temps and other smart data in taskbar prevents drives from spinning down and sleeping properly?


----------



## deepor

porschedrifter said:


> So does anyone know if monitoring HDD temps and other smart data in taskbar prevents drives from spinning down and sleeping properly?


I'm booted into Linux right now, and I just tried putting the drive into standby manually through the command line and then checking Smart data. The drive does not spin up again when I do that. It only started up again when I accessed some folder that's on that drive.

So I guess this means that what you want should work in theory. The question would just be what Windows decides to do about putting the drive into standby.


----------



## porschedrifter

Thanks much for investigating that.



deepor said:


> porschedrifter said:
> 
> 
> 
> So does anyone know if monitoring HDD temps and other smart data in taskbar prevents drives from spinning down and sleeping properly?
> 
> 
> 
> I'm booted into Linux right now, and I just tried putting the drive into standby manually through the command line and then checking Smart data. The drive does not spin up again when I do that. It only started up again when I accessed some folder that's on that drive.
> 
> So I guess this means that what you want should work in theory. The question would just be what Windows decides to do about putting the drive into standby.
Click to expand...


----------



## Mumak

porschedrifter said:


> So does anyone know if monitoring HDD temps and other smart data in taskbar prevents drives from spinning down and sleeping properly?


This depends on the drive, its firmware and probably also on driver.
Normally polling SMART/stats data should not wake the drive up, but I've seen some cases where this happened (might be due to a bug in firmware).


----------



## kz26

Anyone having issues with HWiNFO not detecting Nvidia GPU sensors? Running latest HWiNFO x64 6.06 and GTX 1070 with 430.64 drivers.


----------



## Mumak

kz26 said:


> Anyone having issues with HWiNFO not detecting Nvidia GPU sensors? Running latest HWiNFO x64 6.06 and GTX 1070 with 430.64 drivers.


Which exact sensors are not detected? Can you post a screenshot, HWiNFO Debug File ?


----------



## geronimo

I don't see CPU fan in HWinfo. Aida64 shows it normally. I don't know why. Any info/help?

BTW is it possible to use HWinfo or some special plugin for it, to be able to create screenshots in games cos this is the one option I miss after abandoning afterburner and Aida64 and using HWinfo+RTSS for overlay after I upgraded to vega 56. I also don't like the overlay from radeon drivers. It's bad, as is that ReLive IMO.

thanks.


----------



## Mumak

geronimo said:


> I don't see CPU fan in HWinfo. Aida64 shows it normally. I don't know why. Any info/help?
> 
> BTW is it possible to use HWinfo or some special plugin for it, to be able to create screenshots in games cos this is the one option I miss after abandoning afterburner and Aida64 and using HWinfo+RTSS for overlay after I upgraded to vega 56. I also don't like the overlay from radeon drivers. It's bad, as is that ReLive IMO.
> 
> thanks.


Which board is that, the ASRock Z68 Extreme4? If yes, this board has a special switch between CPU1/2 fan and HWiNFO cannot report both. The switching logic is done pretty stupid so that at one time only one fan can be read, hence full monitoring doesn't work reliably. If your CPU2 header is empty, try to connect the fan there instead of CPU1.
HWiNFO cannot create screenshots in games, this is beyond its scope.


----------



## Scotty99

Anyone know why my kraken all of a sudden looks like this in hwinfo?









Its greyed out and the numbers dont change over the course of a day.


----------



## ssateneth

Means that hwinfo lost access to the device and it's sensors. It happens on graphics cards too if you disable and enable it in device manager. Just restart hwinfo and it'll start working again.


----------



## Scotty99

ssateneth said:


> Means that hwinfo lost access to the device and it's sensors. It happens on graphics cards too if you disable and enable it in device manager. Just restart hwinfo and it'll start working again.


Just closed and reopened hwinfo and there is nothing listed under the kraken now lol. (print screen isnt working for some reason or id post another screen shot). I checked my kraken for an update but it says its up to date, /shrug.


----------



## JackCY

geronimo said:


> I don't see CPU fan in HWinfo. Aida64 shows it normally. I don't know why. Any info/help?
> 
> BTW is it possible to use HWinfo or some special plugin for it, to be able to create screenshots in games cos this is the one option I miss after abandoning afterburner and Aida64 and using HWinfo+RTSS for overlay after I upgraded to vega 56. I also don't like the overlay from radeon drivers. It's bad, as is that ReLive IMO.
> 
> thanks.


Screenshots? Just use ingame screenshot key or any other method (there are millions of programs that can take screenshots after they inject themselves into the game process). I run HWiNFO+RTSS with custom things shown in RTSS from HWiNFO.


----------



## Mumak

Try the latest HWiNFO Beta v6.07.


----------



## ThrashZone

Hi,
Have you noticed after opening hwinfo sensors only mouse pointer is alway taken to the X close and save position ?
That is really annoying because most the time when it does it I'm wanting to click on something else and of course hwinfo closes instead


----------



## Mumak

ThrashZone said:


> Hi,
> Have you noticed after opening hwinfo sensors only mouse pointer is alway taken to the X close and save position ?
> That is really annoying because most the time when it does it I'm wanting to click on something else and of course hwinfo closes instead


Sorry, but I cannot reproduce/observe this.
What settings do you use, just Sensor-only mode enabled?


----------



## ThrashZone

Mumak said:


> Sorry, but I cannot reproduce/observe this.
> What settings do you use, *just Sensor-only mode enabled*?


Hi,
Yes Windows 7 too
Had to go to control panel and mouse and uncheck snap mouse pointer to default position
Think window 10 is the same though I just don't use 10 near as much.


----------



## Mumak

ThrashZone said:


> Hi,
> Yes Windows 7 too
> Had to go to control panel and mouse and uncheck snap mouse pointer to default position
> Think window 10 is the same though I just don't use 10 near as much.


Then such behavior must have happened in several other applications, not just HWiNFO.


----------



## ThrashZone

Mumak said:


> Then such behavior must have happened in several other applications, not just HWiNFO.


Hi,
In an app/ program there is no default position really specified by the apps unless it has another settings option like hwinfo has a few including uac warning but that one is normal
This is only hwinfo for some reason, 

It's like hwinfo is a dialog box like the sensors only popup and sensors warning popup before sensors only main window finally appears but here the pointer is placed on the X save and close.

It's not happening anymore with the mouse option disabled but still a weird default pointer position


----------



## Hequaqua

@Mumak

Would it be possible to add a hotkey function to reset readings?


----------



## ThrashZone

ThrashZone said:


> Hi,
> In an app/ program there is no default position really specified by the apps unless it has another settings option like hwinfo has a few including uac warning but that one is normal
> This is only hwinfo for some reason,
> 
> It's like hwinfo is a dialog box like the sensors only popup and sensors warning popup before sensors only main window finally appears but here the pointer is placed on the X save and close.
> 
> It's not happening anymore with the mouse option disabled but still a weird default pointer position


Hi,
Lastly I also uncheck both updating options too 
Maybe this causes the issue skipping the last popup message :/


----------



## man from atlantis

since a few days ago HWinfo stopped showing some motherboard readings and they're vanished, vDIMM reading stuck at 0.24V and CPU fan rpm is out of touch. I though my motherboard's broken, but hwmonitor shows everything as it should be.

an old screenshot i found: https://abload.de/img/pboawesomeness37f30nbjoc.png

Atm: https://abload.de/img/brokenrijjm.png

I tried uninstal and, reinstall a new version but still the same.


----------



## Mumak

man from atlantis said:


> since a few days ago HWinfo stopped showing some motherboard readings and they're vanished, vDIMM reading stuck at 0.24V and CPU fan rpm is out of touch. I though my motherboard's broken, but hwmonitor shows everything as it should be.
> 
> an old screenshot i found: https://abload.de/img/pboawesomeness37f30nbjoc.png
> 
> Atm: https://abload.de/img/brokenrijjm.png
> 
> I tried uninstal and, reinstall a new version but still the same.


I can see that you have several sensor items hidden. Please check in the sensor settings/layout if there are perhaps some of those required hidden.
If that won't solve the problem, please attach the HWiNFO Debug File for analysis.


----------



## man from atlantis

Mumak said:


> I can see that you have several sensor items hidden. Please check in the sensor settings/layout if there are perhaps some of those required hidden.
> If that won't solve the problem, please attach the HWiNFO Debug File for analysis.


I've hidden some but not those.

here's the debug file
https://we.tl/t-F8JFcIXk7u


----------



## Mumak

man from atlantis said:


> I've hidden some but not those.
> 
> here's the debug file
> https://we.tl/t-F8JFcIXk7u


Thanks. This is a quite rate issue, which might be caused by a BIOS update or some other software causing some inconsistency in the SIO/LPC.
I'll add a workaround for this in the next HWiNFO build.


----------



## Dasboogieman

Hi @Mumak

Love you work.

I noticed the new VCC temperature readout feature.

Something funky seems to be happening because the readout is like 79-80C Idlefor my VRMs on the Z270-H with a 7700K in it. I know the VRM is not the best but I find it hard to believe it actually idles at 80C. I cannot locate any hotspots anywhere on the board, adding direct airflow from a 140mm fan doesn't drop the temperature. I even chilled the VRM heatsink with compressed air and it didn't drop below 80C. I forced the CPU in to power saving mode and it draws no more than 14W and the temperatures still don't drop. Peak load temperatures top out at 105C under Prime 95 115W CPU load.

This lead me to conclude that either the readout is not correct, some offsets are not being applied properly or the VRM is truly this **** (but I haven't found the offending MOSFET yet).

I've tested the VCC on the Z370 Taichi which works properly. My other Asrock Z370M-ITX AC does not support SVID so there was no readout possible.


----------



## man from atlantis

Mumak said:


> Thanks. This is a quite rate issue, which might be caused by a BIOS update or some other software causing some inconsistency in the SIO/LPC.
> I'll add a workaround for this in the next HWiNFO build.


I removed the cpu fan's header to repaste the cpu and after that HWinfo starts showing all the sensors back like it was.


----------



## Mumak

Dasboogieman said:


> Hi @Mumak
> 
> Love you work.
> 
> I noticed the new VCC temperature readout feature.
> 
> Something funky seems to be happening because the readout is like 79-80C Idlefor my VRMs on the Z270-H with a 7700K in it. I know the VRM is not the best but I find it hard to believe it actually idles at 80C. I cannot locate any hotspots anywhere on the board, adding direct airflow from a 140mm fan doesn't drop the temperature. I even chilled the VRM heatsink with compressed air and it didn't drop below 80C. I forced the CPU in to power saving mode and it draws no more than 14W and the temperatures still don't drop. Peak load temperatures top out at 105C under Prime 95 115W CPU load.
> 
> This lead me to conclude that either the readout is not correct, some offsets are not being applied properly or the VRM is truly this **** (but I haven't found the offending MOSFET yet).
> 
> I've tested the VCC on the Z370 Taichi which works properly. My other Asrock Z370M-ITX AC does not support SVID so there was no readout possible.


The VCC Temperature you see is reported straight by the VRM. I already had some reports of odd values seen here, unfortunately I can't do anything about this. Looks like some VRMs are not reporting valid temperatures, but not sure if this can affect operating conditions like triggering a VR Hot alert.


----------



## Gettz8488

Mumak said:


> Hi all,
> 
> I'm the author of HWiNFO/32/64 tools, which I noticed are quite successfully used here.
> I decided to create a thread on this forum to provide support for these tools, listen to your feedback, opinions and ideas.
> Feel free to ask/request/share thoughts about HWiNFO/32/64 here and I hope you enjoy using these tools.
> 
> 
> HWiNFO main site: https://www.hwinfo.com/
> Download HWiNFO: https://www.hwinfo.com/download.php
> HWiNFO forum: https://www.hwinfo.com/forum
> HWiNFO of facebook: https://www.facebook.com/HWiNFO64
> 
> Martin




Hello Mumak I’m a huge fan of your software and have been using it for years. Do you think it’s an option to add a Temperature reading that uses the same formula as Ryzen master? As it’s the most accurate according to Robert Hallock from AMD


Sent from my iPhone using Tapatalk Pro


----------



## Mumak

Gettz8488 said:


> Hello Mumak I’m a huge fan of your software and have been using it for years. Do you think it’s an option to add a Temperature reading that uses the same formula as Ryzen master? As it’s the most accurate according to Robert Hallock from AMD
> 
> 
> Sent from my iPhone using Tapatalk Pro


Just for the record, here the answer: https://www.overclock.net/forum/10-...700x-3800x-ryzen-9-3900x-57.html#post28077132


----------



## Hequaqua

Gettz8488 said:


> Hello Mumak I’m a huge fan of your software and have been using it for years. Do you think it’s an option to add a Temperature reading that uses the same formula as Ryzen master? As it’s the most accurate according to Robert Hallock from AMD
> 
> 
> Sent from my iPhone using Tapatalk Pro





Mumak said:


> Just for the record, here the answer: https://www.overclock.net/forum/10-...700x-3800x-ryzen-9-3900x-57.html#post28077132


Just my two cents here....but couldn't you add a offset in the customized settings?(I know there is one for multiplying and adding, but no subtraction.)

Also...anyway to add a hotkey that would clear readings? Sometimes I want to clear them out when in the middle of a benchmark(3Dmark in particular), if you try to clear it while it's running it stops the testing. Other benchmarks, like Valley/Heaven, it doesn't kill the benchmark, just minimizes it.

Just a couple of thoughts.


----------



## Mumak

Hequaqua said:


> Just my two cents here....but couldn't you add a offset in the customized settings?(I know there is one for multiplying and adding, but no subtraction.)


Why not use a negative number as "add" to subtract an offset?


----------



## Hequaqua

Mumak said:


> Why not use a negative number as "add" to subtract an offset?


I thought I tried that.....but I guess I didn't hit the "set" button. Temp on my 3700X is now reading -11°C 

My temps read correctly....but thanks for the info.

What about a reset hotkey though?


----------



## Zfast4y0u

@Mumak

hey, i was wondering do you know whats causing my hw info monitoring window to return to its default window size each time i open it, after i restart pc??

http://prntscr.com/oq82y1

size i prefer:

http://prntscr.com/oq836z


i noticed, if i turn hw info off, and run registry backup of my settings, and turn program ON, it shows my desired window size, but its messed up after almost every restart, like in 80% of cases it returns to default small window size. im having this issue for months and cant figure out whats causing it.


----------



## Hequaqua

Zfast4y0u said:


> @Mumak
> 
> hey, i was wondering do you know whats causing my hw info monitoring window to return to its default window size each time i open it, after i restart pc??
> 
> http://prntscr.com/oq82y1
> 
> size i prefer:
> 
> http://prntscr.com/oq836z
> 
> 
> i noticed, if i turn hw info off, and run registry backup of my settings, and turn program ON, it shows my desired window size, but its messed up after almost every restart, like in 80% of cases it returns to default small window size. im having this issue for months and cant figure out whats causing it.


Try making it the size you want, then close it and re-open it. 

Any changes you make, after you make them, close the program, then open it back up. I know when I change a name on a value, and don't close it, then restart it, it goes back to the previous name.


----------



## Dbsjej56464

@Mumak


On the last few builds of HWINFO64 I've noticed that ASUS WMI will just randomly freeze and not change. The only way to fix it, is to reinstall hwinfo. Do you know why this might be happening? It's annoying because I have to clear all the reg files each time and I loose my configs.


Thanks


----------



## Hequaqua

Sideways2k said:


> @Mumak
> 
> 
> On the last few builds of HWINFO64 I've noticed that ASUS WMI will just randomly freeze and not change. The only way to fix it, is to reinstall hwinfo. Do you know why this might be happening? It's annoying because I have to clear all the reg files each time and I loose my configs.
> 
> 
> Thanks


You can save your settings by choosing back up on the settings tab when you first open it. I don't install it, I just run the exe. Updating to the next version will keep my settings as well. I do back them up though, because I hate having to go back through all the settings and pick and choose what I want shown. I also color code some entries, I use dual monitors and I like that I can just glance and pick out temp or whatever really quickly. ASUS WMI has always been a bit flaky iirc.


----------



## Zfast4y0u

Hequaqua said:


> Try making it the size you want, then close it and re-open it.
> 
> Any changes you make, after you make them, close the program, then open it back up. I know when I change a name on a value, and don't close it, then restart it, it goes back to the previous name.


i did that, 100x till now, and it just refuses to remember it -.-


----------



## Hequaqua

Zfast4y0u said:


> i did that, 100x till now, and it just refuses to remember it -.-


IDK man.....odd.


----------



## The Sandman

Zfast4y0u said:


> i did that, 100x till now, and it just refuses to remember it -.-


You are clicking the big X in the lower right hand corner "Save Settings and Close" and not closing by the usual method in upper right correct?


----------



## Mumak

Sideways2k said:


> @Mumak
> 
> 
> On the last few builds of HWINFO64 I've noticed that ASUS WMI will just randomly freeze and not change. The only way to fix it, is to reinstall hwinfo. Do you know why this might be happening? It's annoying because I have to clear all the reg files each time and I loose my configs.
> 
> 
> Thanks


Can you please describe the problem more precisely? ASUS WMI is in the hands of BIOS, but if that would be causing hangs then HWiNFO re-install won't help. So I'm not sure whether this isn't a different issue.


----------



## Zfast4y0u

The Sandman said:


> You are clicking the big X in the lower right hand corner "Save Settings and Close" and not closing by the usual method in upper right correct?


i have set it up to minimize when i click on top X, i did try bottom X, save and close, however issue is still there.


----------



## Krisztias

Dear @Mumak,

I love your software, it helping me a lot by overclocking!
Yesterday I have built my new system with Crosshair VIII Hero Wi-Fi and 3800x. After Windows 10 1903 reinstall installed HWiNFO64 6.10 and had a warning about ASUS WMI sensor. Then opened the Program and seen nothing, but the CPU core clocks+VID, memory clocks and timings. With or without the WMI enabled. I mean, I see everything on the left panel, but literally nothing on right panel: no CPU, VGA, HDD's... nothing. I have BIOS 0803.
Do you have an idea, what causing this?
Thank you.

Regards


----------



## Mumak

Krisztias said:


> Dear @Mumak,
> 
> I love your software, it helping me a lot by overclocking!
> Yesterday I have built my new system with Crosshair VIII Hero Wi-Fi and 3800x. After Windows 10 1903 reinstall installed HWiNFO64 6.10 and had a warning about ASUS WMI sensor. Then opened the Program and seen nothing, but the CPU core clocks+VID, memory clocks and timings. With or without the WMI enabled. I mean, I see everything on the left panel, but literally nothing on right panel: no CPU, VGA, HDD's... nothing. I have BIOS 0803.
> Do you have an idea, what causing this?
> Thank you.
> 
> Regards


Please attach a screenshot so I can see exactly how it appears.


----------



## Krisztias

Mumak said:


> Please attach a screenshot so I can see exactly how it appears.


I'm sorry, it was my mistake, I figured out what the problem was and solved it.  It functioning properly now, thank you for yout response!


----------



## yamaci17

Hey folks, is it possible to monitor VCCIO and VCCSA voltages for B360 Asus Prime and H310 Asus Prime boards? 

I really want to learn if my XMP profile shoots this voltage up or not. Sadly Hwinfo doesn't show these voltages, and BIOS neither.


----------



## Mumak

No, such low-end boards are not capable of measuring advanced values like VCCIO and VCCSA.


----------



## yamaci17

Then are they at default? If they can't measure it, how can they adjust that value?


----------



## Mumak

yamaci17 said:


> Then are they at default? If they can't measure it, how can they adjust that value?


They can be set using various methods, but don't feature sensors that would monitor the actual values.


----------



## yamaci17

Thank you a lot friend, one more question, what do these voltages mean? Can they be interpereted to something or are they just randomly generated?

Especially those VINxx voltages, do they carry a meaning? What is the meaning of VTT voltage?


----------



## Mumak

Those are vales taken from generic sensor inputs that are most probably not connected on your mainboard, so the vales are not valid (floating).


----------



## ThrashZone

Hi,
VTT is sometimes referred to as vccio but the reading is always slightly different but pretty close probably a coincidence


----------



## yamaci17

Yeah, I found a setting called "CPU System Agent" in my BIOS. I set it to 1.15 (maximum allowed by the board i guess). And VTT changed to 1.15 as well. I really hoped for it to be VCCIO.

At least we have VCCSA in our hands. My only hope is VCCIO is also max limited by the board. Nothing I can do more.


----------



## gupsterg

Hi Martin,

Just checking in, to share I can see higher CCD1 temp than usual tCTL/tDIE, not highlighting as issue, but an observation. 



Spoiler












Full WMV in this ZIP, it's flicks up at times.



Thanks for new sensor  .


----------



## Mumak

gupsterg said:


> Hi Martin,
> 
> Just checking in, to share I can see higher CCD1 temp than usual tCTL/tDIE, not highlighting as issue, but an observation.
> 
> 
> 
> Spoiler
> 
> 
> 
> 
> View attachment 293370
> 
> 
> Full WMV in this ZIP, it's flicks up at times.
> 
> 
> 
> Thanks for new sensor  .


Thanks for the feedback gup. We're still not sure what exactly Tctl represents, still waiting on feedback from AMD...


----------



## gupsterg

Mumak said:


> Thanks for the feedback gup. We're still not sure what exactly Tctl represents, still waiting on feedback from AMD...


NP, program as always just goes strength to strength, thank you :thumb: .

I see UCLK on TR1 as well  .



Spoiler














RM is pants on TR1 IMO.



Spoiler














Only way to even see decent amount of timings is RTC.



Spoiler


----------



## jamexman

Today AMD has released a preview of their new SDK, to help other monitoring apps (like yours) to better monitor Ryzen.

https://community.amd.com/community...ios-updates-for-boost-and-idle-plus-a-new-sdk

Have you had a chance to take a look? Hopefully this will help monitoring apps other than Ryzen master to better monitor these new CPU's!

Edit: Welp not really a preview of the SDK per se, but in the new version of Ryzen Master. They promise to release the full on SDK on 09/30, here is to hope!


----------



## parallelparadox

I have a quick question. HWinfo shows me that my ram is running at 3733MHz Cas 16 but in the BIOS it is set to 3733MHZ Cas 15? 

Have a Gigabyte Aorus X470 Gaming Mobo and Ballistic Sport 3000MHZ C15 Edie kit. CPU is 3700X.


----------



## Mumak

parallelparadox said:


> I have a quick question. HWinfo shows me that my ram is running at 3733MHz Cas 16 but in the BIOS it is set to 3733MHZ Cas 15?
> 
> Have a Gigabyte Aorus X470 Gaming Mobo and Ballistic Sport 3000MHZ C15 Edie kit. CPU is 3700X.


You might double-check with some other tool like CPU-Z, but my gut feeling is that HWiNFO is correct here.


----------



## Streetdragon

Its correct. 
GearDownMode wont allow uneaven Numbers for CAS. 15 -> 16 17->18 etc


----------



## parallelparadox

Yup, this now makes sense. Gear Down mode is active. Tried to push to Cash 14 but too many errors.


----------



## parallelparadox

Ok managed to get to 3600Mhz C14. This true latency is much better than 3733Mhz C16, yet when using Ryzen DRAM calc to do a latency test, i get 67ns for the 3733 C16 and 70ns for the 3600Mhz C14. Doesnt make any sense at all. The 3600Mhz is clearly faster at C14.


Can someone please shed some light?
Thanks


----------



## Barefooter

I just recently updated my HWiNFO from version 6.12 to 6.14 with the installer. Now I'm missing one of the two sensors I keep in my System Tray. I have both "GPU Temperature" readings there.

Now it appears that HWiNFO is only seeing GPU #1 and is at least not seeing the temperature of GPU #0.

Any ideas?


----------



## Mumak

Barefooter said:


> I just recently updated my HWiNFO from version 6.12 to 6.14 with the installer. Now I'm missing one of the two sensors I keep in my System Tray. I have both "GPU Temperature" readings there.
> 
> Now it appears that HWiNFO is only seeing GPU #1 and is at least not seeing the temperature of GPU #0.
> 
> Any ideas?


Looks like some mess in order of sensor items. Try to do a "Restore Original Order" from sensor settings/layout.


----------



## thomasck

Hi guys, all good?

One question, is there a way to save my current sheme? Like, colours, bold, italic, positioning of the rows and the ones I hided, etc? So in case of formating the pc I could just save and then load after installation?


----------



## Hequaqua

thomasck said:


> Hi guys, all good?
> 
> One question, is there a way to save my current sheme? Like, colours, bold, italic, positioning of the rows and the ones I hided, etc? So in case of formating the pc I could just save and then load after installation?


I think when you open the program, click on settings, then in there look for "Back-up User Settings". It will make a register file. When and if you need it you just open it, and it will add it to the registry. You should be good to go unless you change some hardware or something. BTW, I save my back-ups in a couple of spots just in case I delete them...lol


----------



## thomasck

Hequaqua said:


> I think when you open the program, click on settings, then in there look for "Back-up User Settings". It will make a register file. When and if you need it you just open it, and it will add it to the registry. You should be good to go unless you change some hardware or something. BTW, I save my back-ups in a couple of spots just in case I delete them...lol


Okay! Thanks. The reason I never found out is cause one of the settings seems to be kept upon format, "auto start", and that is the reason I'm not able to reach the settings option, when I execute HWiNFO it goes straight to the sensors. Any idea?


----------



## Hequaqua

thomasck said:


> Okay! Thanks. The reason I never found out is cause one of the settings seems to be kept upon format, "auto start", and that is the reason I'm not able to reach the settings option, when I execute HWiNFO it goes straight to the sensors. Any idea?


Try the portable version....it doesn't install anything. 

After you open it and have your layout like you like it back it up. I don't install it. I just keep the portable version and when I open it, I right click on it and pin it to my task bar.

You also may try the task manager in the start-up section. If it's listed there, disable it...or you can kill it if it auto starts, find it on your computer and run the exe from the folder and see if it will open where you can get into the sensors/settings page.


----------



## thomasck

Hequaqua said:


> Try the portable version....it doesn't install anything.
> 
> After you open it and have your layout like you like it back it up. I don't install it. I just keep the portable version and when I open it, I right click on it and pin it to my task bar.
> 
> You also may try the task manager in the start-up section. If it's listed there, disable it...or you can kill it if it auto starts, find it on your computer and run the exe from the folder and see if it will open where you can get into the sensors/settings page.


That's the version I always used, portable. I don't really remember turning the option auto-start on after formatting the pc, but the only solution was editing the file HWiNFO64.INI, which was harder to remember that it is in the folder there than editing it. 

Thanks for you trying to help


----------



## Hequaqua

thomasck said:


> That's the version I always used, portable. I don't really remember turning the option auto-start on after formatting the pc, but the only solution was editing the file HWiNFO64.INI, which was harder to remember that it is in the folder there than editing it.
> 
> Thanks for you trying to help


No problem....so you got it saved? That's the important thing....I hate taking the time to set it up...then I goof it somehow...lol


----------



## Mumak

Auto start of HWiNFO is managed via Windows Task Scheduler, you can adjust it there too.


----------



## Streetdragon

could it be, that the new version reads a higher SOC power consumption Watt than the older beta? Like 2-3Watt more?


----------



## Mumak

Streetdragon said:


> could it be, that the new version reads a higher SOC power consumption Watt than the older beta? Like 2-3Watt more?


Yes, there has been an adjustment for SVI2 TFN reporting: https://www.hwinfo.com/forum/threads/hwinfo-v6-20-released.6064/post-23033


----------



## l Nuke l

what is the 3v rail labelled as?


----------



## ThrashZone

Hi,
PSU rails
+3.3v
+5v
+12v


----------



## Mumak

+3.3V is usually labelled as +3.3V, alternatively 3VSB or VCC. Exact layout depends on mainboard/sensor chip used.


----------



## l Nuke l

Mumak said:


> +3.3V is usually labelled as +3.3V, alternatively 3VSB or VCC. Exact layout depends on mainboard/sensor chip used.


I have both 3vsb and 3vcc which would be the most accurate one? I am thinking its 3vcc as that reads closest to my DMM reading of 3.314v..here is a screenshot.


----------



## Mumak

3VSB is the Stand-by voltage.


----------



## cssorkinman

Hello, 

I sure appreciate having hwinfo- great tool for this hobby. 

Running windows 10 64 bit on a new build for my son and this error popped up - is there a quick easy solution to this one?

Thank you


----------



## Mumak

Do you maybe have the ThermalTake software running? If yes, try to start HWiNFO before it launches.


----------



## cssorkinman

Mumak said:


> Do you maybe have the ThermalTake software running? If yes, try to start HWiNFO before it launches.


You are amazing - That is exactly what the problem was .

Thank you very much!


----------



## cbjaust

@Mumak using the latest beta 6.21-4050 and 6.21-4040 and the last stable 6.20 HWiNFO stops working after a few tens of seconds and when forcibly quit and restarted it hangs on detection of CPU 11 every time.
Hardware: Crosshair VI Hero BIOS 7704, Ryzen 5 3600X
Software: Windows 7 x64


----------



## Mumak

cbjaust said:


> @Mumak using the latest beta 6.21-4050 and 6.21-4040 and the last stable 6.20 HWiNFO stops working after a few tens of seconds and when forcibly quit and restarted it hangs on detection of CPU 11 every time.
> Hardware: Crosshair VI Hero BIOS 7704, Ryzen 5 3600X
> Software: Windows 7 x64


I suspect this might be a BIOS issue, but please attach the HWiNFO Debug File for analysis.


----------



## cbjaust

@Mumak I restarted HWiFO after it stopped working and recorded teh DEBUG file attached. It hangs detecting CPU11. Also CPU-Z loses the ability to report the memory SPD info while HWiNFO is in the hung state.


----------



## Mumak

cbjaust said:


> @Mumak I restarted HWiFO after it stopped working and recorded teh DEBUG file attached. It hangs detecting CPU11. Also CPU-Z loses the ability to report the memory SPD info while HWiNFO is in the hung state.


This is just another bug in ASUS BIOS. Try to upgrade it to the latest version.


----------



## ugotd8

Hi, first off, great program and thank you. Quick general question. When uncluttering the layout by Hiding items is there any benefit to disabling monitoring first and then hide or just hide the items?


----------



## Mumak

ugotd8 said:


> Hi, first off, great program and thank you. Quick general question. When uncluttering the layout by Hiding items is there any benefit to disabling monitoring first and then hide or just hide the items?


No benefit as hiding an item automatically disables monitoring too.


----------



## Timur Born

Regarding the sensors in Corsair HXi power-supplies:

Among several others HWiNFO lists "PSU Power" and "PSU Power (Sum)", with the latter reading slightly higher values than the former. What is the difference between the two?

Corsair's own iCUE software needs its own Windows service to read measurements, but then it reports "Power IN", which is absent from HWiNFO?!

At 50 - 55 W input power (measured at the wall) the "Power OUT" spikes in iCUE are *considerably* higher than in HWiNFO, even when I set HWiNFO's update rate to 100 ms. I just saw 72 W in iCUE, but only 56 W (max) in HWiNFO. Overall HWiNFO's reading tend to be lower in lower wattage ranges.

The same applies to "Efficiency" where HWinFO tends to stay below 80% (especially average), while iCUE hardly ever drops below 80% at all.

I don't know which of these "measurements" are derived from readings and which are real output from the digital measuring module inside the power-supply?! As such I don't know wich measurement to trust?!


----------



## Mumak

Timur Born said:


> Regarding the sensors in Corsair HXi power-supplies:
> 
> Among several others HWiNFO lists "PSU Power" and "PSU Power (Sum)", with the latter reading slightly higher values than the former. What is the difference between the two?
> 
> Corsair's own iCUE software needs its own Windows service to read measurements, but then it reports "Power IN", which is absent from HWiNFO?!
> 
> At 50 - 55 W input power (measured at the wall) the "Power OUT" spikes in iCUE are *considerably* higher than in HWiNFO, even when I set HWiNFO's update rate to 100 ms. I just saw 72 W in iCUE, but only 56 W (max) in HWiNFO. Overall HWiNFO's reading tend to be lower in lower wattage ranges.
> 
> The same applies to "Efficiency" where HWinFO tends to stay below 80% (especially average), while iCUE hardly ever drops below 80% at all.
> 
> I don't know which of these "measurements" are derived from readings and which are real output from the digital measuring module inside the power-supply?! As such I don't know wich measurement to trust?!


Well, Power calculations for Corsair are not accurate. The device seems to be capable of measuring only one power (either In or Out) depending on the PSU model. The other value is then calculated using an (estimation) formula. This is by design and since Corsair doesn't provide any information nor cooperate at all (unlike most other vendors), I cannot do more here. The fact that you see different numbers between HWiNFO and iCUE could mean that they changed the formula. But since I don't like their attitude towards developers or users I have given up here. And that's not just me, but other tool developers too.
The "PSU Power (Sum)" is the sum of powers of all rails, while the "PSU Power" is the total power as reported by a dedicated register in the PSU. Which one is more accurate - one can only guess due to the above...


----------



## Timur Born

I understand, thanks for the information. What about the "efficiency" reading in HWiNFO, is that based on a measurement or just likely some formula based on the current load state? In iCUE Power In x Efficiency = Power OUT (or maybe Power IN / Efficiency = Power OUT). Compared to my wall measurements (+-1% +1 W average tolerance) I'd say that the "(Sum)" is closer at least.

As mentioned before: While HWinfo can poll the PSU on its own Corsair's iCUE needs the a special Corsair service to run. Said service does not cause high CPU load (below 1% average), but it still measures as one of the highest average CPU loads of all "idle" services on my system.

There is another drawback: Every time the Corsair service polls the PSU my mainboard's (GB Aorus Master) VRM section creates a specific noise pattern. This does not happen when HWiNFO polls the PSU, even at faster rates than 1/s.


----------



## Mumak

Timur Born said:


> What about the "efficiency" reading in HWiNFO, is that based on a measurement or just likely some formula based on the current load state? In iCUE Power In x Efficiency = Power OUT (or maybe Power IN / Efficiency = Power OUT). Compared to my wall measurements (+-1% +1 W average tolerance) I'd say that the "(Sum)" is closer at least.


Efficiency is just a simple result of: PowerOut / PowerIn * 100 [%].
So if the formula for calculating one of the power values is different, Efficiency will be as well.



Timur Born said:


> There is another drawback: Every time the Corsair service polls the PSU my mainboard's (GB Aorus Master) VRM section creates a specific noise pattern. This does not happen when HWiNFO polls the PSU, even at faster rates than 1/s.


This is an interesting observation I wasn't aware of. Probably just another proof of the 'quality' of Corsair software...

There were guys (i.e. the author of SIV) who spent a great amount of time with Corsair stuff trying to figure out how it works and even giving Corsair suggestions how to improve things. But this wasn't neither accepted nor appreciated at all.


----------



## Timur Born

Mumak said:


> Efficiency is just a simple result of: PowerOut / PowerIn * 100 [%].
> So if the formula for calculating one of the power values is different, Efficiency will be as well.


Well, I would have hoped that two of these three variables were known/measured. If only one is measured, one is derived from an algorithm and the third is then calculated then the measurement is not fully useful.



> This is an interesting observation I wasn't aware of. Probably just another proof of the 'quality' of Corsair software...


To be fair, the VRM noise is a result of polling the USB interrupt endpoint in a burst. It's mostly based on C-state / current changes in the VRM and as such only one of many noises.

Turns out that HWiNFO's USB polling also creates its own noise signature, but higher in frequency and more easily masked by other noise. I really wish modern mainboards were less noisy, especially because that noise carries over ground lines to (professional) audio equipment via protective ground (PG) loop.

Curiously my current noise vs. PSU vs. CPU current measurement also finally pointed me to what I always found odd/wrong about HWiNFO's polling rate. In short: I always noticed that polling rates below 1000 ms were longer than what was set in preferences (minimum 100 ms). During USB polling noise tests I noticed that I get one high pitched noise every 5 seconds, similar in tone to HFiNFO's USB polling noise. Then I noticed that whenever this occurs HWiNFO flickers quicker with faster polling rates, which I always kind of noticed, but never looked closer.

While I do not know what is especially happening on my system every 5 seconds I did notice that I can increase HWiNFO's *real* polling rate by decreasing the Windows timer resolution via TimerTool. The lower I set it (minimum 0.5 ms) the faster the polling and the less the 5s interval matters.

Things are a bit more complicated, though, because I noticed that setting 5 ms via TimerTool results in a faster HWiNFO polling rate than just measuring 5 ms being set by Firefox when a Youtube video is started (used to be 1 ms in the past, but they "fixed" it after my report to keep laptops from draining their batteries).

https://github.com/tebjan/TimerTool/blob/master/README.md



> There were guys (i.e. the author of SIV) who spent a great amount of time with Corsair stuff trying to figure out how it works and even giving Corsair suggestions how to improve things. But this wasn't neither accepted nor appreciated at all.


Like HWiNFO I find SIV to be a great tool. I just used it to determine that the Corsair USB 2 endpoint is using interrupt mode.

Did you try to reach Johnny Guru directly (if he still is with Corsair's PSU division)? Or maybe reach out to Channel Well Technology, the real producer of least the HX750i (that I am currently testing)?


----------



## Mumak

Isn't that 5 second noise related to disk SMART polling in case you have a different rate set for it?
If the real polling rate of HWiNFO is significantly longer than the rate set, enable the "Profiling Time" column and check whether some sensor isn't taking too long to read. If there's a sensor taking excessive time (100s of ms), disabling it should improve the rate.


----------



## Timur Born

I use to set SMART to 1000 cycles, the 5 seconds also happen when Hwinfo is not running. So something else in my system is active every 5 seconds.

The "Profiling Time" column reads 0 for most entries, some headlines show higher values even when every sub-entry is 0. CPU xyz: Enhanced is one such headline that shows 1 ms, but all sub-entries show 0. Likely a rounding thing.

Sometimes the GB sensor IR35201 increases to 149 ms, with VR Loop 1 at 117 ms and IIN and IOUT in the two digit range. This happens about every 8 seconds. Changing the Windows timer resolution to 0.5 ms increases the time from 8 seconds to about 38 seconds. I think this is connected to polling cycle, C-states and power profiles. Dimm0 temp occasionally acts up, 1-3 seem to stay at 0, likely based on the same source. These things only every few seconds, though, while HWinfo keeps polling too slow.

GPU headline is 7-10 ms, with GPU load at 3-5 ms and everything else at 0. The Intel PCH and two other GB sensors show 1 in the headline and 0 in the sub-entries. The NVidia driver currently is set to maximum performance (no downclocking for power-saving), so it will not get any faster than that.

And changing the Windows timer resolution does not change the normal "Profiling Time" measurements, but HWiNFO still increases its polling towards what was really set in its preferences.

I also tried HPET on/off in Hwinfo's settings, but it made no difference. Does this really specifically use the HPET or does it use QPC (in my case invariant TRC at 10 MHz)? What does HWinfo use when HPET is disabled?


----------



## Timur Born

Disabling all C-states does not increase HWinfo's polling rate ("Disable Idle" in power profile, which also disabled C1 non E). On the other hand, changing the Windows timer resolution even works when the power saver profile is used at a measly x8 idle CPU multiplier.


----------



## Mumak

HWiNFO uses HPET only in some cases to measure the BCLK, but in your case (on Intel Skylake and later CPUs) it's not used at all.


----------



## Timur Born

I disabled monitoring off everything except the CPU entries, same result. HWiNFO refreshes slower than what I set in preferences except for a short burst every 5 seconds. Once I change the Windows timer resolution via TimerTool it works properly. The tighter the timer resolution (lower value in ms) the faster HWiNFO's refresh rate.


----------



## Timur Born

The short 5 second burst (and corresponding noise) was based on the Apple iCloud service running (as part of the Photo service). Hwinfo still does not refresh as fast as set in preferences unless I mess with the Windows timer.


----------



## sdmf74

Is there a guide or instructions on how to use the multiple column feature? I just figured out how to open multiple colums finally lol but Im wondering if there are more options


----------



## Mooncheese

Hi all, I had to reinstall Hwinfo64 because I upgraded the GPU and it the existing instance of it wasn't detecting the new GPU. Anyhow, I did go out of my way to export the user settings "Hwinfo64_settings.reg" with the hopes that I could simply import them to the updated version. Alas executing his .reg file didn't re-order all of the various data entries and now I'm looking at spending an hour in Hwinfo64 layout to remove data lines that I feel are not necessary. 

Is there a different way to import the previous config and is what I'm trying to do even possible? 

Thanks in advance.


----------



## Mumak

Mooncheese said:


> Hi all, I had to reinstall Hwinfo64 because I upgraded the GPU and it the existing instance of it wasn't detecting the new GPU. Anyhow, I did go out of my way to export the user settings "Hwinfo64_settings.reg" with the hopes that I could simply import them to the updated version. Alas executing his .reg file didn't re-order all of the various data entries and now I'm looking at spending an hour in Hwinfo64 layout to remove data lines that I feel are not necessary.
> 
> Is there a different way to import the previous config and is what I'm trying to do even possible?
> 
> Thanks in advance.


No, this is the only way to export/import settings. Sensor settings are tied to actual hardware, so if you change it, they might not apply to the new one. Reinstalling HWiNFO should not be needed. Simplest way is to check in sensor settings whether there aren't values hidden, sometimes it might be required to completely reset settings.


----------



## Barefooter

sdmf74 said:


> Is there a guide or instructions on how to use the multiple column feature? I just figured out how to open multiple colums finally lol but Im wondering if there are more options


As far as I know you have to select the sensors you want from the first column and drag them to the second column.


----------



## kmetek

hey mumak

does you program offer core temps readings with

msi b450 tomahawk max and ryzen 5 2600 proc?


----------



## Mumak

kmetek said:


> hey mumak
> 
> does you program offer core temps readings with
> 
> msi b450 tomahawk max and ryzen 5 2600 proc?


Per-core temperature reporting is not (officially) supported on AMD processors.


----------



## Dr. Vodka

Hi Mumak, 

I have a reference R9 290. It's a Sapphire Tri-X, flashed with The Stilt's MLU modded BIOS, further tweaked to my liking with Hawaii BIOS reader. The BIOS was then edited to change the 290X's device ID (67B0) so it has the 290's instead (67B1), otherwise the card won't POST on my C6H. This way I've prepared a power saving BIOS (700/1200 0.9v) and a performance BIOS (1100/1375 1.3v). Currently running w10 1909 (18363.720) and 20.2.2 and the power saving BIOS.

For some time now, hwinfo detects the card as having a PLX chip, water pump sensor and memory sensors for temperature... The reference Hawaii board doesn't have any of these. Otherwise, it lets me monitor the card just fine.

Taken with hwinfo 6.22:










Card is currently running [email protected], as shown in the readouts. I was wondering if this sensor misreading is up to the modified BIOS I'm running that's fooling hwinfo? What do you think?


----------



## Mumak

Dr. Vodka said:


> Hi Mumak,
> 
> I have a reference R9 290. It's a Sapphire Tri-X, flashed with The Stilt's MLU modded BIOS, further tweaked to my liking with Hawaii BIOS reader. The BIOS was then edited to change the 290X's device ID (67B0) so it has the 290's instead (67B1), otherwise the card won't POST on my C6H. This way I've prepared a power saving BIOS (700/1200 0.9v) and a performance BIOS (1100/1375 1.3v). Currently running w10 1909 (18363.720) and 20.2.2 and the power saving BIOS.
> 
> For some time now, hwinfo detects the card as having a PLX chip, water pump sensor and memory sensors for temperature... The reference Hawaii board doesn't have any of these. Otherwise, it lets me monitor the card just fine.
> 
> Taken with hwinfo 6.22:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Card is currently running [email protected], as shown in the readouts. I was wondering if this sensor misreading is up to the modified BIOS I'm running that's fooling hwinfo? What do you think?


This is most likely due to the modded BIOS, which results in fooling of drivers/SMU. But there were also certain drivers that reported such false values due to some bugs in the driver.


----------



## man from atlantis

...


----------



## Krisztias

Dear Mumak!

I there a way, to calibrate the Aquacomputer High Flow sensor, when it's connected to the Flow Sensor header on a Crosshair VIII Hero Wi-Fi motherboard?
In HWiNFO I get 7.24 l/m, but it can't be right. In BIOS I'm unable to configure anything. The only thing I know, that the sensor has a polling rate of 169/l.
Thank you in advance.


----------



## Mumak

Krisztias said:


> Dear Mumak!
> 
> I there a way, to calibrate the Aquacomputer High Flow sensor, when it's connected to the Flow Sensor header on a Crosshair VIII Hero Wi-Fi motherboard?
> In HWiNFO I get 7.24 l/m, but it can't be right. In BIOS I'm unable to configure anything. The only thing I know, that the sensor has a polling rate of 169/l.
> Thank you in advance.


Sorry, I don't know. You'll need to check with ASUS or Aquacomputer.
Once you know the correct multiplier, you can adjust it in HWiNFO sensor settings / Custom.


----------



## Krisztias

Mumak said:


> Sorry, I don't know. You'll need to check with ASUS or Aquacomputer.
> Once you know the correct multiplier, you can adjust it in HWiNFO sensor settings / Custom.


Thank you for your answer, I will try it.


----------



## arrow0309

Hi, I wonder what this VIN7 might indicate, also the two T0 and T1 (125C?) aren't incorrect imho.
Talking about my new MSI MEG Z490 ACE:


----------



## Mumak

Krisztias said:


> Thank you for your answer, I will try it.


T0 and T1 are definitely invalid. I don't know what VIN7 is, but it might be an invalid readout from a not connected sensor as well.


----------



## Betroz

Using HWiNFO64 to log Windows WHEA errors, is it recommened to set Polling Period to something less than the standard 2000ms? Like say, 500ms? Will that effect CPU performance much?


----------



## Mumak

Betroz said:


> Using HWiNFO64 to log Windows WHEA errors, is it recommened to set Polling Period to something less than the standard 2000ms? Like say, 500ms? Will that effect CPU performance much?


That depends on type of sensors. EC and disk SMART sensors can cause higher latency and performance issues with a too frequent polling.
For just logging of WHEA errors there's no need for a high polling frequency, these won't be lost during queries as they are read asynchronously and logged in Windows events.


----------



## Betroz

Mumak said:


> For just logging of WHEA errors there's no need for a high polling frequency, these won't be lost during queries as they are read asynchronously and logged in Windows events.


Thank you for your reply. I'll let it stay at 2000ms then


----------



## Antom0

Hi, I have a "problem" (I suppose) with HWInfo64.
I have recently changed laptop and on my previous one, I used MSI Afterburner with HWInfo to see temps and stats during gaming. The first installation was easy and fast.
On my new laptop instead, I can't see data from HWInfo for some reason. I have "Sensor only" enabled, I thought it could be the fact that the option "Shared memory" was not enabled, but everything that should be enabled is actually enabled.
I have tried reinstalling both of them multiple times, but it doesn't work.
Can someone help? 😢


----------



## jura11

Hi @Mumak 

I'm having high memory usage with 6.42, usually 2GB, switched recently to beta and no more memory leaks but with 6.42 memory usage after 2 or 3 hours is always around 2GB 

Hope this helps 

Thanks, Jura


----------



## MacG32

@Mumak Your latest beta has messed up my layout. It's fixed order, but a lot of stuff is hidden. Could you please make the new layout option optional in the settings? I would have to resize all of my windows to fit the new space that it takes up. Thank you for your time and work.


----------



## Mumak

MacG32 said:


> @Mumak Your latest beta has messed up my layout. It's fixed order, but a lot of stuff is hidden. Could you please make the new layout option optional in the settings? I would have to resize all of my windows to fit the new space that it takes up. Thank you for your time and work.


Did you have items hidden prior to the update? Can you please post a screenshot of how it looks like now - what is shown and what is hidden?


----------



## MacG32

This is before the update.








This is after the update.


----------



## Mumak

This is because of the new introduced groups and you have many items hidden. You can easily hide those new items, so your layout will be same as before.


----------



## MacG32

It's too much work messing with it. It was just fine before the update. I'll just stick with the older version. There should be an option to turn on and off grouping to keep this mess from happening.


----------



## Mumak

7 clicks (Ctrl + click to select the group header) and pressing Shift-Del isn't too much work I believe.


----------



## MacG32

Half of the spaces in the update can't be hidden and the middle column doesn't extend to the third column. It would be much easier for the end user to have a choice to have this option or not. It messes up the entire layout for no reason.


----------



## Barefooter

MacG32 said:


> This is before the update.
> View attachment 2483900
> 
> This is after the update.
> View attachment 2483901


This is why I never update the software. No reason to anyway unless you have upgraded some hardware recently.


----------



## Bart

Here's a new one, to me anyways. Latest beta seems to be conflicting with me using MPT (More Power Tool) to unlock the GPU limitations on my Radeon VII in the home theatre PC. When it starts, it gets to "GPU ATI", then just vanishes completely. Anyone else using MPT and seeing this, and is there a work around?


----------



## Mumak

Bart said:


> Here's a new one, to me anyways. Latest beta seems to be conflicting with me using MPT (More Power Tool) to unlock the GPU limitations on my Radeon VII in the home theatre PC. When it starts, it gets to "GPU ATI", then just vanishes completely. Anyone else using MPT and seeing this, and is there a work around?


If you send me the HWiNFO Debug File when it terminates unexpectedly I can have a look at why it happens and how to fix it.


----------



## Streetdragon

i really wanna buy the pro version, but im pissed, because students gets a discount. Sooo nope


----------



## Bart

Mumak said:


> If you send me the HWiNFO Debug File when it terminates unexpectedly I can have a look at why it happens and how to fix it.


I think it's something buggy with the system. I'll do some testing over the long weekend before I waste your time with something _I_ probably broke, LOL! It hasn't been quite right since the latest BIOS update.


----------



## Mumak

Streetdragon said:


> i really wanna buy the pro version, but im pissed, because students gets a discount. Sooo nope


Sorry, what?? Without offering a discount to students it would be OK?


----------



## Streetdragon

Sounds stupid, but yes^^


----------



## Bart

Mumak said:


> If you send me the HWiNFO Debug File when it terminates unexpectedly I can have a look at why it happens and how to fix it.


FYI Mumak, it looks like your latest beta resolved whatever issue I was having. The previous version was hanging on my GPU somewhere, new one starts up just fine.


----------



## Mumak

Thanks for the feedback!


----------



## JustinThyme

Ive lost the majority of my sensors. Dont know whats going on. doesnt matter which version. AIDA 64 sees them all, HWMonitor sees them all but HwInfo is bare! its this way across several versions. Just updated to latest. Takes forever to launch then several clicks to close. Is there a setting Im missing. I looked in the hidden section of the layout and all the CPU temp info is just gone Heres whats left which isnt much.


----------



## Mumak

JustinThyme said:


> Ive lost the majority of my sensors. Dont know whats going on. doesnt matter which version. AIDA 64 sees them all, HWMonitor sees them all but HwInfo is bare! its this way across several versions. Just updated to latest. Takes forever to launch then several clicks to close. Is there a setting Im missing. I looked in the hidden section of the layout and all the CPU temp info is just gone Heres whats left which isnt much.
> 
> View attachment 2511871


Click "Restore Original Order" in sensor setting/layout or "Reset Preferences" in main settings.


----------



## JustinThyme

Thanks, I’ll give that a shot and post back in a bit.


----------



## JustinThyme

Well its semi functional back on 7.0.
7.2 while it says everything is enabled and monitoring its not there when I hit save and red x all over the screen in weird orders with system tray enabled by default. Dunno if windows updates had anything to do with it. I generally leave two columns open then expand as needed or just scroll down the second column. When I close it down to two the right column flashes continously and is very annoying. Even hiding sensors to the point where only two columns worth are there and I close it down to two columns it flashes and sensors that are hidden pop in and out. Ill leave it here for a bit and try the other I have on hand.

Well sheep sheet!!
Launched it got it going run a CB23 to see how it was doing and BSOD critical process died. Now my system won’t boot. Seems the two Intel m.2 drives in a dimm.2 in VROC are MIA all of the sudden. Tried disabling the the direct to CPU just to see if they even show up as single drives and no dice. Can boot off install and it doesn’t show up there either. Poof! Gone. OK maybe one croaked, not unheard of but both of them? Lights lit up on DIMM.2 board makes it through post to detect HDD and it ain’t happening. Green light lit up ready to boot but nothing to boot from. I was just about to do a clean install and can’t do that. Cheese and rice! Gonna have to break out my back up MOBO (same rampage VI Extreme Encore and put a 9940X in there and pull the DIMM.2 and put it in there and see what I get. Also have a single 905P U2 drive with PCIE adapter and a pair of AIC cards that have OS installed in VROC. All other M.2 drives show up as do SATA raid volumes on 860 EVOs. Just not the DIMM.2. Tried different BIOS, not there either. Not happy about now. Could be borked MOBO, borked drives, or borked CPU but I’d doubt it as all other PCIE devices are working.
Crap!!


----------



## JustinThyme

Well, Its alive again. What a PITA this is, still a lot to do. For whatever reason my raid0 array for two intel 905P M.2 drives failed. I had to delete the array then rebuild it in BIOS then the PITA of the right f6 drivers that matched whats in BIOS to get windows to load and just said screw it and did a clean install. Too much old muck that was in there and I DIDNT install the last feature update that says preview!! Im a bit leary on HWinfo but gonna do it now while I haven't installed everything yet.


----------



## JustinThyme

Latest versions don't work for me. 6.40 does


----------



## Mumak

JustinThyme said:


> Latest versions don't work for me. 6.40 does


What means "don't work"? Does it crash? A HWiNFO Debug File of the crash would be useful.


----------



## JustinThyme

Doesnt crash, just missing information. Two biggest items I'm after aren't there and a lot of not displaying red Xs that I know thats a right click away. Two biggest things Im looking at is CPU frequency and core temps with core max and package temps that I did find on the 6.40 buried about 200 items down instead of being up with the core max where it once was. This is on a rampage VI extreme encore with a 10980XE and two 2080TIs with 8X8GB ram. Im a bit skittish after the last episode and Im still not done reinstalling about 50 titles but Id rather get menial things like this solved now. I like the layout of Hwinfo better than HWmonitor and AIDA64 but the only one that doesn't want to play nice is Hwinfo. Most of the time I have AIDA 64 reporting to aqausuite for an OSD and never had issues in the past with both up and running but generally shut down everything else when benchmarking and rely on Hwinfo. Now its taking a good 60 seconds to load no matter which version and this is on brand new install of Win10 Pro 21H1. Summary works great, its the sensor borking. I just uninstalled 6.40 and installed 7.04 and if I launch sensors it dumps straight away. launch it with the sensors only box unticked and it comes up pretty quick, hit the sensors and it dumps.


----------



## JustinThyme

Should have left well enough alone with the 6.4. None of them work now. Installs fine and when launching it hangs on detecting drives. and stays there. Cant even kill it in task manager. Have to reboot into safe mode, uninstall then delete the folder and file with the exe that get left behind then go the HK Local user/software and delete the registry keys. Guess is AIDA64 an HW monitor for me now. I killed Ique, AIDA64, Aqua suite and even AV before installing and same show with all of them now. Im leery especially when it hangs on drives seeing how my raid got hijacked updating to the latest version and killed it which is what started all of this. I was blaming it on windows update but cant anymore. Im running 21H1 and everything works flawlessly at this point but HWinfo.


----------



## Mumak

That looks like a configuration mismatch in sensor settings. Do a full "Reset Preferences" from HWiNFO main settings.


----------



## JustinThyme

Mumak said:


> That looks like a configuration mismatch in sensor settings. Do a full "Reset Preferences" from HWiNFO main settings.


I can’t get that far. Launch it and it hangs at detecting drives. 6.4, 7.0, 7.2 and 7.4. I had 6.4 up after my debacle and should have left well enough alone. Uninstalled that and went for 7.4 that gave me several warnings about different devices like the Corsair PSU not going to work correctly and a few others and selected the do not monitor those. It launched the first time but all the core frequency and temps were nowhere to be found. Uninstalling that is when it went south (same thing happened when my raid failed. The uninstall hung up. Task manager wouldn’t kill it then the exe file still in the programs folder. Said it was running and the only way to get rid of that was boot into safe mode and manually delete it then Hkey/current user/ software/HWinfo delete keys. All the rest after that crashed or hung up on detecting sensors ATPI drives I think or something to that effect. I did have 6.4 running now none of them will even launch. This is with everything that monitors off even AV disabled. Like I said should have left well enough alone. Everything else works fine. AIDA64, HW Monitor, aquasuite etc even simultaneously. Just not HWinfo that’s been my go to for some time. Never had issues before I went and updated to the latest and I’ve been running it for several years without a hiccup. I did note that after the last Windows update (not the preview) I think I was running 7.0 and it became sluggish on launch and continuously refreshing all but the left pane as in starting top to bottom going down in a row with the entire line item blanking out and refilling.


----------



## JustinThyme

Just an Update. Killed my raid array, cant say what caused it for sure but it happened trying to get HWinfo to work. Intel VROC with the array and drives being reported as healthy by the Intel monitoring. 

So fresh install of windows and HWinfo 7.04 is working.


----------



## man from atlantis

Hi,

Could you add power, voltage, battery time reading support for Eaton Ellipse ECO/PRO series UPS?


----------



## storm-chaser

Mumak said:


> I have just released v3.94-1560 which (besides other improvements like enhanced support of GTX 680, EVGA and ASUS 7-series mobos) logs sensor values without the units for better import.
> The decimal separator based on regional settings might be implemented later, because this requires a bit more work.


Really love the real time visualization of clock speed. However, I have a number of dual processor systems and it appears as though this real time clock speed tool is only applicable to cpu 1, not both. Is there any way you can add support for a second CPU so it displays clock speed / turbo operation for both chips, not just the first one? Other than that, I think you do awesome work, great contribution to the tech community, that's for sure.


----------



## Mumak

storm-chaser said:


> Really love the real time visualization of clock speed. However, I have a number of dual processor systems and it appears as though this real time clock speed tool is only applicable to cpu 1, not both. Is there any way you can add support for a second CPU so it displays clock speed / turbo operation for both chips, not just the first one? Other than that, I think you do awesome work, great contribution to the tech community, that's for sure.


I will need more information about those systems, but a HWiNFO Debug File would be best so I can check the details.


----------



## storm-chaser

Mumak said:


> I will need more information about those systems, but a HWiNFO Debug File would be best so I can check the details.


First system is a z820 workstation with two E5 2696v2 12C/24T processors. as you can see from the screenshot below, it only displays processor 0 real time visual clock speed frequency using the (yellow) bars to indicate turbo operation and real time core speed. I will see if I have a complete AIDA64 rig for you, but it might take a little while to track that down...


----------



## Mumak

storm-chaser said:


> First system is a z820 workstation with two E5 2696v2 12C/24T processors. as you can see from the screenshot below, it only displays processor 0 real time visual clock speed frequency using the (yellow) bars to indicate turbo operation and real time core speed. I will see if I have a complete AIDA64 rig for you, but it might take a little while to track that down...
> 
> View attachment 2525583


No need for AIDA64 logs 
If you want to switch to CPU #2, you need to make the choice in the combo box beneath the CPU logo. But these screens won't show you both CPUs at once, only the chosen one.
For a much more detailed monitoring of both CPUs use the Sensors capability in HWiNFO.


----------

