[gentoo-user] emerging with distcc: What's taking so long?

[lee]

Hi,

what's taking so long when emerging packages despite distcc is used?

I have disallowed compiling on the local machine (which is the one
emerge is running on) through distcc settings because the local machine
is relatively slow.  Yet I can see some gcc processes running on the
local machine, and emerging goes painfully slow.  Using distcc doesn't
seem to make it any faster, though disabling local compiling seems to
help a bit.

Some compilations are being run on the remote machine, so distcc does
work.  The log file on the remote machine shows compilation times of a
few milliseconds up to about 1.5 seconds at most.  The distcc server
would be finished with the emerging within maybe 15 minutes, and the
client takes several hours already.

Is there something going wrong?  Is there a way to speed things up as
much as I would expect from using distcc?

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

lee  wrote:

> Hi,
> 
> what's taking so long when emerging packages despite distcc is used?
> 
> I have disallowed compiling on the local machine (which is the one
> emerge is running on) through distcc settings because the local
> machine is relatively slow.  Yet I can see some gcc processes running
> on the local machine, and emerging goes painfully slow.  Using distcc
> doesn't seem to make it any faster, though disabling local compiling
> seems to help a bit.
> 
> Some compilations are being run on the remote machine, so distcc does
> work.  The log file on the remote machine shows compilation times of a
> few milliseconds up to about 1.5 seconds at most.  The distcc server
> would be finished with the emerging within maybe 15 minutes, and the
> client takes several hours already.
> 
> Is there something going wrong?  Is there a way to speed things up as
> much as I would expect from using distcc?

P.S.: distccmon is a good tool to watch the compilation processes.

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

lee  wrote:

> Hi,
> 
> what's taking so long when emerging packages despite distcc is used?
> 
> I have disallowed compiling on the local machine (which is the one
> emerge is running on) through distcc settings because the local
> machine is relatively slow.  Yet I can see some gcc processes running
> on the local machine, and emerging goes painfully slow.  Using distcc
> doesn't seem to make it any faster, though disabling local compiling
> seems to help a bit.
> 
> Some compilations are being run on the remote machine, so distcc does
> work.  The log file on the remote machine shows compilation times of a
> few milliseconds up to about 1.5 seconds at most.  The distcc server
> would be finished with the emerging within maybe 15 minutes, and the
> client takes several hours already.
> 
> Is there something going wrong?  Is there a way to speed things up as
> much as I would expect from using distcc?

You can try pump mode. Preprocessing is then done on the remote server.
Depending on your hardware, this could be faster.

But read carefully the  manpages of pump and distcc before you use it. 
There are some restrictions you should be aware of.

You can also try to optimize the number of concurrent compile processes 
(-j). Watching the load counts of your client and server(s) will help
you to find out the best value.

--
Regards
wabe

Re: [gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[waltdnes]

On Mon, Jan 04, 2016 at 11:20:57AM -0600, »Q« wrote

> AFAICT, details of the gstreamer bug itself haven't been made public
> yet, and nobody is sure whether the unmaintained 0.10 branch needs a
> patch.  See  and
> the following comment.

  As pointed out in comment 12 of that bug, 1.x broke the 0.10.x ABI/API
and causes problems on Firefox.  I use Pale Moon, a Firefox fork, and it
too will only build with gstreamer 0.10.x.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] emerging with distcc: What's taking so long?

[lee]

 writes:

> lee  wrote:
>
>> Hi,
>> 
>> what's taking so long when emerging packages despite distcc is used?
>> 
>> I have disallowed compiling on the local machine (which is the one
>> emerge is running on) through distcc settings because the local
>> machine is relatively slow.  Yet I can see some gcc processes running
>> on the local machine, and emerging goes painfully slow.  Using distcc
>> doesn't seem to make it any faster, though disabling local compiling
>> seems to help a bit.
>> 
>> Some compilations are being run on the remote machine, so distcc does
>> work.  The log file on the remote machine shows compilation times of a
>> few milliseconds up to about 1.5 seconds at most.  The distcc server
>> would be finished with the emerging within maybe 15 minutes, and the
>> client takes several hours already.
>> 
>> Is there something going wrong?  Is there a way to speed things up as
>> much as I would expect from using distcc?
>
> You can try pump mode. Preprocessing is then done on the remote server.
> Depending on your hardware, this could be faster.
>
> But read carefully the  manpages of pump and distcc before you use it. 
> There are some restrictions you should be aware of.

