Eee Atom CPU control - testing

Using applications, configuring, problems
Message
Author
User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

Re: My vote

#21 Post by 01micko »

mawebb88 wrote:
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?
Automatic sounds good to me.

Rgds Mike
Automatic with manual override :) . What if you want 'Performance'?
Puppy Linux Blog - contact me for access

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#22 Post by 01micko »

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 -

Code: Select all

echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable
To check success, run this command -

Code: Select all

cat /sys/class/hwmon/hwmon0/pwm1_enable
where the result should be "1" (manual control enabled)
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 -

Code: Select all

echo x > /sys/class/hwmon/hwmon0/pwm1
where x is a value between 0 (fan off) to 255 (full speed, 12V).

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 temperature

Code: Select all

cat /sys/class/hwmon/hwmon0/temp1_input
EDIT: I was just advised by PM of the correct location of the fan/temp state files.
I have edited the information above.
tempestuous,

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

mawebb88
Posts: 246
Joined: Sun 13 Jul 2008, 09:54
Location: France nr Lyon

Fan tests

#23 Post by mawebb88 »

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 -

Code: Select all

echo 1 > /sys/class/hwmon/hwmon0/pwm1_enable
To check success, run this command -

Code: Select all

cat /sys/class/hwmon/hwmon0/pwm1_enable
where the result should be "1" (manual control enabled)
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 -

Code: Select all

echo x > /sys/class/hwmon/hwmon0/pwm1
where x is a value between 0 (fan off) to 255 (full speed, 12V).

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 temperature

Code: Select all

cat /sys/class/hwmon/hwmon0/temp1_input
Mike: This returns "no such file or drectory" for me. ls

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.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#24 Post by 01micko »

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.

Code: Select all

#cat /proc/acpi/thermal_zone/TZ00/temperature
You will get output in the form:

Code: Select all

temperature:              50 C
(um, no more gui building until this is complete!)

Cheers
Puppy Linux Blog - contact me for access

downsouth
Posts: 41
Joined: Wed 10 Aug 2005, 04:14
Location: S.E. Australia (from 1/1/10 to become 'ozsouth')

Tests eeepc

#25 Post by downsouth »

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).

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#26 Post by tempestuous »

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.

aarf

#27 Post by aarf »

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

User avatar
rhadon
Posts: 1292
Joined: Thu 27 Mar 2008, 11:05
Location: Germany

#28 Post by rhadon »

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

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.

aarf

#29 Post by aarf »

Code: Select all

# cat /proc/acpi/thermal_zone/TZ00/temperature
temperature:             57 C
# 

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#30 Post by tempestuous »

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 -

Code: Select all

eeecontrol
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
Attachments
eee-atom-1.jpg
(17.87 KiB) Downloaded 1497 times
eeecontrol-test01.pet
(987 Bytes) Downloaded 458 times

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#31 Post by tempestuous »

Better still, the CPU settings should be with radiobuttons.
But I don't know how to script the backend for this.
Attachments
eee-atom-2.jpg
(16.2 KiB) Downloaded 1063 times

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#32 Post by 01micko »

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.]
Puppy Linux Blog - contact me for access

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#33 Post by 01micko »

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
Attachments
eee-gui.jpg
(21.04 KiB) Downloaded 982 times
eee-test-Atom-CPU.pet
(11.62 KiB) Downloaded 421 times
Puppy Linux Blog - contact me for access

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#34 Post by tempestuous »

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.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#35 Post by 01micko »

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.
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?

Cheers
Puppy Linux Blog - contact me for access

dawnsboy

#36 Post by dawnsboy »

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

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#37 Post by tempestuous »

01micko wrote:when the gui is started the radio button at the top is checked by default
That's my point; good scripting could avoid this.
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!
01micko wrote:Do you think there is a need for a "current mode" button?
No. The gui should indicate the current mode without the user needing to consciously press something to find out.

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.

dawnsboy

#38 Post by dawnsboy »

@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.
Attachments
eeecontrol1.png
(11.68 KiB) Downloaded 950 times

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#39 Post by 01micko »

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..
Attachments
neweeegui.jpg
(18.12 KiB) Downloaded 1007 times
Puppy Linux Blog - contact me for access

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#40 Post by tempestuous »

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.
Attachments
aarf-CPUtemp-fanspeed.jpg
(4.97 KiB) Downloaded 1010 times

Post Reply