ludicrous minimum temperature being displayed
- Thread starter lwilliams
- Start date
X570 Aorus Pro here. After latest v6.22-4060 I did saw 2 times only (after many days of usage) after long idling, VRM and PCH temps glitch report the max value of 116C and 96C respectively. It was not the same time.
One day was the VRM and some other the PCH. And like I said it happen only one time for each. And prior to this version never had such values through out the 6 months I have the system and use HWiNFO (which is great and the best tool I ever had, lets not forget that)
One day was the VRM and some other the PCH. And like I said it happen only one time for each. And prior to this version never had such values through out the 6 months I have the system and use HWiNFO (which is great and the best tool I ever had, lets not forget that)
Can you please attach the HWiNFO Debug File from latest version? I'd like to check something, but not sure if there's anything I can do here. Most likely those glitches are caused directly by the sensor chip.
lwilliams
Member
It is only in this latest version and the previous that this error reporting occurred.
How do I produce the Debug file please?
think I've found out how
Last edited:
Thanks. I analyzed this and it's quite strange that only the latest HWiNFO version shows such occasional erratic values as there were no changes in this part of code for a quite long time.
Perhaps something else has indirect effect on this, or some other monitoring tool if you're running in parallel with HWiNFO.
Anyway, these ITE IT868x chips have a quite bad reputation. They caused heavy headaches to ASUS in their 3xx/4xx series mainboards with all sorts of problems including erratic values or corruption of the whole SIO state. Also GIGABYTE's designs with dual ITE chips have been causing several issues in the past.
Perhaps something else has indirect effect on this, or some other monitoring tool if you're running in parallel with HWiNFO.
Anyway, these ITE IT868x chips have a quite bad reputation. They caused heavy headaches to ASUS in their 3xx/4xx series mainboards with all sorts of problems including erratic values or corruption of the whole SIO state. Also GIGABYTE's designs with dual ITE chips have been causing several issues in the past.
Thanks Martin!
Also forgot to tell, although we did discuss it some time ago, that from time to time like once or twice a week I get a trigger on
Thermal Throttling (HTC) max value: Yes
Thermal Throttling (PROCHOT EXT) max value: Yes
...for no apparent reason. Again when system is idling for a couple of hours or more. This occurs rare and since the insertion of those values in HWiNFO.
Still apply to the same erratic behaviour as the above?
Those "Thermal Throttling" values (and some other values under the AMD sensor) is a different case and might have several other reasons. Some of them (especially the EXT) might be triggered by external logic (i.e. the SIO) for whatever reason - either the SIO issues PROCHOT as a result of a valid/invalid thermal evaluation or it receives wrong data. Which of those reasons really happens is difficult to determine as it would require hardware debugging. "Thermal Throttling" might also be triggered by the CPU SMU unit as a result of some firmware erratum or erratic read of temperature data internally in the CPU.
Then there is another case of reading wrong data - running simultaneously with other tools accessing the same resources without synchronization. This has been just recently discovered with NZXT CAM software.
So as you can see, there can be several cases and it's quite difficult to tell whether the erratic value read is a problem of the hardware sensor providing wrong data, or a glitch during reading the value, or some other interaction inside the system.
I don't deny the fact that the erratic values under the ITE sensor might be caused by some recent update in HWiNFO, but I don't think this is something directly related to handling of the ITE sensor. It might be some indirect/rare action/situation that's occurring on a completely different place. But why/where exactly is very difficult to determine due to the complexity of the hardware/software and rare occurring of the erratic values.
Then there is another case of reading wrong data - running simultaneously with other tools accessing the same resources without synchronization. This has been just recently discovered with NZXT CAM software.
So as you can see, there can be several cases and it's quite difficult to tell whether the erratic value read is a problem of the hardware sensor providing wrong data, or a glitch during reading the value, or some other interaction inside the system.
I don't deny the fact that the erratic values under the ITE sensor might be caused by some recent update in HWiNFO, but I don't think this is something directly related to handling of the ITE sensor. It might be some indirect/rare action/situation that's occurring on a completely different place. But why/where exactly is very difficult to determine due to the complexity of the hardware/software and rare occurring of the erratic values.
Thanks again!
Indeed the complexity of modern hardware is really high and vendors dont always do their best in choosing better components (cost?). I guess for some parts they have the "if it does the job like 95~99% of the time its ok" mind set...
Keep up the good job, and keep adding sensors!
Indeed the complexity of modern hardware is really high and vendors dont always do their best in choosing better components (cost?). I guess for some parts they have the "if it does the job like 95~99% of the time its ok" mind set...
Keep up the good job, and keep adding sensors!
Haha, some hate me for this and think it's far more than enoughand keep adding sensors!
lwilliams
Member
Looking good so far for myself, just noticed though that my 4th stick of ram isn't fully reported in memory timings
Sorry, but I don't understand what you mean. Memory timings report global values, not per module.