I followed the instructions on the wiki which suggest to have
'FEATURES="distcc distcc-pump"' in make.conf and give instructions how
to set the CPUs.

> You can also try to optimize the number of concurrent compile processes 
> (-j). Watching the load counts of your client and server(s) will help
> you to find out the best value.

Using -j doesn't really help.  The server is pretty much idling --- or
you could say waiting for stuff to compile --- while the client
progresses awfully slowly and isn't overloaded with compilation
processes.  If the server would get more load, emerging could be much
much faster.

Can it be that the client is simply too slow compared to the server to
give it any significant load?  (The client isn't exactly slow; it's slow
compared to the server.)

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

lee  wrote:

>  writes:
> 
> > lee  wrote:
> >
> >> Hi,
> >> 
> >> what's taking so long when emerging packages despite distcc is
> >> used?
> >> 
> >> I have disallowed compiling on the local machine (which is the one
> >> emerge is running on) through distcc settings because the local
> >> machine is relatively slow.  Yet I can see some gcc processes
> >> running on the local machine, and emerging goes painfully slow.
> >> Using distcc doesn't seem to make it any faster, though disabling
> >> local compiling seems to help a bit.
> >> 
> >> Some compilations are being run on the remote machine, so distcc
> >> does work.  The log file on the remote machine shows compilation
> >> times of a few milliseconds up to about 1.5 seconds at most.  The
> >> distcc server would be finished with the emerging within maybe 15
> >> minutes, and the client takes several hours already.
> >> 
> >> Is there something going wrong?  Is there a way to speed things up
> >> as much as I would expect from using distcc?
> >
> > You can try pump mode. Preprocessing is then done on the remote
> > server. Depending on your hardware, this could be faster.
> >
> > But read carefully the  manpages of pump and distcc before you use
> > it. There are some restrictions you should be aware of.
> 
> I followed the instructions on the wiki which suggest to have
> 'FEATURES="distcc distcc-pump"' in make.conf and give instructions how
> to set the CPUs.

I didn't read the wiki. It's some years ago that I used distcc and IIRC
there was no wiki available for it.
 
> > You can also try to optimize the number of concurrent compile
> > processes (-j). Watching the load counts of your client and
> > server(s) will help you to find out the best value.
> 
> Using -j doesn't really help.  The server is pretty much idling --- or
> you could say waiting for stuff to compile --- while the client
> progresses awfully slowly and isn't overloaded with compilation
> processes.  If the server would get more load, emerging could be much
> much faster.
>
> Can it be that the client is simply too slow compared to the server to
> give it any significant load?  (The client isn't exactly slow; it's
> slow compared to the server.)

I used a pentium 4 laptop as client and two phenom2 quadcore pc as 
server. I don't remember the settings that I used but I think it
was something about -j10 or so.

When I compiled large programs, the load count of the servers was
high most of the time and they were very busy with compiling. Only
at linking time they were waiting for new data.
Compilation time was much lower than without distcc.

However when I compiled small programs, the benefit of distcc was 
very small or even null. Also compilation time of OpenOffice was
very long, because of the -j1 setting in the ebuild.

I don't know the reason of your problem. Maybe you should try it
without pump mode to see if this makes a difference.

Have you used distccmon to see what happens while compiling? IIRC
it shows you exactly what's going on at each host (preprocessing,
compiling, waiting). Maybe this will bring some light into the 
whole thing.

And as Dale already said, network speed is very important.

--
Regards
wabe

Re: [gentoo-user] OT: i7-6700, anyone already?

[Stefan G. Weichinger]

On 12/30/2015 11:16 PM, Stefan G. Weichinger wrote:

> right now gcc rebuilds itself, some more packages to re-emerge, load at
> around 7.5, system usable, audio stream without a hickup.

# genlop -t thunderbird

 * mail-client/thunderbird
   Mon Jan  4 22:55:49 2016 >>> mail-client/thunderbird-38.5.0
   merge time: 10 minutes and 36 seconds.

with gcc-5.3.0 and USE="jit"

acceptable?

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

 wrote:

> 
> I used a pentium 4 laptop as client and two phenom2 quadcore pc as 
> server. I don't remember the settings that I used but I think it
> was something about -j10 or so.

Sorry, I think it was about -j16 (twice the totally amount of CPUs).

--
Regards
wabe

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Dale]

