| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On Sat, 2023-08-26 at 11:44 +0000, super1337 wrote:
> Thank you for your replies. Because there is so much in my first
> email,
> I'll section it apart into more readable chunks.
>
> Regarding the utility of an updated LFS bootable media...
> Many various live media doesn't have everything that's needed to
> build
> an entire alfs system. In much the same way that the existing LFS
> bootable can't build a current LFS, other distribution live bootables
> can't do it either. For my particular scenario, this old i586 133MHz
> system needs fossils to come to life, because most of what's readily
> available need a minimum of i686. I'm slowly working my way towards
> getting this dinosaur of a PC running with current software, natively
> compiled. Once done, my intention is to try to make a live cd. This
> is
> a spare time project for me. I'm happy to share when it's done,
> however
> that will be quite some time from now.
>
> Regarding the re-calculated SBU...
> I apologize for the ambiguity. To clarify, the current SBU
> calculation
> is based on 1 out of some 110 different compiles. I would propose
> that
> this be could be changed some when doing a complete alfs build.
> Hypothetically, during the ch5 portion, time {binutils...} creates
> the
> initial SBU value as normal. In addition, this time number is also
> added
> to a "running sbu" file, such as sbu_toolkit.txt
>
> When the script advances to ch5-gcc, what the user sees on the screen
> would now read:
> "Building target 530 GCC (estimated build time $SBU)"
> While gcc is being built, it's being time{} in a very similar way as
> binutils. The time output is then appended to sbu_toolkit.txt
>
> This process of appending the time for each of the ch5 toolchain
> programs is repeated. When the script reaches ch6, $SBU is re-
> calculated
> by generating an average of the build times in sbu_toolkit.txt Using
> assumptions:
> build_time binutils: 5min +
> build_time gcc: 20min +
> build_time kernel headers: 1min +
> build_time glibc: 10min+
> build_time libstdc++: 1min = ch5_build_time 37min
> ch5_total_sbu = (let's assume 6.5)
> ch5_build_time_37min / ch5_total_sbu_6.5 = $RECALC_SBU_5.69min
>
> The SBU has now been re-caculated using a larger data set. As opposed
> to
> the SBU being calculated using %0.9 of the entire project, it's now
> calculated at %4. We've obtained a better representative sample. The
> SBU
> is no longer 5 minutes, it's 5m40s. Consequently, when the human
> looks
> at the screen and it says "Building target 818 binutils (estimated
> build
> time 11m37s)", the estimate will be more accurate. Depending on the
> hardware setup, having a more accurate SBU value can easily mean the
> difference between check in on the build after the night time news
> broadcast vs check in tomorrow after lunch.
>
> One reply stated SBU can't be recalculated from other ch5 packages.
> Perhaps my entire line of thinking is flawed because I'm not familiar
> enough with the entire process to understand why.
>
> I can easily accept a "Brad, you're stupid... it doesn't work that
> way.
> Trying to average the entirety of ch5 will give you a grossly skewed
> SBU." If this is the case, would it be better to recalculate during
> ch7?
You are not stupid, but it does not work this way :)
We give a measure of the time to build each package using a special
time unit, not second, not minute, but SBU. The standard for this unit
is the time to build binutils-pass1. By definition, it is 1 SBU. So to
convert a time from SBU to seconds, you have to multiply the value in
SBU by the number of seconds it takes to build binutils pass1. We
sometime abuse language and tell that the SBU is xx seconds. This means
that the time to build binutils-pass1 on this particular system is xx
seconds.
For us editors, computing a SBU value for building a packages amounts
to measure the time in seconds for building this package, then divide
by xx, the time it takes to build binutils-pass1. So no refinement of
the SBU value can be obtained by measuring a package build time. You
may find that a particular SBU value differs from what is in the book,
because your machine may have a different processor, different disk
access times, whatever, from the one that was used for writing the
book. But this value is not considered "better" than the initial one.
Our experience shows that usually SBU values are reproducible to within
10 % or better.
One could think of making several measurements for each package
(including the measure of the standard SBU by timing binutils-pass1),
and then take the average. But this may be misleading because the
kernel caches some memory, so that usually, an SBU value is shorter on
the second try than on the first one... True statistics would
necessitate to reboot the system between each measurement! But since
for some other reasons, not more than 10 % accuracy can be expected,
this is not worth the hassle.
Pierre
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page