On 2/5/06, Martin Pool <[EMAIL PROTECTED]> wrote: > > ... look at a protocol change for large files to try sending > > just the hash of the source first, and sending the full > > source only if the server replies with 'sorry, not in the cache'. > > I think that would be a good idea. It'd also give you the option of > polling every server to see if any one of them has it.
Polling every server would be too expensive in practice, I bet. Probably better to use the hash of the source to pick a server -- that way we know which one has it. > > But I thought I'd ask: just how awful is it to have a latency > > that alternates betwen 0.4 and 4.0 ms, with an average of 1ms? > > My guess is that it causes a significant overall penalty > > compared to a uniform 0.4ms latency, but I haven't checked. > > It's going to depend on whether the slow jobs are on the critical path > for the overall build, which in turn will be influenced by whether > you're using Make or some other tool better at scheduling. We're using a nonhierarchical Makefile. It seems ok scheduling-wise, but I haven't really looked. First experiments with lzo seem to show a slight performance loss when tested without caching, so I guess it's on to the protocol change. I was hoping to avoid that... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc