Advanced search

Message boards : Number crunching : Load balancing GPUGRID and other boinc projects on Linux.

Author Message
Hank Barta
Send message
Joined: 15 Apr 11
Posts: 4
Credit: 1,760,113
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 20980 - Posted: 15 Apr 2011 | 17:30:44 UTC

I'm running both GPUGRID and Rosetta on a Linux system. I find that the GPUGRID application seems to be starved for CPU even though it has a lower nice setting than the Rosetta tasks. (I have posted more details at the Ubuntu forum - should I copy that here or can I just point to it? http://ubuntuforums.org/showthread.php?p=10680138#post10680138 )

With Rosetta suspended, GPUGRID is using about 8% of one processor and registers about 90% usage on the GPU (GTX 460) With Rosetta active on all four cores, GPUGRID keeps the GPU at about 10% and uses only about 2% of one core. (This is a 4 core AMD based system.)

Ideally GPUGRID would use sufficient processor to keep the GPU loaded and leave the remainder to Rosetta for maximum performance on both projects. (And yes, I have lots of case fans. ;) )

Are there any Linux or boinc tweaks to achieve this?

thanks,
hank

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 20981 - Posted: 15 Apr 2011 | 20:15:15 UTC - in response to Message 20980.
Last modified: 15 Apr 2011 | 20:16:41 UTC

Hi, I recommend a look at this thread to optimize GPU + CPU.

http://www.gpugrid.net/forum_thread.php?id=2461

Having done the above, to allocate a CPU to a GPU and keep the other in another project (not using GPU) in the BOINC options it is best to book a Core or two more .. GPUs as we have.

Ie if we have 4 Cores will "use a maximum of 75%" of processors or (50% etc ...) as appropriate.

It's like I have it and it works perfectly, I run GPUGRID-(GTX295 +2CPUs) + IBERCIVIS (2CPUs) without conflicts. Greetings

Hank Barta
Send message
Joined: 15 Apr 11
Posts: 4
Credit: 1,760,113
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 20983 - Posted: 16 Apr 2011 | 13:04:11 UTC - in response to Message 20981.

Hi Carlesa25,
Thanks for the tip. I tried the SWAN_SYNC environment variable and it seemed to have no effect.

I really hate to give up 100% of one core for 8% on another project.

I just tried reducing CPU usage from 100% to 95% (in preferences) and that also seems not to help.

thanks,
hank

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 20984 - Posted: 16 Apr 2011 | 14:19:39 UTC - in response to Message 20983.
Last modified: 16 Apr 2011 | 14:27:54 UTC

Hi SWAN_SYNC works and what it does is assign a core to 100% (or almost) to each GPU, GPUGRID performance increases between 10 and 20% according to task, it works better on Linux than Windows (like all Boinc) .

I comment on the use of specific processor is, in "Preferences Using Boinc Manager + Processor + On multiprocessor systems use a maximum of" select that we can use 75% etc ... of processors available on the CPU, ie will be three of the four (or other combination as appropriate)

If we assign A CORE to have four cores and GPUs available, we note use maximum 75% of the CORES thus leave the three remaining free for other tasks without interference with the GPU.

Another thing is the "Maximum Use" of processes, people usually put 60% of time,for general cargo temperatures and PC.
This parameter does not affect the core (or cores) assigned to the variable SWAN_SYNC GPUs, just others.

I do not know if I explained well. Greetings.

Kirby54925
Send message
Joined: 21 Jan 11
Posts: 31
Credit: 70,061,988
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 20985 - Posted: 16 Apr 2011 | 18:49:06 UTC
Last modified: 16 Apr 2011 | 19:03:01 UTC

Well, where did you put the swan_sync environment variable? Different distros read the environment variable in different places, so YMMV.

EDIT: For instance, I placed the line "export SWAN_SYNC=0" in my /etc/default/boinc-client file (Linux Mint 10). Others have reported that placing it in /etc/environment works, but it didn't work for me.

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 20986 - Posted: 16 Apr 2011 | 18:59:09 UTC - in response to Message 20985.

Hello. In Ubuntu 10.10 should be put in " / etc / environment " in other distributions do not know, if based on Debian in principle be equal ... who whose I guess. Greetings.

