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

[Neil Bothwick]

On Mon, 11 Jan 2016 23:55:27 +0100, lee wrote:

> > Firstly, things like Flash and Skype are not special cases, they are
> > widely used and many of us have to use them, whether we like it or
> > not.  
> 
> They are special cases.  Flash never really worked, and when it does,
> it's pretty much unusable because it's too crappy.  Skype only kinda
> works and is not usable due to total lack of privacy.

You can call those and other binary-only programs special cases as much
as you like, and maybe they are for you. But for many people there is no
real choice but to use them.

> > Secondly, no one is forcing you to use anything? There is a
> > no-multilib profile,  
> 
> There doesn't seem to be a desktop profile that isn't multilib.

Probably for the reasons I've already suggested, but you don't have to
use a desktop profile.

> > and nothing to stop you creating a no-multilib version of your
> > preferred desktop profile if you so wish (the desktop profiles are
> > basically a different set of default USE flags).  
> 
> I wouldn't know how to do that.

emerge --info with the desktop profile to get a list of USE flags, then
set those same flags on the no-multilib profile. What's so hard?
 
> In any case, the default is simply wrong.

Of course it is, it's a default, it can't be right for everyone. That's
why it is a default starting point, not an enforced setting. If you don't
want to move away from the defaults, what are you using Gentoo?

> > Multilib should be going away on due time. Until then you have two
> > courses of action: complain about it or use a no-multilib profile
> > with your preferred flags. Only one of those choices has any real
> > benefit.  
> 
> There is no non-multilib profile one could use when they want a desktop
> profile.  Perhaps multilib goes away in 20 years or so, or never.  That
> doesn't help.

However long it takes, the timescale will not be altered by one second by
any amount of complaining in here.


-- 
Neil Bothwick

Make it idiot proof and someone will make a better idiot.


pgpQNZMhcgLh0.pgp
Description: OpenPGP digital signature

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

[lee]

Neil Bothwick  writes:

> On Mon, 11 Jan 2016 23:55:27 +0100, lee wrote:
>
>> > Firstly, things like Flash and Skype are not special cases, they are
>> > widely used and many of us have to use them, whether we like it or
>> > not.  
>> 
>> They are special cases.  Flash never really worked, and when it does,
>> it's pretty much unusable because it's too crappy.  Skype only kinda
>> works and is not usable due to total lack of privacy.
>
> You can call those and other binary-only programs special cases as much
> as you like, and maybe they are for you. But for many people there is no
> real choice but to use them.

Of course it's a choice, no matter whether ppl make it or not.

>> > Secondly, no one is forcing you to use anything? There is a
>> > no-multilib profile,  
>> 
>> There doesn't seem to be a desktop profile that isn't multilib.
>
> Probably for the reasons I've already suggested, but you don't have to
> use a desktop profile.
>
>> > and nothing to stop you creating a no-multilib version of your
>> > preferred desktop profile if you so wish (the desktop profiles are
>> > basically a different set of default USE flags).  
>> 
>> I wouldn't know how to do that.
>
> emerge --info with the desktop profile to get a list of USE flags, then
> set those same flags on the no-multilib profile. What's so hard?

It is something you need to know before you can do it.  Look at the
instructions on the wiki for installing kde, for example.  They tell you
to use the corresponding profile.  That profile is a multilib profile,
and you cannot switch to a multilib profile from a non-multilib one.  Of
course, I choose a non-multilib profile when I install.

>> In any case, the default is simply wrong.
>
> Of course it is, it's a default, it can't be right for everyone. That's
> why it is a default starting point, not an enforced setting. If you don't
> want to move away from the defaults, what are you using Gentoo?

Ok, it's not only wrong, it's badly made.  Who knows what all a profile
does.

