Availability of XO-1.5 ATest-2 machines

[david at lang.hm]

On Mon, 20 Jul 2009, Richard A. Smith wrote:

> david at 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. (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