One more suggestion - Look carefully at your USE keywords - you might get a boost with less stuff compiled into each prog - smaller binaries result, hence more rapid response.
Doing "emerge -pv -e --update --newuse --deep world" will give you a breakdown of what is being compiled for each prog.
DON'T remove "nsl" or "acl" I did both around last Tuesday - one new install coming up... Obviously the more USE keywords you remove the less functionality - as per my last post: your choice there...
The zappier your system, the quicker it will be able to change between user/other system calls input and Einstein requirements - a smaller kernel will do the same - just read the help for each option and google - when in doubt leave the default on.
Check the "rc-update show" list - the more you have there the slower stuff will run - obviously don't remove stuff that was put in by the system when it got installed - but if you have added lots of stuff consider starting them manually when needed.
What I really like about Gentoo, is the ability to start from scratch. That way I could make decisions on what I want on my system. So I just left out major "bloatware", especially KDE. I am also quite comfortable using fluxbox, runs like a charm, with virtually no impact on CPU and RAM. What I read also, is that apparently applying a theme doesn't have a lot of impact either (just in case I'd consider a more fancy window manager in the future).
Very good point you made about manually starting modules indeed. I think I'll go scripting a bit. As for your alsa example: I consider writing a script loading alsa, starting xmms, and unload alsa on exit again. Many applications could probably be scripted that way. I'm looking forward to it, but first I'll have to increase my knowledge on Linux a bit further.
Another thought: why not use an INIT level dedicated to BOINC. That way it's possible to unload even more stuff. Just crossed my mind...
BTW: apparently my harddisk was already used optimally (ultraDMA enabled). hdparm didn't increase performance. I considered it too risky to go further than that. I guess squeezing more out of the 760+ MB/sec wouldn't make a lot of difference either...
Regards,
Bert
PS: at the start of this thread I really didn't imagine ending up here...
I had to remove the password in the /var/lib/boinc directory - file name: gui_rpc_auth.cfg .
BTW: do you know that the reason for having a password there is to keep people out of your boinc? It's better to change it to another password!
Regards,
Bert
Hiya Bert
Yup - was aware of that (and thanks), and mostly just suggested that initially, until you got stuff running - Once all works I shoved a password back in again. I'm behind a nat router anyway so quite well protected, but yep a password does help a tad :)
I have always used the BOINC GUI - well I come from Windows XP sooo....
Anyhow just before you go to bed or go out for the evening, log out of fluxbox back to where you did "startx". Then type "boinc_cmd --help" and set boinc to run automatically. I found running out of X and fluxbox gets rid of another 7 services, resulting in Einstein getting 99,9 per cent of the cpu, and boosting the crunching a fair old bit. Whether you are in fluxbox or not boinc will continue to crunch - all the above assumes you have boinc set to start at default run level - "rc-update add boinc default" - I have now left boinc on auto permanently - convenient and I can just close down fluxbox and go to bed.
There has to be a first time: I recompiled my kernel and screwed up. I couldn't boot anymore. My lack of experience let me finaly decide to re-install the whole thing again... I've recompiled a kernel on Debian, but with genkernel I missed the ability to rename the kernel. So I lost my old one as well...
Quote:
Anyhow just before you go to bed or go out for the evening, log out of fluxbox back to where you did "startx". Then type "boinc_cmd --help" and set boinc to run automatically. I found running out of X and fluxbox gets rid of another 7 services, resulting in Einstein getting 99,9 per cent of the cpu, and boosting the crunching a fair old bit. Whether you are in fluxbox or not boinc will continue to crunch - all the above assumes you have boinc set to start at default run level - "rc-update add boinc default" - I have now left boinc on auto permanently - convenient and I can just close down fluxbox and go to bed.
I had something like that in my mind as well. I'd suggest even going further be defining another run-level. I've got to work that out though.
Another strange thing happened as well. My Debian experience taught me to check "top" every now and then, just to make sure that an app wasn't taking cpu resources after it was supposed to be closed. But now, "top" it self was taking over 90%... So I checked it with "ps" as well, but it was still in memory. So, you really have to check your back...
BTW: the command line client has the disadvange that you can't see your progress if desired. I solved that with a script using something like cat client_state.xml|grep fraction_done. It even loaded data from the net ( total credits, pending credits and RAC). A very lightweight alternative to the graphical boinc manager (still some changes to make, but it's running quite nice).
I recompiled my kernel and screwed up. I couldn't boot anymore
The kernel names did not change, but apparently grub.conf was changed. I thought I had to do it manually. It changed my root(hd0,x) to the root partition instead of the boot partition. Yet another lesson for the future...
I recompiled my kernel and screwed up. I couldn't boot anymore
The kernel names did not change, but apparently grub.conf was changed. I thought I had to do it manually. It changed my root(hd0,x) to the root partition instead of the boot partition. Yet another lesson for the future...
Oh well, was about to use new flags anyway :)
Hiya Bert
Did you make the kernel using genkernel or by yourself (just asking fmoi). I screwed up numerous installs in the past - every time they released a new kernel in fact :(
Anyhow, now that I have symlink in the use keywords, everytime I need to update the kernel I do: genkernel --menuconfig (insert exact command - man genkernel to get this - to direct new kernel to previous config file /etc/kernels/(whatever kernel is called) all. Then nano -w /boot/grub/grub.conf and set the kernel name correctly.
For future reference, you can always mount /root, /boot, /proc and set swap and chroot into system from the install cd - that saved me huge amounts of time - couple times I didn't change grub.conf for example. You can emerge stuff as per install etc.
Having said that, every time I have done an install I figure something out that might make it all work better - not just BOINC orientated tweaks but sometimes just short cuts, like for example I plan on putting all my config files as well as the stage 3 and portage files onto a CD, so I can just reuse all that stuff - speed up re-installs for future - save on valuable BOINC crunching time :)
Re that script - that would come in vert useful - I'd like to see it when you finish :)
Yeah, I'm using genkernel (--menuconfig all). This time I was wise enough to save the kernel configuration to disk. It already saved a lot of time to copy some old config files to another partition. Also, boinc is running again (it was compiled on my home directory).
As soon as everything is running, I'll look over the script again. It's working fine, but it retrieves the same website twice. So, it's a bit slow. I'll post it then!
Are you using ccache to compile stuff? Apparently, recompilation would be 5 to 10 times faster. Comes in handy when trying to find the optimal settings! The list for suggested improvements is getting bigger and bigger...
My apologies for keeping you busy! But I just have to share those things...
Yeah, I'm using genkernel (--menuconfig all). This time I was wise enough to save the kernel configuration to disk. It already saved a lot of time to copy some old config files to another partition. Also, boinc is running again (it was compiled on my home directory).
As soon as everything is running, I'll look over the script again. It's working fine, but it retrieves the same website twice. So, it's a bit slow. I'll post it then!
Are you using ccache to compile stuff? Apparently, recompilation would be 5 to 10 times faster. Comes in handy when trying to find the optimal settings! The list for suggested improvements is getting bigger and bigger...
My apologies for keeping you busy! But I just have to share those things...
Happy crunching!
Bert
Hiya Bert
Nope, I don't have much issue with compilation speed - GCC, GTK+ and Xorg are the only really big 'uns on this system and as I have my USE keywords + compile settings sorted as far as I am prepared to go - well the less on the system the better really. I have noticed that the less I shove into /usr/bin/ the faster BOINC runs fwiw. Also my cpu is 2.6 GHz, so while far from cutting edge, does compile fast enough for me - on the other hand if you trip over a couple of Intel's letest, I wouldn't say no... (grin) - might come in handy if I ever decide to go OpenOffice in Gentoo - now THAT'S a compile and a half !!
By the way I tried the fancy stuff for Fluxbox and found some of it very uninspiring - I may be forced to do me own wallpaper one of these days ! Anyhow I took all that stuff off the system - the Spiff style is fine for me: clear, fairly smart and really, really low footprint - "Minimal" was OK but boring and actually used more cpu power would you believe.
Actually since I realised just how much faster BOINC runs outside the GUI, I tend to just login and write a little note to meself for the morning to check BOINC in the morno, and go to bed. It would appear that I can do a long Einstein in 9,15 minutes at command prompt, compared to 9,30 with the GUI - basically the cpu gets less interruptions.
I checked "top" by the way - it seems to use 0.3 per cent of cpu every now and again - so I use it once to make sure BOINC is doing what it should be, and "q" just leaving meself logged in for the night.
Re genkernel - once I learnt the trick of symlink, using the old config file, and remembering to update grub.conf, I have not had a prob since - can't remember when I last had a system run a whole week minus a wipeout through over tweaking (grin). etc-update seemed to kill my system in the past but Gentoo seems to have sorted that side out a bit.
Re keeping me busy - think of it as a good deed - you are stopping me from getting bored and doing the "let's see what happens if...." usually after a glass of red wine (grin).
Hello Bert One more
)
Hello Bert
One more suggestion - Look carefully at your USE keywords - you might get a boost with less stuff compiled into each prog - smaller binaries result, hence more rapid response.
Doing "emerge -pv -e --update --newuse --deep world" will give you a breakdown of what is being compiled for each prog.
DON'T remove "nsl" or "acl" I did both around last Tuesday - one new install coming up... Obviously the more USE keywords you remove the less functionality - as per my last post: your choice there...
The zappier your system, the quicker it will be able to change between user/other system calls input and Einstein requirements - a smaller kernel will do the same - just read the help for each option and google - when in doubt leave the default on.
Check the "rc-update show" list - the more you have there the slower stuff will run - obviously don't remove stuff that was put in by the system when it got installed - but if you have added lots of stuff consider starting them manually when needed.
Happy crunching - Gray
Hi Gray! Thanks again for
)
Hi Gray!
Thanks again for your input.
What I really like about Gentoo, is the ability to start from scratch. That way I could make decisions on what I want on my system. So I just left out major "bloatware", especially KDE. I am also quite comfortable using fluxbox, runs like a charm, with virtually no impact on CPU and RAM. What I read also, is that apparently applying a theme doesn't have a lot of impact either (just in case I'd consider a more fancy window manager in the future).
Very good point you made about manually starting modules indeed. I think I'll go scripting a bit. As for your alsa example: I consider writing a script loading alsa, starting xmms, and unload alsa on exit again. Many applications could probably be scripted that way. I'm looking forward to it, but first I'll have to increase my knowledge on Linux a bit further.
Another thought: why not use an INIT level dedicated to BOINC. That way it's possible to unload even more stuff. Just crossed my mind...
BTW: apparently my harddisk was already used optimally (ultraDMA enabled). hdparm didn't increase performance. I considered it too risky to go further than that. I guess squeezing more out of the 760+ MB/sec wouldn't make a lot of difference either...
Regards,
Bert
PS: at the start of this thread I really didn't imagine ending up here...
Somnio ergo sum
Hi Gray, RE: I had to
)
Hi Gray,
BTW: do you know that the reason for having a password there is to keep people out of your boinc? It's better to change it to another password!
Regards,
Bert
Somnio ergo sum
RE: Hi Gray,RE: I had to
)
Hiya Bert
Yup - was aware of that (and thanks), and mostly just suggested that initially, until you got stuff running - Once all works I shoved a password back in again. I'm behind a nat router anyway so quite well protected, but yep a password does help a tad :)
Cheers - Gray
Hello Bert I have always
)
Hello Bert
I have always used the BOINC GUI - well I come from Windows XP sooo....
Anyhow just before you go to bed or go out for the evening, log out of fluxbox back to where you did "startx". Then type "boinc_cmd --help" and set boinc to run automatically. I found running out of X and fluxbox gets rid of another 7 services, resulting in Einstein getting 99,9 per cent of the cpu, and boosting the crunching a fair old bit. Whether you are in fluxbox or not boinc will continue to crunch - all the above assumes you have boinc set to start at default run level - "rc-update add boinc default" - I have now left boinc on auto permanently - convenient and I can just close down fluxbox and go to bed.
Cheers - Gray
Hi Gray, There has to be a
)
Hi Gray,
There has to be a first time: I recompiled my kernel and screwed up. I couldn't boot anymore. My lack of experience let me finaly decide to re-install the whole thing again... I've recompiled a kernel on Debian, but with genkernel I missed the ability to rename the kernel. So I lost my old one as well...
I had something like that in my mind as well. I'd suggest even going further be defining another run-level. I've got to work that out though.
Another strange thing happened as well. My Debian experience taught me to check "top" every now and then, just to make sure that an app wasn't taking cpu resources after it was supposed to be closed. But now, "top" it self was taking over 90%... So I checked it with "ps" as well, but it was still in memory. So, you really have to check your back...
BTW: the command line client has the disadvange that you can't see your progress if desired. I solved that with a script using something like cat client_state.xml|grep fraction_done. It even loaded data from the net ( total credits, pending credits and RAC). A very lightweight alternative to the graphical boinc manager (still some changes to make, but it's running quite nice).
Cheers,
Bert
Somnio ergo sum
RE: I recompiled my kernel
)
The kernel names did not change, but apparently grub.conf was changed. I thought I had to do it manually. It changed my root(hd0,x) to the root partition instead of the boot partition. Yet another lesson for the future...
Oh well, was about to use new flags anyway :)
Somnio ergo sum
RE: RE: I recompiled my
)
Hiya Bert
Did you make the kernel using genkernel or by yourself (just asking fmoi). I screwed up numerous installs in the past - every time they released a new kernel in fact :(
Anyhow, now that I have symlink in the use keywords, everytime I need to update the kernel I do: genkernel --menuconfig (insert exact command - man genkernel to get this - to direct new kernel to previous config file /etc/kernels/(whatever kernel is called) all. Then nano -w /boot/grub/grub.conf and set the kernel name correctly.
For future reference, you can always mount /root, /boot, /proc and set swap and chroot into system from the install cd - that saved me huge amounts of time - couple times I didn't change grub.conf for example. You can emerge stuff as per install etc.
Having said that, every time I have done an install I figure something out that might make it all work better - not just BOINC orientated tweaks but sometimes just short cuts, like for example I plan on putting all my config files as well as the stage 3 and portage files onto a CD, so I can just reuse all that stuff - speed up re-installs for future - save on valuable BOINC crunching time :)
Re that script - that would come in vert useful - I'd like to see it when you finish :)
Gray
Hi Gray, Yeah, I'm using
)
Hi Gray,
Yeah, I'm using genkernel (--menuconfig all). This time I was wise enough to save the kernel configuration to disk. It already saved a lot of time to copy some old config files to another partition. Also, boinc is running again (it was compiled on my home directory).
As soon as everything is running, I'll look over the script again. It's working fine, but it retrieves the same website twice. So, it's a bit slow. I'll post it then!
Are you using ccache to compile stuff? Apparently, recompilation would be 5 to 10 times faster. Comes in handy when trying to find the optimal settings! The list for suggested improvements is getting bigger and bigger...
My apologies for keeping you busy! But I just have to share those things...
Happy crunching!
Bert
Somnio ergo sum
RE: Hi Gray, Yeah, I'm
)
Hiya Bert
Nope, I don't have much issue with compilation speed - GCC, GTK+ and Xorg are the only really big 'uns on this system and as I have my USE keywords + compile settings sorted as far as I am prepared to go - well the less on the system the better really. I have noticed that the less I shove into /usr/bin/ the faster BOINC runs fwiw. Also my cpu is 2.6 GHz, so while far from cutting edge, does compile fast enough for me - on the other hand if you trip over a couple of Intel's letest, I wouldn't say no... (grin) - might come in handy if I ever decide to go OpenOffice in Gentoo - now THAT'S a compile and a half !!
By the way I tried the fancy stuff for Fluxbox and found some of it very uninspiring - I may be forced to do me own wallpaper one of these days ! Anyhow I took all that stuff off the system - the Spiff style is fine for me: clear, fairly smart and really, really low footprint - "Minimal" was OK but boring and actually used more cpu power would you believe.
Actually since I realised just how much faster BOINC runs outside the GUI, I tend to just login and write a little note to meself for the morning to check BOINC in the morno, and go to bed. It would appear that I can do a long Einstein in 9,15 minutes at command prompt, compared to 9,30 with the GUI - basically the cpu gets less interruptions.
I checked "top" by the way - it seems to use 0.3 per cent of cpu every now and again - so I use it once to make sure BOINC is doing what it should be, and "q" just leaving meself logged in for the night.
Re genkernel - once I learnt the trick of symlink, using the old config file, and remembering to update grub.conf, I have not had a prob since - can't remember when I last had a system run a whole week minus a wipeout through over tweaking (grin). etc-update seemed to kill my system in the past but Gentoo seems to have sorted that side out a bit.
Re keeping me busy - think of it as a good deed - you are stopping me from getting bored and doing the "let's see what happens if...." usually after a glass of red wine (grin).
Cheers - Gray