Opportunity for speedup

[Gary C Martin]

Hi Bobby,

On 1 Mar 2009, at 21:44, Bobby Powers wrote:

> I've fixed a few issues, packaged up bootanim-2.3-1, and (finally)
> actually ran some benchmarks.  Results (all times in seconds):
>
> fresh os801, from pressing the power button to appearance of sugar's
> prompt for name screen
> 80
> 79
> 78
>
> with rhgb-client renamed so that init can't find it:
> 69
> 68
>
> and with bootanim-2.(1-3) rpm installed:
> 67
> 67
> 67
> 68
> 67
>
> If anyone is unconvinced, I could run more tests, but this seems
> pretty good to me.  Its a 15% overall speedup in the boot process.

I've just run a test here with candidate 801; average over 5 runs;  
starting on button press, stopping when XO first appears in users  
colours:

Before bootanim-2.3-1.i386.rpm:

	85.9 seconds

After patching:

	74.6 seconds

Booting in ugly text mode (includes the 3 sec ok wait):

	72.2 seconds

So, if this 10 sec boot saving gets accepted in a future build, you've  
just gained the world 1,400 extra hours of XO usage from the time this  
patch lands, and for every day thereafter (assumes a conservative 500K  
kids boot their XO just once a day on average).

Fantastic work, what an impressive butterfly effect!! :-)

--Gary

> Interesting notes:
> chkconfig doesn't like binary services - it parses services in
> /etc/init.d to look for metadata in comments, and the mechanism to
> override this data (sticking a file with the same name in
> /etc/chkconfig.d with appropriate comments) doesn't seem to work if
> the original script can't be parsed.  So I had to make small wrappers
> for ul-warning, boot-anim-start and boot-anim-stop.  This doesn't seem
> to affect performance.
>
> I can't seem to get ul-warning to come up properly, so if anyone can
> tell me what I'm doing wrong that would be great.  I've got it to work
> by manually placing some symlinks in /etc/rc0.d and /etc/rc6.d, but
> neither Scott's nor my chkconfig comments seem to work.
>
> source:
> http://dev.laptop.org/git?p=users/bobbyp/bootanim
> koji-built rpms:
> http://dev.laptop.org/~bobbyp/bootanim/
> (koji task https://koji.fedoraproject.org/koji/taskinfo? 
> taskID=1211738 )
>
> I don't know if this could make it into 8.2.1, or what the process
> would be toward getting it at least in the Rawhide/SOAS images, but it
> seems pretty low risk (assuming someone can tell me what I'm doing
> wrong w.r.t. ul-warning).
>
> yours,
> Bobby
>
> On Thu, Feb 19, 2009 at 3:03 AM, Mitch Bradley <wmb at laptop.org> wrote:
>> Cool!
>>
>> Bobby Powers wrote:
>>>
>>> On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley <wmb at laptop.org>  
>>> wrote:
>>>
>>>>
>>>> I just measured the time taken by the boot animation by the simple
>>>> technique of renaming /usr/bin/rhgb-client so the initscripts  
>>>> can't find
>>>> it.
>>>>
>>>
>>> how did you measure exactly? stopwatch? I'd like to recreate the
>>> tests.  It sounds like you did this on a freshly flashed system?
>>>
>>
>> Yes on both counts.  Stopwatch on freshly-flashed os7.img .
>>
>>
>>>
>>>>
>>>> With boot animation, OS build 7 (an older 8.2.1 candidate) takes 60
>>>> seconds from first dot (indicating OFW transfer to Linux) to Sugar
>>>> "prompt for your name".   Without it, 53 seconds.  I repeated the  
>>>> test
>>>> several times with consistent results.
>>>>
>>>> Clearly, it should be possible to display that amount of  
>>>> information in
>>>> much less than 7 seconds.
>>>>
>>>> The boot animation code is in the OLPC domain, not the upstream  
>>>> domain,
>>>> so replacing it should be relatively free of upstream politics.
>>>>
>>>> So if anybody is interested in implementing a relatively simple
>>>> boot-time speedup, I offer this as low-hanging fruit.
>>>>
>>>> I suggest 1 second (differential time between animation and no- 
>>>> animation
>>>> cases) as a reasonable target goal, assuming images of the  
>>>> complexity of
>>>> the current ones.  Arbitrary full-screen graphics might require  
>>>> more
>>>> time, but speeding up the baseline case is a good starting point.
>>>>
>>>> Go wild.
>>>>
>>>
>>> So I've taken a first cut at this, implemented with the following
>>> design considerations (mostly from a conversation with Mitch)
>>> - the Python client/server was reimplemented as several standalone C
>>> programs (boot-anim-start, boot-anim-client, and some cleanup in
>>> boot-anim-stop)
>>> - a client and server was used before because there is state
>>> information that needs to be saved: we need to keep track of where  
>>> in
>>> the animation we are.  We can keep track of this by using offscreen
>>> memory in the framebuffer (its 16MB in size, and only the first 2ish
>>> MB is used for the onscreen graphics (my terminology might be off
>>> here)).  For state we really only need to keep track of 2 integers,
>>> one for the current frame number and another to store the offset of
>>> the next diff to apply.
>>> - on startup we load an initial image into the framebuffer (the  
>>> first
>>> 1200*900*2 bytes, since we use 2 bytes per pixel for color
>>> information), and then load in a series of changes to the  
>>> framebuffer
>>> image (<300KB).  This takes the form of a series of diffs
>>> - for each update (a valid call to boot-anim-client) we apply the  
>>> next
>>> diff in the series to the onscreen image and update our state
>>> information
>>> - after applying the last diff we have (the end in the animation
>>> series), freeze the DCON (when I first attempted to freeze the DCON
>>> when z-boot-anim-stop was called it left the screen in an  
>>> inconsistent
>>> state, I believe because of X startup)
>>> - its designed to be as light as possible, using syscalls instead of
>>> libc functions as much as possible (the only thing we use libc for  
>>> is
>>> string comparison, which could be replaced with a local function).
>>> while its written like this, I haven't worked on cutting down the
>>> linking (I need some guidance for that)
>>>
>>
>> To reduce the execution footprint, you could try linking it against
>> dietlibc, http://www.fefe.de/dietlibc/
>>
>> I'm not sure just how much time that would save; maybe it wouldn't be
>> significant.  But it's worth a try.
>>
>>
>>> comments and suggestions welcome :)
>>>
>>> I'd appreciate any testing as well as any code review.  (the  
>>> shutdown
>>> image appears to be broken, FYI.  i haven't looked at that in depth,
>>> its probably a one line fix.)
>>> rpms (built with mock) are available at
>>> http://dev.laptop.org/~bobbyp/bootanim/
>>> and source is avail at
>>> http://dev.laptop.org/git?p=users/bobbyp/bootanim
>>>
>>> -Bobby
>>>
>>
>>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel