Re: SBU calculations
On Wed, 2005-06-15 at 22:57 -0600, Archaic wrote: On Wed, Jun 15, 2005 at 11:47:47PM -0500, Randy McMurchy wrote: As a builder, and especially as a BLFS editor, I want to run these 3 steps individually, and examine the output of each log file. Sure, this is tedious, but I don't care. If make fails because I added a dependency that chokes the build, and then immediately run make install, I'll get who-knows-what installed on the system. Don't the 's take care of you? I actually do things in a more tedious fashion, but differently from you. I build and install twice. Once running each step individually and then pouring over the log output, then I uninstall it and do a more automated build to get timing and size. Then I diff the log output. But after that, it's always automated and the initial logs are kept for comparison even with future versions. I have to agree w/Randy that the SBUs are a rough approximation and usefull as such. I use a 3rd method by timing configure-make-make install using s for processes that usually take 3~5 SBUs and divided by the number in the book to get the value of 1 SBU. Then, when I see 11 SBUs, I know if have time to have a full meail or just a sandwich for lunch. My $.02 GN aka SeattleGaucho -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
On 6/17/05, Steve Crosby [EMAIL PROTECTED] wrote: 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) +1. My thoughts exactly, though I doubt if I could have said it so appropriately. -- Tushar Teredesai http://www.linuxfromscratch.org/~tushar/ http://www.geocities.com/tushar/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
Tushar Teredesai wrote: On 6/17/05, Steve Crosby [EMAIL PROTECTED] wrote: 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) +1. My thoughts exactly, though I doubt if I could have said it so appropriately. Even though it is an estimate for users, we should have a precise methodology. Giving SBUs to four or five significnat digits is not appropriate, but giving our best approximation is. If you check the SBU site main page, http://www.linuxfromscratch.org/~bdubbs you will see in the numbers the standard deviation of the submitted values. In some cases, it is obvious that the values are wildly divergent. In other cases, they are pretty good. I recommend just establishing a policy and using it as specified. The details of the policy are not that important. Documenting and following the policy is important. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
DJ Lucas wrote:
I'd guestimate that approx 90% or more of users (probably all
developers) use the the first cmmi for binutils as the baseline SBU just
Change it or don't, but justify
the change.
On second thought, don't. The extra commands are to be installed later
and seem to me to be part of a seond build (they are installed and used
later, not now). Explain it on the about SBUs page, and give _the_
example of how to determine your SBU.
time {
../binutils-2.15.91.0.2/configure --prefix=/tools \
--disable-nls
make configure-host
make LDFLAGS=-all-static
make install
}
-- DJ Lucas
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: SBU calculations
Randy McMurchy wrote: I don't think the last two binutils commands belong in the timing of the SBU, as these two commands aren't involved in the build process of the *binutils* pass1 chapter 5 package. These two commands are used as part of the setup for binutils in pass2. To me I see this different than you. Well, I'm in violent agreement with you here, Randy. Like you though, I'm not sure it much matters whether the two extra instructions are included or not. I'd prefer they are left out, but I'll defer to whatever the lists' consensus is on this one. Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
Matthew Burgess wrote:
Randy McMurchy wrote:
I don't think the last two binutils
commands belong in the timing of the SBU, as these two commands
aren't involved in the build process of the *binutils* pass1
chapter 5 package. These two commands are used as part of the
setup for binutils in pass2. To me I see this different than
you.
Well, I'm in violent agreement with you here, Randy. Like you though,
I'm not sure it much matters whether the two extra instructions are
included or not. I'd prefer they are left out, but I'll defer to
whatever the lists' consensus is on this one.
Just for reference, this is the script I use for my timing build of
binutils.
Doing some checking, the timing of:
make -C ld clean
make -C ld LIB_PATH=/tools/lib
takes 5.1% of the total build time. Changing the process to not include
this 5% will increase all the others by this amount. The largest value,
glibc in Chapter 6, will increase from 12.3 SBU to 12.9 SBU.
The way it is measured will, of course, affect BLFS, but since we have
to rebuild everything and remeasure everything for a released based on a
new LFS anyway, it wouldn't make any difference.
My only concern is telling users how to measure. I have always thought
of the SBU measurements as the time it takes to accomplish the
procedures in a section of the book, not necessarily the time to build
the 'package'. If you are not going to measure all the instructions in
Chapter 5's binutils, then this needs to be made very clear in the book.
For instance, after the make install, add a note like:
Note: If you are timing your build of binutils to determine a base time
for SBU calculations, do not include the following two instructions in
the timing measurements.
If other sections of the book have instructions that are not included in
the timing, similar notes should be added. This is cumbersome and IMO
unnecessary.
If I were making the decision, I think I would change the second
paragraph in section 4.5 - About SBU's from the present:
The SBU measure works as follows. The first package to be compiled from
this book is Binutils in Chapter 5. The time it takes to compile this
package is what will be referred to as the Standard Build Unit or SBU.
All other compile times will be expressed relative to this time.
to:
The SBU measure works as follows. The first package to be compiled from
this book is Binutils in Chapter 5. The time it takes to execute all the
instructions in that section is what will be referred to as the Standard
Build Unit or SBU. All other compile times will be expressed relative to
this time.
-- Bruce
#!/bin/bash
TIMEFMT='%1R Elapsed Time - '
###
# Installing binutils-pass-1
PROGRAM='binutils-2.15.94.0.2.2'
LOG='../binutils5-1.log'
TITLE=$PROGRAM - Pass 1
TIMEFORMAT=$TIMEFMT $TITLE
before2=`df -k $LFS | grep $LFS | sed -e s/ \{2,\}/ /g | cut -d' ' -f3`
pushd $BUILDDIR
tar -jxf $SRCDIR/$PROGRAM.tar.bz2 || exit 1
cd $PROGRAM || exit 1
{ time \
{
echo Making $TITLE
date
mkdir ../binutils-build
cd ../binutils-build
../$PROGRAM/configure --prefix=/tools --disable-nls
make
make install
make -C ld clean
make -C ld LIB_PATH=/tools/lib
}
} 21 | tee -a $LOG
if [ $PIPESTATUS -ne 0 ]; then exit 1; fi;
echo `du -k $SRCDIR/$PROGRAM.tar.bz2` size | tee -a $LOG
after2=`df -k $LFS | grep $LFS | sed -e s/ \{2,\}/ /g | cut -d -f3`
echo $(($after2-$before2)) kilobytes / build size - $PROGRAM | tee -a $LOG
popd
###
exit 0
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: SBU calculations
On Thu, Jun 16, 2005 at 11:28:40AM -0500, Randy McMurchy wrote: Okay, we really need this sorted. Randy: SBU changes will throw everything off Bruce: SBU changes are minor I was only holding off due to Randy's concern for the timings, but if it isn't a big deal, I'd rather the book assumes *all* commands (sans testsuites) as that is the only was for us to use *one* standard. I am not loking at this as This part is really for package X and this part for package Y as that is not maintainable without a list of exceptions explicitly stated in the book. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
Archaic wrote these words on 06/16/05 11:59 CST: Okay, we really need this sorted. Let's first decide on how the SBUs will be calculated. It seems I read Matt is in agreement that configure-make-make install to build and install the Chapter 5 Pass1 binutils should be used to calculate. You and Bruce think it should be the entire page of instructions. Until this issue is agreed upon, everything else is moot. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 12:07:00 up 75 days, 11:40, 2 users, load average: 0.34, 0.27, 0.20 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
El Jueves, 16 de Junio de 2005 18:59, Archaic escribi: On Thu, Jun 16, 2005 at 11:28:40AM -0500, Randy McMurchy wrote: Okay, we really need this sorted. Randy: SBU changes will throw everything off Bruce: SBU changes are minor I was only holding off due to Randy's concern for the timings, but if it isn't a big deal, I'd rather the book assumes *all* commands (sans testsuites) as that is the only was for us to use *one* standard. I am not loking at this as This part is really for package X and this part for package Y as that is not maintainable without a list of exceptions explicitly stated in the book. Remember that we will have the issue about how to measure SBUs on cross-lfs (LFS 7.0): http://linuxfromscratch.org/pipermail/lfs-dev/2005-June/051682.html -- Manuel Canales Esparcia Usuario de LFS n2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
David Jensen wrote these words on 06/15/05 18:08 CST: actually I think all the values could be grep'd, cut, adjusted with a ratio and sed'd, all in a for loop. Anyone up to the script? Well, there's certainly no rush. This would be for after BLFS-6.1. And we must wait until we know what version of GCC and what version of binutils our next LFS target after 6.1 is. Too many intangibles to do anything now. This is of course, going on Matt and Archaic's recommendation that the SBU factoring doesn't change until after LFS-6.1. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 20:16:01 up 74 days, 19:49, 2 users, load average: 0.02, 0.05, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
Archaic wrote these words on 06/15/05 23:30 CST: On Wed, Jun 15, 2005 at 08:20:04PM -0500, Randy McMurchy wrote: This is of course, going on Matt and Archaic's recommendation that the SBU factoring doesn't change until after LFS-6.1. Randy, what is your take on the proposal for post-6.1? It really doesn't matter to me. SBU is just a rough guideline anyway. If post 6.1 changes to use the other two binutils commands, it just decreases the SBU time in all the other LFS and BLFS packages by a hair. To answer your question, I don't think the last two binutils commands belong in the timing of the SBU, as these two commands aren't involved in the build process of the *binutils* pass1 chapter 5 package. These two commands are used as part of the setup for binutils in pass2. To me I see this different than you. Where I am confused, is to what extent of the gray boxes as you phrase it, do we count in the BLFS side when calculating? Do we stop after the installation section concludes, or do we use the steps included in the configuration section? More than that though, is my personal way of calculating the SBU times, I must admit I do it in a most peculiar way. I don't run configure-make-make install all at one time and time it. I take separate times for the 3 steps (more steps in unusual cases) and add them. Why? As a builder, and especially as a BLFS editor, I want to run these 3 steps individually, and examine the output of each log file. Sure, this is tedious, but I don't care. If make fails because I added a dependency that chokes the build, and then immediately run make install, I'll get who-knows-what installed on the system. This is not worth it to me. I like to be very precise and know that when I run make install, it is after a totally clean build. So I run configure-make-make install in separate steps and add the times together. If I had to now change things, so that everything in gray boxes was needed to be added in, this would be simply too much work for me to do correctly. However, it is my experience that you can run all the configuration and nic-nac post-installation tasks (even installing docs during the installation commands) after make install in one second or less. So the configuration steps really are negligible time-wise. Sorry for the long post. My take is that it doesn't matter if the last two binutils commands are used, I'll just adjust times accordingly. But I'm not sure I'll ever time anything after the make install commands, unless it really proves to be time-consuming. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 23:31:00 up 74 days, 23:04, 2 users, load average: 0.07, 0.11, 0.10 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SBU calculations
On Wed, Jun 15, 2005 at 11:47:47PM -0500, Randy McMurchy wrote: As a builder, and especially as a BLFS editor, I want to run these 3 steps individually, and examine the output of each log file. Sure, this is tedious, but I don't care. If make fails because I added a dependency that chokes the build, and then immediately run make install, I'll get who-knows-what installed on the system. Don't the 's take care of you? I actually do things in a more tedious fashion, but differently from you. I build and install twice. Once running each step individually and then pouring over the log output, then I uninstall it and do a more automated build to get timing and size. Then I diff the log output. But after that, it's always automated and the initial logs are kept for comparison even with future versions. Sorry for the long post. My take is that it doesn't matter if the last two binutils commands are used, I'll just adjust times accordingly. But I'm not sure I'll ever time anything after the make install commands, unless it really proves to be time-consuming. And glibc is just such a case. I was thinking of a way of reducing future maintenance load because if it is assumed that all commands (sans testsuites) are included, then you don't have to create a list of exceptions to the asumption. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
