View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001726 | SpeedFan | Configuration | public | 2011-01-09 09:06 | 2011-01-17 17:49 |
Reporter | DavidGGG | Assigned To | alfredo | ||
Priority | urgent | Severity | major | Reproducibility | sometimes |
Status | acknowledged | Resolution | open | ||
Platform | Windows | OS | 7 | OS Version | Home Prem Ed 64b |
Product Version | 4.42 | ||||
Summary | 0001726: Multiple issues, which make SpeedFan lose control | ||||
Description | 1. At startup: Around 1 times out of 10, it fails to load SF through the scheduler. I solved this by instead adding it to the Aytostart folder. Then it never fails (but takes longer to load and thus makes more noise). Therefore this is minor. (Did try all settings in schedular first, like rettrying 3 times etc.) 2. During normal use (even idle): SF on one PC believes it sees a very high temp (from chipset I think) for 1-2secs, and therefore sets fan to 100% speed for maybe 1 sec (then slowly decays). Can be seen very clearly in the charts. On this PC I had tweaked scheduler settings etc for all Windows apps (this is the first prototype PC and thus has been used for some tests). If I run the same system with a different HD cloned from a fresh install (without scheduler tweaks), it doesn't have these issues. It could be easily fixed if SF would ignore too high temp that doesn't last at least 3secs (or adjustable from 0 to 9s). 3. The remaining, major issue: After reboot, it sometimes (maybe 1 reboot out of 5) forgets a few settings. Two PCs have forgotten temp threshold & warning level for HD0, two have forgotten the same for Cores 2 and 3. At the same time it forgets my "log" tick, and ticks that select which fans these temp sensors shall affect. I have one interesting clue: The order of the temp sensors usually is Temp1-Temp3-HD0-Cores 0 through 3. Last time it forgot Cores 2&3, the order was Temp1-Temp3-Cores0&1-HD0-Cores2&3. (I have seen similar issues in this forum for other PCs but no cure is mentioned even though threads may be closed, I assume a new version of SF is supposed to have fixed it in those cases.) | ||||
Additional Information | Privileges set to high. Working sensors are named Temp1, Temp3, HD0, Core0-3. Temp1 probably is chipset, Temp3 probably some extra CPU sensor. One fan only. Says it finds "IT8720F" in tab "advanced". Access through both ISA and SM bus in options tab. Will move on to beta 4.4.3 now. | ||||
Tags | No tags attached. | ||||
Motherboard Model | Gigabyte GA-H55N-USB3 | ||||
Video Card Model | GPU chip inside Intel Core i3-540 | ||||
|
1) Please, send me DEBUG.NFO from SpeedFan's directory after program fails to start. 2) CPU temperatures can raise very very quickly. This is the reason why high values are not ignored. I will consider adding an option to ignore spurious values, but it would be slightly dangerous. 3) It is difficult to understand how SpeedFan could lose settings only partially. Can it see the relevant sensors? The latest beta improves ITE sensors detection and this might fix the issue. |
|
|
|
|
|
1) At the moment I start SF via autostart folder on all PCs, which seems to fix that issue, so I have no logs. I should be able to provide one later, but I still hope to get one PC to work properly today, and so I'll stick with autorun for a while. 2) Seems this is mostly related to my PC (MB, CPU and/or communication). Just uploaded 2 chart pics. Temp chart (blue is HD): I get these glitches on Temp3, often over 40degC, and not related to any system events. The last glitch in this chart caused the fan to get activated (see fan speed pic). And seems the fan speed info also has false glitches: I was in the same room and probably would have heard if the first 5 fan speed glitches in that pic actually occurred. Also note that the last speed glitch (which is a true one) shows a pretty decay slope while the other ones don't - a true glitch should have such a slope. And temp going up 40C then down to the present value within 2 secs doesn't seem believable. What happens if I start some program that uses the CPU/GPU on a healthy board is that I can get temp glitches of maybe 6-7degC. Should try this on at least one more PC though. Edit: Just saw a negative glitch from 52C all the way down to 0C for Temp1 (not Temp3 this time) for ~2secs on the bad PC. Weird. The bad PC is since this morning using a HD cloned from the good PC, and that didn't help, so it seems to me it must be a HW error on a bus or in the chipset or something (can't really be the sensors or software). Meanwhile, charts on the good PC are nice and stable. 3) Don't understand what you mean by "can it see"? (Seems to me it might have a hard time finding them fast enough at startup, but that they are always present when I open the i/f.) |
|
Update of item 2: I get these unnatural transients on 3 different PCs, all using the same motherboard, one with Pentium G6950. Glitches occur on both sensors "Temp1" and "Temp3" and also on the fan speed reading. E g fan speed stable at ~1477rpm then suddenly 3342rpm during 2 log entries then back to a stable 1477rpm (this being a false glitch). And >20degC glitches on Temp3 and Temp1, sometimes causing fan to speed up in a very annoying manner. System idle, and I monitor CPU activity (there is none). Transients can be gone for hours, then come more than one within minutes. I bet this is related to the similar problems I had when trying the original Gigabyte temp detector / fan regulator (Easy Tune), both on this board and on a u-ATX Gigabyte board I used spring 2009. Adding a filter to SpeedFan might help. When starting a task at 100% CPU I note it takes over 10 minutes for Temp1 and Temp3 to reach 70C, so a 1 to 9s filter shouldn't cause any problems. Edit: Being convinced both the Gigabyte and Almico fan controllers failed to communicate properly with the sensors, and having looked through a bunch of old SpeedFan logs which almost always showed occasional transients of 20 or even 30deg that I don't believe exist IRL, I decided to move on to a different project. Before I did, however, I decided to try the beta. And..... This is something else! Temp1 and Temp3 are VERY stable! So far anyway... will let it run over the night, and check the logs. Edit2: After 5 hours: One PC ran idle, had no glitches. The other one ran almost idle (playing an AAC stream in Winamp), it had 3 false glitches on fan speed, 2 positive glitches on Temp1 (+13 and +15C, possibly true), and 4 glitches down to ~0C on Temp3. Conclusion: Still glitches. SpeedFan not useful for this system (except maybe for home users who don't mind occasional fan bursts) |
|
Are you running SpeedFan together with another similar tool? |
|
No other temp monitoring tools active (such as easy tune, real temp etc). Can give you a complete list of installed SW if you want. Just uploaded info from two PCs, put "bug report 1726" in motherboard field. |
|
Thank you for the report. I'm investigating. |
|
What is the value that you see in logs when you see the glitch? Is it a completely wrong value, like 0, 128 or 255? |
|
Typically for Temp3 it is +20 to 30C (although many of amplitude around +10C also occur). For Temp1 (which is usually near 50C) it is often negative spikes down to between 0 and 5C, but sometimes positive. The fan (I have only one) has spikes independent of the temperature events, from the typical idling value just under 1500rpm to e g 2626rpm or other values in that vicinity. The fan can also have spikes triggered by false temp events - I can see the difference since these occur just after a temp goes above a threshold, and there is a decay slope on the fan speed then (have set speed step to 2% so it's quite slow) All false spikes of duration 1 to 2 log intervals (most often 2) |
|
According to what you are reporting it looks like the actual sensor is returning wrong data. Did you try to log values using any other tool and having SpeedFan closed? Consider that +20 to +30C can be a real temperature increase from the previous reading and that ignoring it for some seconds can be dangerous. I'm writing some code that tries to fix this automatically. |
|
Didn't try logging, but have tried Gigabyte's Easy Tune 6 for regulating fan and it too quite often thinks temp is too high when itäs not and that fan is standing still. Same problems on different Gigabyte uATX board spring 2009, and more problems than with SpeedFan. I have my suspiscions more on the communication bus than the sensor itself, especially since the rpm value has the same kind of errors. How on earth can temp increase 20C in 2 secs the go back to prev value 2 secs later when idle and fan at low speed, when for the same system with CPU at 100% it takes over 10 minutes for a bigger temp increaase? Seems to me there are time constants involved here, which are in the order of several minutes. |
|
Consider that you are looking at your specific setup while I refer to the rather large number of different setups I have seen in over 10 years. According to your findings, anyway, it seems that the glitch is originated by the H/M. Communication in your case is hardly a cause because ISA is very easy to access and having a collision there is highly unlikely to happen. |
|
Item No.2 solved! When you said it could be a conflict (and I thought it must have to do with communication rather than HW), I used Autoruns to look through all startup items (and active processes) and there was only one that I at all suspected: des2srv.exe (or des2svr.exe?). Des2 is Gigabyte's "Dynamic Energy Saver 2" which you probably heard of, and I knew I had installed most Gigabyte utilities that came with the MoBo and updated them but not activated them. Turns out des2srv.exe is a helper app for that, that provides "stealth mode".. I tried killing that process and logged data on 3 PCs over night (two with 4.4.2, one with beta) and all 3 were totally glitch free on Temp1/Temp3/Fan speed! Meaning none even had a step of 10degC or 100rpm. Edit: After trying restarts about 40 times, I conclude that item 3 also is solved. Item 1 however (failing to start when on scheduler) is not. I have solved it by using the autostart folder, and I don't have time to test it more now anyway. |
|
Sorry for the late answer. I got flu. Now I feel better. I am happy to read that most issues are no longer an issue. To look at issue #1 I need DEBUG.NFO file from SpeedFan's directory after a failed start. |
|
I hope to be able provide that in the near future when I have more time. For now I am satisfied with the autostart folder solution. //DS |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-01-09 09:06 | DavidGGG | New Issue | |
2011-01-09 09:06 | DavidGGG | Status | new => assigned |
2011-01-09 09:06 | DavidGGG | Assigned To | => alfredo |
2011-01-09 10:49 | alfredo | Note Added: 0005665 | |
2011-01-09 10:49 | alfredo | Status | assigned => acknowledged |
2011-01-09 14:43 | DavidGGG | File Added: temp charts V6-1 recent fan burst.jpg | |
2011-01-09 14:44 | DavidGGG | File Added: speed chart, a few secs before temp charts.jpg | |
2011-01-09 14:51 | DavidGGG | Note Added: 0005667 | |
2011-01-09 15:15 | DavidGGG | Note Edited: 0005667 | |
2011-01-09 16:53 | DavidGGG | Note Edited: 0005667 | |
2011-01-11 02:36 | DavidGGG | Note Added: 0005669 | |
2011-01-11 04:16 | DavidGGG | Note Edited: 0005669 | |
2011-01-11 09:48 | DavidGGG | Note Edited: 0005669 | |
2011-01-11 10:13 | DavidGGG | Note Edited: 0005669 | |
2011-01-11 11:01 | alfredo | Note Added: 0005671 | |
2011-01-11 11:04 | DavidGGG | Note Added: 0005672 | |
2011-01-11 11:10 | alfredo | Note Added: 0005673 | |
2011-01-11 11:12 | DavidGGG | Note Edited: 0005672 | |
2011-01-11 11:20 | alfredo | Note Added: 0005674 | |
2011-01-11 11:28 | DavidGGG | Note Added: 0005675 | |
2011-01-11 12:09 | alfredo | Note Added: 0005676 | |
2011-01-11 12:22 | DavidGGG | Note Added: 0005677 | |
2011-01-11 12:47 | alfredo | Note Added: 0005678 | |
2011-01-12 08:09 | DavidGGG | Note Added: 0005681 | |
2011-01-12 22:35 | DavidGGG | Note Edited: 0005681 | |
2011-01-17 10:08 | alfredo | Note Added: 0005700 | |
2011-01-17 17:49 | DavidGGG | Note Added: 0005706 |