Availability of XO-1.5 ATest-2 machines
david at lang.hm
david at lang.hm
Mon Jul 20 13:33:18 EDT 2009
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. (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
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
More information about the Devel