Linux On My Samsung

I was playing with Karmic to see how low I could get the power drain using "normal" operations in order to try to get as much battery life as WinXP. I am using the scripts from the PPA (they sure are nice )

It seems that it's getting pretty close, but there are some things that concern me.

Even with the webcam and bluetooth turned off, powertop is still saying they are active. I know powertop has some bug related to USB autosuspend (from what I gathered, it seems it doesn't read those value correctly). So, I was using the Gnome power managers data (right click on the battery icon and do power history). It collects similar information to powertop, just without the suggestion.

Here are the questions:
1) the scripts just deactivate the driver for the bluetooth/webcam. Does this also power down the device, or are we relying on the kernel to do that for us?

2) same question for the wifi - even after disabling the wifi, there is still 6 wake-ups per second from the uhci modile with the test "usb5, i915, ath", which I'm assuming is the wifi module. If we turned it off, shouldn't that go down to zero? It seems that the chip is still powered up and not transmitting.

3) I'm using blueman instead of the built-in bluetooth manager because it's WAY better. This also allows you to turn off the bluetooth device from the program, but I'm not sure what it actually does. I do know that the scripts don't sync with it. If I disable from the program, "nc10 bluetooth status" still returns enabled. Basically, it allows some wackiness in mismatched states between the two programs. Is there any way to sync the two programs? Is one disabling better/more completely than the other?

and for reference, the command I was using to watch wake-ups was gnome-power-statistics

Here is a related bug for processor wake-ups:
https://bugs.launchpad.net/ubuntu/+sour ... bug/373245
http://bugzilla.kernel.org/show_bug.cgi?id=14424

It also seems something may be going on with the SMP support for the Atom processors (any maybe others).

I think there is definitely something going on with the netbooks. I just tested a P4m laptop while running a network copy, and it was only waking up 14 times per second, up to 80 or so with mouse input. My NC10 was base 22-30 and up to like 12000 (no joke) with a lot of mouse activity.

TeutonJon78 wrote:1) the scripts just deactivate the driver for the bluetooth/webcam. Does this also power down the device, or are we relying on the kernel to do that for us?

My scripts set the radio off for the bluetooth, and this means the device should be powered down.
Concerning the webcam, the scripts just remove its kernel module, but I'm not sure if this power down the device.

TeutonJon78 wrote: 2) same question for the wifi - even after disabling the wifi, there is still 6 wake-ups per second from the uhci modile with the test "usb5, i915, ath", which I'm assuming is the wifi module. If we turned it off, shouldn't that go down to zero? It seems that the chip is still powered up and not transmitting.

I'm pretty sure the wireless card is powered down, because the 'ath5k' module has native rfkill function built in. Removing the module is a way to set rfkill on (ie, radio killed).

TeutonJon78 wrote: 3) I'm using blueman instead of the built-in bluetooth manager because it's WAY better. This also allows you to turn off the bluetooth device from the program, but I'm not sure what it actually does. I do know that the scripts don't sync with it. If I disable from the program, "nc10 bluetooth status" still returns enabled. Basically, it allows some wackiness in mismatched states between the two programs. Is there any way to sync the two programs? Is one disabling better/more completely than the other?

My scripts use the 'hciconfig' command line utility to check/set the status of bluetooth.
I've never used blueman so I don't know how it works, anyway 'nc10 bluetooth status' read the state from the hciconfig output. I definitely trust hciconfig more.

Just checked blueman, and I have to say I like it.

Anyway, if I shut down the bluetooth with blueman, 'hciconfig' reports the radio is down and my (old) scripts work (the just-released new ones act differently, they check if the btusb module is loaded).
The problem is, if I try to re-enable the bluetooth with blueman, it does nothing, the bluetooth remains disabled. I have to reload the kernel module to restore it.

blueman is significantly better than built in bluetooth manager (in the fact that it actually works). I couldn't connect to my cellphone over the built in one, but it connects right away with blueman. Plus, I liked it because it has the built in bluetooth disable, and it remembers the settings over the boot. Here is the website: http://blueman-project.org/ . If you use Ubuntu Tweak, it can take care of installing the newest version for you as well.

Any chance the newer script method could be made compatible with blueman as well? It would be nice to have them be synced somehow.

------------

I'm still curios about the other wakeup events. I don't have Ubuntu installed on my main computer, but I'm going to boot a livecd and see what it shows up for number of wake-ups. It just seems odd that the lowly atom would be woken up more often than a P4M or an old P4 (not HT). If it is really the hyperthreading, then something may be amiss in the kernel (as per the bug reports).