>> > Multilib should be going away on due time. Until then you have two
>> > courses of action: complain about it or use a no-multilib profile
>> > with your preferred flags. Only one of those choices has any real
>> > benefit.  
>> 
>> There is no non-multilib profile one could use when they want a desktop
>> profile.  Perhaps multilib goes away in 20 years or so, or never.  That
>> doesn't help.
>
> However long it takes, the timescale will not be altered by one second by
> any amount of complaining in here.

Well, I suppose you have no idea how awfully stupid and retarded it is
to encounter criticism and/or suggestions, or questioning something, by
claiming that someone is complaining.

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

[lee]

Neil Bothwick  writes:

> On Mon, 11 Jan 2016 08:25:05 +0100, lee wrote:
>

> [...]
>> 
>> That there are a few special cases for which some people still need it
>> doesn't mean that everyone should be forced to use a multilib profile
>> when 100% of the software they're running is 64bit.
>
> Firstly, things like Flash and Skype are not special cases, they are
> widely used and many of us have to use them, whether we like it or not.

They are special cases.  Flash never really worked, and when it does,
it's pretty much unusable because it's too crappy.  Skype only kinda
works and is not usable due to total lack of privacy.

> Secondly, no one is forcing you to use anything? There is a no-multilib
> profile,

There doesn't seem to be a desktop profile that isn't multilib.

> and nothing to stop you creating a no-multilib version of your
> preferred desktop profile if you so wish (the desktop profiles are
> basically a different set of default USE flags).

I wouldn't know how to do that.

In any case, the default is simply wrong.

> Multilib should be gong away on due time. Until then you have two courses
> of action: complain about it or use a no-multilib profile with your
> preferred flags. Only one of those choices has any real benefit.

There is no non-multilib profile one could use when they want a desktop
profile.  Perhaps multilib goes away in 20 years or so, or never.  That
doesn't help.

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

[Neil Bothwick]

On Mon, 11 Jan 2016 08:25:05 +0100, lee wrote:

> >> > What about things like flash plugins? Those are often wanted on
> >> > desktops and need multilib.
> >> 
> >> Flash sucks, and fortunately, it's dead.  
> >
> > It should be, but it's not. There are still many sites that require
> > it.  
> 
> It's not my problem when they are still using it.

Your problems are not the subject of discussion.

> > That's where the ABI_* stuff comes in, which I believe should replace
> > multilib eventually. The problem is not software you compile, it is
> > precompiled software. If you don't like flash, here's another example
> > that you probably hate but is needed by a lot of people - Skype.  
> 
> Skype sucks --- and it's not usable at all because there is no privacy
> whatsoever.  They will listen in and record whatever they like.

That's your opinion, which I tend to agree with, but it is once again
irrelevant. A lot of people use Skype, whether or not they like it, as I
have to.

> You may also have some ancient games you might want to play, or you can
> have an old computer that doesn't do 64bit.  And if you do want to use
> 32bit software or an old computer, nothing would prevent you from
> selecting a profile that gives you 32bit support, or you can have
> everything in 32bit.
> 
> That there are a few special cases for which some people still need it
> doesn't mean that everyone should be forced to use a multilib profile
> when 100% of the software they're running is 64bit.

Firstly, things like Flash and Skype are not special cases, they are
widely used and many of us have to use them, whether we like it or not.

Secondly, no one is forcing you to use anything? There is a no-multilib
profile, and nothing to stop you creating a no-multilib version of your
preferred desktop profile if you so wish (the desktop profiles are
basically a different set of default USE flags).

Multilib should be gong away on due time. Until then you have two courses
of action: complain about it or use a no-multilib profile with your
preferred flags. Only one of those choices has any real benefit.


-- 
Neil Bothwick

Oxymoron: Clearly Misunderstood.


pgpT1MB2MmUwz.pgp
Description: OpenPGP digital signature

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

[lee]

Neil Bothwick  writes:

> On Fri, 08 Jan 2016 21:37:55 +0100, lee wrote:
>
>> > What about things like flash plugins? Those are often wanted on
>> > desktops and need multilib.  
>> 
>> Flash sucks, and fortunately, it's dead.
>
> It should be, but it's not. There are still many sites that require it.

