On Mon, Jul 20, 2009 at 6:33 PM, <da...@lang.hm> wrote: > On Mon, 20 Jul 2009, Richard A. Smith wrote: > >> da...@lang.hm wrote: >> >>>> My proposal is instead to stop giving out inaccurate predictions, wait >>>> a little longer, and publish real data. >>> >>> the trouble is that there is no such thing as 'real data' with >>> suspend/resume because the power used is so highly dependant on actual >>> useage patterns. >>> >>> however a worst case 'you will always get this much time, and may get >>> significantly more' is very repeatable and testable. >>> >> >> The wost case will be quite disappointing as the peak power draw of this >> machine is higher than XO-1. I'd say how much higher but I don't yet know >> because we don't have the software support for turning on everything at once. >> (on XO-1 peak power draw was camera running full screen with a ping -f going >> on on WLAN) >> >> It may take a bit to discover where peak usage is on this system. I'll get >> an idle baseline soon. >> >> While we are on subject it would be nice to outline what usage profiles >> should be tested to how to automatically and repeatedly create these >> profiles. >> >> I've been studying the stuff listed below which outlines several different >> workloads and has code that will automate them if you install the apps. >> >> http://www.lesswatts.org/projects/bltk/ >> >> Unfortunately the bltk fails to run on my Ubuntu system. It seems to trip >> the buffer overflow detection code and gets shutdown. >> >> I've also been pondering using dogtail to automate some workloads >> >> https://fedorahosted.org/dogtail/ >> >> I'm leaning toward using dogtail to re-implement some of the suggested >> workloads from bltk and add some OLPC specific ones. So if anyone wanted to >> help then creating a couple of different automated workloads via dogtail >> would be very nice. This can be done on a Gen 1. >> >> I'll work on verifying that my previous power management logging stuff works >> on Gen 1.5. > > thank you for working to get good numbers. > > while I understand that worst-case numbers can be abused, I think it's > much better to have 'guaranteed never to do worse than this' numbers > instead of 'garanteed never to do _better_ than this' type of numbers that > most vendors publish. > > while this does put you at a disadvantage for people that just casually > look at the numbers, it will build trust with people. > > the biggest problem with the XO-1 numbers wasn't just the fact that they > were wrong, it was the direction they were wrong in.
Precisely my point. Take, for instance, this article about the new Mac Pros: http://www.anandtech.com/mac/showdoc.aspx?i=3580 Apple quotes 7 hours of "wireless productivity", not just leaving the thing idling - they deliver more than 8 hours. Notice the praise and good word of mouth. Best regards, Tiago Marques > (and the fact that > the caviots that were part of the inital number announcements weren't > maintained by the people re-publishing the data, including the mainstream > media), so you had people planning to get long life, but ending up getting > _far_ shorter lifetimes. > > if you set the expectation to the short side of things, then actions taken > (sleep, dimming the backlight, turning off wireless, etc) are clear wins > that produce longer lifetimes. > > I think that it would be useful to get the following numbers > > 1. everything running full blast > 2. how much is saved by turning off each of the following components > camera > mic > wireless > backlight > SD card > slower CPU setting (if any) > USB > > > it would also work to define a baseline and list how much additional power > some of these options use, but I don't think that is really as good as > making everything subtract from the baseline > > after these numbers are available, then you can define workloads to try > and simulate 'typical useage patterns', idle system measurements, etc (the > numbers that are so squishy) > > > re CPU speed: sometimes the cost to sleep/wake is high enough that it is > better to throttle down rather than spinning idle at high speed until the > timeout to go fully to sleep hits > > > David Lang > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