Greg Beach
Avatar
Send message
Joined: 5 Jul 10
Posts: 21
Credit: 50,844,220
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwat
Message 21031 - Posted: 20 Apr 2011 | 22:37:31 UTC - in response to Message 20985.

Well, where did you put the swan_sync environment variable? Different distros read the environment variable in different places, so YMMV.

EDIT: For instance, I placed the line "export SWAN_SYNC=0" in my /etc/default/boinc-client file (Linux Mint 10). Others have reported that placing it in /etc/environment works, but it didn't work for me.


The effectiveness of adding it to /etc/environment seems to be inconsistent at best. Some distros ignore /etc/environment when starting daemons.

Adding it to the /etc/default file as you did is the best approach. It isolates the scope of the change to the boinc-client (no need to make the variable visible to every process on your system) and it is exactly what the file was intended for.

Here are instructions that should cover most of the common distros.

File on Debian based distros (including Ubuntu, Mint)

/etc/default/boinc-client

File on Fedora based distros (including Red Hat, CentOS)

/etc/sysconfig/boinc-client

Text to add

# Enable SWAN_SYNC for GPUGRID project
export SWAN_SYNC=0

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21032 - Posted: 20 Apr 2011 | 23:56:51 UTC - in response to Message 21031.

Hi, What I can say is that in Ubuntu 10.10, / etc / environment, it works perfectly. Greetings.

Kirby54925
Send message
Joined: 21 Jan 11
Posts: 31
Credit: 70,061,988
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 21033 - Posted: 21 Apr 2011 | 8:57:06 UTC - in response to Message 21031.

The effectiveness of adding it to /etc/environment seems to be inconsistent at best. Some distros ignore /etc/environment when starting daemons.

Adding it to the /etc/default file as you did is the best approach. It isolates the scope of the change to the boinc-client (no need to make the variable visible to every process on your system) and it is exactly what the file was intended for.


Actually, I got that advice from you in another thread. Solved the problem I had earlier.

Greg Beach
Avatar
Send message
Joined: 5 Jul 10
Posts: 21
Credit: 50,844,220
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwat
Message 21038 - Posted: 22 Apr 2011 | 17:46:11 UTC - in response to Message 21032.

Hi, What I can say is that in Ubuntu 10.10, / etc / environment, it works perfectly. Greetings.

I don't doubt that it works for you. I was merely pointing out that using /etc/environment works some of the time but using the /etc/[default|sysconfig] will always work so should be the preferred solution.

Greg Beach
Avatar
Send message
Joined: 5 Jul 10
Posts: 21
Credit: 50,844,220
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwat
Message 21039 - Posted: 22 Apr 2011 | 17:47:42 UTC - in response to Message 21033.

Actually, I got that advice from you in another thread. Solved the problem I had earlier.

Glad it helped.

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21041 - Posted: 22 Apr 2011 | 20:21:41 UTC - in response to Message 21039.

Hi: The problem I see in the solution, is that only works if you have installed Boinc from the classical form.

In a custom configuration, selecting a different place and method of installation /etc/default/-- not have "boinc-client".

For example I have a Boinc installed in a folder /home/carlos/BOINC, this form is the least intrusive on the system, in my opinion and use the form "/etc/environment" is independent of the type of installation.

Personally I am not an expert (amateur only) on Linux (or any other) if I'm wrong I would appreciate your comments. Greetings.

Kirby54925
Send message
Joined: 21 Jan 11
Posts: 31
Credit: 70,061,988
RAC: 0
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwat
Message 21044 - Posted: 23 Apr 2011 | 16:50:42 UTC

You mean you didn't use a package manager to install BOINC? I'm curious as to why you did that.

Profile Carlesa25
Avatar
Send message
Joined: 13 Nov 10
Posts: 328
Credit: 72,619,453
RAC: 206
Level
Thr
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21046 - Posted: 23 Apr 2011 | 23:44:50 UTC - in response to Message 21044.

Hi, As you know, in Linux, Boinc can be installed in several ways:

View http://boinc.berkeley.edu/wiki/Installing_BOINC

If installed from the Software Center Ubuntu does with the default settings, directories, folders, startup, screensavers etc ...

Through direct download installation package Berkeley, what we have is a file. "sh" an installer that allows Boinc place where we are interested in a directory of your choice or believe in another physical disk etc ... not interfere at all with the OS (without demon etc ...).
We created a program launcher and start or quit when we are interested.

