Your opinion about fan speed algorithm plugin for speedfan?
Moderators: NeilBlanchard, Ralf Hutter, sthayashi, Lawrence Lee
Your opinion about fan speed algorithm plugin for speedfan?
I'll write the author of speedfan a mail about my idea. I believe he will consider it more when several people here also share my opinion.
I ask him to give access to the fan speed algorithm, perhaps via a plugin. The hardcoded one is unfortunately not very suitable for systems with variable workload since it fails to find a sweet spot. As a result the speed goes up and down all the time. So you can tweak the setting very hard or work with a fixed speed. This is a pity since there is much potential.
So what do YOU think about this topic?
Forum members here have discussed algorithms recently:
http://forums.silentpcreview.com/viewtopic.php?t=6961
http://forums.silentpcreview.com/viewtopic.php?t=7416
Speedfan: http://almico.com/speedfan.php
I ask him to give access to the fan speed algorithm, perhaps via a plugin. The hardcoded one is unfortunately not very suitable for systems with variable workload since it fails to find a sweet spot. As a result the speed goes up and down all the time. So you can tweak the setting very hard or work with a fixed speed. This is a pity since there is much potential.
So what do YOU think about this topic?
Forum members here have discussed algorithms recently:
http://forums.silentpcreview.com/viewtopic.php?t=6961
http://forums.silentpcreview.com/viewtopic.php?t=7416
Speedfan: http://almico.com/speedfan.php
-
- Posts: 226
- Joined: Sat Sep 06, 2003 5:59 am
- Location: Finland
-
- Posts: 1283
- Joined: Wed Sep 03, 2003 1:35 am
- Location: Sweden, Linkoping
There are other programs that do essentially the same. Perhaps you want to check with the authors of those programs and see if they show more interest.
Also, you might be going from the wrong direction.
The "common" way to do this like this in Linux is that someone writes the bottom layer with real good functionality. E.g. a framework to control fans based on temps, with a few algorithms and you can specify what algoritm to use of send in a function with your own algorithm. This program will not contain any UI (and this is really important). It will however contain a well documented interface so anyone can build a fancy user interfac on top of this program.
An example of something like this is CD-burning. There is no point in reinventing the wheel by implementing a new CD-burning framework b/c there is an excelent framework that can be used with any GUI that you like.
Also, you might be going from the wrong direction.
The "common" way to do this like this in Linux is that someone writes the bottom layer with real good functionality. E.g. a framework to control fans based on temps, with a few algorithms and you can specify what algoritm to use of send in a function with your own algorithm. This program will not contain any UI (and this is really important). It will however contain a well documented interface so anyone can build a fancy user interfac on top of this program.
An example of something like this is CD-burning. There is no point in reinventing the wheel by implementing a new CD-burning framework b/c there is an excelent framework that can be used with any GUI that you like.
-
- Posts: 226
- Joined: Sat Sep 06, 2003 5:59 am
- Location: Finland
It's not the UI but the basic stuff required to probe and drive all the different sensor chips over ISA and SMBUS. It takes a lot of effort to track down all the necessary datasheets and implement the code. I'm not really a Windows programmer and I use it so rarely that I don't have the motivation to go to all that trouble. I might have had the inclination to produce a quick plugin, though.
I actually asked the guy to GPL the code or, failing that, at least provide a plugin API. Maybe that offended him.
It's funny really, how Linux programmers share the fruits of their labour as a matter of course while anyone who writes a small Windows utility tends to hoard the code and generally try to make a few bucks with it. The differences in cultures run deep.
I actually asked the guy to GPL the code or, failing that, at least provide a plugin API. Maybe that offended him.
It's funny really, how Linux programmers share the fruits of their labour as a matter of course while anyone who writes a small Windows utility tends to hoard the code and generally try to make a few bucks with it. The differences in cultures run deep.
-
- Posts: 291
- Joined: Mon Feb 10, 2003 11:19 am
My hope in building controllers is that people would take advantage of the relatively simple set of commands (sent via serial port) and develop their own top layer stuff. Over time and iterations it could develop into something really neat.
Didn't happen. At all.
I wonder if the guys don't want to give up their code because they have done it before and all it led to was questions without any contribution?
Didn't happen. At all.
I wonder if the guys don't want to give up their code because they have done it before and all it led to was questions without any contribution?
-
- Posts: 580
- Joined: Sun Aug 11, 2002 3:26 pm
- Location: USA (Phoenix, AZ)
-
- Posts: 226
- Joined: Sat Sep 06, 2003 5:59 am
- Location: Finland
fancontrol -- It might be that people simply feel they have nothing worth sharing. It's pretty simple to write a quick fan control algorithm for a particular environment, when you know your hardware and your set of sensors. However, it's a long jump from that to something generic that is usable for other people with different hardware.
My Linux implementation is just like that: all the sensors and parameters are basically hardcoded for my environment. Even so, 90% of the code is just setup. I'm quite happy with how it works and I only change the code when the lm-sensors guys change the programming interface (seems like every other day, though). Unfortunately to produce something generic, that 90% would have to be extended to 99% or more. And that's with the HW drivers already available in the kernel.
The problems are the same in Winblows -- worse, since you have to write your own HW drivers. That's why it would make sense to have a plugin interface to an existing SW platform like SpeedFan.
Has anyone looked at MBM, btw? I know it has a plugin interface but does it support fan control?
My Linux implementation is just like that: all the sensors and parameters are basically hardcoded for my environment. Even so, 90% of the code is just setup. I'm quite happy with how it works and I only change the code when the lm-sensors guys change the programming interface (seems like every other day, though). Unfortunately to produce something generic, that 90% would have to be extended to 99% or more. And that's with the HW drivers already available in the kernel.
The problems are the same in Winblows -- worse, since you have to write your own HW drivers. That's why it would make sense to have a plugin interface to an existing SW platform like SpeedFan.
Has anyone looked at MBM, btw? I know it has a plugin interface but does it support fan control?
MBM does not have fan controls. Besides I think the the author has said he will stop supporting it soon.
Fancontrol are you the person who wrote the pwmconfig and fanspeed konsole scripts for lm-sensors? Or did you do something else with this in Linux?
The differenece between the open source Linux world and Windows cultures is huge.
Fancontrol are you the person who wrote the pwmconfig and fanspeed konsole scripts for lm-sensors? Or did you do something else with this in Linux?
The differenece between the open source Linux world and Windows cultures is huge.