lee wrote:
>  writes:
>
>> lee  wrote:
>>
>>> Hi,
>>>
>>> what's taking so long when emerging packages despite distcc is used?
>>>
>>> I have disallowed compiling on the local machine (which is the one
>>> emerge is running on) through distcc settings because the local
>>> machine is relatively slow.  Yet I can see some gcc processes running
>>> on the local machine, and emerging goes painfully slow.  Using distcc
>>> doesn't seem to make it any faster, though disabling local compiling
>>> seems to help a bit.
>>>
>>> Some compilations are being run on the remote machine, so distcc does
>>> work.  The log file on the remote machine shows compilation times of a
>>> few milliseconds up to about 1.5 seconds at most.  The distcc server
>>> would be finished with the emerging within maybe 15 minutes, and the
>>> client takes several hours already.
>>>
>>> Is there something going wrong?  Is there a way to speed things up as
>>> much as I would expect from using distcc?
>> You can try pump mode. Preprocessing is then done on the remote server.
>> Depending on your hardware, this could be faster.
>>
>> But read carefully the  manpages of pump and distcc before you use it. 
>> There are some restrictions you should be aware of.
> I followed the instructions on the wiki which suggest to have
> 'FEATURES="distcc distcc-pump"' in make.conf and give instructions how
> to set the CPUs.
>
>> You can also try to optimize the number of concurrent compile processes 
>> (-j). Watching the load counts of your client and server(s) will help
>> you to find out the best value.
> Using -j doesn't really help.  The server is pretty much idling --- or
> you could say waiting for stuff to compile --- while the client
> progresses awfully slowly and isn't overloaded with compilation
> processes.  If the server would get more load, emerging could be much
> much faster.
>
> Can it be that the client is simply too slow compared to the server to
> give it any significant load?  (The client isn't exactly slow; it's slow
> compared to the server.)
>
>


Once a really long time ago I tried doing this sort of thing.  What I
found is that the network speed between the two systems was what was
slowing it down.  It just couldn't transfer the data back and forth fast
enough.  I had a network card that really didn't have any good drivers
for it.  Anyway, it may not be your problem but it may be worth looking
at to be sure.  Using iftop or some similar tool should tell you
something. 

One way to test it, just find a really large tarball and copy it over. 
Even if it only takes a few seconds, it should be long enough to give
you a idea if something network wise is getting in the way. 

Just throwing a idea out there.

Dale

:-)  :-) 

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Frank Steinmetzger]

On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:

> P.S.: distccmon is a good tool to watch the compilation processes.

I never got it to display anything. I just tried it again: synced portage
and ran a world update -- 16 Packages, among them kdevplatform, a lengthy
Qt package (which by the way is one of those who benefit greatly from
compression if distcc’ed over a slow network).

At no time during building did I see any activity in distccmon-gui. I
started it on both client and server and as my own user as well as root.
Nada. Can you give a suggestion? Thanks.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

What woman is looking for a man who is looking for a woman looking for a man?


signature.asc
Description: Digital signature

Re: [gentoo-user] emerging with distcc: What's taking so long?

[Frank Steinmetzger]

On Mon, Jan 04, 2016 at 04:38:56PM -0600, Dale wrote:

> >>> what's taking so long when emerging packages despite distcc is used?
> >>> […]
> >>> Some compilations are being run on the remote machine, so distcc does
> >>> work.  The log file on the remote machine shows compilation times of a
> >>> few milliseconds up to about 1.5 seconds at most.  The distcc server
> >>> would be finished with the emerging within maybe 15 minutes, and the
> >>> client takes several hours already.
> >>>
> >>> Is there something going wrong?  Is there a way to speed things up as
> >>> much as I would expect from using distcc?
> > […]
> > Can it be that the client is simply too slow compared to the server to
> > give it any significant load?  (The client isn't exactly slow; it's slow
> > compared to the server.)
>
> Once a really long time ago I tried doing this sort of thing.  What I
> found is that the network speed between the two systems was what was
> slowing it down.  It just couldn't transfer the data back and forth fast
> enough.  I had a network card that really didn't have any good drivers
> for it.  Anyway, it may not be your problem but it may be worth looking
> at to be sure.  Using iftop or some similar tool should tell you
> something.

Well I’m using distcc over WiFi which gives me shy of 2 MB per second (only
the big PC which acts as server is connected to the router via cable). For
such cases I recommend using compression. It definitely increased throughput.

