Well DA may be happy that is the way it works, but the other developers have strongly commented that they are unhappy with the way it works now. Mentioned in the developers issues and also in the weekly conference call.

Whether DA ever gets around to fixing work_fetch will be the question. Probably will come to down to some of the other developers fixing the problem.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The way I read it, it means what DA says it means. Total number of tasks, including cached tasks. Why have cached tasks if it takes months to finish one task?
Anyway, it appears it now works the way DA wanted it to. At least the last time I read the thread. I wouldn't hold my breath.

Actually it is well documented and always has been. https://boinc.berkeley.edu/wiki/Client_configuration#Application_configuration
If you scroll down to the project-level configuration you will read the explanation and use of project_max_concurrent and max_concurrent options. Totally valid uses.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

That's because the max_concurrent was never meant to be used the way you were using it. It now works the way DA meant it to work. It was another one of those 'undocumented features' (BUG). He meant it to keep from having idle tasks in the cache, so, good luck getting him to change it back. I just found a few more 'undocumented features' on my ASUS board in the Hackintosh. Apparently it is impossible to run more than 4 NV GPUs in the 5 available slots. Also, if you try to use the iGPU with all 4 of the main slots filled, it kills the USB ports. Strange stuff. So, to use the iGPU I have to have 3 GPUs in the main slots and the 4th in the x4 slot. Then trying to run another NV GPU in the 4th main slot again kills all the USB ports. But, I can run a 5th GPU if it's an AMD card. Just a few more reasons the board was a refurb I suppose. It does have two M2 slots, but you would basically have to run All the cards on extenders to use the M2s as PCIe slots. Hmmm, at least the macOS runs the 4 main slots at Gen3 even when using a x1 cable, but, it treats the x4 slot as Gen1. Lots of undocumented features.

No the problem was evident on BOINC 7.8.3. Not tested on any of the newer BOINC's until much later in the debugging for Richard. I never checked whether it was evident on 7.4.44 but assume so since the work_fetch.cpp module didn't really have many changes between the two versions.

You can read about the issue in my OP https://setiathome.berkeley.edu/forum_thread.php?id=83645&postid=1969035

The gpu_exclude is what broke things. Always used a max_concurrent with no issues until I added the gpu_exclude. The bug is what prompted the massive rewrite for work_fetch and other modules for my #PR2918.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Well they made it compatible in the new build right? But they totally removed the “caching” behavior as a byproduct right? I guess that’ll have to be fixed again before you can use it the way you prefer.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

I like the use of max_concurrent too. Unfortunately I have been forced to abandon it since it is incompatible with gpu_exclude statements required for Turing cards at GPUGrid. Doing so forces all cpu task into "waiting to run"

Now I have to limit the number of cpu tasks via the cpu % in local preferences.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Thats why I stiked it out, and more or less what I was hinting at with my correction. He’s stated in the past (and can be verified by looking at his task info) that he’s using -nobs. We all know that forces 100% use of the core. So for 9 GPUs, that’s 22.5% CPU use from GPU jobs alone (because 40 core system). Where as far as boinc is concerned, he’s using less so it runs more CPU jobs than it should be. BOINC just doing what it’s told.

If he intends to use a full CPU core for GPU jobs by running -nobs, then it’s probably best that he configure it in such a way that BOINC accounts for that.

I like the control of just telling BOINC to use 100% and manually limiting it with project_max_concurrent. It works perfectly for me. But everyone has their own preferences *shrug*

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

EDIT: that might not be completely correct. it might be a strange interaction happening when using the -nobs option (which forces full CPU core use) with the 0.1 CPUs option which is telling it to not use so much. I really am not sure

No, it isn't 'exactly' correct. The reason he pegged the CPU is his GPUs are using much more than 10% of the CPUs, and he only allotted 10% for the GPUs. The Correct way, the way BOINC/SETI has been using Forever, is to find the amount of CPU the System/GPUs require and then reserve that much with the "% of the processors" setting. That's WHY the %CPU setting Exists, and that settings has No Effect on the amount of CPU the GPUs use. But it will starve the GPUs if you don't set it correctly. The way it's been done for Years is to suspend all the CPU tasks so all that is running is the GPUs and System. The amount used when just running the GPUs and System is what you need to reserve in the %CPU setting. If it takes 30% to run the GPUs/System then the Max setting you should use is 70% CPU for the CPU tasks. If you want to use less then set the %CPU setting lower, that's why it exists. If you start messing with the <max_ncpus> setting you will screw up the task scheduling and complain about tasks not running when they should as that setting only affects scheduling and nothing else.

On My 12 GPU System without running any CPU tasks the System/GPUs are running around 50% of an i7-6700 without using nobs. That means the highest I could set the %CPU setting is around 50% or lower.

I have it set to 1 GPU per core.

There are 40 total “cores” in the system with 2x 10c/20t chips.

I have CPU % set to 100 in BOINC Compute preferences and use the project_max_concurrent flag in the app_config file to regulate how much CPU work is done.

So the argument to use with project_max_concurrent would be #GPUs + #CPUs. You also have a 40 thread system. 90% = 36 cores. 9 of that will be GPU Jobs so with <project_max_concurrent>36</project_max_concurrent> you’d end up with about the same as you’re doing now.

The reason you pegged the CPU with your 1GPU/0.1CPU setting is because that effectively told BOINC to use 10 CPUs per GPU and you ran out of resources with more than 4 GPUs.

