[distcc] Re: distcc stats

[Martin Pool]

> These sound good.  We're mostly interested in finding down machines
> and working out if our utilisation is any good.  (ie. potentially no
> point building on a 200MHz Pentium if your own box is 5 times
> faster).

It's possibly still worthwhile.  I think you'll only lose if 

 (A) The effort your local machine expends in talking across the
     network is greater than just doing the work locally.  Since
     distcc is much lighter than gcc, this ought never to be true.

 (B) At the end of the build, we're waiting around for a slow machine
     to finish, and we would have done better to build it locally or
     on some faster volunteer.  

     So if you statically placed an equal number of jobs onto each
     machine, then obviously the fast ones would finish first and we'd
     be waiting around for the slow ones.  The current algorithm of 
     trying to keep all machines equally busy does better.

So I think we do pretty well in steady state, but not so well at the
start and end of compilation.

If you knew that the current file was the only one you were building,
you'd probably be better off doing it locally.  If you knew you had
hundreds more to go, you'd probably be better off sending it away so
that the local machine could concentrate on running make, cpp, and
distcc.  Of course Make doesn't tell us how many files there are to
compile, so I suppose we just need an algorithm that does reasonably
in all cases.

By the way, there's now a distcc list on lists.samba.org; please join.

-- 
Martin