It's not my problem when they are still using it.

>> 64bit should be the default for all profiles, with the option to add
>> 32bit support in case you need it.  Which parts of gnome, kde or another
>> IDE don't compile as 64bit?
>
> That's where the ABI_* stuff comes in, which I believe should replace
> multilib eventually. The problem is not software you compile, it is
> precompiled software. If you don't like flash, here's another example
> that you probably hate but is needed by a lot of people - Skype.

Skype sucks --- and it's not usable at all because there is no privacy
whatsoever.  They will listen in and record whatever they like.

You may also have some ancient games you might want to play, or you can
have an old computer that doesn't do 64bit.  And if you do want to use
32bit software or an old computer, nothing would prevent you from
selecting a profile that gives you 32bit support, or you can have
everything in 32bit.

That there are a few special cases for which some people still need it
doesn't mean that everyone should be forced to use a multilib profile
when 100% of the software they're running is 64bit.

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

[lee]

Neil Bothwick  writes:

> On Tue, 05 Jan 2016 18:41:25 +0100, lee wrote:
>
>> > Try Neil's suggestion of using a chroot and NFS exporting. I use it
>> > here to good effect.  
>> 
>> I must be missing his posting?
>
> It's in the "QEMU/distcc combination question" thread, among other places.

Thanks, I'll take a look at that.

>> Of course, I installed the client no-multilib and found that gnome
>> cannot be installed on no-multilib, so I had to reinstall.  Then I
>> decided to use KDE because I don't want systemd, and installing gnome
>> without it is a PITA.
>> 
>> However, I don't see why gnome --- or anything else --- should require
>> multilib.  It's not like I'd want to run anything 32bit.
>
> What about things like flash plugins? Those are often wanted on desktops
> and need multilib.

Flash sucks, and fortunately, it's dead.

Last time I looked, years ago, there was a 64bit version and it was
announced that no new versions will be published.


64bit should be the default for all profiles, with the option to add
32bit support in case you need it.  Which parts of gnome, kde or another
IDE don't compile as 64bit?

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

[Neil Bothwick]

On Fri, 08 Jan 2016 21:37:55 +0100, lee wrote:

> > What about things like flash plugins? Those are often wanted on
> > desktops and need multilib.  
> 
> Flash sucks, and fortunately, it's dead.

It should be, but it's not. There are still many sites that require it.
 
> 64bit should be the default for all profiles, with the option to add
> 32bit support in case you need it.  Which parts of gnome, kde or another
> IDE don't compile as 64bit?

That's where the ABI_* stuff comes in, which I believe should replace
multilib eventually. The problem is not software you compile, it is
precompiled software. If you don't like flash, here's another example
that you probably hate but is needed by a lot of people - Skype.


-- 
Neil Bothwick

Friends may come and go, but enemies accumulate.


pgpHqGijHAJRo.pgp
Description: OpenPGP digital signature

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

[Jeremi Piotrowski]

On Tue, Jan 5, 2016 at 12:49 PM, lee  wrote:
> The gui monitor doesn't seem to exist.

Recompile distcc with the gtk use flag.

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

[Peter Humphrey]

On Tuesday 05 January 2016 14:18:12 lee wrote:

> Is there a way to offload the preprocessing to the server, and can
> compiling on localhost be avoided as much as possible somehow?

Try Neil's suggestion of using a chroot and NFS exporting. I use it here to 
good effect.

-- 
Rgds
Peter

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

[lee]

Peter Humphrey  writes:

> On Tuesday 05 January 2016 14:18:12 lee wrote:
>
>> Is there a way to offload the preprocessing to the server, and can
>> compiling on localhost be avoided as much as possible somehow?
>
> Try Neil's suggestion of using a chroot and NFS exporting. I use it here to 
> good effect.

I must be missing his posting?

