1 | <?xml version="1.0" encoding="UTF-8"?>
|
---|
2 | <!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
---|
3 | "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
---|
4 | <!ENTITY % general-entities SYSTEM "../general.ent">
|
---|
5 | %general-entities;
|
---|
6 | ]>
|
---|
7 |
|
---|
8 | <sect1 id="ch-preps-aboutsbus">
|
---|
9 | <?dbhtml filename="aboutsbus.html"?>
|
---|
10 |
|
---|
11 | <title>About SBUs</title>
|
---|
12 |
|
---|
13 | <para>Many people would like to know beforehand approximately how long
|
---|
14 | it takes to compile and install each package. Because Linux From
|
---|
15 | Scratch can be built on many different systems, it is impossible to
|
---|
16 | provide absolute time estimates. The biggest package (gcc) will
|
---|
17 | take approximately 5 minutes on the fastest systems, but could take
|
---|
18 | days on slower systems! Instead of providing actual times,
|
---|
19 | the Standard Build Unit (SBU) measure will be
|
---|
20 | used instead.</para>
|
---|
21 |
|
---|
22 | <para>The SBU measure works as follows. The first package to be compiled is
|
---|
23 | binutils in <xref linkend="chapter-cross-tools"/>. The time it takes to
|
---|
24 | compile using one core is what we will refer to as the Standard
|
---|
25 | Build Unit or SBU. All other compile times will be expressed in terms of this
|
---|
26 | unit of time.</para>
|
---|
27 |
|
---|
28 | <para>For example, consider a package whose compilation time is 4.5
|
---|
29 | SBUs. This means that if your system took 4 minutes to compile and
|
---|
30 | install the first pass of binutils, it will take
|
---|
31 | <emphasis>approximately</emphasis> 18 minutes to build the example package.
|
---|
32 | Fortunately, most build times are shorter than one SBU.</para>
|
---|
33 |
|
---|
34 | <para>SBUs are not entirely accurate because they depend on many
|
---|
35 | factors, including the host system's version of GCC. They are provided here
|
---|
36 | to give an estimate of how long it might take to install a package, but the
|
---|
37 | numbers can vary by as much as dozens of minutes in some cases.</para>
|
---|
38 |
|
---|
39 | <para>On some newer systems, the motherboard is capable of controlling
|
---|
40 | the system clock speed. This can be controlled with a command such as
|
---|
41 | <command>powerprofilesctl</command>. This is not available in LFS, but
|
---|
42 | may be available on the host distro. After LFS is complete, it can be
|
---|
43 | added to a system with the procedures at the
|
---|
44 | <ulink url='&blfs-book;sysutils/power-profiles-daemon.html'>
|
---|
45 | BLFS power-profiles-daemon</ulink> page.
|
---|
46 |
|
---|
47 | Before measuring the build time of any package it is advisable to use a
|
---|
48 | system power profile set for maximum performance (and maximum power
|
---|
49 | consumption).
|
---|
50 |
|
---|
51 | Otherwise the measured SBU value may be inaccurate because the
|
---|
52 | system may react differently when building <xref linkend='ch-tools-binutils-pass1'/>
|
---|
53 | or other packages.
|
---|
54 |
|
---|
55 | Be aware that a significant inaccuracy can still show up even if the same
|
---|
56 | profile is used for both packages because the system may respond slower if
|
---|
57 | the system is idle when starting the build procedure. Setting the power
|
---|
58 | profile to <quote>performance</quote> will minimize this problem. And
|
---|
59 | obviously doing so will also make the system build LFS faster.</para>
|
---|
60 |
|
---|
61 | <para>If <command>powerprofilesctl</command> is available, issue the
|
---|
62 | <command>powerprofilesctl set performance</command> command to select
|
---|
63 | the <literal>performance</literal> profile. Some distros provides the
|
---|
64 | <command>tuned-adm</command> command for managing the profiles instead of
|
---|
65 | <command>powerprofilesctl</command>, on these distros issue the
|
---|
66 | <command>tuned-adm profile throughput-performance</command> command to
|
---|
67 | select the <literal>throughput-performance</literal> profile.</para>
|
---|
68 |
|
---|
69 | <note>
|
---|
70 | <para>When multiple processors are used in this way, the SBU units in the
|
---|
71 | book will vary even more than they normally would. In some cases, the make
|
---|
72 | step will simply fail. Analyzing the output of the build process will also
|
---|
73 | be more difficult because the lines from different processes will be
|
---|
74 | interleaved. If you run into a problem with a build step, revert to a
|
---|
75 | single processor build to properly analyze the error messages.</para>
|
---|
76 |
|
---|
77 | <para>The times presented here for all packages
|
---|
78 | (except <xref linkend='ch-tools-binutils-pass1'/> which is based on one core)
|
---|
79 | are based upon using four cores (-j4). The
|
---|
80 | times in Chapter 8 also include the time to run the regression tests for
|
---|
81 | the package unless specified otherwise.</para>
|
---|
82 | </note>
|
---|
83 |
|
---|
84 | </sect1>
|
---|
85 |
|
---|