TeutonJon78 wrote:Any chance the newer script method could be made compatible with blueman as well? It would be nice to have them be synced somehow.

The fact is that the scripts have to be as more generic as possible, in order to work good with any configuration. And to accomplish this, hciconfig utility and module removal are the best way to work.
Anyway, the blueman tray icon disappears when the bluetooth module is removed, so I think it works good enough this way.

TeutonJon78 wrote:I'm still curios about the other wakeup events. I don't have Ubuntu installed on my main computer, but I'm going to boot a livecd and see what it shows up for number of wake-ups. It just seems odd that the lowly atom would be woken up more often than a P4M or an old P4 (not HT). If it is really the hyperthreading, then something may be amiss in the kernel (as per the bug reports).

This is a long standing bug now, we are all waiting for a solution.

voRia wrote:Anyway, the blueman tray icon disappears when the bluetooth module is removed, so I think it works good enough this way.

Hmmm....I'll have to play with that. My icon didn't disappear at all. It just stays there.

I hope they fix this wake-up kernel bug.

However, in going back to ubuntu 8.10 (before the hr_timer wakeup kernel bug), I was hardly able to get the wakeups to be significantly lower than 9.03 or 9.10, probably due to other inefficiencies.

If you disable hyperthreading in the bios, it cuts the cpu wakeups in half (I've tested this, 1 less virtual cpu to wake-up).

The lowest wakeups/sec I was able to get for my 9.03 or 9.10 machine was around 15-25. However, powertop would record my cpu to be in the lowest state (C4 or C3) over 95%-98% of the time, which is good. Power usage : 7-11 W (lower than winXP, but still shorter battery life).

One thing I noticed about 9.10 vs 9.03, is that 9.03 allowed a much more fine-tuned adjustment of screen brightness. I cannot get 9.10 to go as dim (but visible) as 9.03. There probably is a way to adjust these power management settings in a config file, but I haven't looked....

So I was looking at some of the USB settings as to why the bluetooth and webcam were always powered up.

1) USB 1-8: Webcam
"powertop -d" shows the webcam as 100% active regardless of kernel module being present or not, so I went to look at the usb power values (as we all know, powertop makes some incorrect recommendations)

/sys/bus/usb/devices/1-8/power/level = on
/sys/bus/usb/devices/1-8/power/autosuspend = 2 (same as rest of USB devices by default)

- (as root) "echo auto > /sys/bus/usb/devices/1-8/power/level"
- Now, the USB hub can go into autosuspend mode. Using powertop reveals that it is now 0% active without having to remove the kernel module.
- You can start up cheese or something else and the webcam will powerup as normal.

2) USB 3-2: Bluetooth
"powertop -d" shows the bluetooth as 100% active, regardless of whether or not the bluetooth module is present or not.

/sys/bus/usb/devices/3-2/power/level = on
/sys/bus/usb/devices/3-2/power/autosuspend = 2 (same as rest of USB devices by default)

- (as root) "echo auto > /sys/bus/usb/devices/3-2/power/level"
-"powetop -d" shows the bluetooth as 100% active still (well, I sort of expected that since as a radio, it would still doing it's radio-like things for discovery and such
-disable bluetooth
- "powertop -d" now shows the bluetooth usb device as 0% active
- re-add the bluetooth module and bluetooth starts up again

So, the nc10-scripts are working well. But there is a bug with the USB power level of the webcam and bluetooth. Does anyone know who (and by who, I mean what piece of software) controls those default settings?

3) nc10-scripts and blueman
I'm now getting the same results with enabling and disabling. If I disable the blueooth, the icon is disappearing now (with the new 11-12 version of the scripts). This wasn't the case with the earlier version. However, if you have bluetooth radio disabled in blueman and then disable-enable the module, blueman will not start up again (not sure why) which is unfortunate. If it would start up again and just still be disabled, that would be great.

blueman "disable bluetooth" does essentially issue a "hciconfig hci0 down" command, but does not remove the bluetooth module.

4) possible new nc10-scripts command - would it be possible to get a command "nc10 status" that just basically runs through each of the commands to show the current status of each device? I'm lazy.

5) Something is odd with the synaptics driver OR the touchpad. On another laptop that has an Alps touchpad, when I watch gnome-power-statistics, there isn't a large increase in the processor wake-ups when using the pad. When using a USB mouse on a real desktop or in a VM, the same thing happens. But when I use the trackpad on the NC10, there are anywhere from 300-7000+ wake-ups per second from using the trackpad. This seems really odd, and since it is different from every other device, seems to say "bug" to me. Is anyone else having this same thing happen to them?

