Availability of XO-1.5 ATest-2 machines
tiagomnm at gmail.com
Mon Jul 20 14:37:23 EDT 2009
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
>> 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.
>> 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
>> 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:
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.
> (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
> SD card
> slower CPU setting (if any)
> 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
More information about the Devel