| Newsgroups |
gmane.linux.lfs.automated |
| Message-ID |
<[email protected]> |
On Sat, Aug 26, 2023 at 11:44:28AM +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.
>
I think that ship has sailed. I'm surprised that you have working
drives (PATA-IDE>) for what sounds like a 20 years old machine.
> 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
>
The LFS SBU assumes your current system has sufficient tools to
build LFS. But the time is very much dependent on the machine and
the architecture (even before items like access to slow memory, slow
disks, swapping).
> 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.
>
Your recalculations are no longer SBUs, they are some other form of
build-time calculation.
> 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.
>
An SBU is conceptually simply - time the first package.
For BLFS, when I'm editing I try to retime an SBU after booting, and
to get an average of reasonable results (some kernels/machines are
consistently within a second or two, other times there is more
variation than epected in one run). But if the initial time is on
an old toolchain (where 'old' particularly means - 'before current
versions of gcc/binutils/glibc') then I expect a change: older
toolchains tended to be faster.
ĸen
> 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?
--
NEITHER RAIN NOR SNOW NOR GLOM OF NIT CAN STAY THESE MEßENGERS
ABOT THEIR DUTY -- motto on the Ankh Morpork Post Office
from 'The Night Watch' by Sir Terry Pratchett
--
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page