On Wed, Oct 08, 2003 at 12:32:42PM +1000, Martin Pool wrote: > On 7 Oct 2003, Zygo Blaxell <[EMAIL PROTECTED]> wrote: > > 2. Locking, backoff, and scheduling should be done by IP address. > > Currently if any single volunteer fails, distcc will drop all of the > > IP addresses associated with the name.
Actually I now realize the above is wrong, it should only be the backoff that uses the IP. Scheduling and locking should be done using just the names... > A fair number of machines have multiple A entries because they have > multiple network interfaces. (In particular, I use one such in my > build farm.) We wouldn't want them to get twice as many jobs, or to > interfere with sending the jobs over the best interface. ...and this is why. Well, that, and the fact that I actually want only a subset of each rr dns record to be used by any given client, as this tends to result in better load balancing when there are very fast machines at the head of the list. Certainly the error-reporting wish still holds even (especially) in this case. One of the interfaces may be down, or a user might be unintentionally using a multi-homed host's name instead of an interface-specific alias, and wondering why it only works once or twice until it hits an unreachable IP address and puts the DNS name into backoff mode. > Using multiple names with different options for each is an intruiging > idea, but once you start putting configuration like that on each > client you've lost much of the benefit. I encode the relative speeds of the machines into the DNS round robin names. I have a small office LAN with several identical machines where there is a single 'distcc' rr dns record. I also have a larger office with three CPU architectures, three gcc versions, and CPU speeds ranging from 0.2 to 3.0 GHz, with a number of records based on what features the client needs and what resources it is entitled to. So for example any "distcc3" machine has less than half the FSB speed of any "distcc1" machine. When faster machines are added to the pool, the "distcc1" machines move to "distcc2", "distcc2" machines move to "distcc3", and so on. Client configuration doesn't have to change every time some machine is upgraded or broken. > If this is going to be stored in DNS, then using something like the > SRV record would be a better solution. I don't see any way in which > SRV is worse than A, and it avoids overloading the mechanism. I don't see any way in which SRV is better than A, or for that matter _different_ than A. In either case I'm putting a bunch of rr aliases in DNS, but with SRV I need to add client- and server-side support that I didn't need with A. I'd also still need diagnostics from distcc that tell me which machine (by IP:port) I have to fix if a distcc volunteer breaks. > Alternatively I can just be lazy and suggest that you fetch > /etc/distcc/hosts over HTTP, rsync or some similar mechanism. The volunteers list is a function of project (pre- or post- gcc-2.95) and architecture (x86 or not) and priority of the current work (urgent or not--does it take up the few fast machines or the many slow ones). I wouldn't be using RR DNS if I didn't think it was the best approach.
pgp00000.pgp
Description: PGP signature
__ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