So export / via NFS, mount it on the server and chroot into it?  That
might not work because of the stupid multilib requirement:  The server
is no-multilib, the client is not.

Of course, I installed the client no-multilib and found that gnome
cannot be installed on no-multilib, so I had to reinstall.  Then I
decided to use KDE because I don't want systemd, and installing gnome
without it is a PITA.

However, I don't see why gnome --- or anything else --- should require
multilib.  It's not like I'd want to run anything 32bit.

Why are there no no-multilib profiles when you need a desktop profile?

It has taken two days now to install Gentoo, and it's still not finished
...

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

[lee]

Jeremi Piotrowski  writes:

> On Tue, Jan 5, 2016 at 12:49 PM, lee  wrote:
>> The gui monitor doesn't seem to exist.
>
> Recompile distcc with the gtk use flag.

Oh, I thought that was an extra package ...

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

[Neil Bothwick]

On Tue, 05 Jan 2016 18:41:25 +0100, lee wrote:

> > Try Neil's suggestion of using a chroot and NFS exporting. I use it
> > here to good effect.  
> 
> I must be missing his posting?

It's in the "QEMU/distcc combination question" thread, among other places.

> Of course, I installed the client no-multilib and found that gnome
> cannot be installed on no-multilib, so I had to reinstall.  Then I
> decided to use KDE because I don't want systemd, and installing gnome
> without it is a PITA.
> 
> However, I don't see why gnome --- or anything else --- should require
> multilib.  It's not like I'd want to run anything 32bit.

What about things like flash plugins? Those are often wanted on desktops
and need multilib.


-- 
Neil Bothwick

If only the good die young then what does that say about senior citizens?


pgpl6RcOwSQzT.pgp
Description: OpenPGP digital signature

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

[lee]

Frank Steinmetzger  writes:

> 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.

Wireless is a bad crutch which is only useful when it's entirely
impossible to use a cable.  I'd recommend using a cable, especially in
this case where the CPU is already compiling so slow.

Dale, thanks for the suggestion --- the network is fine and transfers
about 100MB/sec+.

> 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.

The server might be busy, or it's not possible to compile remotely.

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

[lee]

 writes:

> lee  wrote:
>
>>  writes:
>> 
>> > lee  wrote:
>> >
>> >> Hi,
>> >> 
>> >> what's taking so long when emerging packages despite distcc is
>> >> used?
> [...]
>> 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.

The load average only goes high on the client.  The server is too fast
to notice.

> 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 haven't emerged libreoffice yet --- that might take very long.

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

Hm, that's worth a try.

> 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.

It doesn't show anything but blank lines --- it might compile too fast
for anything to show up.  I can see in /var/log/messages that things are
being compiled, like this:


distccd[29727]: (dcc_job_summary) client: 192.168.3.33:38604 COMPILE_OK
exit:0 sig:0 core:0 ret:0 time:372ms x86_64-pc-linux-gnu-g++ drvvtk.cpp


The gui monitor doesn't seem to exist.

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

[lee]

 writes:

> 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. 

Hm.  Are you saying you can run it only on the client?

Oh, I can see it now!  Preprocessing seems to be done on localhost only,
and some compilation, too.  Some is compiled on the server.

I tried to remove 'distcc' and leaving only 'distcc-pump' in make.conf
to force preprocessing to the server.  With that, nothing shows up.

Is there a way to offload the preprocessing to the server, and can
compiling on localhost be avoided as much as possible somehow?

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

[lee]

Frank Steinmetzger  writes:

> 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've set log level to 'notice' and can see messages in
/var/log/messages.  distccmon-gui doesn't seem to exist, and nothing
shows up with distccmon-txt.

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

[lee]

 writes:

>  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).

The wiki says to use twice CPUs plus 1.  That's 57 here.  That should be
fast.  I could add more servers and bring it up to -j81, but since the
server is pretty much idle, that won't help.

[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] 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] 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