On Mon, 18 Oct 2010, Ken Moffat wrote: > Any thoughts, or alternative suggestions ? Yes, a few:
Over the past years I took a look at the build times quite often. Never systematically, but this is what I experienced: Most of the time I'm building a package its because of a new version. I'm using scripts per package close to LFS but package version independant and with optimization and only run few of them in a row, just as much as I prepared packages in advance. As I tend to be impatient, I tail my previous log file of the package currently building quite often to see when the package building right now is expected to be finished. Most of the time the build times are pretty close to the previous attempt, even though I'm building a newer version of that package. So in my case a certain package is usually built the first time after booting the machine and the build times are pretty close even after (minor) version updates. As others already suspected, I would expect latency (like seek times) of the hard drive to have a significant influence on build times and thus times might be influenced by caching as well as by significantly changed fill level of a partition. If thats the case then using an SSD should improve the relyability of build times. I'll run a series of builds of the same package this night (binutils as well for comparison) on a quite fast SSD and report back. If HD turns out not to be the problem: what about those modern processors that overclock some cores automatically? That might easily be influenced by running *something* in the background that keeps yet another core active and prevents the package building core(s) from overclocking... Uwe -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
