I have been running TThrottle on a new computer build recently, and I have noticed that the CPU temperature swings wildly when I am away. It rises and lowers sharply between ~55 deg C and 0 deg C, probably a few dozen times a minute (I can screen cap when I get home tonight). I think this happens when the monitor goes to sleep, and I know for sure it does this when I lock the computer. Once the computer "wakes up", the temperature displays like normal. Keep in mind, BOINC is running the whole time.
However, I am using HWiNFO to reference the Tctrl temp, and when I graph that temperature it stays in the 50s. I suspect TThrottle is either getting bad information when my computer turns off the display, or it is having difficulty interpreting the data for some reason. This does not appear to be affecting throttling or performance of the computer, it just looks weird.
My computer is a Ryzen 3 2200G with a ASRock B450 Pro4 mobo, stock cooler, running Windows 10. No discrete GPU.
Quote from: vulpine05 on January 04, 2019, 06:37:16 PM
My computer is a Ryzen 3 2200G with a ASRock B450 Pro4 mobo, stock cooler, running Windows 10. No discrete GPU.
TThrottle is using the AMD driver, it probably stops recognizes it without a monitor, that's not an uncommon problem.
HWiNFO reads the card more directly.
If HWiNFO is running all the time, TThrottle can interface with HWiNFO and can use it's temperature.
Go to the tab external and check HWiNFO and select the right temperature source.
QuoteTThrottle is using the AMD driver, it probably stops recognizes it without a monitor, that's not an uncommon problem.
HWiNFO reads the card more directly.
If HWiNFO is running all the time, TThrottle can interface with HWiNFO and can use it's temperature.
Go to the tab external and check HWiNFO and select the right temperature source.
Actually, this is happening with HWinfo engaged. I have TThrottle reading the Tctrl/Tdie sensor for the CPU, and the GPU thermal diode for the integrated graphics.
I actually had to install HWinfo and read these sensors because if I don't, the temperature it is "reading" is 0 deg C, constant, with no fluctuation.
Quote from: vulpine05 on January 05, 2019, 04:08:26 AM
Go to the tab external and check HWiNFO and select the right temperature source.
Actually, this is happening with HWinfo engaged. I have TThrottle reading the Tctrl/Tdie sensor for the CPU, and the GPU thermal diode for the integrated graphics.
I actually had to install HWinfo and read these sensors because if I don't, the temperature it is "reading" is 0 deg C, constant, with no fluctuation.
[/quote]
You can contact HWinfo, they might have a solution.
But it isn't HWiNFO where the error is popping up, it is in TThrottle. When I look at the temperature trend on HWiNFO for the same sensor, it is "normal".
Quote from: vulpine05 on January 06, 2019, 12:57:57 AM
But it isn't HWiNFO where the error is popping up, it is in TThrottle. When I look at the temperature trend on HWiNFO for the same sensor, it is "normal".
That indicates TThrottle looses the connection with HWiNFO.
Locking the computer shouldn't do anything.
My guess Windows blocks the connection.
You could try GPUZ instead.
Hi! I also have been seeing a sawtooth pattern in TThrottle's graph of the cpu temperature data. In my case it IS a problem with HWiNFO64. My motherboard, an ASUS ROG STRIX B450-F GAMING, uses an ITE IT8665E Super IO chip for temperature sensing and fan control. This chip apparently has a history of not being happy if more than one application is accessing it at the same time, causing it to eventually, any where from hours to days, stop responding to data requests. This causes HWiNFO64's sensor readings to lock and Tthrottle to oscillate between what it natively sees, in my case 15 C, and the last value HWiNFO64 presented at the time of lockup. The other application in my case is iCUE from Corsair used for controlling the lights on my Corsair memory. Once this issue is triggered, it takes a system reboot to get access to the data again. Would it be possible for you to add OpenHardwareMonitor to the list of external temperature sources? It seems to be able to sense my AMD Ryzen 7 2700X with no problems when this happens, showing the same temperature data under AMD Ryzen 7 2700X/CPU Package as HWiNFO64 shows for the cpu die reading. It publishes its data through WMI.
Quote from: pcook on August 17, 2020, 08:54:41 PM
Hi! I also have been seeing a sawtooth pattern in TThrottle's graph of the cpu temperature data. In my case it IS a problem with HWiNFO64.
Did you report it here https://www.hwinfo.com/forum/ (https://www.hwinfo.com/forum/)? The best approach is to get rid of the bug there.
Hmmm.... The first thing I did was check out the hwinfo.com forum, where I found that other people have been having problems with the sensor readings of ASUS motherboards. (2020 thread.)
https://www.hwinfo.com/forum/threads/frozen-values-in-hwinfo.6495/
I checked on the Corsair forums and found talk of the issues of using HWiNO and iCUE together. (2018 thread.)
https://forum.corsair.com/forums/showthread.php?t=180150&t=180150
I tried disabling HWInfo's monitoring of Corsair devices, but that didn't seem to work.
And here on an ASUS forum, I found where they talk about a bug with the ITE IT8665E (the Super IO chip that the motherboard uses for fan/temperature sensors and fan control) and how it reacts to getting polled a lot by software like hwinfo. (2018 thread.)
https://rog.asus.com/forum/showthread.php?102138-CPU-and-case-fans-mysteriously-stopping-on-the-ASUS-Prime-X470-Pro
Open Hardware Monitor seems to be accessing CPU, GPU and hard drive temperature data directly. If the ITE IT8665E is available, Open Hardware Monitor will show it under ASUS ROG STRIX B450-F GAMING and show the motherboard sensor data, ie. temperatures (CPU, Socket, Chipset, etc.) fan speeds, memory temperatures, etc. If the ITE IT8665E is hot feeling sociable, then it doesn't even show, in fact nothing shows, under the motherboard entry.
Since finding out all of this info, I have been looking into writing a little app as a test of how to access Open Hardware Monitor's sensor readings via WMI as they suggest. What language is TThrottle written in?
Quote from: pcook on August 19, 2020, 05:06:09 PM
Hmmm.... The first thing I did was check out the hwinfo.com forum, where I found that other people have been having problems with the sensor readings of ASUS motherboards. (2020 thread.)
The Open Hardware Monitor seems to require TThrottle to run as Administrator.
Don't know why they don't add a better interface/api.
TThrottle is written in CPP.
Hi again! Here is what I came up with. It is a little console app that finds out what CPUs/GPUs are in the system using OpenHardwareMonitor WMI, then displays some temperature data for them. The code is based on the WMI sample code found here:
https://docs.microsoft.com/en-us/windows/win32/wmisdk/example-creating-a-wmi-application
The app WMI Code Creator v1.0 was used to inspect the OpenHardwareMonitor WMI namespace. It can be found here:
https://www.microsoft.com/en-us/download/details.aspx?id=8572
I was going to attach the code and exe, but adding attachments does not seem to be an option.
I hope this helps. It ran on my system, but only further testing will tell how well it does on others.
Quote from: pcook on August 22, 2020, 02:36:26 AM
Hi again! Here is what I came up with. It is a little console app that finds out what CPUs/GPUs are in the system using OpenHardwareMonitor WMI, then displays some temperature data for them. The code is based on the WMI sample code found here:
Working on it, enumeration OK
Fred
Quote from: pcook on August 22, 2020, 02:36:26 AM
Hi again!
If you want your name added to the TThrottle About Box let me know the name to use.
At the moment everything seems to work. After more testing the beta version should arrive soon.
Hi Fred! Thank you. Yes, I would enjoy being added. After looking at the about again, I think that "pcook" should work just fine.
Quote from: pcook on August 25, 2020, 12:22:20 AM
Hi Fred! Thank you. Yes, I would enjoy being added. After looking at the about again, I think that "pcook" should work just fine.
Download is here https://efmer.eu/download/boinc/tthrottle/unified/setup_32_64_tthrottle_7_7_3.exe (https://efmer.eu/download/boinc/tthrottle/unified/setup_32_64_tthrottle_7_7_3.exe)
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?
Quote from: pcook on August 25, 2020, 07:33:07 PM
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.
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.
I'm puzzled, because I use the same code, made some changes to run it in a class.
https://we.tl/t-QDKv5H9EOJ (https://we.tl/t-QDKv5H9EOJ)
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.
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
Great, that looks much better, thanks.
I somehow missed that, glad you did a good job making things right.
I'm testing right now.
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
Quote from: pcook on August 28, 2020, 01:52:34 PM
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/ (https://efmer.com/download-throttle-beta/)