HWiNFO 4.41-2265 Alert Bug

[Mexxxi]

The sensor alerts get triggered even though nothing is wrong. I have two alerts set, one for my chassis fan and one for the CPU fan. The alert for the chassis fan is supposed to kick in if rpm go below 500, for the CPU if the rpm fall below 1500 rpm.

My chassis fan runs at a rather low speed of only 700 rpm. Today I constantly received an alert that the fan had stopped (0 rpm). The fan was spinning though and also the minimum sensor value showed a normal value just slightly below average. The alert message only started to stop when I increased the chassis fan's speed to 1000 rpm.

I thought that for some reason HWiNFO had trouble with the rather low rpm value, but then I started to receive CPU alerts telling me that the fan had also stopped (0 rpm) while in fact it was spinning with more than 2000 rpm. The minimum sensor value also showed a proper value, only the monitor function for the alerts seems to go way off track.

 

[Martin]

Maybe sometimes HWiNFO fails to read the fan speed. Are you maybe running some additional system monitoring tools in parallel ?
I'd also suggest to enable logging of sensor values (into CSV) and then check back what values have been read.
Please let me know the result.

 

[Mexxxi]

Maybe sometimes HWiNFO fails to read the fan speed.

Shouldn't this false zero value then show up in the minimum column?

Are you maybe running some additional system monitoring tools in parallel ?

Nope.

I'd also suggest to enable logging of sensor values (into CSV) and then check back what values have been read.
Please let me know the result.

Good idea. I did just that. Check out the appended csv. I lowered the chassis fan speed to a minimum of about 500 rpm and HWiNFO sure did indeed read that as 0 rpm even though the fan didn't stop turning.


Edit: I realized that I still had some ASUS services running, including its fan control service. I deaktivated all of them, yet the behavior continues. Also, if there would indeed be software interfering on some level, why only at low fan speeds?

Edit 2: I cross-checked with HWMonitor and OpenHardwareMonitor. The latter had no problems and tracked the fan speeds properly regardless of their speeds, but HWMonitor exhibited the same behavior as HWiNFO.

It constantly jumped between 0 and extraordinary values of 675000 rpm. Unlike HWiNFO, it also showed the wrong zero value in the minimum column. This kinda looks like what happens when a value exceeds the range of the predefined data type. There seems to be a threshold that has to be reached for that not to happen. When I kept the chassis fan running above 700 rpm, both HWiNFO and HWMonitor would show the values correctly. As soon as it would dip slightly below 700 rpm, both programs would show false values.

Unlike HWiNFO, HWMonitor also constantly jumped between 0 and 3000 rpm for my CPU-fan. HWiNFO only seems to freak out in this regard when the speed falls below 2000 rpm.

I'd think seeing that HWMonitor behaves quite similarly to HWiNFO in this regard, that the error is on my end or may be in the driver. Still, neither OpenHardwareMonitor, nor the ASUS tools have trouble properly displaying the lower fan speeds. Then again, HWMonitor shows plenty of wrong values, including temperatures of over 100°C for several sensors all of which are properly displayed by HWiNFO, so I wouldn't use that program for a point of reference, so may be it's just a coincidence and both programs carry the same programming bug?

 

[Martin]

It is possible that the circuit measuring fan speed has troubles reading lower speeds. Thus it sometimes experiences an underflow and reports this as 0.
It's also possible that the OpenHardwareMonitor and ASUS tools ignore such values (treat them as invalid) and don't report them at all.
HWiNFO on the other hand doesn't include this value in Min, I should check that...
Is this the machine for which you already posted a report+DBG - Phenom II X6 1090T and the sensor on mainboard shown ITE IT8721F ?

 

[Mexxxi]

It is possible that the circuit measuring fan speed has troubles reading lower speeds. Thus it sometimes experiences an underflow and reports this as 0.
It's also possible that the OpenHardwareMonitor and ASUS tools ignore such values (treat them as invalid) and don't report them at all.

Interesting! May be you could implement a similar feature with a threshold that can be defined by the user, or can this already be achieved with the notification distance setting? I had it at 10 seconds and it still got triggered constantly despite the csv showing that HWiNFO never read that zero value for such a long time span.

Is this the machine for which you already posted a report+DBG - Phenom II X6 1090T and the sensor on mainboard shown ITE IT8721F ?

Yes, indeed.

 

[Martin]

Actually HWiNFO already uses a filter for some erratic values for this chip (IT8721F). Very high RPM speeds are already filtered out and reported as 0, but low speeds are not filtered.
That explains why HWMonitor reports 675000 RPM and HWiNFO doesn't.
A user-defined filter might be a good idea, though a bit difficult to implement because of the way how HWiNFO works internally. I'll think about this. Nevertheless, this doesn't answer/solve why the chip is sometimes reporting erratic values. Also, applying such filter would render your alerts unusable - it wouldn't catch the situation when the fan stops (it would be filtered out).
You can't solve this using the Notification Distance setting - that defines the minimum interval in which alerts are reported (to avoid too many alerts while a sensor is crossing a threshold).

 

