Availability of XO-1.5 ATest-2 machines

[Tiago Marques]

On Mon, Jul 20, 2009 at 6:33 PM, <david at lang.hm> wrote:
> 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.

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 at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>