This weekend I had a kernel 2.4.26 -> kernel 2.6.16 upgrade gone terribly wrong leaving me with a laptop without any network support: the latest version of ndiswrapper was incompatible with the version I had installed various files in /etc/ndiswrapper and I found that out after the reboot.
Anyways — to make a long story even longer — I quickly downgraded the kernel (yeah downgraded, because 2.4.24 was the only fully compiled kernel source tree still present on that machine — and I’m lazy and impatient and can’t wait for a complete rebuild).
Today — while waiting until the compile of the latest in the 2.4-branch (2.4.32) was done, my eye fell on the binary distcc. This nifty thing enables one to distribute the compilation jobs over multiple machines.
The perfect solution to compile big software projects on relatively slow machines — an excellent way to speed them up significantly!
After studying the man-page and some pages on the internet I realized it would be a serious waste of time and CPU if I now canceled the running kernel compile — that was almost half-way by now. (Incidentally, the total compile-time for the kernel was about 28 minutes.)
So meanwhile, I configured some machines in my network to accept jobs. On every machine that I wanted into the loop (2 machines at the moment), I created the required user (distcc wants to run as user ‘distcc’) and a seperate group:
~# echo "distcc:x:26:26:distcc:/home/distcc:" >> /etc/passwd
~# echo "distcc::26:distcc" >> /etc/group
Because I run Slackware, I then created the executable sh-script /etc/rc.d/rc.local/rc.distcc that I call from /etc/rc.d/rc.local upon system boot:
#!/bin/sh
HOSTS="127.0.0.1 192.168.0.14 192.168.0.15 192.168.0.16"
DISTCCD="/usr/bin/distccd --daemon"
KILLALL=/bin/killall
if ([ "$1" = "stop" ]);
then
echo “Stopping DISTCC…”
$KILLALL distccd
else
for HOST in $HOSTS;
do
DISTCCD=”$DISTCCD –allow $HOST”
done;
echo "Starting up DISTCC: $DISTCCD"
$DISTCCD
fi
exit 0
The above script will start DISTCC, allowing only jobs from those IP addresses in the HOSTS-variable.
After starting the processes on the two machines, for fun I compiled the latest CVS version of MPlayer on the pretty slow laptop:
main# export DISTCC_HOSTS="192.168.0.15 192.168.0.16"
main# CC=distcc ./configure --prefix=/opt/mplayer-cvs --enable-gui
And this is the fun part (this is what I already did on machines with more than one CPU), specifying that make should built in parallel. For the heck of it I told it to attempt to do 8 files in parallel:
main# make -j 8
I couldn’t believe what I then witnessed — the files were scrolling by as if I was running the machine at 1Ghz! OK — the loads on the other machines went up a bit, though:

The (light) red line is the laptop I was running on, the dark red and blue the
other machines in the loop. The machine indicated by green was not in the loop.
I didn’t time it as I didn’t have anything to reference to — but the graph above indicates that it must be somewhere between 14:30 and 14:40.
That is pretty damn fast…

on
March 26th 2006 at 4:26 pm in 










I just updated the
rc.distccscript to include localhost (127.0.0.1) as well — although this gives the local machine significantly more load.You might not want to do that if you machine cannot handle that much load.