6) and then of course there is the hyperthreading issue (and the fact that is seems to have ridiculous amount of wakeups for ACPI and interrupt scheduling). oh well.

ossas81 wrote:One thing I noticed about 9.10 vs 9.03, is that 9.03 allowed a much more fine-tuned adjustment of screen brightness. I cannot get 9.10 to go as dim (but visible) as 9.03. There probably is a way to adjust these power management settings in a config file, but I haven't looked....

The brightness control behaviour was not correct with 9.04 (or BIOS < 11CA), it had way too many brightness levels (about 160, with the side effect of fine tuning adjustement you are talking about).
The latest BIOS (or the kernel module installed with 'nc10-backlight') corrects this behaviour and only allows for 8 levels, as it should be (and how it is with windows).

The only way to get back the old behaviour is to use a BIOS < 11CA and disable KMS by passing the option 'nomodeset' on kernel command line.

TeutonJon78 wrote: 1) USB 1-8: Webcam
...
2) USB 3-2: Bluetooth
...
So, the nc10-scripts are working well. But there is a bug with the USB power level of the webcam and bluetooth. Does anyone know who (and by who, I mean what piece of software) controls those default settings?

Probably udev?
Anyway, I can use your results and modify nc10-scripts accordly in order to handle the autosuspend for bluetooth and webcam. Thank you.

TeutonJon78 wrote: 3) nc10-scripts and blueman
I'm now getting the same results with enabling and disabling. If I disable the blueooth, the icon is disappearing now (with the new 11-12 version of the scripts). This wasn't the case with the earlier version. However, if you have bluetooth radio disabled in blueman and then disable-enable the module, blueman will not start up again (not sure why) which is unfortunate. If it would start up again and just still be disabled, that would be great.

Same here. I don't know how to avoid this behaviour, I'll search for a solution.

TeutonJon78 wrote: blueman "disable bluetooth" does essentially issue a "hciconfig hci0 down" command, but does not remove the bluetooth module.

This is the way how the old version of my scripts worked. Then I added the module removal just to make the bluetooth icon disappears when bluetooth is disabled (it works with the official bluetooth manager applet too). I can add a new option in '/etc/default/nc10-scripts' in order to enable/disable the module removal, if needed.

TeutonJon78 wrote: 4) possible new nc10-scripts command - would it be possible to get a command "nc10 status" that just basically runs through each of the commands to show the current status of each device? I'm lazy.

Done.

TeutonJon78 wrote: 5) Something is odd with the synaptics driver OR the touchpad. On another laptop that has an Alps touchpad, when I watch gnome-power-statistics, there isn't a large increase in the processor wake-ups when using the pad. When using a USB mouse on a real desktop or in a VM, the same thing happens. But when I use the trackpad on the NC10, there are anywhere from 300-7000+ wake-ups per second from using the trackpad. This seems really odd, and since it is different from every other device, seems to say "bug" to me. Is anyone else having this same thing happen to them?

I'll check this.
Anyway, if you think this is a bug, then the best thing to do is to file a new bug report on bugs.freedesktop.org.

voRia wrote:

TeutonJon78 wrote: 1) USB 1-8: Webcam
...
2) USB 3-2: Bluetooth
...
So, the nc10-scripts are working well. But there is a bug with the USB power level of the webcam and bluetooth. Does anyone know who (and by who, I mean what piece of software) controls those default settings?

Probably udev?
Anyway, I can use your results and modify nc10-scripts accordly in order to handle the autosuspend for bluetooth and webcam. Thank you.

Well, I'm not sure this is the best way for this to happen. I think we might want something that gets added into the startup rules so that they get set to auto power level. Just making it part of the scripts won't necessarily help.

For the webcam, if it was set to auto, the device would be powering down automatically, and we wouldn't even need to "turn it off". It turns back on automatically when a request is sent to it.

For the bluetooth, it doesn't matter quite as much, as it only turns it the bus down when the device is actually off. Although, this would allow Blueman or similar methods to actually turn the whole device off when disable and still leave the kernel module installed. I think the simpler things are, the better. Plus, then there is a GUI control over the bluetooth. I'm not sure where these scripts would go. I have links for some other distributions with netbooks:

