On Mon, Nov 18, 2013 at 10:16:10AM -0600, Bruce Dubbs wrote:
>
> Bottom line -- jsut use what you have. Sometimes a short description is
> useful like (all dependencies) or (with[out] tests).
>
Another comment on the SBU measurements : for a long time, I've
been repeating the SBU calculation when I boot the new system, so
that I've got what I assume is a reliable figure [ the first build
is from an older system, and build times change as the toolchain
changes (or indeed other things, e.g. makeinfo was reputedly
slower in 5.0 than the old version).
BUT - when I was playing with make-4.0 I got some very inconsistent
results. I've now retried the calculations, and they seem to be
"ok" again, but something else has obviously influenced my times.
Anyway, my point is that if my recorded SBU is 5% slower, any large
package will apparently build in a smaller number of SBU, and vice
versa.
Linux isn't a real-time OS, so some variation is to be expected.
FWIW, here are my calculated SBUs (all these are recorded on my
AMD Phenom where I've now been looking at this). To be clear, these
timings don't include untarring the source.
1. LFS-7.4
probably from 2013-04-20 158.660s
after booting 208.542s
manual run this week 172.275s
(system was idle, I dumped the time to a file, ran a
command, dumped the time - thought something in my script
must be broken but couldn't see any problem)
reran my script 175.285s
2. LFS-2013-10-06 with make-4.0, v1 with eudev
from 7.4 156.559s
after booting 253.243s
reran my script today 156.637s
3. LFS-2013-10-06, with make-4.0, v2 with udev-from-systemd
from v1 134.085s ???
after booting 207.081s
reran my script this week 154.089s
Typically, fcron will run updatedb and mandb soon after booting.
Depending on the time of day, it might also back up '/' via rsync
over nfs. This box has 8GB of RAM and 4 CPUs so I'd assumed that
there was plently of capacity to calculate an SBU even if both of
those things were happening. Maybe that is a mistake.
Anyway, as we say in LFS : In general, SBUs are not entirely
accurate because they depend on many factors.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