[Mexxxi]

Actually HWiNFO already uses a filter for some erratic values for this chip (IT8721F). Very high RPM speeds are already filtered out and reported as 0, but low speeds are not filtered.
That explains why HWMonitor reports 675000 RPM and HWiNFO doesn't.

Yes, that explains it. Seems that reading sensor values is more of a science than it seems

Nevertheless, this doesn't answer/solve why the chip is sometimes reporting erratic values.

May be it's just the way the chipset was implemented by the manufacturer. You wrote a post about certain CPUs not properly reporting internal temperature values. May be this is also a case where the chip's sensors have similar deficiencies.

Also, applying such filter would render your alerts unusable - it wouldn't catch the situation when the fan stops (it would be filtered out).

May be I'm not getting it right, but looking at the csv it's clear that HWiNFO doesn't get stuck with all zeroes but only gets them occasionally. A threshold that allows the user to set a time limit or the amount of instances to ignore those until the warning is triggered wouldn't make the alerts useless.

Imagine the user sets the threshold to 10 seconds. Then the alert would be triggered if HWiNFO would get a constant stream zeros for 10 seconds. As soon as this streak is interrupted with a higher value, the threshold should be reseted. If the fan actually fails to function, then HWiNFO will still be able to trigger an alert after the predefined threshold time. Since overheating is a slow process that allows for some delay, this wouldn't really hurt much, especially considering that people having such misbehaving chips are basically stuck with no alert protection at all.

You can't solve this using the Notification Distance setting - that defines the minimum interval in which alerts are reported (to avoid too many alerts while a sensor is crossing a threshold).

Also a useful setting, especially since I misinterpreted it the first time as the proposed threshold and had to realize that I was mistaken when the described behavior occured and I had set it to 1 second which basically disabled me to navigate the program

 

[Martin]

May be I'm not getting it right, but looking at the csv it's clear that HWiNFO doesn't get stuck with all zeroes but only gets them occasionally. A threshold that allows the user to set a time limit or the amount of instances to ignore those until the warning is triggered wouldn't make the alerts useless.

Imagine the user sets the threshold to 10 seconds. Then the alert would be triggered if HWiNFO would get a constant stream zeros for 10 seconds. As soon as this streak is interrupted with a higher value, the threshold should be reseted. If the fan actually fails to function, then HWiNFO will still be able to trigger an alert after the predefined threshold time. Since overheating is a slow process that allows for some delay, this wouldn't really hurt much, especially considering that people having such misbehaving chips are basically stuck with no alert protection at all.

Sorry, I didn't understand your idea first, now I got it That sounds like a useful feature, will give it a thought.

Though I'd still prefer that the sensor would provide correct data always. Are you setting the fan speed using the ASUS tool? Can you try SpeedFan if that might configure the fan speed in a different way and thus report better values back ?

 

[Mexxxi]

Sorry, I didn't understand your idea first, now I got it That sounds like a useful feature, will give it a thought.

Awesome

Though I'd still prefer that the sensor would provide correct data always.

Yeah, I think no one would disagree with that

Are you setting the fan speed using the ASUS tool?

Yes.

Can you try SpeedFan if that might configure the fan speed in a different way and thus report better values back ?

Good idea. I did just that, but I'm rather disappointed. Unfortunately, SpeedFan has insanely long update frequencies and those don't allow for tracking quick value changes. Even when it's plotting fan speeds in its graph:

Going below 700rpm triggered the strange sensor values. Thanks to the long update delay, SpeedFan only showed 0 RPM but in the diagram you can see that it also read 637000rpm just like HWMonitor.

I can congratulate you on HWiNFO, because despite its constant 0-value jumps it was still capable of tracking the speed down to about 400 RPM (40% in SpeedFan) until it finally gave out and showed only zeroes.

In SpeedFan I was able to lower the speed to 25% (250-300 rpm) till the fan actually stopped, so from an ideal point of view, tracking software should be able to show appropriate values right up to that point. HWiNFO comes very close though.

I did stumble over another bug in this regard though. I had the chassis fan running at 100%, started SpeedFan and lowered it immediately to 35% and HWiNFO started to show values ranging from 33000 to 135000 rpm. I appended a csv to showcase the bahavior. Seems like the function you employ to filter out outrageous values has a loophole

 

[Martin]

Thanks for the feedback.
That another bug you found is still related to the same fact that the ITE fan monitor has problems measuring certain low fan speeds.
HWiNFO currently uses filters for too high/too low values, so the question is what should be the upper limit for this filter. In the CSV I can see speeds ranging from 135000 to ~10000 which must be wrong. Since there are so many erratic values, it seems to be a constant issue when the fan speed is too low.

 

[Mexxxi]

You're welcome. May be it would be a good idea to allow the user to set an upper limit for valid values. The chassis fan I'm using tops out at 1200 rpm, while my CPU-fan manages to reach 7000 rpm. The borders for validity vary greatly, so only the user can safely tell where the right dropoff point is.

 

[Martin]

Have you seen the new version released v4.42 ? I hope you like the new feature in sensors