wild CPU temperature swings, but not really

[pcook]

Hi Fred! I downloaded and installed TThrottle 7.73. When I ran my test app on my system, a Ryzyn 7 2700x, I got two temperature readings for the CPU. One corresponded to HWiNFO64 Tdie (CPU Package) which is the true temperature of the CPU chip, and the second corresponded to HWiNFO64 Tctl (CPU Tctl) which is higher, in my case by 10 C, and intended by AMD to provide a consistent fan response across their various products. The only CPU option right now seems to be for CPU Tctl, with no way to select CPU Package. Was this intended?

[fred]

Hi Fred! I downloaded and installed TThrottle 7.73. When I ran my test app on my system, a Ryzyn 7 2700x, I got two temperature readings for the CPU. One corresponded to HWiNFO64 Tdie (CPU Package) which is the true temperature of the CPU chip, and the second corresponded to HWiNFO64 Tctl (CPU Tctl) which is higher, in my case by 10 C, and intended by AMD to provide a consistent fan response across their various products. The only CPU option right now seems to be for CPU Tctl, with no way to select CPU Package. Was this intended?

That's what my system shows, no package temperature.
I checked the query for the temperatures and the package temperature wasn't there.
If you can find the package temp with the program you send me let me know.

[pcook]

Hmmm... Here is a screenshot, via Dropbox, of the output of that code I sent you on my system. The three line groups are the Hardware Name, the Sensor (temperature) Value, and the Sensor Name taken once per second for 10 seconds. This is the Dropbox link:

https://www.dropbox.com/s/307m8p8ukug33nd/Screenshot%202020-08-26%2000.01.10.png?dl=0

When I am running Open Hardware Monitor on my system, the user interface for Open Hardware Monitor does not even show the Tctl temperature, only the package (Tdie) one. I only found out that it was reporting the Tctl temperature when during code development I was listing all of the temperature sensors found and I saw it.

[fred]

I'm puzzled, because I use the same code, made some changes to run it in a class.
https://we.tl/t-QDKv5H9EOJ

[pcook]

Hi Fred! I think I have found the issue. While each sensor has only one piece of parent hardware, each piece of hardware can have more than one sensor. I did not know how you handled internal data access, so my example code just printed out the sensor data as it found it. It looks like the array you set up to store temperature data, m_iHardware, assumes that there is only one temperature reading per piece of hardware. If there are more than one, then each new find will overwrite the previous one. In my case, I have always seen the package (Tdie) temperature being displayed before the Tctl one, though I imagine that it would not be wise to assume that that is always the case.

It looks like you are presenting people with a list of hardware to choose from, when it appears that what is needed is a list of senors. (No criticism intended.) I will be contemplating the code further to see if I can come up with a way to modify things such that GetID will return a string containing the hardware Identifier, hardware Name and sensor Name for user selection, and GetTemperature will return the desired temperature sensor reading, in both cases not changing the signature.

[pcook]

Hi again Fred! Here is what I came up with. It's been too long since I coded in C++, so while I suspect that m_sHardware[m_iHardwareCount][2] = L"-1"; has something to do with marking the end of valid data in the array, I am not sure. Information about hardware is now in hardware data structures while information about sensors is in sensor data structures. Each has their own array and an array to link the two. As I have set it up now, only one hardware query statement is really needed for CPU/GPU discovery, but I left it as is because I wasn't sure if you wanted them separate. A sensor query is now in the Init() to record info about those sensors that belong to the CPU/GPUs for use in later temperature updates.  GetID now returns a string containing the hardware Identifier, hardware Name and sensor Name. ReadTemperature mostly works the same, but now searches through the sensors for those matching the sensor identifiers that we are interested in updating.  GetTemperature also works mostly the same, it just reads data from m_iSensor instead of m_iHardware. Hopefully I haven't screwed up your code too badly.

https://www.dropbox.com/s/erv7my61ond68v0/NewVersion-01.zip?dl=0

[fred]

Great, that looks much better, thanks.
I somehow missed that, glad you did a good job making things right.

I'm testing right now.

[pcook]

If you are interested, the code that combines CPU/GPU detection into one query. It seems to create an executable that shows about 1K smaller.

https://www.dropbox.com/s/juf1pi0hqifncel/NewVersion-02.zip?dl=0

[fred]

If you are interested, the code that combines CPU/GPU detection into one query. It seems to create an executable that shows about 1K smaller.

Yes I looked at that, but it's not a noticeable difference on computers nowadays.

The latest version 7.732 Beta: https://efmer.com/download-throttle-beta/