source: chapter04/aboutsbus.xml@ eae92372

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-preps-aboutsbus">
  <?dbhtml filename="aboutsbus.html"?>

  <title>About SBUs</title>

  <para>Many people would like to know beforehand approximately how long
  it takes to compile and install each package. Because Linux From
  Scratch can be built on many different systems, it is impossible to
  provide absolute time estimates. The biggest package (gcc) will
  take approximately 5 minutes on the fastest systems, but could take
  days on slower systems! Instead of providing actual times,
  the Standard Build Unit (SBU) measure will be
  used instead.</para>

  <para>The SBU measure works as follows. The first package to be compiled is
  binutils in <xref linkend="chapter-cross-tools"/>. The time it takes to
  compile using one core is what we will refer to as the Standard
  Build Unit or SBU. All other compile times will be expressed in terms of this
  unit of time.</para>

  <para>For example, consider a package whose compilation time is 4.5
  SBUs. This means that if your system took 4 minutes to compile and
  install the first pass of binutils, it will take
  <emphasis>approximately</emphasis> 18 minutes to build the example package.
  Fortunately, most build times are shorter than one SBU.</para>

  <para>SBUs are not entirely accurate because they depend on many
  factors, including the host system's version of GCC.  They are provided here
  to give an estimate of how long it might take to install a package, but the
  numbers can vary by as much as dozens of minutes in some cases.</para>

  <para>On some newer systems, the motherboard is capable of contolling 
  the system clock speed. This can be controlled with a command such as
  <command>powerprofilesctl</command>. This is not available in LFS, but 
  may be available on the host system. After LFS is complete, it can be 
  added to a system with the procedures at the
  <ulink url='&blfs-book;sysutils/power-profiles-daemon.html'>
  BLFS power-profiles-daemon</ulink> page.

  Before measuring the build time of any package it is advisable to use a
  system power profile set for maximum performance (and maximum power 
  consumption). 

  Otherwise the measured SBU value may be inaccurate because the 
  system may react differently when building <xref linkend='ch-tools-binutils-pass1'/>
  or other packages.

  Be aware that a significant inaccuracy can still show up even if the same
  profile is used for both packages because the system may respond slower if
  the system is idle when starting the build procedure. Setting the power
  profile to "performance" will minimize this problem.</para>

  <para>On most distros the power profile can be managed with either
  <command>power-profiles-daemon</command> or <command>tuned</command>.
  If the distro runs <command>power-profiles-daemon</command>, issue the
  <command>powerprofilesctl set performance</command> command to select
  the <literal>performance</literal> profile.  If the distro runs
  <command>tuned</command>, issue the <command>tuned-adm profile
  throughput-performance</command> command to select the
  <literal>throughput-performance</literal> profile.</para>

  <para>Even if you are not measuring the SBU values, it's still better to
  select the power profile for maximum performance before building LFS, as
  doing so can (obviously) make the system faster to build LFS
  packages.</para>

  <note>
    <para>When multiple processors are used in this way, the SBU units in the
    book will vary even more than they normally would.  In some cases, the make
    step will simply fail.  Analyzing the output of the build process will also
    be more difficult because the lines from different processes will be
    interleaved.  If you run into a problem with a build step, revert to a
    single processor build to properly analyze the error messages.</para>

    <para>The times presented here for all packages 
    (except <xref linkend='ch-tools-binutils-pass1'/> which is based on one core)
    are based upon using four cores (-j4). The
    times in Chapter 8 also include the time to run the regression tests for
    the package unless specified otherwise.</para>
  </note>

</sect1>