Monitor CPU and GPU fan RPM on Clevo laptops

demattin

Active Member
I have a small problem with the last build and the EC-Status:
Sometimes it lasts very long, till the first value of the fanspeed occurs (many updatecycles) and mostly I even have to restart HWinfo to get the values.
The CPU-temp (the only other EC-value) doesn't have this problem.
After the fanspeed has been read out the first time, the problem is gone and the value-actualisation works well.
Is it possible, that this has something to do with your "lag-optimization"?

I found no way to reproduce this and am not able to give you more information why or under what circumstances it doesn't function.
 

Martin

HWiNFO Author
Staff member
I don't think that's related to the latest change. So there was no such behavior with the previous build ?
 

demattin

Active Member
I haven't seen this in the previous version.
But I haven't used this version much enough to say, that this problem is new.

It seems to me, as it is a problem with the first time initialisation.
Today the monitoring doesn't work after autostart and as I activated the HWinfo-sensor screen after some minutes, the value came instantly to the gadget.

I do not monitor many values (because I think this probably could save ressources) - could this make this problems?
For testing I will activate CPU-Temp over EC too and have a look at it.
 

Martin

HWiNFO Author
Staff member
No, disabling other items should have no impact on this.
I don't know why it happens, nor what to do yet. Maybe it might help if you could perform more tests to determine when the issue occurs and when it doesn't. Are you using any other system monitoring tools in parallel? If yes, try without them.
 

demattin