This is not the recommended way to install Boinc, but personally is what interests me and it works perfectly. Greetings.

Hank Barta
Send message
Joined: 15 Apr 11
Posts: 4
Credit: 1,760,113
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 21077 - Posted: 26 Apr 2011 | 20:16:15 UTC

Hi folks,
I'm now crunching SETI on my GTX 460 and have tried a few things out. I thought I'd share my findings with all of you.

While on GPUGRID, I found that using a real time kernel increased GPU utilization to a range from 35-65% (with 4 instances of Rosetta competing for the CPU.) That only used a couple percent CPU for GPUGRID but the extra overhead for the real time kernel reduced Rosetta throughput about 15% Still that seemed like a decent tradeoff. It was interesting to note that while the GPU utilization seemed to range quite a bit from WU to WU, it was relatively constant for any particular WU.

A Linux/CUDA/Fermi SETI app recently became available so I have switched to that. One characteristic of it is that a single WU seems to cover a wide range of utilization, ranging from 15 to about 85%. (Again, RT kernel and 4 instances of Rosetta.) I found that if I cut back to 3 instances of Rosetta, the SETI WUs ran to completion in about 15 minutes. Next I tried running two instances of SETI and found that WUs now completed in about half an hour. This was no huge surprise, but I was happy that overall throughput was not reduced.

My big surprise was when I added the fourth Rosetta task. GPU utilization remains high at about 85-95% and it appears that throughput will be about the same as if I cut back to three instances of Rosetta. I'm still losing about 15% on Rosetta by using the RT kernel, but at least I'm getting high GPU utilization in return.

I have no way of knowing how this translates to other GPUs, other OSs or other DC projects, but it is certainly something worth further exploration if you're crunching on both CPU and GPU.

happy crunching,
hank

Profile CJ in Seattle [BlackOps]
Avatar
Send message
Joined: 3 Mar 09
Posts: 35
Credit: 434,840,087
RAC: 0
Level
Gln
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21081 - Posted: 27 Apr 2011 | 2:05:07 UTC

I'm crunching on 3 gpus in my tower and felt that losing a core for a small performance gain seemed kind of pointless. I run a quad core processor and I like to keep it running with tasks from other projects as well as GPUGRID. I tried swan sync and I can say that it works but I feel it's not worth it for 10-15% increase when you can put that core to work doing other helpful things. My gpu's still crank out the work without sacrificing other projects. GPU utilization seems to vary from pc to pc but I find that even with 100% cpu use I'm still getting 60-85% GPU use and that works for me to help keep the temps down. Good luck crunching!
____________

Profile skgiven
Volunteer moderator
Volunteer tester
Avatar
Send message
Joined: 23 Apr 09
Posts: 3968
Credit: 1,995,359,260
RAC: 0
Level
His
Scientific publications
watwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwatwat
Message 21090 - Posted: 27 Apr 2011 | 10:50:55 UTC - in response to Message 21081.

A high end GPU will do 20 times the work of a high end CPU, so it makes more sense to sacrifice the CPU and not the GPU.
10-15% gain for one CPU Core/thread. You are talking about losing 25% of a CPU for a 10-15% increase in a GPU. So you are losing 25% but gaining 10 to 15% times 20 (relative to the CPU). Thats a gain of 200% to 300%.

Obviously it depends on what you want to crunch for. Well it should, and you should ignore any arbitrary credit systems.

60% to 85% is quite a wide margin. I'm not seeing that, 93% usually, but then you are using Win7, which is at least 11% slower than XP, and that's after all GPU favoring optimizations.

Hank Barta
Send message
Joined: 15 Apr 11
Posts: 4
Credit: 1,760,113
RAC: 0
Level
Ala
Scientific publications
watwatwatwatwat
Message 21093 - Posted: 27 Apr 2011 | 15:39:28 UTC - in response to Message 21081.

... GPU utilization seems to vary from pc to pc but I find that even with 100% cpu use I'm still getting 60-85% GPU use and that works for me to help keep the temps down. Good luck crunching!
OS has an impact as well. I'm running Linux and 4 cores crunching Rosetta starved a single GPU task to the point it kept the GPU at about 15%.

Post to thread

Message boards : Number crunching : Load balancing GPUGRID and other boinc projects on Linux.

//