View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001746 | SpeedFan | Fan control | public | 2011-02-05 15:23 | 2011-07-13 09:46 |
| Reporter | phobos | Assigned To | alfredo | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Multiple AMD & Intel | OS | Multiple Windows | OS Version | All |
| Product Version | 4.42 | ||||
| Fixed in Version | 4.44 beta | ||||
| Summary | 0001746: Temperature range for fan speed increase. | ||||
| Description | Feature request. Have been using Speed fan for many years now and love it. But the problem I have is that fans seems to go either at their minimum or maximum value, without much in between. What I mean is that you have a desired temp for a component (GPU, CPU, etc) and below that temp the controlled fan sits at the min set speed percentage. When the temperature goes over that desired value (even if by just 1-2C) the fan straight away goes to full speed. What would be preferable is if there was a temperature range where below that range the fan speed would be at the minimum setting and at the top of the range the fan would be going fully. But within the range the fan would increase speed in a linear way rather than this binary either minimum or maximum. So I could say set a range of 10 degrees C from 50C - 60C. Under 50C the fan would say go at 0% and at 60C the fan would be going at 100%. And for every degree C over 50C the fan will increase by 10%. Obviously the temps and percentages are just an example and you would be able to select different things for each of these. I thought that would be the purpose of the warning temp setting, but it has no effect. There already is a bit of a step increase in fans speed but it happens over only 2C, which is not much help. The behavior I get at the moment with speedfan for say controlling my CPU temp is that the fan just see saw between min speed and max speed, since min speed is not enough to keep it below the desired temp and max speed is too fast so the temp and fans go up an down with the load on the PC being constant. With my a temp range the system would find an equilibrium between fan speed and temperature automatically. This is not something new as it is the system most fan controlling motherboards already have this setup with a max and min temperature setting where it works out that if the temp is in the middle of the range the fan does not have to go at full speed. And it works really well, so much so that I am reluctant to use speedfan on these PC's. Now I realize I may not have made myself very clear, so please if this does not make sense please contact me so I can explain better. But the bottom line is that it is definitely something where on-board motherboard fan controllers have an advantage over Speedfan at the moment. | ||||
| Tags | No tags attached. | ||||
| Motherboard Model | Multiple | ||||
| Video Card Model | Multiple | ||||
|
|
Also sorry if this feature request has already been logged. But after much searching I could not find it anywhere. |
|
|
I thought about it too, adjustable linear interpolation of FAN speed would be great! |
|
|
I'll second this suggestion. It's something I, too, have always thought would be very good to have in SpeedFan. Below a minimum temperature, the fan stays at a selectable minimum speed (which could be 0 RPM). Above a maximum temperature, the fan stays at a selectable maximum speed (which could be the one corresponding to 100% PWM). Between those two, the PWM changes linearly with the temperature (yes, this won't mean a linear variation of the actual speed for most fans, but it's still good enough - not worth making it more complicated than that). I've set up my graphics card fan this way (through the fan controller integrated on the board, accessible through Rivatuner) and it's working great; it does a very good job of keeping the board quiet when idle and cool when playing games. This could be an optional behaviour that could be selected in the configuration dialogs; people who like the current behaviour could then keep it as it is. |
|
|
Basically, it would require only two settings (two points) - two pairs (TEMP t, RPM(t)), below t0 RPM would be set to selected minimum, above t1 to selected maximum, and linearly interpolated between t0 and t1. http://img145.imageshack.us/img145/4302/image1km.jpg |
|
|
I don't see the problem. SpeedFan already allows three different rpm settings for each fan. Below the "Desired" temperature, SF uses the minimum rpm. Between "Desired" and "Warning" SF uses the maximum rpm and above "Warning" the fan always runs at 100 %. For example: Core Temp 1 and Fan 1. I set the desired to 63°C and warning to 70°C. Fan speed settings are 48 and 70 %. With those settings the fan runs at 48% below 63°C, at 70% between 63 and 70°C and at 100% above 70°C. If I understand Phobos correctly, that's exactly what he wants, isn't it? |
|
|
Thanks everyone for your responses. I was just expecting this suggestion to be ignored. @norman02us. I did not of know that behaviour existed, so you post was very educational to me. But it was not the behaviour I was requesting in my feature request. @wlw_wl you have pretty much described what I mean. To see the type of behaviour I am on about you just have to look how hardware fan controllers on motherboards and GPUs work when speedfan is not used. That's if you are lucky enough to own a motherboard that has this. But all modern highend Nvidia and ATI cards do. You see that the fan speed goes up as temperature does. The min and max temp range are hardware programmed but can be changed with software like rivatuner, etc. For motherboards like the ones made by ASUS (which all seem to have this). The motherboard bios can be set with max and min temps for the fan speed of the CPU and chassi fans and will increase fan speed in a smart way, in that range. Now don't get me wrong, I understand that setting this up might be tricky for speedfan, becuase wheras the hardware fan controllers, I have described, have only to workout 1 fan to 1 temperature relationship, speedfan has mutiple tempertures to multiple fan relationships to workout. Though if requested I do have some idea of how to deal with that. For example I have chassi fan speeds tied to my GPU temps as well as the motherboard temp in speedfan. With the on-board controller it is only tied to the motherboard temp. So speedfan has the advantage. But the mothervoard controller and other hardware controllers increase the fan smoothly over a temperature range, rather than only giving 3 set speed options of below desired, above desired and above target. So anyway as I said to get an idea of what I am on about, just have a look at how your GPU controls fan speed. |
|
|
Just to add some info: Graphic cards use 4pin PWM controlled fans. Their control mechanism is very different from 3pin voltage control. |
|
|
@norman02us: As far as I know, these days, many (most?) motherboards have at least two 4-pin fan headers as well: the one for the CPU, and another one for case fans. Those headers use PWM control, just like the ones on the graphics cards (I'm using PWM control on all my three case fans, for example). Anyway, I think the suggestion is valid regardless of the fan speed control method: have an (almost) linear, continuous relationship between temperatures and fan speeds, not just three discrete fan speeds, as mentioned in your first post (by the way, I'm using pretty much the same setup as you, and it works, but I think what's been suggested in this thread would be better). @phobos: Regarding the one-fan-to-many-temperatures relationship, I'd say there's a pretty simple solution: have as many one-fan-to-one-temperature relationships as there are temperatures, then calculate the fan speed that results from each of those relationships, and then take the largest value and apply it to the fan. I think SpeedFan already implements this logic when a fan is tied to multiple temperatures, so there may not be any change needed in this area at all. |
|
|
Also it is worth noting, that SpeedFan doesn't just switch from min to max value when temps change. It modifies the speed one step by step, each step being equal to delta fan speed setting. It isn't enough, however, because the steps occur too fast for the temperatures to react to modified fan speeds. In the end it all comes down to setting the highest speed for given range, be it Speed Max (setting) or Absolute Max (100%). That's why I think the user adjustable interpolation would be great. |
|
|
@mikutoc. That was exactly the way I was going to suggest handling it with the largest value being used. Good to hear that it is not that different to how this is being done at the moment. Like you, all my fans are PWM. But I only really use Speedfan on my gaming PC, due to wanting to make more fan to temperature relasionships than the hardware controllers can do. On all my other PC's I use the motherboard hardware controllers (have always only brought motherboards that can automatically control fan speed) since they have the linear fan control that would be great to have in speedfan. This control happens with both 4 pin PWM and 3 pin voltage controlled fans so it is not functionallity that can only happen with PWM. Anyway I still have no idea what a good description / name is for this functionallity but I think at least everyone here knows what I am on about so that is good. So I will leave you all to work out if it is possible with speedfan in some future version. Thanks again for the feedback. |
|
|
@wlw_wl: Good point. The algorithm used by SF to adjust speeds is clearly more complicated than just setting those three values, but it usually ends up that way. The speed of the variation can be adjusted in the settings (Configure -> Options -> Delta value for fan speeds) but, even for a 1 degree delta, it still ends up with the three values; I have mine set to 3. On the other hand, you sometimes want the fans to react quickly to some temperature increase (the sooner they change, the cooler it stays), so, setting a very low delta is not really a solution. Basically, the delta value establishes the slope of the speed variation curve in relation to time, whereas what we need is a curve in relation to temperature. In all fairness, I'll say that, sometimes, I notice the fan speeds stabilizing at some intermediate value between min and max speed; rare, but it does happen. However, they stay there much longer than I would like them to. I suppose the algorithm tries to infer what intermediate value could keep the temperatures to their desired values, based on past variations - quite a difficult task, and it's not very successful at it, unfortunately. That's why I, too, think that letting the ancient and simple principle of continuous negative feedback do all the work for us is a simpler and more reliable solution. |
|
|
I think it works on a much simpler basis: when there is a need to increase the fan speed (temperatures passed the desired level setting + histeresis), it's being increased by [Delta value for fan speed] per time unit (couple of seconds) until there is no more need to increase it - temperatures fall back down. If the temperature still rises or is static but above desired level set, the speed will be increased further, until max speed setting. Or until warning level is passed. It's not very effective when there is a sudden change from 0% to 100% for example on CPU usage. The fan is most likely idling on minimum setting while the CPU temp is rising fast, fan speeds up when the temp passes desired level, but the temperature is still climbing, because fan speed is being adjusted slowly. Solution proposed here would allow fluid fan management, which would ease such temperature climb in a first place, and then counter it more efficiently. |
|
|
Take a look at this. My new GPU has this tiny but brilliant app called Trixx, and its Fan control is *exactly* what we are talking about here: http://img251.imageshack.us/i/image1whk.jpg/ Left click on the line adds a new point, right click deletes the point. You can move the points around, they snap to the grid every 1 degree Celsius/1% fan speed. Just excellent. |
|
|
@wlw_wl: Very nice. That's pretty close to the Holy Grail of fan speed control. That said, I think it would be a bit too much in SpeedFan. I think the simple graph described by two points, the one in the first image you posted, would do just fine. It would also make the user interface implementation much simpler, with no need for displaying interactive graphs, just four numeric fields - for the two pairs describing the points. |
|
|
Agreed, just given an example of awesomeness. |
|
|
I am working on this, but remember that SpeedFan can control each single fan using multiple temperatures. Something that the proposed tool seems to be unable to do. |
|
|
Alfredo, SpeedFan rocks! There's no debate about that. It's the only tool (that I know of) that can control several fans in a system in a concerted fashion. That's why we're all using it. As wlw_wl said, Trixx was only given as a graphical example of a method of fan control, not as a replacement for SpeedFan, not by a long shot. The only purpose of this discussion, with the included suggestions, is to make SpeedFan... rock even more. By the way, I'm a programmer with quite a bit of experience with system-level software (I've written a couple kernel-mode device drivers for NT and 2000 at some stage in the past). I may be a bit rusty at the moment, but, if I can help in any way, just let me know. |
|
|
@mikutoc Thank you. I might ask you something in the "near" future :-) About the graphical example, that's exactly the same kind of graph I created in one of my prototypes. At the moment I am trying to define a powerful, yet easy to use, interface to allow users define complex fan responses based on multiple temperatures. |
|
|
I'd say, for a start, a minimal change to the interface could implement the basic solution suggested in comments number 3 and 4. Basically, you'd need to replace the 'Desired' field on the 'Temperatures' tab with two fields - 'Low' and 'High' temperatures. These two, together with the 'Minimum' and 'Maximum' values on the 'Speeds' tab, would specify the two points needed to describe the linear variation. I also think you should keep the existing behaviour unchanged, and provide an option on the 'Options' tab to switch to the new algorithm; after all, there are lots of people who have working configurations and are happy with them. You could also keep the 'Warning' temperature field with its current role. The user could choose the 'Maximum' value to be 100%, in which case the 'Warning' field would be redundant. But, in case 'Maximum' is set below 100%, 'Warning' could provide an additional point, as it does now, to set the fan to 100%. Besides the interface change, the burden would fall on the algorithm implementation: calculating the fan speed based on the linear curve, and then combining the resulting values to get the actual, final, speed. I think you already have the second part implemented - get all individual speeds resulting from the separate dependencies for each temperature, then take the highest one. Of course this could all be implemented with a nicer interface, but, for starters, as I said, I think the simpler solution together with a short explanation in the tutorial would do just fine. |
|
|
SpeedFan 4.44 beta is online. What you asked for is finally available, but... with many more options (some yet to come): - a fan can be controlled by multiple temperatures - the relationship between each temperature and its intervention on the fan speed is graphically configurable - different histeresis for each controlling temperature - final fan speed depending on SUM of interventions or on MAX intervention. I have other options to add, but before I tailor the new method to my own point of view, I would like to hear your voice. |
|
|
First comment: WOW! Great stuff, Alfredo. I took a quick look at it, but I won't be able to do much more until later in the day or tomorrow. Expect a looong comment at that stage, with questions and suggestions - I have quite a few written down already. I just didn't want to miss the opportunity to say a big 'thank you' for your work on this - excellent, as usual. |
|
|
Thank you :-) |
|
|
A dream has come true! Thank you so much for implementing this feature. I've played around with it and here are my suggestions so far: This is is the fan-speed table i would like to have: http://s7.directupload.net/file/d/2482/kudsfuko_jpg.htm Yes, i know, it's not possible to set this kind of ramp in the settings dialog with the mouse. So I had to manually set them in the configuration file. The corresponding case-fan is 140mm in size. It's huge disadvantage is that it start's at about 8-9V (70% Speed). But once it spins, the fan would run at 40% also. So my idea was to ramp it up at a certain temperature to get it going and let it fall down to the 40% cause the airflow is high enough. But it's not working. Everything runs fine 'til the temperature hits 42°C and after that the speed is not changing at all. The funny thing is that when I'm heating the CPU up to for example 47°C and just press "OK" in the settings dialog and let the CPU cool down, the ramp is working as expected! So I wonder if you could do something about it? Besides , the "Remove" buttons are actually doing nothing. Oh, and is there a switch or some option that would enable the advanced fan control at the start of program? So that I don't have to enable it manually in the settings everytime it starts? |
|
|
@Yako Thank you for explaining the reason behind the odd ramp. I will add more checks in the future. This means that your "hack" will no longer work. The need to give a "short" overvoltage to the fan to make it start makes sense in some configurations. The problem is that, in order to achieve this in a more polite way, the fan controller would need to know which is the fan it is acting on and which is the reported fan speed to check in order to decide whether the initial pulse is needed or not. My suggestion is to never let fans stop in this case. Thank for reminding me of REMOVE buttons. The advanced fan control is not yet a sticky option. To be honest, I considered this feature so young that I didn't even think that one of the first requests would have been to have it running without any further intervention :-) |
|
|
Hey Alfredo, the new speed controller is very nice :) Here is my input on it: - the number of points should be configurable, e.g. you start with 2 points (0% and 100% for example), right click adds a point, left click moves the point - when you add multiple temperatures to the controller, the graph should be copied from previous/first temperature on the list, it's a bit of a hassle to configure 6 graphs that look (almost) the same; solution from first point solves this to some degree - I configured one fan based on CPU temp. and it's stuck on 50% while it should be about 30% according to the graph. It's not adjusting. Other controllers work fine. The fan is being properly adjusted using the old method. Also, the speed limits are 25% and 100%, so it should go down but it won't, no idea why. When I manually change it's speed up or down, it's going back to 50%. - where is ATI GPU temp readout? :( You said 4.44 will show it :( quote in view.php?id=1712 |
|
|
Hi Alfredo, This is the best! Just spend few hours testing v4.44 beta 2, As @Yako said: "A dream has come true!" And just one suggestions IMPORTANT: In advanced fan control, "Histeresis", doesn't work as expected. An example with 1 fan (on CPU). My graph is set from 49-56 deg. 1st point at 0%, 2nd point at 50% and others goes smoothly to 100%, hysteresis set to 10 deg., so when temp. raise it works fine, at 49 deg. fan is off 0%, at 50 deg. fan starts at 50%, at 51 - 60%, 52 - 70% and so on. But when temp goes down, from 52 deg, to 41 deg. (hyst. 10 deg), the fan stops, rather then just go back to 60%, and at 40 deg. goes back to 50%, and at 39 deg. to 0% (off). And something else, @Yako wants to be added "ramp" to fans, for example this could be done by setting "ramp" time for every fan, for example if "ramp"=200 (mS), means starts fan at 100% for 200ms and then set to desired point, so if ramp=0 means 0 ms at 100% (ramp off). Or something like that. Can be done the hard way, by sensing fan speed... which is not nessesary. P.S. Another idea for easier setting is to make graph with just 2 points: start temp. and %; end temp. and %; max. temp. (above which set 100%), and min. temp. (under which set to 0% - turn off fan). Thanks again for the great work! It's really a DREAM CAME TRUE! Another P.S.: Hmmmm.... about histeresis. When temp. raise it's just taking fan speed from graph table. May be this could help "solve the idea" when temp. fall down: {function graph(temp), returns fanspeed for specified temperature.} If fanspeed > graph((temp+histeresis)) then fanspeed:=graph(temp+histeresis)); |
|
|
alfredo: Histeresis is shown in *C and *F, for 2*C it says 36*F. This isn't right. I mean it's right if you mean that the absolute temperature is 2*C which is equal to 36*F. I suppose it calculates that with this formula: [*F] = [*C] x 9/5 + 32 which is right for converting temperature readout, while for temperature interval it should be calculating it using this formula: 1*F = (5/9)*C = 0.55555555(5)*C So it should say "Histeresis 2*C (1.11*F)" etc. |
|
|
As the original requester, I wanted to put a big thank you out to alfredo for putting this out there so quickly. Have been wanting to have this on speedfan for may years, and had requested it before. But maybe the suggestion was before it's time and did not reach critical mass. Unfortunately due to 'other circumstances', I won't actually get to try out this super new feature, I have been waiting for, for so long to try untill late next week and will comment and probably shower more praise then. Really looking forwards to trying it out and taking part in perfecting the feature. But until then thanks again for the quick turn around on this. This has out a smile on my face, it has been lacking a bit recently. So thanks for that. So now if not already, speedfan is unquestioned, the ultimate software for looking after cooling on a PC. Good work..... For those asking about ramping fans to get them started. I normally have this becuase I have ticked the option 'set fan speed 100% when closing speedfan'. This seems to mean the when speedfan starts it put's all fans to 100% at sartup and then down speed the fans to the speed that speedfan wants. I use that to get all my fans started at speedfan startup. But I may be missing what you are wanting or something with the new features. |
|
|
@wlw_wl You are absolutely right. I fixed it. |
|
|
Thank you phobos :-) |
|
|
Do you mean that you uploaded new file while the version is the same with those small fixes, or that it will be applied in next beta version? :) |
|
|
Fixes will appear in new beta :-) |
|
|
As promised, here comes the long comment: First, the most important issues. Two strange things happen when you select 'Advanced fan control': 1. On the one hand, it looks like the settings in the 'Temperatures' section are disabled for all fans, even the ones for which there is no fan controller defined. I defined a fan controller for the case fans, but left the CPU one alone; when I loaded the processor, its temperature rose up to the warning level, but its fan speed didn't change. I think there should be a warning about that. 2. On the other hand, it looks like the settings in the 'Speeds' tab are somehow still in effect: even though the case fans had a fan controller defined, with continuous graphs and all, the PWM values still jumped between the minimum, maximum and 100% values, as defined in the 'Speeds' tab, with no intermediate values. It looks like some cleanup is still needed there. Now that we have that out of the way, some suggestions for features (some have been mentioned by other people as well): 3. Multiple selection in the dialog window used for choosing temperatures to be included in a fan controller configuration. 4. In a fan controller's temperatures list box, it would be good if we could change the order of the temperatures after they've been added; however, this is really minor. 5. A mechanism like copy-paste for duplicating both fan controllers in their entirety and individual speed graphs separately. 6. A mechanism for deleting and adding points to the graph (up to a max value, of course - the current one is large enough, I think). I, for one, would only need 2 - 3 points most of the time. 7. A way to adjust the vertical scale of the graph (the scale of the PWM percentage axis). Most of my fans will stop anywhere below 60% on my current motherboard, so that's just wasted space in the graph area. 8. A way to see the exact coordinates of a point, and to adjust them interactively (while seeing the exact values). I have some pretty precise PWM values for the case fans (like 73% or 88%), chosen mostly based on perceived noise. If we have number (7), and number (9) below is as I suppose it is, then this becomes less of an issue, but it would still be useful. And some questions: 9. What happens for temperatures outside the range in the graph? I would suppose the graph 'continues horizontally' outside that range; is that the way you implemented it? 10. If a fan is under the new fan control rules, I suppose the settings in the 'Temperatures' and 'Speeds' tabs should no longer apply to it, at all. Not even the warning temperatures? I would suppose so, but just checking. (I know I touched upon this in the first two points, but now I'm talking about how things should be.) 11. The minimum value for 'hysteresis' seems to be 1. Does that mean 'no hysteresis'? If not, I suggest there should be a way to set it to 0, or disabled, individually for each temperature graph. I think this would be useful for tight temperature ranges (as I have for the hard drives). And some small issues: 12. What happens if several fan controllers act on the same fan? I think you should add a check to avoid that. 13. If you create a fan controller, display its details, then uncheck 'Advanced fan control', the fan-controller-details part of the interface doesn't disappear. This is what I have so far. All in all, as I said, great stuff. I realize this is in a kind of alpha stage, and I'm very happy you chose to share it with us. I hope we'll be able to help you with these comments. On top of this, I have a lot to say about 'hysteresis'. Other reporters have mentioned it, and I think it's a tricky subject, worthy of a comment of its own - coming, probably, tomorrow. |
|
|
First thing to say about histeresis : Hysteresis. :) |
|
|
@deltafx Argh!!! I hate tipos ;-) @mikutoc Thank you for taking the time to evaluate the Advanced Fan Control. Let me say that usually I wouldn't have released such a feature at such an early stage even if in an beta. This time I chose to follow an Open Innovation approach :-) Please consider that I might decide not to include this feature in 4.44 Final should I think that Fan Control requires further analysis. 1) Advanced Fan Control COMPLETELY replaces standard fan control when enabled. 2) I need to have a look at your settings. WARNING is considered. 3) Do you really think this would help that much? 4) I thought about this, but the current strategies (MAX or SUM) are immune to the sort order. 5) This is something I will add to the UI when I will have finalized functionalities. 6) Hmmm... Although this is not easy, I think that the data structures and objects I defined could allow that. I need to understand how to easily allow editing in the UI. 7) This is something I considered. The current representation works better when you have multiple temperatures selected for a fan controller because the scale is fixed. This is a cosmethic fix I can apply later. 8) Good point. And a difficult one to add to the current UI. I must allow this kind of fine tuning because I know that some motherboards react only to a very limited range of values. 9) Yes. 10) The settings in SPEED are still applied. WARNING too. I am working on some code that uses DESIDERED too. 11) Ops! I thought I already allowed 0. 12) This is something I will prevent when everything else will be finalized. 13) Fixed. Feel free to elaborate on hysteresis :-) |
|
|
6) is what I have proposed a bit earlier, right click to add/delete point and left click+drag to move the point around. See Sapphire Trixx application custom fan control for reference, it's very well done there ;) |
|
|
The new fan control method is great news. I have not had much time to play with it yet but it seems functional. I sure would like a larger graph though. On a 1920x1080 res monitor the graph is way too small. BTW the GUI itself is too small at high res and needs updating to allow resizing also. It seems strange that the configure window can be resized but the main GUI can't. Alfredo thank you for the hard work all these years. If speedfan did not exist I would have pulled my hair out long ago. Bill |
|
|
Had a chance to play with it. The first big issue is the 'remove' buttons for 'fan controllers' and 'temperature' boxes, don't do anything for me. The second issue is the temperature scale. For my GPU's I only start speeding up chassis fans for GPU temps above 70c. So a max of 60c means the feature is useless for me. Also have a problem with the mandatory min fan speed in graphs. Some fans I will only start to spin at a certain temperature. Below that temp I would want to set the speed to zero. Edit: Still learning the interface, ignore this bit, zero is selectable. Cannot play more without being able to remove some of the things I added mistakenly, which I cannot do at the moment. Was able to add some components twice?! |
|
|
@phobos I will add removes asap. Upper and lower temperature limits can be changed using the the small buttons with "<" and ">". I am not sure I understood the "min fan speed". Would you like to set pwm below zero? :-) |
|
|
alfredo Ah, awesome, did not resize window to see that. Running a larger than normal windows font / DPI size, so window did not show everything. Thanks, am in tweak heaven at the moment... |
|
|
@phobos I have read again your sentence about setting the speed to zero. If you set the first PWM value to zero, every temperature on the left of the minimum temperature shown in that graph will set PWM to zero. |
|
|
@alfredo Yeah, got that just after posting the message and updated the posting sorry. All is good. After setting: Upper and lower temperature limits can be changed using the the small buttons with "<" and ">". That's a lot of clicking. One suggestion for the future is to allow a dialogue of the min / max temp, where you could quickly type the number into (like the max min temp boxes in normal temp control). Or at least < & > that repeat when you held the button down. I know, I know, early days... Last one for today. This maybe by design, due to being a beta, but just in case it isn't. I have to keep activating 'advanced fan control' every time I start speedfan.... New day, new thing to add. If you use /nosmartscan option and have a graph set for a HDD temp you get the following error at startup: Access violation at address 0066AC43 in module 'speedfan.exe'. Read of address 00000014. I know that it is very unlikely to be monitoring a hardrive and the use that switch, but I do sometimes. I know this is a super minor thing/bug, but I thought a bug is a bug and should be reported. |
|
|
Hey, I'm back! I was out of the game for a few days, as my motherboard died on me. It was, of course, the fault of that dreadful SpeedFan beta, which fried my board, reprogrammed my microwave... ... just kidding. (It was the B2 version of the P67 chipset; its SATA controller died, so I had to exchange it with a B3 version, and now I'm back up and running.) Didn't have time to elaborate on the hysteresis thing, but I will. Thanks for your answers on my points above. A few more comments, maintaining the numbering: 3. No, not much, just a convenience feature, consider it low priority. 4. Same as above, even lower priority. 5. The thing is, if you're 'unlucky' to have a quad-core processor with hyperthreading enabled (8 virtual processors), setting up the processor fan graphs to be the same for all of those will be a huge pain. On top of that, some motherboards, including mine, have a feature where there are actually two PWM values controlling the CPU fan speed (I reported on this in another issue). So, double the work. Add to it the fact the system fans have to depend on the core temperatures as well (to ensure proper airflow in the case when under load), so... triple the work. That's why I think a feature to at least duplicate individual graphs would be essential to allow people to play around with the settings. 1. and 10. I think I may have misunderstood your answers to these points. If the new fan control completely replaces the old method, how are the settings in Speeds and Temperatures still applied? |
|
|
@mikutoc I'm sorry for the B2 revision. Luckily I had B3 :-) 5. I am still testing the inner features of the new Fan Control, but I will try to speed up the creation of what you're asking for. About the double PWM on a single fan, this is something I thought I found on my motherboard... Until I discovered that the first PWM had some circuitry that delayed the actual speed down of the fan. This delay made me think that it was the other PWM to cause the real slow down. 10. The new fan control completely replaces the old method, but still makes use of some settings describing each temperature. I might add a couple of checkboxes to disable this feature. |
|
|
5. Great, thanks. 10. Yeah, checkboxes would be good, they would make everything more visible. I think it would also be good if you could drop us a note explaining how the two sets of settings interact, so we know what to look for when we're testing. As far as I'm concerned, I'm still confused about that. As I reported previously, on my system, it still seems like the end result is a combination of the temperature settings in the graphs and the speed steps on the Speeds tab - I haven't managed to get a continuous fan speed variation so far. |
|
|
Consider that it is difficult to have a continuous variation when using CORE temperatures as they change so much so quickly. SpeedFan does its best to improve this. |
|
|
Agreed, but I managed to hold the temperatures relatively steady at an intermediate value, and the resulting speed value wasn't according to the graph. Besides, I encountered this problem with HDD temperatures as well (I was testing the case fans). It was rather strange that the resulting speeds were exactly the ones set in the Speeds tab (jumping between minimum, maximum, and 100%) and I couldn't get other values. Anyway, I'll try some more scenarios and report back. |
|
|
You are right: MIN and MAX selected for each SPEED is taken into consideration. WARNING and DESIRED for temperatures and MIN and MAX for speeds are properties that I think makes sense to take into consideration whichever fan control strategy is used. |
|
|
But that negates the purpose of the graphs, doesn't it? I mean, at least in my case, so far, the behaviour with advanced fan control enabled and graphs defined has been the same as before - the graphs haven't made any difference, basically (I've double-checked this today with beta 4). In my opinion, when advanced fan control is enabled, _none_ of the other tabs should have any influence on the final fan speed. Some settings in there could still be used, like logging, or maybe the desired and warning temperatures for setting the icons in the main tab, but nothing related to setting fan speeds - that should be entirely controlled by the graphs. The more I think about it, the stronger I believe this is the right solution. I think any other combination would be confusing and difficult to manage for the user. Initially, I thought that it might be a good idea to keep just the warning temperatures active (force the fans to 100% even if the graphs say otherwise), but, after giving it some more thought, I think even that is not a good idea. The same effect can easily be obtained with the graphs, more intuitively and, most importantly, localized, that is, all settings related to a particular fan would be in one place, easy to view and understand. I think this is very important from a usability point of view. Another benefit of this is that it allows you to have two entirely independent configuration sets, without worrying about cross-dependencies. It should simplify the code, in the end. |
|
|
@mikutoc Every suggestion is welcome. I think that global SPEED settings make sense. Most likely I will add a checkbox for them too in Advanced FC. The code is already completely separated :-) |
|
|
Is it right that advanced fan control has to be manually engaged every time speedfan starts, by going into config and ticking adv fan check box, or am I missing something? |
|
|
You're not missing anything; that's how Alfredo intended it to be for now, since this feature is in an early beta stage. |
|
|
How are people finding this function. I know Alfredo is unsure whether it is really for prime time yet, but my experience has been good and I have had not problem at all. Even though this was a first stab and a beta, I am even very happy with the way it has been implemented with the graphs etc. I have seen the hibernation / standby bug noted (not something I use). What other bugs are there? So what do others think, ready for prime time, or still too many bugs? And if not due to bugs, which one are the show stoppers at the moment? |
|
|
Phobos wrote something very interesting and I would like to read what you think about that. |
|
|
I tested the advanced fan control feature a few times. So far no problems with it. It would be better to the leave the feature activated after restart in the next beta, because I often forget to activate it. The only thing I didn't understand so far is the method option (MAX / SUM of speeds). |
|
|
I voted for the option, but to be honest, I'm not using it. IMHO the configuration is too complicated, there's a bazillion points on the graph where two or three would suffice. My proposition, where left click adds/moves the point and right click deletes one went. Add no GPU temp support/GPU fan adjustment to the above, and I'm better off with default (old) behavior. MAX selects the greatest of values while SUM adds values, so that if CPU requires 20% airflow and HDD requires 40% airflow, the fan will be set to 60%. |
|
|
I really like that Advanced control. Don't make it too complicated. I would be fine even with just 3 or 4 steps in the graph. No problems/bugs there so far on my ASUS P55 (ATK0110-readings are way useless and wrong, but thats a different story). Maybe add a warning popup when clicking on "Advanced fan control". Making the "Advanced control"-Option permanent gets a really big +1 from me... GPU-Stuff (I have ATI)... Temp would be nice (for the Charts) but a goody. Fan-Control? hm, I'm glad that my GPU itself knows when it's hot... |
|
|
So no one objects to having it that if you enable the functionality it stays activated when you restart the program? We may need a command line reset / safe mode option though, if not already there, just in case.... We will have to discuss about how the feature goes forwards, as for me even though it takes a while to initially setup, I would not like to loose any of that complicatedness or loose the amounts of points on the graph. But I am sure there is a compromise to be reached. User selection of the number of points etc. |
|
|
phobos - that's why I'm suggestin again and again a very simple solution: left click adds or moves the point, right click deletes the point. This way you can have just 3 or 4 points, or have 20 if you feel like it. |
|
|
@wlw_wl - Either that or if it is easier to program, a number dialogue box with up & down buttons to define the number of points.... |
|
|
Well yes, but then there's the placement of the points on the X axis, should they be uniformly distributed just based on their total number, or movable in two directions? I see this as a complication, rather than a simplification, but to each his own :) |
|
|
I just wanted to say how much I appreciate the addition of this feature. Really great software. Thank you. |
|
|
Really looking forwards to not having to remember to enable this every-time speedfan starts... |
|
|
Yay to not having to have to remember to engage AFC at startup with Beta 6. Thanks Alfredo |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-02-05 15:23 | phobos | New Issue | |
| 2011-02-05 15:23 | phobos | Status | new => assigned |
| 2011-02-05 15:23 | phobos | Assigned To | => alfredo |
| 2011-02-05 15:28 | phobos | Note Added: 0005813 | |
| 2011-02-06 23:46 | wlw_wl | Note Added: 0005815 | |
| 2011-02-07 14:22 | mikutoc | Note Added: 0005817 | |
| 2011-02-07 17:34 | wlw_wl | Note Added: 0005819 | |
| 2011-02-07 20:42 | norman02us | Note Added: 0005820 | |
| 2011-02-07 21:33 | phobos | Note Added: 0005821 | |
| 2011-02-07 21:36 | phobos | Note Edited: 0005821 | |
| 2011-02-07 22:38 | norman02us | Note Added: 0005822 | |
| 2011-02-07 23:03 | mikutoc | Note Added: 0005823 | |
| 2011-02-07 23:24 | wlw_wl | Note Added: 0005824 | |
| 2011-02-07 23:31 | phobos | Note Added: 0005825 | |
| 2011-02-08 12:05 | mikutoc | Note Added: 0005826 | |
| 2011-02-08 17:24 | wlw_wl | Note Added: 0005827 | |
| 2011-02-11 22:37 | wlw_wl | Note Added: 0005830 | |
| 2011-02-12 11:51 | mikutoc | Note Added: 0005831 | |
| 2011-02-13 22:31 | wlw_wl | Note Added: 0005836 | |
| 2011-03-19 17:52 | alfredo | Note Added: 0005947 | |
| 2011-03-19 17:52 | alfredo | Status | assigned => acknowledged |
| 2011-03-20 12:23 | mikutoc | Note Added: 0005961 | |
| 2011-03-20 12:42 | alfredo | Note Added: 0005963 | |
| 2011-03-20 13:41 | mikutoc | Note Added: 0005964 | |
| 2011-04-02 10:48 | alfredo | Note Added: 0006000 | |
| 2011-04-02 12:39 | mikutoc | Note Added: 0006005 | |
| 2011-04-02 12:59 | alfredo | Note Added: 0006006 | |
| 2011-04-02 15:21 | Yako | Note Added: 0006007 | |
| 2011-04-02 16:27 | alfredo | Note Added: 0006008 | |
| 2011-04-03 04:06 | wlw_wl | Note Added: 0006011 | |
| 2011-04-03 05:25 | elektrogenii | Note Added: 0006014 | |
| 2011-04-03 05:28 | elektrogenii | Note Edited: 0006014 | |
| 2011-04-03 05:49 | elektrogenii | Note Edited: 0006014 | |
| 2011-04-03 06:01 | elektrogenii | Note Edited: 0006014 | |
| 2011-04-03 12:31 | wlw_wl | Note Added: 0006018 | |
| 2011-04-03 15:41 | phobos | Note Added: 0006020 | |
| 2011-04-03 15:46 | phobos | Note Edited: 0006020 | |
| 2011-04-03 15:51 | phobos | Note Edited: 0006020 | |
| 2011-04-03 18:45 | alfredo | Note Added: 0006021 | |
| 2011-04-03 18:46 | alfredo | Note Edited: 0006021 | |
| 2011-04-03 18:46 | alfredo | Note Edited: 0006021 | |
| 2011-04-03 18:47 | alfredo | Note Added: 0006022 | |
| 2011-04-03 19:47 | wlw_wl | Note Added: 0006024 | |
| 2011-04-03 23:16 | alfredo | Note Added: 0006026 | |
| 2011-04-03 23:43 | mikutoc | Note Added: 0006027 | |
| 2011-04-04 10:14 | DeltaFX | Note Added: 0006028 | |
| 2011-04-04 18:21 | alfredo | Note Added: 0006029 | |
| 2011-04-05 02:38 | wlw_wl | Note Added: 0006031 | |
| 2011-04-05 16:03 | Wonderwrench | Note Added: 0006033 | |
| 2011-04-05 19:54 | phobos | Note Added: 0006039 | |
| 2011-04-05 19:57 | phobos | Note Edited: 0006039 | |
| 2011-04-05 19:58 | alfredo | Note Added: 0006040 | |
| 2011-04-05 20:19 | phobos | Note Edited: 0006039 | |
| 2011-04-05 20:21 | phobos | Note Added: 0006041 | |
| 2011-04-05 20:26 | alfredo | Note Added: 0006042 | |
| 2011-04-05 20:30 | phobos | Note Added: 0006043 | |
| 2011-04-05 20:30 | phobos | Note Edited: 0006043 | |
| 2011-04-05 20:30 | phobos | Note Edited: 0006041 | |
| 2011-04-05 20:31 | phobos | Note Edited: 0006041 | |
| 2011-04-05 20:31 | phobos | Note Edited: 0006041 | |
| 2011-04-05 23:46 | phobos | Note Edited: 0006043 | |
| 2011-04-05 23:47 | phobos | Note Edited: 0006043 | |
| 2011-04-06 11:39 | phobos | Note Edited: 0006043 | |
| 2011-04-09 03:47 | mikutoc | Note Added: 0006075 | |
| 2011-04-09 08:43 | alfredo | Note Added: 0006076 | |
| 2011-04-09 13:08 | mikutoc | Note Added: 0006078 | |
| 2011-04-09 13:31 | alfredo | Note Added: 0006079 | |
| 2011-04-09 20:56 | mikutoc | Note Added: 0006083 | |
| 2011-04-09 21:05 | alfredo | Note Added: 0006084 | |
| 2011-04-09 23:50 | mikutoc | Note Added: 0006086 | |
| 2011-04-10 11:47 | alfredo | Note Added: 0006087 | |
| 2011-04-10 13:00 | phobos | Note Added: 0006089 | |
| 2011-04-10 13:38 | mikutoc | Note Added: 0006091 | |
| 2011-04-11 09:50 | alfredo | Relationship added | related to 0001785 |
| 2011-04-28 11:39 | alfredo | Relationship added | related to 0001798 |
| 2011-04-29 11:19 | phobos | Note Added: 0006154 | |
| 2011-04-29 11:20 | phobos | Note Edited: 0006154 | |
| 2011-04-29 13:54 | alfredo | Note Added: 0006157 | |
| 2011-04-29 19:24 | moritz2k | Note Added: 0006159 | |
| 2011-04-29 21:21 | wlw_wl | Note Added: 0006161 | |
| 2011-04-30 01:22 | HWurst | Note Added: 0006163 | |
| 2011-05-03 14:11 | phobos | Note Added: 0006167 | |
| 2011-05-03 14:14 | phobos | Note Edited: 0006167 | |
| 2011-05-03 15:53 | wlw_wl | Note Added: 0006168 | |
| 2011-05-03 21:11 | phobos | Note Added: 0006169 | |
| 2011-05-03 21:12 | phobos | Note Edited: 0006169 | |
| 2011-05-03 21:12 | phobos | Note Edited: 0006169 | |
| 2011-05-03 23:58 | wlw_wl | Note Added: 0006170 | |
| 2011-05-05 04:22 | nmkaufman | Note Added: 0006173 | |
| 2011-05-25 20:15 | phobos | Note Added: 0006211 | |
| 2011-06-17 00:19 | phobos | Note Added: 0006245 | |
| 2011-07-13 09:46 | alfredo | Status | acknowledged => resolved |
| 2011-07-13 09:46 | alfredo | Resolution | open => fixed |
| 2011-07-13 09:46 | alfredo | Fixed in Version | => 4.44 beta |