Active Member
I actually use:
1. crystaldiskinfo (for Harddiskmonitoring) - want to use it further more.
Because getting SMART-infos prevents the disk going in standby (doesn't wake up, but restarts sleep timer).
So I need a longer interval for diskmonitoring

2. BatteryCare - want to use it further more.
For batterymonitoring but with deactivated HDD-temp (SMART) and CPU-temp function

3. coretemp (with rainmeter) - should be replaced by HWinfo
As long, as the problem (lags) with the FAN-check over EC exists, I only use HWinfo to monitor FAN, PCH and TotalCPU- and MemUsed-Graph in the separate HWinfo-gadget (with the other sensors deactivated).
So I can deactivate HWinfo but don't get lost of CPU-temp-monitoring if I want play games where the lag occurs.

It's curious, but if the monitoring once works, I'm able to stop and restart HWinfo and it runs instantly.

The only causal relationship I could figure out by now, is the temp of the system and if HWinfo has run once with a correct EC-readout.
When the system runs a while, there seems to be no problems.
But this CAN NOT BE the real reason - strange ...
I'll try to figure it out!
 

Martin

HWiNFO Author
Staff member
Please try to run without BatteryCare just to check if that might have any influence.
 

demattin

Active Member
I found out some other or helping issues:
Some other sensors behave the same as above mentioned:
- PCH Temp (sometimes)
- NVidia VID Voltage (sometimes)
- SMSC LPC 47B397/SCH53x7 header with one senseless sensor (often, but when shown, always 100%, if I remember right. I don't know the sensor name at the moment.)
and as above mentioned:
- CPU-Clock EC (not often)
- CPU-Fan EC (often)
maybe more - but no sensor of my interest ... ;)

And the NVidia-initialisation seems to fail (I have a Notebook with optimus).
I think the activation of the NVidia during HWinfo startup should recognice and show up all possible sensors after HWinfo is started.
The header of the NVidia sensors is generated in the sensors screen every time, but the sensors aren't shown before I use an application that activates the NVidia.
After leaving the NVidia-activating app and using the integrated graphics, the sensors are set to 0 but remain displayed (correct behaviour).
When I activate HWinfo it activates the NVidia-card for a very short time - may be too short to recognize the sensors?

At all it seems to be a timing problem with some specific sensors.

Btw. I tested with all other monitoring tools deactivated. There seems to be no correlation.

Another hint for the CPU-Fan (EC) problem:
In the HWinfo-sensors screen there is generated a blank line for this sensor beneath the Clevo header even when the sensor is not shown.
Seems to be, that the program knows, there is something, but doesn't know, what to show here ...

Added some screenshots of the sensor screen with comments.
Hope this is helpfull.
 

Attachments

  • Clevo W370ET HWinfo sensor problem.pdf
    333.6 KB · Views: 15

Martin

HWiNFO Author
Staff member
The behavior with Optimus is intentional and absolutely normal. During start, HWiNFO needs to wake the card up for a short while to recognize it. Then it continues depending on status of Optimus. If HWiNFO would constantly poll the DGPU, it would not allow it to go back into disabled state, which would cause higher power usage. When the DGPU is used, HWiNFO displays all information about it. If it's in disabled state, it's not possible to query DGPU parameters. This way it doesn't interfer with the system power policy.

As for the issues, I believe the problem might be the EC protocol, more precisely, HWiNFO is not able to correctly read out the values from EC.
It works this way:
- If HWiNFO is able to properly read a value from EC, it does display it
- If HWiNFO gets an error when attempting to read a value from EC, it doesn't display it. If there's currently a value displayed, it doesn't change it, so it keeps the last properly read value.
So I believe, this is the reason why it takes some time to display a value - there are errors returned by the EC protocol. And once you see a value, you get a feeling that it's always read out, which might not be true (it just doesn't update when it's not possible to read a new value).
This might be proved if I would put more debugging information into HWiNFO and you would run it in Debug Mode and send me the Debug File produced.
There's still a question remaining - why are there errors occurring during readout? This is hard to say exactly, since there's no unique way to determine this. But I think this might be caused by either the ACPI subsystem sending too many queries to the EC, or another application (this might be some special application from the notebook manufacturer, like tools to enable special notebook controls, backlight, etc).
You might try the following test - take the battery out of the notebook and try to run HWiNFO and watch if this changes something. I'm asking this, because the battery communication protocol is usually realized via ACPI->EC, so removing the battery might save a lot of EC communication (which might interferr with HWiNFO).
 

demattin

Active Member
Martin said:
If there's currently a value displayed, it doesn't change it, so it keeps the last properly read value.
... And once you see a value, you get a feeling that it's always read out, which might not be true (it just doesn't update when it's not possible to read a new value).

I had this idea, too.
But it is really as I described! The values seem to be correctly actualizised after the first successfull reading.
It's easy to proof with the fan-sensor, because I can hear every bigger change and see this instantly in the Fan-graph. And the RPM often changes for some digits (metering tolerance).
During my reply to your post, fanspeed changed 6 times in bigger steps (0 to ~1200) and this also was propper and directly displayed by HWinfo.
Only after a suspend to ram I sometimes recognize this "staying on old value for some cycles".
Perhaps it would be a great feature enhancement to colorize or mark values which are not actualisized because of a temporarry readout error?!
Ok, colorization would be difficult, because this has to interferr with the displaying-tool (gadget), but a *-mark in front of the value should be easy to implement.
Hmm - but than it isn't a number-value any more. Same problem with the displaying tool ...
Perhaps would a separate error-log in plane ASCII be a solution?
The debugging logs too much information.

You might try the following test - take the battery out of the notebook and try to run HWiNFO and watch if this changes something.

During last tests (for some days now) I don't have the battery in the notebook because I actually use it only at home only with powercord to save battery livetime.

I don't have any idea any more.
If I get something new, I will tell you.
I also will have a look at the debug-feature. But as the problem is not reproduceable, the log may become very long to see something.
And sadly, the debugging log is hard to read without preparation.
But I have found the word "Error" there and will attach a log with some HWinfo starts. But during this period of logging everything (incl. EC) seems to work and start fine.


Thanks for your support and the in spite of it all really great tool!
I will use it with the HWinfo gadget side by side with Coretemp and rainnmeter and this suits me well.

Edit:
I have also added a debug-file with EC readout for CPU temp working and for FANspeed not working!
 

Attachments

  • HWiNFO64-Debug.zip
    48.4 KB · Views: 3
  • HWiNFO64 - EC Fan error.zip
    46.3 KB · Views: 4

Martin

HWiNFO Author
Staff member
The HWiNFO Debug File is not meant to be analyzed by users, it's for my internal analysis. And currently HWiNFO doesn't store enough information in the Debug File that would allow me to trace your problem. I first need to integrate this.
 

demattin

Active Member
You recogniized my edit of the previous post with the 2nd debug log?
Suspending to ram seems to be a good way to reproduce the error.

But if I understand you right, you plan to enhance the debugging infos with further output.

I stay tuned ... ;)
 

demattin

Active Member
Puh ... I found another mysterious bug.
It was the 3rd time now, that some sensorsettings in the Gadget got lost.
Now I figured out the reason.
I checked the "prefMonitors_0.json" file and the id of the sensors have changed (from something like 7xxxxx to 8xxxxx - this time it have been the smart-infos of the hdds). It was a hard work because of missing CR/LF after each dataset/sensorsetting (would be a nice enhancement to make this file editable or checkable with standard-tools ;) ).

So there were the old ids with the settings, but they weren't used, because the ids of the information sended from HWinfo have been changed and the sensors were duplicated to the end of the sensor-list with default settings.
At first this "new" (and old) sensors weren't displayed in the sensorlist of HWinfo - like the "not show bug sensor".
The new enmeration occurs after the sensors were found (I think, I had to restart HWinfo).
The names of the sensors seemed to be identical and the "purge unused sensors" in the gadget even didn't recognize this dublication and wasn't able to delete the "old" sensors.
But they were shown as double in the gadgets config menu.

How is this possible? Do you have an idea?
Could you tell me in short, how you enumerate the sensors?

