Crowdfunding an Ubuntu smartphone

joerg Reisenweber joerg at openmoko.org
Mon Aug 26 13:32:41 CEST 2013


On Mon 26 August 2013 13:17:09 Radek Polak wrote:
> On Saturday, August 24, 2013 03:20:10 PM joerg Reisenweber wrote:
> > On Sat 24 August 2013 14:22:55 Radek Polak wrote:
> > > 1/ poor power management
> > 
> > [...]
> > 
> > > something. But i always worked in userspace. I barely understand kernel
> > > and i have no EE skills and equipment to contribute. I can contribute
> > > only as a tester. I thought that i will deliver working userspace and
> > > IMO QtMoko is very good at it. But without working kernel and HW there
> > > is not much point to improve it.
> > 
> > many thanks for this contribution, it's already a better help than much
> > of the discussion about what's wrong with our community and the GTA04
> > project at large.
> > 
> > However one remark about it: it's not that simple to blame kernel for
> > poor power management. What we learned from last maybe 6 years of
> > different OM distros and from maemo and mer and nitdroid etc is: poor
> > power management is way too often caused by userland, like sensorfw and
> > WLAN connection manager and X11/windowmanager and audio (alsa/PA) and
> > whatnot else.
> 
> Yup, after playing with alsa settings i could save a few mAmps on GTA04
> too.
> 
> > Often it's even rogue apps that do silly stuff like updating their system
> > status icon 25 times per second or constantly chatting with internet or
> > even just polling files when you should use inotify instead.
> > Kernel power saving measures are relatively simple to test and fix, and
> > usually it's not kernel to blame for abysmal standby time and/or
> > operation time.
> > 
> > To give you a simple example: on N900 maemo you have "scanning period" in
> > settings-internet, which makes device scan for WLAN APs only every 5, 10,
> > ... even 30 min. This is needed since the WLAN chip cuts thru the battery
> > in less than 3 hours when you constantly scan for APs. Clearly a userland
> > issue where kernel can't do much. Now you can start to blame kernel WLAN
> > driver for not doing proper powersaving but that won't help establish a
> > decently working usable OS on N900.
> 
> I think in case of QtMoko on GTA04 we can blame kernel/HW a little bit
> more, since we are using suspend to RAM whereas N900 is always on (which
> really cool btw). So while GTA04 is in standby there should be idealy just
> PMU+RAM+modem turned on, everything else should be off. But something is
> wrong and noone has yet figured what it is. At best there is ~16mA with
> omap enable_off_mode - but then we hit "imprecise external abort" bug so
> currently we have ~22mA at best. If you compare this with GTA02 or N900
> it's really bad. GTA02 is 12mA and i'd say N900 is even better. Together
> with reenumerating modem it makes GTA04 barely usable even for a few
> hardcore supporters but unusable for normal users.
> 
> Regards
> 
> Radek

Yes, absolutely (I can't confirm neither deny your facts). N900 easily goes 
down to ~10mA in *standby*, see 
http://wiki.maemo.org/N900_Hardware_Power_Consumption
and also
http://wiki.maemo.org/N900_software_power_management

What I can think of are floating lines making chips eat more than they should - 
may particularly due to suspend mode.

Let's hope we'll iron that out during next few months

cheers
jOERG
-- 
()  ascii ribbon campaign - against html e-mail     
/\  www.asciiribbon.org   - against proprietary attachments
(alas the above page got scrapped due to resignation(!!), so here some 
supplementary links:)
http://www.georgedillon.com/web/html_email_is_evil.shtml          
http://www.nonhtmlmail.org/campaign.html
http://www.georgedillon.com/web/html_email_is_evil_still.shtml    
http://www.gerstbach.at/2004/ascii/ (German)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openmoko.org/pipermail/community/attachments/20130826/37575318/attachment.sig>


More information about the community mailing list