Why only one parallell GPU task?

archae86
archae86
Joined: 6 Dec 05
Posts: 3,134
Credit: 6,796,602,783
RAC: 349,838

shauge wrote:it did not start

shauge wrote:
it did not start doing multiple apps immediately, even after forcing a config update. It may be because I had too much work for the other CPU only project I run. The new gpu apps require a whole CPU core pr. instance. After a day or two it started running multiple GPU apps.

Just a reminder, Einstein GPU multiplicity changes commanded by web site changes do not take effect until a new WU is actually downloaded.  Once downloaded, they do take effect (including previously downloaded work and even already running work), though the "branding" does not update.

On the other hand, yes, if local BOINC on your host is running CPU tasks as High Priority (because of calculated deadline trouble), that can crowd out CPU support for GPU multiplicity and lead to temporary running at lower than requested multiplicity.

shauge
shauge
Joined: 21 Apr 07
Posts: 9
Credit: 539,071,863
RAC: 0

archae86 wrote:shauge

archae86 wrote:
shauge wrote:
it did not start doing multiple apps immediately, even after forcing a config update. It may be because I had too much work for the other CPU only project I run. The new gpu apps require a whole CPU core pr. instance. After a day or two it started running multiple GPU apps.

Just a reminder, Einstein GPU multiplicity changes commanded by web site changes do not take effect until a new WU is actually downloaded.  Once downloaded, they do take effect (including previously downloaded work and even already running work), though the "branding" does not update.

Your interpretation of the information you get each time you make a change on the web site, is not completely correct. You can also do a force update on the client side. Besides, I did also make other changes at the same time that were in effect, so the local settings had been updated.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,778
Credit: 105,846,205,967
RAC: 66,121,914

shauge wrote:archae86

shauge wrote:
archae86 wrote:
shauge wrote:
it did not start doing multiple apps immediately, even after forcing a config update. It may be because I had too much work for the other CPU only project I run. The new gpu apps require a whole CPU core pr. instance. After a day or two it started running multiple GPU apps.

Just a reminder, Einstein GPU multiplicity changes commanded by web site changes do not take effect until a new WU is actually downloaded.  Once downloaded, they do take effect (including previously downloaded work and even already running work), though the "branding" does not update.

Your interpretation of the information you get each time you make a change on the web site, is not completely correct. You can also do a force update on the client side. Besides, I did also make other changes at the same time that were in effect, so the local settings had been updated.

He is correct - you are not understanding what he said.  With this one setting (changing the number of concurrent GPU tasks through the GPU utilization factor on the website) it will not be reflected on your host just by clicking 'update' locally, no matter how many times you do it.  The key point is that the new setting ONLY gets implemented locally AFTER a new GPU task is actually downloaded.  So, to get the change to happen quickly, just increase the work cache size setting sufficiently to download a new GPU task.  Then the change will occur immediately.

 

Cheers,
Gary.

Suffkoppus
Suffkoppus
Joined: 28 Oct 07
Posts: 47
Credit: 649,648,843
RAC: 0

Thanks for all the input. The

Thanks for all the input. The fix for me was to clear up all cpu work downloaded to my problem host. It had with a cache set to 1, over 330 cpu tasks and only about 20 gpu tasks on my drive. After aborting the 330 cpu tasks it was all fine again. Somehow the cache also does not fill up again with too many cpu tasks. But that should have been the problem in the beginning.

At all: have a good crunching year 2017

Ace Casino
Ace Casino
Joined: 25 Feb 05
Posts: 36
Credit: 1,139,556,023
RAC: 851,558

How come my 8 cpu machine is

How come my 8 cpu machine is running 9 cpu's.

8 cores of Gamma-Ray SSE

1 core of Gamma-Ray Nividia GPU

The new Nividia GPU's take 1 core, so that's 9 running at once.

This is happening.

Edit: My Quad core machine is acting like you might think it should Running 2 Gamma GPU and 2 CPU...not 5.  These new Gamma-Ray GPU's are supposed to take 1 cpu.

Mad_Max
Mad_Max
Joined: 2 Jan 10
Posts: 152
Credit: 2,069,166,976
RAC: 421,782

Looks like the same problem

Looks like the same problem same problem as Suffkoppus had have:  too many CPU tasks in queue force client running in "high priority". So recommendation is a same too:

Mad_Max wrote:

Check if your BOINC client running E@H in "high priority mode" (on tasks tab). It may be cause if you right about 8 (not 7) Multi-Directed Continuous Gravitational Wave search CV CPU tasks running on 8 cores CPU.

If so - try to reduce work cache size in BOINC settings and(only after new cache size, 0.5-1 day max) abort some of GW WUs until BOINC stop running in ""high priority". Or just wait few days while it clear some of WU queue without downloading new ones.

 

Root of the problem in the wrong assessment of the duration of the work - overestimated for GPU jobs and underestimated for the CPU jobs. As a result, the client downloads too much CPU jobs and too little of the GPU jobs.

But this thing can not be corrected by the user, it should be the administration of the project change and tweak some settings. Small work cache and aborting some of CPU WUs is just a workaround.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,552,419,649
RAC: 307

If you're a user with a fast

If you're a user with a fast GPU, one thing you can do to reduce the mismatch in CPU vs GPU runtimes is to run several GPU tasks at once to slow the per GPU task runtime down.  Ultimately, what is needed though is to update the boinc platform to use multiple Duration Correction Factors - ideally 1 per work unit type; but at an absolute minimum separate CPU and GPU values are needed.  A lot of this probably could be done purely on the client, although (especially with a per-app implementation) server side support would make for nicer behavior (ie the devs could explicitly link science apps that should have a similar DCF together instead of requiring the client to guess relationships based on naming conventions).

Holmis
Joined: 4 Jan 05
Posts: 1,118
Credit: 1,055,935,564
RAC: 0

A fix for these DCF problems

A fix for these DCF problems has already been developed with the CreditNew, but as that system has some other quite big problems the admins here has opted not to implement it until it's updated/rewritten to function much better.
CreditNew was tested on Albert a few years ago and some of the problems with the system was identified but hasn't been fixed yet.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.