At present there are not enough tasks to go around & most/all WU's have high GPU utilization so the project doesn't benefit (overall) from even high end GPU's running 2tasks at a time. Considering the recent upload/server availability issues it makes even less sense to run more than 1task/GPU. I would even go so far as to suggest its time we were running 1 task across multiple GPU's (for those who have them) - something that would also benefit those with 2 or more smaller GPU's; assuming an NV-link/SLi isn't required. By the way, GPU utilization isn't the end all be all of GPU usage; apps that perform more complex simulations, that require more GDDR, and more PCIE bandwidth are just using the GPU differently; not more or less (one probably comes at the expense of the other).

When available tasks are exclusively low GPU-utilizing tasks, only then could the project benefit from high-end GPU's running 2tasks simultaneously.

PS. The Pascal app (cuda80) is different from the previous app (cuda65) which can run mixed GPU setups; the latest app is exclusively for Pascal's (GTX 1000 series).

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

At present there are not enough tasks to go around & most/all WU's have high GPU utilization so the project doesn't benefit (overall) from even high end GPU's running 2tasks at a time.

I think though that Betting Slip meant his suggestion in a different way: not talking about 2 tasks running at a time, but rather one task running, with another task downloading already (long time) before the running task gets finished.

However, I am asking whether the policy suggested by him has meanwhile been implemented:
On one of my PCs, when the BOINC manager tried an Update on GPUGRID tasks (i.e. trying to download the next WU) while one WU was in progress, it said "the computer has reached a limit on tasks in progress".

At present there are not enough tasks to go around & most/all WU's have high GPU utilization so the project doesn't benefit (overall) from even high end GPU's running 2tasks at a time.

I think though that Betting Slip meant his suggestion in a different way: not talking about 2 tasks running at a time, but rather one task running, with another task downloading already (long time) before the running task gets finished.

However, I am asking whether the policy suggested by him has meanwhile been implemented:
On one of my PCs, when the BOINC manager tried an Update on GPUGRID tasks (i.e. trying to download the next WU) while one WU was in progress, it said "the computer has reached a limit on tasks in progress".

No, it has not been implemented evidenced by one of your computers with a single 750ti having 2 long WU's. How does that even begin to make any sense? http://www.gpugrid.net/results.php?hostid=372115

I'm not holding my breath on it being implemented either.

No, it has not been implemented evidenced by one of your computers with a single 750ti having 2 long WU's. How does that even begin to make any sense? http://www.gpugrid.net/results.php?hostid=372115

I'm not holding my breath on it being implemented either.

Do you mind aborting at least one of those WUs? My two 1070s and 980ti are idling, and I'm sure many others are like me.

Frankly, I don't think it's a good idea that crunchers are not starting to bite (not to say: attack) each other because there are WUs in waiting position at the host of a given cruncher, while the GPU of another cruncher is running idle.
The policy in place so far allows for this, and it's up to GPUGRID to either continue it or to change it.

However, the situation of idle GPUs would of course not happen if there were enough WUs available all the time.
So, crunchers should not blame other crunchers for GPUs in idle status.

Do you mind aborting at least one of those WUs? My two 1070s and 980ti are idling, and I'm sure many others are like me.

There's no point in aborting a task on an alive and active host, as there's nothing that could make sure that this task gets assigned to an idle and active host. As the number of tasks in progress decreases, there are more hosts trying to get work (in vain) including those which never finish the work. The overwhelmed / inactive hosts could impede the most the progress of a chain, as there's a 5 days deadline, so such a host could cause that much delay in a single step. When there's no work the chance of getting a previously timed out task is higher, even such tasks which timed out more times (causing 10, 15, 20... days delay). For example this one. It spent 10 days in vain before I've received it.

Frankly, I don't think it's a good idea that crunchers are not starting to bite (not to say: attack) each other because there are WUs in waiting position at the host of a given cruncher, while the GPU of another cruncher is running idle.
The policy in place so far allows for this, and it's up to GPUGRID to either continue it or to change it.

However, the situation of idle GPUs would of course not happen if there were enough WUs available all the time.
So, crunchers should not blame other crunchers for GPUs in idle status.

Right, squabbling will get us nowhere.

Well ... seems that GPUGRID is self regulatory in terms of crunching power as many things in nature. I try not to take that personally. If there is not enough work, quite a few crunchers will walk away and seek for jobs elsewhere. I have already withdrawn my 1070 from GPUGRID and my remaining 1080 still is idle very often due to lacking tasks. Maybe I should withdraw this one as well. Leaves more work for others.

---

I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Zoltan you are very right, there is a risk, but I have been fast enough to claim every aborted task so far. And JoergF, there's no sense in completely withdrawing GPUs from GPUGrid, just have a backup with less priority so it automatically switches to that other work load if there is no work in GPUGrid. This is the only way I can keep my house warm with this intermittent work, and with no babysitting.

Yes --- Leave GPUGrid attached!

I recommend setting GPUGrid at resource share 100 or higher, and attach to other GPU projects like SETI or Einstein or Asteroids, at 0 resource share, as backup projects, meaning they only get work when your non-backup projects don't have work.

Resource Share info:
http://boinc.berkeley.edu/wiki/Preferences#List_of_project_preferences

Honestly, all this griping about "no work" is a bit sickening. You all sure do like to micromanage :) Just attach to multiple projects, set your resource shares correctly, and let BOINC do its job to keep your resources busy!

Somehow I manged to not get a single WU from the 600 new WUs released even though I manually updated all my my computers during the time they were still being claimed.

Somehow I manged to not get a single WU from the 600 new WUs released even though I manually updated all my my computers during the time they were still being claimed.

That's regrettable, but it's not unexpectable, and I see it as a justification of my observation I've posted earlier:
"there's nothing that could make sure that this task gets assigned to an idle and active host."
BTW, I haven't received from these workunits either.

