Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Solved FPS drops
#1
Very strange. For some time I have to constantly fight with FPS drops (125 to 50), very annoying. I tried everything to get it away. After much testing I noticed that it is up to hwinfo. I've checked several times and it is actually hwinfo, comes when the sensors (temperature sensors) are running in the background it again at frequent intervals to cut FPS drops.

How can that be?
Reply
#2
Depends on particular sensor/system. Some of them (SMART on certain systems) might cause a CPU load when trying to read the value.
Please try to disable the sensors one by one until you find the one which is causing this problem. Then let me know which one it was.
Reply
#3
Follow sensors cause the problem.

[img][Image: unbenanntw3p7a.jpg][/img]

I can not say exactly what. I switched one after the other, it was slowly getting better, but it was completely gone off only when I have all the listed.
Reply
#4
I see now.. Indeed, the EC sensor is one case which can consume more resources when read.
Unfortunately there's no workaround for this, so the only advise I can make is to disable this sensor in case you don't need those values and don't want to see performance drops.
Reply
#5
Ok, if there is no other way. Then there is the best solution for sensor disable.

Thank you
Reply
#6
Got some kind of the described problem, but...
When I run simultaneously hwinfo and dead island, the game renderer freezes every time hwinfo is reading the sensors.
Have not seen such a behavior in any other game.
Also, when I was running an amd platform, freezes were not that annoying. I've even thought it was the game engine feature. Now I know it wasn't.
Reply
#7
Have you tried to disable some sensors if that fixes this issue? If yes, which sensor was the one causing it?

(06-06-2012, 05:24 PM)ckotick Wrote: Got some kind of the described problem, but...
When I run simultaneously hwinfo and dead island, the game renderer freezes every time hwinfo is reading the sensors.
Have not seen such a behavior in any other game.
Also, when I was running an amd platform, freezes were not that annoying. I've even thought it was the game engine feature. Now I know it wasn't.
Reply
#8
Well, it's "ASUS P8P67 EC".
So, it seems that if there were any freezes on amd platform, they have not been caused by hwinfo.
The most strange thing is that I'm experiencing freezes only with one game.
Reply
#9
well. i had problems with this sensor too

look at pics, when reading sensor was enabled
[Image: 12.jpg]


weird Gflops....

and when the sensor was disabled:
[Image: 11.jpg]


please, disable the 'eating resources sensor' and be happy
Reply
#10
I can't disable this sensor for all users, because there are users which need these values.
I'm thinking about adding some kind of warning when such sensor is found, so users will be aware...
Reply
#11
(06-17-2012, 07:47 PM)Martin Wrote: I can't disable this sensor for all users, because there are users which need these values.
I'm thinking about adding some kind of warning when such sensor is found, so users will be aware...


ya, i know

when i'm adjusting my OverClock, is very nice to che Vcssa, PLL and others.

later i only need to disable show reading in order to get an optimal system

I can confirm you, if i use the Asus Suite Monitor Sensor (Asus Formula X79 Rampage), i have the same problem.

A Warning message will be nice for some users that doesn't know this sensor problem

Thanks
Reply
#12
Moreover, if you run ASUS AI Suite with HWiNFO in parallel, it can happen that one of these applications starts to report wrong data from this sensor.
That's because of a conflict between them. Unfortunately, there's no will at ASUS to solve this situation by adding a synchronization between their tool and others.

The next build of HWiNFO will display a warning if such sensor is found...
Reply
#13
(06-18-2012, 03:21 PM)Martin Wrote: Moreover, if you run ASUS AI Suite with HWiNFO in parallel, it can happen that one of these applications starts to report wrong data from this sensor.
That's because of a conflict between them. Unfortunately, there's no will at ASUS to solve this situation by adding a synchronization between their tool and others.

The next build of HWiNFO will display a warning if such sensor is found...

Hi Martin.

I know if i run Asus Suite and HWInfo together, I have some wrong reads (like Temp -125 CPU, 0.00 +12Vdc, etc......)

I only use Asus Suite to adjust in first step, my OC (possibility to change Vcore on the fly, and other parameters). then I close and disable Asus suite sensors etc.....

I only use Hwinfo (is very usefull with RTSS to get a good info console while gaming)

The only APP from asus that i usually use, is Xfan to make a custom profile for my fans (and this because i can't control my fans with other software..... Sad)

Thank you!
Reply
#14
Since 4.24 I'm experiencing heavy freezes while HWiNFO performs the sensor scan.
4.22 is fine, 4.25 beta is not. Seems something was changed.
Tried disabling sensors 1-by-1, got no effect. Compared the settings GUI in 4.22 and 4.24, found the difference in "CPU clock measurement" block. Disabled periodic polling – no effect.

.zip   HWiNFO64.zip (Size: 74.71 KB / Downloads: 2)
Reply
#15
The only items that might cause such problems on your system are:
- ASUS EC sensor. But it seems you have this one disabled. Maybe try to disable the entire "EC Support" in HWiNFO to see.
- S.M.A.R.T. sensors. Maybe try to disable the entire "Drive scan"..
Please let me know the results...
Reply
#16
Ok, it's really S.M.A.R.T. "sensors" of HDDs. Each adds approx. 5% CPU usage on scan. SSD "sensor" has no impact. 20% CPU on scan is kind of extreme.
Weird. It worked fine before.
I have also noticed the same change of behavior on another system (my office PC) with one Hitachi HDD (and one Seagate; I'll look tommorow if it has any impact).

Btw, 4.22 consumes no more than 0.4% CPU on scan with HDDs while 4.24 goes up to 0.8% without HDDs.
Reply
#17
v4.24 indeed changes the way how (S)ATA drives are enumerated and communicated with. But in both cases (v4.22 and v4.24) all the SMART queries for drive status/temperature go thru storage drivers and these are responsible for any excessive usage. Certain versions of Intel RST drivers are known to cause such issues. Please try to upgrade the storage driver (RST probably in your case) to the latest version and let me know the result.
Reply
#18
Checked my office PC. It was using the same driver version 11.2. Hitachi's S.M.A.R.T. caused heavy freezes, Seagate's – no freezes, but still significant CPU usage.
Updated driver to 12.8 – no freezes and CPU usage went down to 0.4% (but it's a dual-core machine; should be 0.2% on a quad core like my home PC).
But. Driver versions 11.5 and newer mess something up in the system (ATA –> SCSI) and my home Windows (OEM license) starts demanding reactivation (it seems that no more hardware changes are allowed in it's current state – I cannot even change the MAC-address without the need for reactivation). I'll stick to 11.2 and 4.22 for a while...
Reply
#19
If Windows demands reactivation without a real reason, you might call the Microsoft activation hotline and tell them about that. From my experience they approve the reactivation without asking too much Smile
Reply
#20
Reactivation is not a problem, actually. Just not going for it in the nearest future.
At least now I know what's the source of these freezes.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)