What I observe on my setup, though, is that sometimes a package builds with
distcc, and then all of a sudden I get (the meaning of) “distributing via
distcc failed, building locally” and after a while it works again. No idea
what’s going on there.

-- 
Gruß | Greetings | Qapla’
Please do not share anything from, with or about me with any social network.

“Your code is shit.. your argument is shit.” – Linus Torvalds, linux.kernel


signature.asc
Description: Digital signature

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

Frank Steinmetzger  wrote:

> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
> 
> > P.S.: distccmon is a good tool to watch the compilation processes.
> 
> I never got it to display anything. I just tried it again: synced
> portage and ran a world update -- 16 Packages, among them
> kdevplatform, a lengthy Qt package (which by the way is one of those
> who benefit greatly from compression if distcc’ed over a slow
> network).
> 
> At no time during building did I see any activity in distccmon-gui. I
> started it on both client and server and as my own user as well as
> root. Nada. Can you give a suggestion? Thanks.
> 

I remembered something:

It is important to use the same value for the DISTCC_DIR environment 
variable as the user running the client and that this directory is 
readable by the user that is running distccmon. 

--
Regards
wabe

Re: [gentoo-user] emerging with distcc: What's taking so long?

[wabenbau]

Frank Steinmetzger  wrote:

> On Mon, Jan 04, 2016 at 09:48:42PM +0100, waben...@gmail.com wrote:
> 
> > P.S.: distccmon is a good tool to watch the compilation processes.
> 
> I never got it to display anything. I just tried it again: synced
> portage and ran a world update -- 16 Packages, among them
> kdevplatform, a lengthy Qt package (which by the way is one of those
> who benefit greatly from compression if distcc’ed over a slow
> network).
> 
> At no time during building did I see any activity in distccmon-gui. I
> started it on both client and server and as my own user as well as
> root. Nada. Can you give a suggestion? Thanks.

It's a long time ago and I can't remember any problems or difficulties
with distccmon. IIRC I run it on the client and I used the gui as well 
as the text version. 

I don't remember wich UID I used for distccmon. Maybe it is necessary
to run it as user portage.

I would like to test it, but I don't have a second linux host that I
could use for a test. Only some xubuntu qemu VMs that are installed 
on my gentoo box. And I don't know if these are working with distcc 
and a gentoo host without problems. 

And as I'm down with a ugly cold, I don't have enough power to build 
up a test environment with some old hardware or struggle with bitchy 
VMs. 

--
Regards
wabe

Re: [gentoo-user] Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[Grant]

>>> GLSA 201512-07 requires that I remove gstreamer-0.10 but I'm finding
>>> it rather inextricable due to dependencies.  Has anyone else run into
>>> this problem?
>>
>> I think this is another case of glsa-check not handling slots correctly.
>>
>
> I believe it handles ranges fine, but it seems that we occasionally
> have GLSAs that don't correctly specify ranges.  You can log a bug
> against it.


I don't see the bug.

# equery l gstreamer
 * Searching for gstreamer ...
[IP-] [  ] media-libs/gstreamer-0.10.36-r2:0.10
[IP-] [  ] media-libs/gstreamer-1.6.2:1.0

# glsa-check -d 201512-07
[snip]
Affected package:  media-libs/gstreamer
Affected archs:All
Vulnerable:<1.4.5
Unaffected:>=1.4.5
[snip]

What am I missing?

- Grant

[gentoo-user] Re: Difficulty fixing GLSA 201512-07 (gstreamer-0.10)

[»Q«]

On Sun, 3 Jan 2016 11:49:49 -0500
Rich Freeman  wrote:

> On Sun, Jan 3, 2016 at 11:28 AM, Neil Bothwick 
> wrote:
> > On Sun, 3 Jan 2016 07:52:30 -0800, Grant wrote:
> >  
> >> GLSA 201512-07 requires that I remove gstreamer-0.10 but I'm
> >> finding it rather inextricable due to dependencies.  Has anyone
> >> else run into this problem?  
> >
> > I think this is another case of glsa-check not handling slots
> > correctly. 
> 
> I believe it handles ranges fine, but it seems that we occasionally
> have GLSAs that don't correctly specify ranges.  You can log a bug
> against it.

AFAICT, details of the gstreamer bug itself haven't been made public
yet, and nobody is sure whether the unmaintained 0.10 branch needs a
patch.  See  and
the following comment.