Dan Kegel wrote:
On 1/5/06, Victor Norman <[EMAIL PROTECTED]> wrote:
The nice things about dmucs are:
o if other engineers are using the compile machines for other tasks, the
loadavg daemons will communicate the loads to the dmucs server, and those
machines will be used less often for compiles -- so my system takes into
account not just loadavg based on number of compiles on a machine, but on
other factors as well.
This is a very good thing.
I have an alternative approach which achieves
part of this benefit without requiring a central server.
The idea is, the user invokes 'make' via a wrapper
that runs a client-side program which queries all
the servers in parallel to see how quickly they respond to a compile
request for 'hello, world'. Servers that respond promptly
are added to the host list for the current make job.
This lets you avoid machines which are loaded down or otherwise having problems.
It's not as good as dmucs, but it's quite useful.
A third approach could be to use the same idea as in dmucs, but let all
the servers send the loadavg as a multicast instead of a unicast. This
will allow all machine in the cluster to have its own db.
The advantage will be that we have a distributed load-db and the client
does not need to send a tcp-question for each file to compile.
The disadvantage could be higher netload on slow machines since all
loadavg messages need to be handled, perhaps this could be benchmarked?
/ Patrik
__
distcc mailing list http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
