SBU calculations

Steve Crosby steve.crosby at gmail.com
Fri Jun 17 04:03:18 PDT 2005


On 17 Jun 2005, you wrote in lfs.dev:

> On Thu, Jun 16, 2005 at 08:32:56PM +0100, Matthew Burgess wrote:
>> 
>> Well, personally I measure them using the following simple rule:
>> 
>> 1. Start timing immediately after the tarball has been unpacked.
>> 2. Don't time the running of any testsuite commands.
>> 3. Stop timing immediately after 'make install' has completed.
>> 
>> This applies for all packages, including pass 1 of binutils in chapter 
> 
> I beg to differ.
> 
> Both glibc pages have time consuming post-make install commands.
> Both llh pages have no make install.
> util-linux in chapter 5 doesn't have a make install.
> perl in chapter 5 doesn't have a make install.
> zlib has 2 make installs.
> mktemp has 2 make installs.
> texinfo has 2 make installs.
> e2fsprogs has 2 make installs.
> hotplug has no make install.
> 
> That's 11 pages that might lead to confusion.
> 

First,

  Are users expected to be measuring package build times? I expect the SBU 
calculations for the BOOK involve the end user measuring binutils in 
Chapter 5, then using that as a GUIDE on how long remaining packages will 
take, rather than actually caluclating their own as they go.

  Certainly the editors\testers need to be able to calculate the actual 
SBU's, but they can refer to seperate (editors guide?) instructions for 
that surely.

Second,

  SBU's are a wild-ass guess. The methodology of calculating SBU's is fine, 
but the application of someone else's build time measurements bear only 
rough resemblance to my system - specifically because of architecture, 
disk, memory, CPU cache differences etc. Do we really need to care about 
<10% variances in build times for the initial SBU, when you can get greater 
variance than that due to other variables in the system.

(The point being, should we really care that much about how accurate the 
SBU is, given it's a finger in the air, rough-guide anyway....)

- --
Steve Crosby



More information about the lfs-dev mailing list