1 |
On Tue, Dec 21, 2010 at 1:56 AM, Bill Longman <bill.longman@×××××.com>wrote: |
2 |
|
3 |
> On 12/18/2010 07:15 AM, Peter Humphrey wrote: |
4 |
> > On Saturday 18 December 2010 10:18:43 Neil Bothwick wrote: |
5 |
> > |
6 |
> >> I've found there's just too much overhead with distcc, plus much of |
7 |
> >> the work is still done locally. |
8 |
> > |
9 |
> > I expected that but I wanted to try it to see. |
10 |
> > |
11 |
> >> I have a couple of Atom boxes, a server and a netbook, and I've set up |
12 |
> >> a chroot for each on my workstation. In the chroot I have |
13 |
> >> FEATURES=buildpkg, using an NFS mounted PKGDIR available to both |
14 |
> >> computers, then I emerge -k on the Atom box. |
15 |
> > |
16 |
> > Maybe I'll go this way instead. Thanks for the idea, which is similar to |
17 |
> > one from YoYo Siska three days ago. |
18 |
> |
19 |
> I had my Atom 330 running as a distcc client for a long time. I have |
20 |
> several other speedy CPUs alongside it so it could spray plenty of |
21 |
> compilation requests out its gigabit NIC to various much beefier |
22 |
> machines. But as Neil stated, lots of the processing still occurs |
23 |
> locally, so as you increase nodes, you need to decrease the amount of |
24 |
> compilation done locally. With such a disparity between CPU, it takes |
25 |
> less time overall to just do it the way Neil describes - make a chroot |
26 |
> and then just build it with the intention that the slow CPUs will use |
27 |
> the binary build. |
28 |
> |
29 |
> You still need lots of CPU to compile, so a slow machine will still |
30 |
> compile slowly. If your client is a pokey 1.6GHz Atom and you're sending |
31 |
> jobs to two quad core 3GHz CPUs on your subnet, you'll soon see that the |
32 |
> Atom's load goes up toward 8 as it tries to bring those remote jobs |
33 |
> back. So, the four threads on my 330 get completely filled up and it's |
34 |
> dog slow. And it's even more painful when you use the preprocessor |
35 |
> because the client must zip the compile "construction" before it ships |
36 |
> it out, so you have even less CPU available for compilation (although |
37 |
> you get some of that back). |
38 |
> |
39 |
> All said and done, my back-of-the-napkin and seat-of-the-pants |
40 |
> calculation tells me that I still get a _minimum_ 25% reduction in |
41 |
> overall compile times with distcc. That's my experience after using |
42 |
> distcc for almost ten years with various configurations of network and |
43 |
> CPUs. |
44 |
> |
45 |
> |
46 |
I have set up my system as Neil described chroots for different systems on a |
47 |
fast computer. I use this setup for my gentoo boxes I have and it has made |
48 |
my compilations fast(er). I tried to use distcc with one U2300 celeron and |
49 |
some amd 4x cpu and the amd didn't really compile, because the U2300 was a |
50 |
bottleneck, so I decided to chroot it and been happy ever since. |
51 |
|
52 |
I have been thinking about a tool that could automagically start the emerge |
53 |
on the remote system. I thought about just ssh in with a script. But I am on |
54 |
so many flaky Internet connections that it isn't reliable enough. |
55 |
|
56 |
Petri |