http://wiki.archlinux.org/index.php/Samsung_NC10
https://help.ubuntu.com/community/AA1/Using
https://fedoraproject.org/wiki/Acer_Aspire_One

Obviously, for the other netbooks, the USB numbers are different (as they are even for the NC10 on ArchLinux it seems). The numbers may even be different for different models/builds as well. So, it may be difficult to make it a default part of the script (or at least need to make the script figure out the actual USB number).

voRia wrote: This is the way how the old version of my scripts worked. Then I added the module removal just to make the bluetooth icon disappears when bluetooth is disabled (it works with the official bluetooth manager applet too). I can add a new option in '/etc/default/nc10-scripts' in order to enable/disable the module removal, if needed.

I had already opened a bug against Blueman, because it seems like either way, it should be able to handle starting up again, even if it's starting up in "off".
https://bugs.launchpad.net/blueman/+bug/482892

voRia wrote:

TeutonJon78 wrote: 5) Something is odd with the synaptics driver OR the touchpad. On another laptop that has an Alps touchpad, when I watch gnome-power-statistics, there isn't a large increase in the processor wake-ups when using the pad. When using a USB mouse on a real desktop or in a VM, the same thing happens. But when I use the trackpad on the NC10, there are anywhere from 300-7000+ wake-ups per second from using the trackpad. This seems really odd, and since it is different from every other device, seems to say "bug" to me. Is anyone else having this same thing happen to them?

I'll check this.
Anyway, if you think this is a bug, then the best thing to do is to file a new bug report on bugs.freedesktop.org.

I'll probably play with it some more first, but will probably submit the bug. It was wondering if there is a "sensitivity" setting that is just crazy high and hence the large amount of interrupts.

TeutonJon78 wrote: Well, I'm not sure this is the best way for this to happen. I think we might want something that gets added into the startup rules so that they get set to auto power level. Just making it part of the scripts won't necessarily help.

The 'nc10-scripts' package already installs an upstart job and a pm rule in order to restore devices status on boot/resume/thaw. So, it would very easy to set autosuspend too.

TeutonJon78 wrote: For the webcam, if it was set to auto, the device would be powering down automatically, and we wouldn't even need to "turn it off". It turns back on automatically when a request is sent to it.

The webcam script is originally born with the idea to disable the webcam function, not really for power saving. It's always been a "plus", I personally prefer to keep the webcam always disabled (ie, module not loaded) because I never use it.

TeutonJon78 wrote: For the bluetooth, it doesn't matter quite as much, as it only turns it the bus down when the device is actually off. Although, this would allow Blueman or similar methods to actually turn the whole device off when disable and still leave the kernel module installed. I think the simpler things are, the better. Plus, then there is a GUI control over the bluetooth.

For me here is the same as for the webcam: I never use bluetooth too (used at most 2-3 times in about an year I have the NC10), and I prefer to not see the bluetooth icon in the taskbar. Anyway, as I said, it would be very easy to add a new option to disable the module removal, if anyone prefers so.

TeutonJon78 wrote: Obviously, for the other netbooks, the USB numbers are different (as they are even for the NC10 on ArchLinux it seems). The numbers may even be different for different models/builds as well. So, it may be difficult to make it a default part of the script (or at least need to make the script figure out the actual USB number).

Here too, it would be easy to add an option in '/etc/default/nc10-scripts' to allow the user to change the default USB numbers.

I was just playing with the bluetooth and autosuspend. The module can only be powered down with the module is removed. So just correcting the autosuspend and disabling bluetooth (via Blueman) still leaves it powered up. Removing the module allows it to power down completely.

I wonder how the bluetooth module in windows handles it. I usually keep it powered down, but wonder if the driver powers it down as well, or if it's still "active".

Here are the open related bugs to optimizing power drain:

Kernel
https://bugs.launchpad.net/ubuntu/+sour ... bug/373245
Basically, it seems UbuntuOne may be causing some of this, but investigation is still going on.

Touchpad
https://bugs.launchpad.net/ubuntu/+sour ... bug/194489
https://bugs.launchpad.net/ubuntu/+sour ... bug/487347 (mine)
It seems like this might not get fixed. There are some related bugs that after looking into it, seem to be similar and probably are. No one seems to believe that it's a problem though. Quite frankly, if only a touchpad is generating that many interrupts and not a mouse of other things, then it seems to me that there is a problem with the driver.

Blueman
https://bugs.launchpad.net/blueman/+bug/482892 (mine)

Non-bugs
USB sleeping (chaging power level to auto)