Hello, On Wed, Jun 3, 2009 at 05:34, Peter Robinson <[email protected]> wrote: > You also have to realise that a atom cpu with a gig of ram and a relatively > fast SSD are hardware wise > an order of magnitude faster than the current Gen 1 XO hardware.
Of course I do, but IMHO there are also some things that could have been done differently. > The time it takes for a kernel to be loaded into RAM is hardware > dependant on things like the speed/bandwidth of the storage/bus/ram > etc And maybe not having to do complicated access to the storage space, uncompressing, or having to load an initrd as well :-) > I'm not sure you'll save that much by removing it. If you really want > to play with boot speed I suggest you flash on a copy of Fedora 11 and > then use some of their boot profiling tools to test and see where you > can save time. I will try fedora 11, if only to have a good refence point. But since you said many of the speedups where dependant on kernel fixes, how is 2.6.29 doing on the XO? Could anyone using f11/2.6.29 on the XO give some feedback ? > What version of XO software are you running? Have you tried SOAS or > one of the F11/rawhide test images to see if that improves speed at > all over 8.2.1? I'm not using sugar. The OLPC will be used to access drug information, so I made some different choices. Ideally, it would go straight into X and run opera to display local webpages built from information stored on a SQL database (which needs ~600 Mb of flash total). I'm more of a debian guy, so I took what I knew to have a working base which can be improved. At the moment, I am using a bootstrapped lenny where I removed everything I could. No udev, no hotplug but a custom made script to provide the firmware and do automounts, (etc). Going straight into X to run an old opera version (easier on ram use) Approx timings from pressing on the power button on my test machine using an old 2.6.22 on a jffs2 partition 2 seconds with the screen turned off 8 seconds to the end the jingle 11 seconds to the first OFW mesages and boot delay 18 seconds to initrd load 25 to leds blinking 37 seconds to the kernel black screen 45 seconds to mesh initialisation 52 seconds it init 2 starting its daemons 58 seconds to startx 1:04 seconds to having X loaded 1:10 seconds to having opera loaded and displaying the page Pretests results show a usage pattern where doctors prefer to power on the laptop when some specific information is needed. This behaviour is based on multiple factors, but in the end having a minute of delay is considered too long and could discourage users. IMHO jffs2 is only responsible for ~20 seconds (between initrd load and kernel black screen). I see ~10 other seconds before that which could be cut, if the boot status was saved and reused (something that old eeepcs do, saving HW status to the a special partition. Maybe ofw can also do that too?)Then there's 5 seconds of boot delay that a ofw recompilation can fix. The kernel init improvements will certainly bring 15 other seconds. Maybe some parallelisation of the sysvinit will save some time, say 5 seconds (low end estimation) So I see a boot delay that could be easily cut by half, and maybe reach 20 seconds while doing some moblin-like preinitialisation for the x server, etc. -- Dr. Guylhem Aznar, MD PhD Unité d'Analyse Médico-Économique Service de Santé Publique et d'Économie de la Santé Pôle SPSSR CHU de Fort de France BP 632 97261 Fort De France Cedex Martinique, France Tel : 05 96 55 23 47 Fax : 05 96 75 84 57 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
