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 <w...@laptop.org> wrote: >> Cool! >> >> Bobby Powers wrote: >>> >>> On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley <w...@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@lists.laptop.org > http://lists.laptop.org/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel