LiveCDPerformance

Differences between revisions 12 and 37 (spanning 25 versions)
Revision 12 as of 2005-04-26 05:48:59
Size: 3999
Editor: intern146
Comment:
Revision 37 as of 2008-08-06 16:14:57
Size: 2181
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
== Status ==

  * Created: [[Date(2005-04-23T03:04:58Z)]] by MattZimmerman[[BR]]
  * Priority: MediumPriority[[BR]]
  * People: MatthewGarrettLead, FabioDiNittoSecond[[BR]]
  * Contributors: MattZimmerman[[BR]]
  * Interested: JuanjeOjeda[[BR]]
  * Status: WaitingOnColinCharles, BreezyGoal, UduBof, DistroSpecification, DraftSpec,[[BR]]
  * Branch: [[BR]]
  * Malone Bug: [[BR]]
  * Packages: [[BR]]
  * Depends: [[BR]]
  * UduSessions: 1, 4, 8, etc [[BR]]
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/live-cd-performance
 * '''Created''': <<Date(2005-04-23T03:04:58Z)>> by MattZimmerman<<BR>>
 * '''Contributors''': TollefFogHeen, MattZimmerman
 * '''Packages affected''': casper
Line 26: Line 17:
The better the load time, the better the liveCD experience, the greater chance an end user will want to use it and move on to installing Ubuntu or another distro.

== Scope and Use Cases ==
The better the load time, the better the live CD experience, the greater chance an end user will want to use it and move on to installing Ubuntu or another distro.
Line 32: Line 21:
Performance issues in two areas:

1) Installer

 * Can generation of locales be made faster?
The LiveCDPrompts looking after eliminate some unnecessary questions in the boot process. Language, keyboard layout and so on are some of them.

If we already now this stuff we save time from the input data and the reconfiguring of packages.

A possible solution is placing a localised version on the mirrors. For example, Spanish mirror with Spanish localised Live CD, and so on.

Generic CD required - we need to be able to ship them to the rest of the world.

 * Background things like network setup?
We don't actually need setup the network at the beginning


2) Post-di boot

 * Readahead configuration may be suboptimal
Seems not very helpful. See this experiment on Knoppix (the same compress filesystem: cloop):
http://unit.aist.go.jp/itri/knoppix/readahead/index-en.html

 * Do we need gdm?
GDM takes a lot of memory (what we need during the live session to run the applications) and takes a lot of time to run. We could run the ''/etc/alternatives/x-session-manager'' instead of the GDM

GDM takes a negligible amount of memory. Someone needs to time X startup with and without GDM.

 * The dma activations help, but no so much
 * We need check out the filesystem compression(whichever we want to use: cloop, squashfs...) performance. But seems this is not the main problem.
 * Check out if we run unnecessary services at the distribution boot time

Nope. There's nothing significant that we can remove.

 * Somebody did a comparative between the official Kubuntu live CD and the same content of the image but compress with ''Squashfs'' instead of ''cloop'' and ''unionfs'' instead of ''device-mapper''. Also he used the [http://metadistros.hispalinux.es Metadistros] live system. The result was the second one takes 50 sec less than Kubuntu to boot.
http://listas.hispalinux.es/pipermail/metadistros-dev/2005-April/000580.html

NEEDS INSTRUMENTATION - do we have detailed enough logfiles?


IMPLEMENTATION:

1) Full timings for initial install and second-stage boot.
2) For packages that spend an extended amount of time in configure, see if that can be improved
3) Investigate whether dropping gdm makes a significant difference to startup time
4) Test different filesystems
5) Investigate the interaction of readahead with the current compressed filesystem - are we spending more time seeking than we'd spend just loading the programs anyway?
 1. Instrumentation is required in order to identify bottlenecks. d-i logs stage 1, we can wrap init scripts to provide timing information on their startup. Bootchart would also be useful. Bootchart wraps init and would be used for instrumenting stage 2. It stores it information in the live cd system where it could be uploaded to a central location such as bugzilla.
 2. Enable DMA on livecd - it may not work on some systems, but it's effectively required
 3. Readahead may be a performance win with 256MB or more, but slower otherwise. Verify with different memory configurations, and ensure that readahead is only enabled when it's a performance benefit. http://unit.aist.go.jp/itri/knoppix/readahead/index-en.html has figures for Knoppix on cloop.
 4. Filesystem comparison - squashfs and unionfs may give a performance benefit. http://listas.hispalinux.es/pipermail/metadistros-dev/2005-April/000580.html suggests a 50 second improvement.
 5. Background network setup - this can be left for when the user has hit the desktop (NetworkMagic)
Line 82: Line 29:
None.
Line 83: Line 32:

For instrumentation, init requires modification or bootchart, which will be a better choice. Performance issues in the first stage install will require d-i modifications. Any slow packages in second stage boot will need tweaks to improve performance.
Line 86: Line 37:
== Outstanding Issues == None.
Line 88: Line 39:
=== UDU BOF Agenda ===

 * d-i performance
 * casper performance
 * Ubuntu boot performance (FasterBoot)

=== UDU Pre-Work ===

 * Profile the live CD boot sequence to measure the time taken for each step
  * d-i startup (time-to-first-question)
  * Pre-casper d-i activity (measured per menu entry)
  * Casper d-i activity (measured per casper.d script)
  * Standard boot sequence
----
CategorySpec

Live CD Performance

Introduction

The boot time for the Ubuntu live CD should be comparable (or superior) to other popular live CDs.

Rationale

The better the load time, the better the live CD experience, the greater chance an end user will want to use it and move on to installing Ubuntu or another distro.

Implementation Plan

  1. Instrumentation is required in order to identify bottlenecks. d-i logs stage 1, we can wrap init scripts to provide timing information on their startup. Bootchart would also be useful. Bootchart wraps init and would be used for instrumenting stage 2. It stores it information in the live cd system where it could be uploaded to a central location such as bugzilla.
  2. Enable DMA on livecd - it may not work on some systems, but it's effectively required
  3. Readahead may be a performance win with 256MB or more, but slower otherwise. Verify with different memory configurations, and ensure that readahead is only enabled when it's a performance benefit. http://unit.aist.go.jp/itri/knoppix/readahead/index-en.html has figures for Knoppix on cloop.

  4. Filesystem comparison - squashfs and unionfs may give a performance benefit. http://listas.hispalinux.es/pipermail/metadistros-dev/2005-April/000580.html suggests a 50 second improvement.

  5. Background network setup - this can be left for when the user has hit the desktop (NetworkMagic)

Data Preservation and Migration

None.

Packages Affected

For instrumentation, init requires modification or bootchart, which will be a better choice. Performance issues in the first stage install will require d-i modifications. Any slow packages in second stage boot will need tweaks to improve performance.

User Interface Requirements

None.


CategorySpec

LiveCDPerformance (last edited 2008-08-06 16:14:57 by localhost)