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.
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.
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.
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.
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.
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 problemin the wrongassessment ofthe duration ofthe work-overestimatedforGPUjobsandunderestimated for the CPU jobs.As a result,the client downloadstoo muchCPUjobsand too littleof the GPU jobs.
Butthis thingcan not be correctedby the user,it should be theadministration of the project change and tweak some settings. Small work cache and aborting some of CPU WUs is just a workaround.
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).
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.
shauge wrote:it did not start
)
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.
archae86 wrote:shauge
)
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.
shauge wrote:archae86
)
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.
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
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.
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:
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.
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).
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.