All the problems I have, are with "special sensors" - the normal sensors (reported from system or CPU) don't make any problems.

PS:
And I found out where that previous mentioned GPU VID disappearing comes from.
GPU VID is from the NVidia GPU , but reported from the CPU sensor!
It only comes up, when NVidia GPU hasn't been used. So it's correct this way - either GPU VID or all the NVidia GPU infos, depending on the optimus state first use. The only mystic thing is, that after onetime use of NVidia, the Nvidia rests with all values set to "0" and GPU VID doesn't come up any more until reboot and that the sensor is placed in the NVidia-section of the sensors.
But the gadget tells me, it's a CPU-depending sensor!
{"id":"3002000","title":"GPU VID","units":"V","value":0.000000,"sensor":"CPU [#0]: Intel Core i7-3632QM"}, in the HWiNFOMonitor.log file.
 

Martin

HWiNFO Author
Staff member
The "GPU VID" value comes from CPU and in fact it's the value of the Intel GPU. I understand that it's confusing if this value appears at the end of the sensor list, because then it seems it belongs to the nVidia GPU.
It seems there are more problems with order of sensor values when certain sensors/values appear or disappear. This all is because of the latest changes in HWiNFO which allow the user to reorder any sensor value. It seems to still require some tuning and I'll have a look at that, but it will take some time... Currently you can do a "Restore Original Order" under Configure/Layout to bring the sensor values back to original positions.

Here's a new build with additional debug information for your problem: www.hwinfo.com/beta/hw64_423_1987.zip
Please create a new Debug File when there are problem with EC values using that build.
 

demattin

Active Member
I will test the reordering of the values, when the problem is seen again.
But you are right, I have changed the order to suit my needs.

Martin said:
The "GPU VID" value comes from CPU and in fact it's the value of the Intel GPU.

Hmm - but the sensors value is always "0". Only when starting HWinfo the first value is sometimes ~0,9V for the first cycle.
So I thought, it was an NVidia related information but read out from the CPU sensor.
That seemed to be logical to me.
Now it doesn't seems to be logical any more because of the value "0", when internal GPU is activ!?

I will try to create short logs with wrong sensor readings with the new beta.
Thanks!
 

demattin

Active Member
When NVidia GPU is used, the GPU VID sensor disappeares completely.
And GPU VID never comes back in sensors screen.
The NVidia-sensors remain displayed but then set to 0 when NVidia GPU is disabled!
I have to restart HWinfo to see GPI VID again with deactivated NVidia GPU.

My idea was, that this GPU VID is "renamed", replaced or wrapped to "GPU core Voltage" of the NVidia sensors. This value is ~0,9V (in idle with activated NV GPU), too.
Once the NVidia was long enough initialized, the values are recognized and then set to 0 during the next NV GPU deactivation.
This was the reason for my question, if it is possible to let HWinfo activate the NV GPU a bit longer during its start.
Maybe you need 2 cycles to get all NV values properly and show them in the sensors list.
Actually you have to activate NV GPU once yourself to see the NV sensors in the HWinfo list!

This all would fit my logic ... ;)
 

Martin

HWiNFO Author
Staff member
GPU VID should not be renamed by HWiNFO, it's only possible that it would be moved to a different position (end of the list) if this value appears after it was not present before. You might try to "Restore Original Order" or completely reset HWiNFO preferences and then run again.
 

demattin

Active Member
I made a COMPLETE reset of HWinfo by deleting all preferences in gadget (json-files were empfty) an overwriting hwinfo64.ini with the default ini-file.

Then:
-> startet hwinfo.
-> after some cycles GPU VID appears.
-> activating nVidia-GPU
-> NV-sensors appear in sensor screen and gadget
-> GPU-VID is gone in sensor screen!!
-> deactivated NV GPU
-> NV-sensors all were set to 0
-> GPU-VID isn't seen in sensor-screen
-> In the gadget-configuration the GPU VID remains as a not actual present sensor (purgeable)
-> stop HWinfo
-> restart HWinfo
-> GPU VID comes up in sensor screen and is diplayed in gadget
-> NV sensors are not displayed
...

It's as I described before.
 

demattin

Active Member
Have a look on the attachment of this previous post: ;)
http://www.hwinfo.com/forum/Thread-...GPU-fan-RPM-on-Clevo-laptops?pid=4706#pid4706

Edit:
If I press "restore original order of the sensors" with the nVidia Sensors are at 0-state, the NV-Sensors go away.
And GPU-VID comes back again!!
But this has to be done every time, the NV-state changes!
So the solution would be to do an automatic reorder, when NV-state changes!

Edit 2:
Now, after reorder, the GPU VID is under CPU sensors.
But after all I don't understand this now. What stands this Voltage for? 0V on internal graphics, when it is used?!
 
Top