Automatic with manual override . What if you want 'Performance'?mawebb88 wrote:Automatic sounds good to me.tempestuous wrote:Well the question now becomes: do you want a manual CPU FSB control,
or do you want an automatic control, so that the CPU FSB goes into Powersave mode whenever the laptop is on batteries?
Rgds Mike
Eee Atom CPU control - testing
Re: My vote
Puppy Linux Blog - contact me for access
tempestuous,tempestuous wrote:Now moving on to the fan.
I have already compiled the third-party "eee" kernel module for this purpose, and jakfish reports that it works OK, but it would probably be better to use the fan control functions of the new "eeepc-laptop" module now that Puppy 4.3 contains this module.
Some testing is needed -
normally the fan speed is controlled by bios. Running this command should set the fan control to manual -To check success, run this command -Code: Select all
echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable
where the result should be "1" (manual control enabled)Code: Select all
cat /sys/class/hwmon/hwmon0/pwm1_enable
but if the result is "0" then manual control is disabled, and the bios still has control.
Now that you're in manual mode, do this to set a fan speed -where x is a value between 0 (fan off) to 255 (full speed, 12V).Code: Select all
echo x > /sys/class/hwmon/hwmon0/pwm1
Of course, you need to keep an eye on temperature! I haven't been able to Google the exact information, but could users please look in /sys/class/hwmon/hwmon0 and you should see some file relating to temperature.
EDIT: I think it's "temp1_input". If true, you would do this to check temperatureEDIT: I was just advised by PM of the correct location of the fan/temp state files.Code: Select all
cat /sys/class/hwmon/hwmon0/temp1_input
I have edited the information above.
Now, I understand 'jakfish' is using a Celeron... (from main post), so, I will test the appropriate commands and report.
mawebb88,
Perhaps I should have written in the 'tool tip' to wait 5 seconds. If you wait 5 seconds does it work?
Cheers
Puppy Linux Blog - contact me for access
Fan tests
tempestuous wrote:Now moving on to the fan.
I have already compiled the third-party "eee" kernel module for this purpose, and jakfish reports that it works OK, but it would probably be better to use the fan control functions of the new "eeepc-laptop" module now that Puppy 4.3 contains this module.
Some testing is needed -
normally the fan speed is controlled by bios. Running this command should set the fan control to manual -To check success, run this command -Code: Select all
echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable
where the result should be "1" (manual control enabled)Code: Select all
cat /sys/class/hwmon/hwmon0/pwm1_enable
but if the result is "0" then manual control is disabled, and the bios still has control.
Mike: I get 1
Now that you're in manual mode, do this to set a fan speed -where x is a value between 0 (fan off) to 255 (full speed, 12V).Code: Select all
echo x > /sys/class/hwmon/hwmon0/pwm1
Mike: echo 255 > /sys/class/hwmon/hwmon0/pwm1 works. I can hear the fan roar! Tried 0 and yes the fan stops. Tried intermediate values 100 and 150 and both give the corresponding fan roar.
Of course, you need to keep an eye on temperature! I haven't been able to Google the exact information, but could users please look in /sys/class/hwmon/hwmon0 and you should see some file relating to temperature.
EDIT: I think it's "temp1_input". If true, you would do this to check temperatureMike: This returns "no such file or drectory" for me. lsCode: Select all
cat /sys/class/hwmon/hwmon0/temp1_input
BTW /sys/class/hwmon/hwmon0 is a syslink to /sys/devices/virtual/hwmon/hwmon0/
In there is:
fan1_input
name
power (a directory)
pwm1
pwm1_enable
subsystem (a syslink)
uevent
I tried to Pfind temp1_input but it did not find any files
EDIT: I was just advised by PM of the correct location of the fan/temp state files.
I have edited the information above.
Hello tempestuous and all else.
The fan commands all work as expected for me on the 701sd. However, the temperature command does not work for me, I get the same result as Mike above.
I normally use conky/Pwidgets to monitor temperature but there is another command I found that returns the correct temperature.
You will get output in the form:
(um, no more gui building until this is complete!)
Cheers
The fan commands all work as expected for me on the 701sd. However, the temperature command does not work for me, I get the same result as Mike above.
I normally use conky/Pwidgets to monitor temperature but there is another command I found that returns the correct temperature.
Code: Select all
#cat /proc/acpi/thermal_zone/TZ00/temperature
Code: Select all
temperature: 50 C
Cheers
Puppy Linux Blog - contact me for access
-
- Posts: 41
- Joined: Wed 10 Aug 2005, 04:14
- Location: S.E. Australia (from 1/1/10 to become 'ozsouth')
Tests eeepc
Sorry to be late - watching Geelong win again.
pup430-small 2.6.30.5 eeepc901 (atom 1.6):
changed mode from performance to normal; temp 51C using 01micko method; fan matching cpu mode automatically sounds good.
also changed fan to manual - speed 123 then 167 then 123 - could hear speed changes, but no temp change (51C).
pup430-small 2.6.30.5 eeepc901 (atom 1.6):
changed mode from performance to normal; temp 51C using 01micko method; fan matching cpu mode automatically sounds good.
also changed fan to manual - speed 123 then 167 then 123 - could hear speed changes, but no temp change (51C).
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Thanks for the results. For the eeepc-laptop module to read temperature it appears that the "lm-sensors" utilities might be needed ... or maybe the i2c-dev kernel module ... but it's getting too difficult.
Dougal's fan control script is based on the "eee" kernel module, so it makes sense to use that module, even though it needs to be installed separately.
I should have a package available shortly.
Dougal's fan control script is based on the "eee" kernel module, so it makes sense to use that module, even though it needs to be installed separately.
I should have a package available shortly.
Code: Select all
# cat /sys/class/hwmon/hwmon0/temp1_input
cat: /sys/class/hwmon/hwmon0/temp1_input: No such file or directory
#
- Attachments
-
- no fans.jpg
- (4.97 KiB) Downloaded 1580 times
Hi,
with EeePc900 (Celeron, 900Mhz), frugal, booting from sd-card:
fan works as expected, temperature depending from fan speed during test 49C -56C.
No luck with cpu speed.
Everytime the answer is 512, no matter the question was (sorry meaning no matter I use 0, 1 or 2 from console or the GUI from 01micko. If I use GUI and choose "Normal", cursor freezes, can't kill X and must poweroff.
Although the thread is titled "Eee Atom CPU control - testing" I hope this is of interest.
~ Rolf
Edit: For displaying temperature I use the command from 01micko
with EeePc900 (Celeron, 900Mhz), frugal, booting from sd-card:
fan works as expected, temperature depending from fan speed during test 49C -56C.
No luck with cpu speed.
Everytime the answer is 512, no matter the question was (sorry meaning no matter I use 0, 1 or 2 from console or the GUI from 01micko. If I use GUI and choose "Normal", cursor freezes, can't kill X and must poweroff.
Although the thread is titled "Eee Atom CPU control - testing" I hope this is of interest.
~ Rolf
Edit: For displaying temperature I use the command from 01micko
Code: Select all
cat /proc/acpi/thermal_zone/TZ00/temperature
Ich verwende "frugal", und das ist gut so. :wink:
Raspberry Pi without Puppy? No, thanks.
Raspberry Pi without Puppy? No, thanks.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Here is a rough gtkdialog gui for CPU/fan control. I intend that it will be launched by the Fn+F6 hotkey combination.
For testing purposes you can launch it from the terminal -
Don't try the fan control button. It's not finished.
I'm not good at bash and gtkdialog. The gui correctly displays the CPU mode when launched, but I don't know how to refresh the gui when the mode is changed. It would be great if someone could refine the script - /usr/bin/eeecontrol
For testing purposes you can launch it from the terminal -
Code: Select all
eeecontrol
I'm not good at bash and gtkdialog. The gui correctly displays the CPU mode when launched, but I don't know how to refresh the gui when the mode is changed. It would be great if someone could refine the script - /usr/bin/eeecontrol
- Attachments
-
- eee-atom-1.jpg
- (17.87 KiB) Downloaded 1497 times
-
- eeecontrol-test01.pet
- (987 Bytes) Downloaded 459 times
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Better still, the CPU settings should be with radiobuttons.
But I don't know how to script the backend for this.
But I don't know how to script the backend for this.
- Attachments
-
- eee-atom-2.jpg
- (16.2 KiB) Downloaded 1063 times
Hi tempestuous
Nice gui. (ATM I am the only download and I did that before work around 5.30am this morning)
I'll take a look. 'zigbert' is my tutor so all should be how you want it to look.
Cheers
[Side note: I compiled the driver for the rtl8187se for k2.6.30.5 and posted (with appropriate warnings) in this ("Users (For the regulars)") forum. Just want to make sure it looks fine to you. For me, almost 24 hrs running on my 701sd and no dropouts.]
Nice gui. (ATM I am the only download and I did that before work around 5.30am this morning)
I'll take a look. 'zigbert' is my tutor so all should be how you want it to look.
Cheers
[Side note: I compiled the driver for the rtl8187se for k2.6.30.5 and posted (with appropriate warnings) in this ("Users (For the regulars)") forum. Just want to make sure it looks fine to you. For me, almost 24 hrs running on my 701sd and no dropouts.]
Puppy Linux Blog - contact me for access
Well I had a crack at an improved gui. It works.
I replaced the 3 scripts (calling the fsb changes) with a functions script ala zigbert and added a calling script. That is necessary (for me) to refresh the gui with the new status.
The fan scripts are included and the call to them is from the functions script too. There is a delay while the gui refreshes (caused by the system changes) so I added a splash screen informing the user.
The dotpet retains the original pinstall.sh script
Here it is...
NOTE: for testing.
Cheers
I replaced the 3 scripts (calling the fsb changes) with a functions script ala zigbert and added a calling script. That is necessary (for me) to refresh the gui with the new status.
The fan scripts are included and the call to them is from the functions script too. There is a delay while the gui refreshes (caused by the system changes) so I added a splash screen informing the user.
The dotpet retains the original pinstall.sh script
Here it is...
NOTE: for testing.
Cheers
- Attachments
-
- eee-gui.jpg
- (21.04 KiB) Downloaded 982 times
-
- eee-test-Atom-CPU.pet
- (11.62 KiB) Downloaded 422 times
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
No problem. Will do it this evening. Only thing, when the gui is started the radio button at the top is checked by default, so when you start there is no indication of what mode you used last. Do you think there is a need for a "current mode" button?tempestuous wrote:Hey that's great that you made a gui. Before I intgrate it into the Eee hotkeys package, just a note -
with radiobuttons, the "Current Mode of Atom CPU: xxx" text becomes redundant, because the radiobuttons not only allow you to change mode, they're also an indicator of the current mode.
Cheers
Puppy Linux Blog - contact me for access
I made a new gui for the package that I downloaded. I made it before I checked in on this thread so it does not have radio buttons as tempestuous suggested. It is simply a variation on the one I made for pupeeecontrol.pet.
- Attachments
-
- eeecontrol.png
- (14.47 KiB) Downloaded 1055 times
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
That's my point; good scripting could avoid this.01micko wrote:when the gui is started the radio button at the top is checked by default
When the gui is launched, the right backend script should determine the CPU FSB state, and highlight the correct radiobutton.
Maybe we need the expertise of Dougal or Zigbert.
Similarly, when the user changes the CPU FSB state, the backend script should re-read the state, and keep the new radiobutton highlighted only if this new state is confirmed to be true.
When testing, you should try to create a situation where the script fails, this is the principle of rigorous testing.
For example, you could temporarily enter the wrong command within the gtkdialog script to change to a particular CPU FSB state. This creates a good test for the gui - because when the user selects that particular radiobutton to change the state, the gui should highlight that new radiobutton only temporarily, then jump back to the previous highlight when its script determines that the state has failed to change. This would confirm that the gui is telling you the truth!
No. The gui should indicate the current mode without the user needing to consciously press something to find out.01micko wrote:Do you think there is a need for a "current mode" button?
dawnsboy, yes I based these gui's on the same basic controls as you had in your older Pupeeecontrol gui, but you will see that the significant difference is the "Current speed of CPU ..." text display, which Pupeeecontrol did not have.
But I still consider this form of user-interface design rough and inadequate.
With the current 2-button display, the choice of "which" button to press is unintuitive. The user must read the information about what their current FSB state is, then select the "other" button if they decide that they want to change this state.
@tempestuous
I have been the grateful beneficiary of your fine work. I appreciate being able to install and use the various drivers and applications that you have created for the eeepc. I doubt that I would be using Puppy Linux if it were not for those packages ( and I do enjoy using Puppy Linux). I ask that you forgive me if I have offended you with my simplistic offering.
I personally think that the idea being developed for a GUI with radio buttons is the way to go with the Atom processor as it has significantly greater capabilities than my 701 with the Intel Celeron M processor and would of course be capable of much more than two or three steps in speed change (that would be a mess having that many buttons for one purpose). I believe that having control of the fan configuration is probably more pertinent to the Atom processor as well.
I originally became interested in creating the GUI that I eventually placed in the pupeeecontrol.pet file because the fan on my system always operated continuously at 100% whether it needed to or not. It seemed like a good idea to include the buttons for changing cpu speeds in the same gui. Jakfish suggested in an offhand way that he would appreciate it if someone would make a gui for the original package. That is how that gui came about.
I eventually discovered that if I remove the battery when plugged in that my 701 (with your eee module loaded) does a fine job of regulating fan speeds without any help from me. So the only real reason that I have for even dropping back to 630MHz is to save power when running on the battery. Generally the fan runs at 40% with 630MHz selected on battery. As a result I don't use pupeeecontrol very often any more. Especially since there seems to be 110Hz AC wherever I travel. A simple two button gui with or without fan control is all that is needed for that. So I shared the one I made for my own use.
Personally I favor one even simpler than that for the 701.
I have been the grateful beneficiary of your fine work. I appreciate being able to install and use the various drivers and applications that you have created for the eeepc. I doubt that I would be using Puppy Linux if it were not for those packages ( and I do enjoy using Puppy Linux). I ask that you forgive me if I have offended you with my simplistic offering.
I personally think that the idea being developed for a GUI with radio buttons is the way to go with the Atom processor as it has significantly greater capabilities than my 701 with the Intel Celeron M processor and would of course be capable of much more than two or three steps in speed change (that would be a mess having that many buttons for one purpose). I believe that having control of the fan configuration is probably more pertinent to the Atom processor as well.
I originally became interested in creating the GUI that I eventually placed in the pupeeecontrol.pet file because the fan on my system always operated continuously at 100% whether it needed to or not. It seemed like a good idea to include the buttons for changing cpu speeds in the same gui. Jakfish suggested in an offhand way that he would appreciate it if someone would make a gui for the original package. That is how that gui came about.
I eventually discovered that if I remove the battery when plugged in that my 701 (with your eee module loaded) does a fine job of regulating fan speeds without any help from me. So the only real reason that I have for even dropping back to 630MHz is to save power when running on the battery. Generally the fan runs at 40% with 630MHz selected on battery. As a result I don't use pupeeecontrol very often any more. Especially since there seems to be 110Hz AC wherever I travel. A simple two button gui with or without fan control is all that is needed for that. So I shared the one I made for my own use.
Personally I favor one even simpler than that for the 701.
- Attachments
-
- eeecontrol1.png
- (11.68 KiB) Downloaded 950 times
Well I'm stumped at the moment trying to get the radiobuttons to remember.
The gui is quite simple, in fact so simple that it may be possible to get rid of the functions script entirely. It all depends on the outcome of the radiobutton problem.
There are only a few examples of radiobutton retention (?) in stock Puppy (and those methods are not working) and not much documentation on gtkdialog on the web.
I might post my code on zigbert's 'howto' thread and see what happens. I'm sure someone can help.
Everything else works as expected, even threw in some icons and a temp button, showing a splash of the current cpu temp
Here's how it looks..
The gui is quite simple, in fact so simple that it may be possible to get rid of the functions script entirely. It all depends on the outcome of the radiobutton problem.
There are only a few examples of radiobutton retention (?) in stock Puppy (and those methods are not working) and not much documentation on gtkdialog on the web.
I might post my code on zigbert's 'howto' thread and see what happens. I'm sure someone can help.
Everything else works as expected, even threw in some icons and a temp button, showing a splash of the current cpu temp
Here's how it looks..
- Attachments
-
- neweeegui.jpg
- (18.12 KiB) Downloaded 1007 times
Puppy Linux Blog - contact me for access
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
dawnsboy, heck no. No offence at all.
I have a perfectionist attitude, myself (it's a character fault), but I respect and admire everyone else's attempts to do whatever works for them.
My own expertise is in TV/media production, but I do have some exposure to interface design from when I was involved with internet video streaming 10 years ago. I was taught that fundamentally, interfaces should always report the outcome of what users ask of them. So if you ask your interface to change CPU speed to 900MHz, for example, the interface should indicate success or failure.
01micko, I agree that giving users access to temperature has merit, but I disagree with your particular implementation ie. requiring the user to consciously "ask" for the temperature.
We need to be mindful that the hotkeys package I provided contains Dougal's automatic fan speed control daemon, so strictly speaking it's not necessary to monitor the temperature. The daemon is quietly watching the temperature, and adjusting fan speed accordingly.
Ideally, I would like to see the permanent CPU temp/fan speed indicators which aarf illustrated, be integrated within the Eee scripts.
aarf, how about telling use what application that is? It's certainly not standard in Puppy.
Unfortunately, I suspect that the application which displays the fan speed uses a different mechanism than used by Dougal's script, so we would need to ask Dougal to rewrite his script.
I have a perfectionist attitude, myself (it's a character fault), but I respect and admire everyone else's attempts to do whatever works for them.
My own expertise is in TV/media production, but I do have some exposure to interface design from when I was involved with internet video streaming 10 years ago. I was taught that fundamentally, interfaces should always report the outcome of what users ask of them. So if you ask your interface to change CPU speed to 900MHz, for example, the interface should indicate success or failure.
01micko, I agree that giving users access to temperature has merit, but I disagree with your particular implementation ie. requiring the user to consciously "ask" for the temperature.
We need to be mindful that the hotkeys package I provided contains Dougal's automatic fan speed control daemon, so strictly speaking it's not necessary to monitor the temperature. The daemon is quietly watching the temperature, and adjusting fan speed accordingly.
Ideally, I would like to see the permanent CPU temp/fan speed indicators which aarf illustrated, be integrated within the Eee scripts.
aarf, how about telling use what application that is? It's certainly not standard in Puppy.
Unfortunately, I suspect that the application which displays the fan speed uses a different mechanism than used by Dougal's script, so we would need to ask Dougal to rewrite his script.
- Attachments
-
- aarf-CPUtemp-fanspeed.jpg
- (4.97 KiB) Downloaded 1010 times