EDIT: that might not be completely correct. it might be a strange interaction happening when using the -nobs option (which forces full CPU core use) with the 0.1 CPUs option which is telling it to not use so much. I really am not sure.

best to just use 1 GPU and 1 CPU so BOINC can properly allocate resources with how you are trying to use them.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

That is a question. Exactly how are you divvying up your cpu cores? 1 per gpu or less?

I have the task manager showing around 90%. And the % of cpus is set to 90% in the local Boinc Manager mode.
Right now the ratio is cpu to gpu is 1 to 1.

I have tried running the gpus at 1 gpu / 0.1 cpu and it caused the Task Manager to peg 100%.

Tom

---

"I owe", "I owe", "Its off to work I go" (from a bumper sticker on a smallish Mercedes Benz)
(on the back of a Semi Tractor) "If you can read this bumper sticker, I've LOST MY TRAILER!"

Looks like you’re stuck in limbo between 20/21 place. Since Vypers dual 2070 system is listed in both places lol.

You should pop up on the next update.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Great. I would try to put the slots back to gen 3. You’ll get some more speed out of it. Maybe around a 10% boost.

Hmmmm..... BRB....

Burp.... Bump.

Came right up. Unfortunately to get to 9 gpus I had to steal one from my Windows Amd 2700 box...

Maybe next month....

Now if the LeaderList would update. I am currently MIA on it.

Tom

---

"I owe", "I owe", "Its off to work I go" (from a bumper sticker on a smallish Mercedes Benz)
(on the back of a Semi Tractor) "If you can read this bumper sticker, I've LOST MY TRAILER!"

Great. I would try to put the slots back to gen 3. You’ll get some more speed out of it. Maybe around a 10% boost.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

I don't know if I want to laugh or cry. It just booted and is running 9 gpus again.

https://setiathome.berkeley.edu/show_host_detail.php?hostid=8676008

Tom

---

"I owe", "I owe", "Its off to work I go" (from a bumper sticker on a smallish Mercedes Benz)
(on the back of a Semi Tractor) "If you can read this bumper sticker, I've LOST MY TRAILER!"

No one is saying to put in a bigger hard drive.

Look at the link I posted. It has information about adding a kernel option to your grub config. This is what solved my problem with PCIe errors and having the hard drive fill up.

Start over. Fresh install 18.04, apply the fix I gave you, then try put the PCIe gen back to 3

I managed to install Lubuntu 18.04 accidentally before I went to bed earlier this morning. It was allowing 7 gpus.

I have applied the grub parameter fix. And have now had it come up with 8 gpus on Gen2.

THANK YOU for both the advice and the explanation for why my HD was "filling up".

It had run without quitting for 3+ hours when I added the grub parameter and took it back up to 8 gpus.

I think I will declare the rest of Friday a "day of rest" as far as this computer is concerned.

Tom

---

"I owe", "I owe", "Its off to work I go" (from a bumper sticker on a smallish Mercedes Benz)
(on the back of a Semi Tractor) "If you can read this bumper sticker, I've LOST MY TRAILER!"

No one is saying to put in a bigger hard drive.

Look at the link I posted. It has information about adding a kernel option to your grub config. This is what solved my problem with PCIe errors and having the hard drive fill up.

Start over. Fresh install 18.04, apply the fix I gave you, then try put the PCIe gen back to 3

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

Great information Ian. I now remember that post in the thread. Tom needs to investigate the system log for those kind of errors and then try your fix.

Unfortunately, the only OS (Lubuntu 16.x) I have been able to get to run 8 gpus lately also fills up my HD to the point where the Boinc complains about not having any space. This is a 250 GB hard drive so dropping in a 500 GB probably won't do any good. I have googled the Ubuntu advice and it doesn't clear enough space.

Ubuntu 16.4 won't install on the flash drive because of missing programs in the ISO.

When I re-installed with 18.4 it immediately went from an 8 gpu machine to a 5 gpu machine (at Gen 1) or 4 gpu machine (at Gen 2).

I am now fighting with the "dreaded logon loop" with Ubuntu 14.4.

Someone remind me "Linux is simpler and more reliable than windows" Hah!

Tom

---

"I owe", "I owe", "Its off to work I go" (from a bumper sticker on a smallish Mercedes Benz)
(on the back of a Semi Tractor) "If you can read this bumper sticker, I've LOST MY TRAILER!"

Great information Ian. I now remember that post in the thread. Tom needs to investigate the system log for those kind of errors and then try your fix.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

you dont want PCIe to gen 1. that is incredibly slow. and even worse with the risers since you are running only a single lane.

PCIe gen1 is 4x slower than PCIe gen3.

you want all your slots to run PCIe gen3 if you can.

I agree in principle. Prior to this situation I had some trouble (some kind of errors?) when running a smaller number of gpus at Gen3 on this MB.

The default on the MB is Gen2 anyway.

1) I need direction on the error message I posted.
2) So far, based on eye balling the times, the processing has not (yet) slowed down.

Tom

what errors were you getting exactly?

early on when setting up on my first multi GPU system for Seti on Linux, I also would get lots of PCIe errors when i ran gen3. my stopgap measure until i found the solution was to run gen2 (with a small performance hit).

once i found the problem, and fixed it, the issue went away completely.

see my comments and links and info in this post:
https://setiathome.berkeley.edu/forum_thread.php?id=83613&postid=1967880#1967880

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours