How to assign just 1 cpu to 2 GPU's if possible.

Greg_BE
Greg_BE
Joined: 15 Aug 08
Posts: 90
Credit: 104,689,972
RAC: 24,186
Topic 225728

I have multiple projects running that use all my cpu's.

At the moment, all 16 are in use by other projects and .144 cpu is being used to control 1 gpu for prime grid.

How do I write a "script" to just use 15 cpu's for CPU projects and 1 cpu to control both GPU's if that is possible?
It appears this project uses .9 cpu's and prime grid uses .144.

I've looked at some BOINC threads, but it not clear to me if by limiting cpu's to 15 if I would kill 1 cpu core from being used by BOINC or if I would still have 16 being used and 15 for CPU projects and 1 for GPU control?

Harri Liljeroos
Harri Liljeroos
Joined: 10 Dec 05
Posts: 4,192
Credit: 3,112,317,077
RAC: 1,821,576

You can use a file called

You can use a file called app_config.xml where you specify how much each application uses your CPU and GPU. The file is placed in the project data folder for each project you want to apply it. Here is a forum topic about it: https://einsteinathome.org/content/appconfigxml-2. The last post in that thread gives you a link to the manual for it.

Greg_BE
Greg_BE
Joined: 15 Aug 08
Posts: 90
Credit: 104,689,972
RAC: 24,186

I already have app_config for

I already have app_config for some other stuff.

What I am getting at is more general.

How to tell BOINC to use 15 cores for CPU projects and 1 core for GPU control.

Not related to any particular app.

So I want 1 core to work both GPU's which run Prime and Einstein and also Amicable Numbers  and 15 cores for the rest, (Rosetta, WCG, LHC (Atlas).

So 3 GPU projects and 3 CPU only projects.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,870
Credit: 115,841,808,379
RAC: 35,409,474

In your thread title, you ask

In your thread title, you ask about 'assigning' 1 CPU to 2 GPU tasks.  You cannot assign - rather you create a budget for BOINC to use when it decides what mix of tasks to run so as not to over-allocate the available resources.

The thing that's really important to remember is that any GPU task will probably need some level of support and you shouldn't try to force it to take more or less than it actually uses.  Project supplied values are only estimates and may be wildly inappropriate values to use, depending on individual circumstances.  They absolutely can't account for complicated project mixes.

Also how frequently the resource needs occur (and the latency in servicing them) can have a dramatic effect on GPU task performance.  In simple terms, if a GPU task has to 'fight for access', its performance could suffer really, really dramatically.

Greg_BE wrote:
I have multiple projects running that use all my cpu's.

If you haven't already done so, you should find out for yourself, exactly what you will lose in GPU task performance by running CPU tasks on all threads.  It's very easy to do.  Just suspend all CPU tasks on board and allow just a single GPU task to run (choosing just one - suspend all others) so you find the absolute best possible crunch time for that type of task with nothing else competing.  Rinse and repeat for each different type of GPU task.

Then do exactly the same again but with all 16 CPU threads running CPU tasks.  When you finish that, you will have a very good idea of what you will lose in GPU performance in the worst case scenario of all CPU threads being fully used.  Since you state that you always run all cores, you've pretty much done this test already.

If you were really keen to optimise performance, you could rinse and repeat with 15, 14, 13, etc. threads running to see where the optimum mix between CPU output and GPU output really was.  When you have found that number, you can set it by changing the % of cores BOINC is allowed to use.  For example, if you found the optimum conditions were with 13 CPU tasks running, you would just set BOINC's % of cores allowed to something like 82% (anything above 81.25% but not as high as 87.5% which would only reserve 2 cores).  I suspect that optimum conditions might be with more CPU cores reserved than the 3 in the example.

Alternatively, you could have an independent (but much more complicated) method of control if you decided to use the app_config.xml method that Harri has pointed you towards.  If you have several different GPU projects, that could be quite difficult to get right, since each one would need a carefully thought out app_config.xml file of its own.

Because you have such a complicated mix of projects to run, and your own particular hardware mix to run them on, nobody will be able to give you any sort of accurate answer.  You have to work out the best solution for your particular circumstances.

Greg_BE wrote:
At the moment, all 16 are in use by other projects and .144 cpu is being used to control 1 gpu for prime grid.

With 16 CPU tasks running, the GPU task is having to fight for what it needs.  There is no magic cavity somewhere with 0.144 CPUs sitting and waiting, ready to go.  When the GPU needs CPU support, it will be the OS (not BOINC or the magic cavity) that will supply it.  There will be a queue and that queue will likely be lengthy because all CPUs are heavily in use all the time.  This is precisely why you need to do the experiments to see what you will lose by joining a long queue.

You need to realise that if all your 0.144 CPUs (or other fractional values in play at the time) don't add up to a full core, they may as well not be there at all.  BOINC will still run the full number of CPU tasks allowed, even if all these fractional budgets added up to 0.999 CPUs.

Fractional budgets are pretty useless.  You really need to see for yourself what you lose if you don't have BOINC reserve a full thread even if the budget claims that 0.144 (or 0.9) is all that is needed.

Please also realise that your machine has 8 cores (16 threads).  That means you already have 2 CPU tasks fighting each other for access to a single core.  That may be very beneficial if each competing task needs different parts of the core.  That's probably much less likely if tasks are from the same project and both running the same sort of high intensity number crunching.  So a GPU task may be quite hampered in getting access in a timely manner when it needs to.


Greg_BE wrote:
It appears this project uses .9 cpu's and prime grid uses .144.

Nvidia owners have repeatedly noted on these boards and for quite a while that an nvidia GPU task actually needs significantly more than a full thread and that if it's not immediately available, performance does suffer.

You have two GTX 1080 GPUs (according to the website).  I looked at some crunch times, many were several hours (many examples in the 2-4 hour range) which is absolutely woeful compared to what that hardware could do if it had proper CPU support.

Do the first basic test listed above and give yourself quite a shock as to what the proper crunch times could be.

Cheers,
Gary.

Greg_BE
Greg_BE
Joined: 15 Aug 08
Posts: 90
Credit: 104,689,972
RAC: 24,186

Thanks Gary!That's really

Thanks Gary!

That's really good info.

The GPU's are a 1050 and a 1080. I had to replace the CPU as I burned up the last one on a fixed OC frequency and ran it 24/7 at max temp. So my profile is a bit confusing.

If I understand your information, I could limit the threads/cores that BOINC uses by lowering the percent? And this would allow the system to dedicate a thread/core to the GPU's?

Actually it looks like Rosetta is using the most threads. So I'll try a limiter there in app_config.

For now I will try an app_config in Rosetta limiting it to 13 tasks/threads.

This is allowing the second GPU to start working and WCG to run.
I forgot to mention that the GPU's are also working on FAH so this probably sucks some power out of BOINC GPU crunching. I'll lower the usage there.

Tom M
Tom M
Joined: 2 Feb 06
Posts: 6,258
Credit: 8,913,663,658
RAC: 10,405,323

Greg_BE wrote:If I

Greg_BE wrote:

If I understand your information, I could limit the threads/cores that BOINC uses by lowering the percent? And this would allow the system to dedicate a thread/core to the GPU's?

I usually set my CPU % to 87.5 with 100 % usage for my 8c/16t cpus.   I have a 2700x, 3950x, and another CPU.

And lower the CPU threads total for all projects to at least 1 thread lower.

In your case, I would guess you want to run no more than 13 cpu threads.

Tom M

 

A Proud member of the O.F.A.  (Old Farts Association).  Be well, do good work, and keep in touch.® (Garrison Keillor)

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5,870
Credit: 115,841,808,379
RAC: 35,409,474

Greg_BE wrote:The GPU's are a

Greg_BE wrote:
The GPU's are a 1050 and a 1080.

OK, I guess that's why I saw some tasks taking over 12ksecs and others taking a lot less.  I hadn't previously looked at any individual logs for returned tasks so I now had a look to be sure that big difference was largely due to the different GPUs.

Yes it was.  I saw this task taking close to 13ksecs on a 1050 Ti, whilst this other task taking 6700ksecs was on the 1080.  The interesting thing is that those logs now contain extra info at the end that I don't recall seeing before.  There are time stamps that show exactly how long the follow up stage at the end takes.  In addition, there are reports of "peak RAM usage" and "peak VRAM usage".  In both cases, the RAM usage was reported as "-1.0 MB" and the peak VRAM was reported as "871.4 MB".  Obviously the first value is bogus and since the second one was identical with different tasks on different GPUs, it makes you wonder as to how reliable/accurate that information might be.

Greg_BE wrote:
If I understand your information, I could limit the threads/cores that BOINC uses by lowering the percent?

Yes.  It limits the total number of CPU tasks running.

Greg_BE wrote:
And this would allow the system to dedicate a thread/core to the GPU's?

No.  The "system" that will decide what to do with any available thread is still the OS itself which will just allocate those resources as it sees fit.

Sure, the GPU tasks will get better access (and will run faster), but there will still be a queue - hopefully a lot less restrictive than before.  You still have a CPU thread that is accessing the same underlying bit of hardware so it won't be unfettered access.  I know I'm a broken record, but the only way to know the optimum conditions for sure, is to run the experiments and find out for your particular setup.  Be conservative in what you try to run.  Less is often more :-).

Greg_BE wrote:
Actually it looks like Rosetta is using the most threads. So I'll try a limiter there in app_config.

Just remember that if you limit just one project, and the CPU threads released are still available to BOINC, the client will just pick different CPU projects to use them.  If you limit BOINC itself to a maximum number of threads running CPU tasks, the resource shares you have set will have a better chance of working and you wont be setting targets that make it difficult for the client to work as it's programmed to do.  Sometimes, external settings that seem innocent enough can actually cause the client to screw up.
 

Cheers,
Gary.

Tom M
Tom M
Joined: 2 Feb 06
Posts: 6,258
Credit: 8,913,663,658
RAC: 10,405,323

The thing that I am confident

The thing that I am confident of and have substantial experience with is that running 100% of the available CPU threads (for CPU tasks or GPU tasks) slows your total production down.

If you "free" 2 CPU threads so that no BOINC task uses them your over-all production is most likely to go up.

I am assuming you have an 8c/16t cpu.  So I proposed the 87.5% for the number of CPU threads would keep 2 free.

I usually manually limit the CPU processing tasks per project because there is no "globle way" (that I am aware of) to do that cross project. This means the gpus always have access to cpu threads (if I do the total cpu task thread count right).

This means that if one of your projects runs "dry" the unused threads are not automatically taken up by the other cpu task projects.

As Gary has said experimenting is the only way to know for sure.

Baseline: Free at least 1 CPU thread (probably 2) to allow CPU to have time to take care of non-BOINC processes and (probably) run the BOINC processing faster.

2) After running the baseline for a while make one change at a time (going from lower eg 1 to higher eg 2,3,4) and give your system time to show you how it reacts to the changes.

It could very well be that you would be perfectly happy with the results of the baseline (freeing 1 or 2 CPU threads) and will leave everything else alone.

Tom M

 

 

A Proud member of the O.F.A.  (Old Farts Association).  Be well, do good work, and keep in touch.® (Garrison Keillor)

Comment viewing options

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