Has the 1 WU per GPU rule been enforced? It seems so. I have just purchased a new 1080ti and have very poor utilization (~70%) with only one 1WU (although the client config is set to 2WU in parallel). My 6700K (not OC yet) isn't fast enough to feed the 1080ti with data, so this is the outcome. My old 1080 had >90% with 2WU even under Windows 10.

What a bother.

Any suggestion ... aside from switching to Folding@Home ... or cooling the 6700K with LN2 and massively OC it?

---

I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Well.. at present there are not many WU in the Queue anyway... :-(

---

I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Has the 1 WU per GPU rule been enforced? It seems so. I have just purchased a new 1080ti and have very poor utilization (~70%) with only one 1WU (although the client config is set to 2WU in parallel). My 6700K (not OC yet) isn't fast enough to feed the 1080ti with data, so this is the outcome. My old 1080 had >90% with 2WU even under Windows 10.

One WU per GPU has not been enforced, rather there just aren't enough WUs to go around so everyone is lucky if they get just one. As for the utilization, if you look at the Server Status link at the top right of the web page, you'll see that they run a fleet of different WUs, all with different utilization. Some with have 90%+ even on windows, and some, 70-80% on any machine and any operating system.

There are ways to improve this. There is a variable called SWAN_SYNC in windows' environment variables. You get there by searching "variable" in the windows search. Once there you can click Environment variables on the bottom right. Under "user variables for your account" Click New and add SWAN_SYNC with a variable value of 1. Restart your computer and you will gain a few % in GPU utilization.

I beg to differ. My app_config.xml is the same as always... but Boinc seems to ignore it.

<app_config>
<app>
<name>acemdlong</name>
<max_concurrent>2</max_concurrent>
<cpu_usage>1.0</cpu_usage>
<gpu_usage>0.5</gpu_usage>
</app>
</app_config>

---

I would love to see HCF1 protein folding and interaction simulations to help my little boy... someday.

Have you tried disabling Hyper Threading (HT)? I've been experimenting and have seen slightly higher utilization when HT is off on my i7-7700k. CPU usage jumps from 13% to 25% per WU, and GPU-Z shows a small gain in usage.

I wish there was a way to force the WU to use a full physical core without turning HT off, but I haven't been able to figure it out. I tried setting <cpu_usage>2.0</cpu_usage> with HT on, but that didn't help, still 13% usage.

My comments apply to Windows 10, cpu usage in Linux seems less, I'm not sure this would help there.

I've been experimenting and have seen slightly higher utilization when HT is off on my i7-7700k.

That's because there are only 3 CPU tasks running when HT is off, and 7 when HT is on.
You can gain a little further GPU utilization if you run only 1 CPU task, or no CPU tasks at all.

[when HT is off] CPU usage jumps from 13% to 25% per WU

That's because when HT is on your CPU can handle 8 threads (on the 4 physical cores), so one thread uses 100%/8=12.5% (~13%),
while your CPU can handle 4 threads on the 4 physical cores when HT is off, so one thread uses 100%/4=25%

GPU-Z shows a small gain in usage [when HT is off].

See my first explanation for its reason. (less CPU tasks = higher GPU usage)

I wish there was a way to force the WU to use a full physical core without turning HT off, but I haven't been able to figure it out. I tried setting <cpu_usage>2.0</cpu_usage> with HT on, but that didn't help, still 13% usage.

The <cpu_usage> option tells the BOINC manager how many cores (threads) to assign for the given application, it does not instructs the application to use that many cores (threads). You can use the SWAN_SYNC environmental variable to instruct the GPUGrid application to use a full core (thread), but it won't use more than one.

My comments apply to Windows 10, cpu usage in Linux seems less, I'm not sure this would help there.

There's no WDDM in Linux, so GPU usage will be higher under Linux than on Windows 10 (Vista, 7, 8, 8.1).

less CPU tasks = higher GPU usage

To clarify, are you saying that the only reason that disabling HT is showing an improvement is because it's reducing the number of CPU tasks from other projects? That would imply that the increase in CPU usage from 12.5% (HT) to 25% (HT off) does not in itself improve WU return times.
For example, if no other projects were running, I would still think that more CPU usage is better regardless, but perhaps it is not that simple.

less CPU tasks = higher GPU usage

To clarify, are you saying that the only reason that disabling HT is showing an improvement is because it's reducing the number of CPU tasks from other projects?

Yes.

That would imply that the increase in CPU usage from 12.5% (HT) to 25% (HT off) does not in itself improve WU return times.

Yes.

For example, if no other projects were running, I would still think that more CPU usage is better regardless, but perhaps it is not that simple.

It's not that simple, as there are many factors which are reducing the GPU usage.
WDDM has the most impact, and it can't be turned off; you should use Linux or Windows XP (up to GTX 980 Ti, so you can choose only Linux for your GTX 1080)
More than 1 CPU task usually cause demonstrable decrease (depending on the task, as these are usually work on large data sets, which won't fit in the L3 cache of the CPU, thus they will flood the memory bus which will slow everything down a bit).
Using SWAN_SYNC (in combination with no CPU tasks) could increase the the GPU usage on Windows XP by up to ~15%, and by up to ~5% on Windows 10.

BTW you can try it very easily by simply suspending all CPU projects in BOINC manager for a test period.

Retvari Zoltan wrote:

Using SWAN_SYNC (in combination with no CPU tasks)...

..or just increase priority of GPU tasks.
I wrote earlier in this message how to automate the process of increasing priority of GPU tasks.
I see no reason to abandon computing CPU tasks, if there is a quite simple way to minimize their effect(or other programs, if it's not a dedicated host for computing) on GPU tasks.