Multiple BOINC clients on a host: Projects which DON'T work with it

[StefanR5R]

So, there can be several boinc-client instances running on the same host, provided each instance has its own data directory and its own remote GUI control port. (And some more requirements.)

Here are projects which are not compatible with such a setup:

• GPUGrid collapses all the instances into a single host. As soon as tasks are fetched in instance 2, the tasks in instance 1 are marked as "abandoned".

• There are one or more other projects which behave like GPUGrid. Maybe you know some that I don't recall right now. You can detect this kind of project this way: When you add another client instance to the project, you don't see another host added to your hosts list at the project's web site.

• Cosmology@Home's vboxwrapper based camb_boinc2docker tasks get stuck in "postponed: VM Hypervisor failed to enter an online state in a timely fashion" if there is another boinc-client instance on the same host starting jobs in whatever other project. (Seen when trying to run Cosmo in instance 1 and MindModeling in instance 2.)
  
  If memory doesn't deceive me, LHC@Home's vboxwrapper based applications are similarly wonky.
  
  Edit: camb_boinc2docker also fails if MindModeling runs in the same client instance. I have not yet tried to reproduce the multi-client problem with other projects. Maybe there was no multiple-instance problem with vboxwrapper after all.

 

[crashtech]

So far, I have not judged myself in enough command of BOINC to hazard more than one instance, though this may be the year when I do. It's certainly a worthwhile topic. I wonder what tips the non-compatible apps off? Could it be something as simple as a MAC address? How about running the second instance in a VM?

 

[GLeeM]

WUProp@Home won't run in a second instance if you also have NCIGoofy running in both instances.

A second instance really helps with FB Sprints.

Now I am using them to try to get WUs for Xansons, Acoustics, CAS, MindModeling and DrugDiscovery by using StefanR5Rs update script. With nothing running in the instance I don't get "Not requesting tasks: don't need" messages.

Well, I do have NCIGoofy running.

 

[[H]Coleslaw]

I don't know if he is still doing it, but WUProp was cutting your runtime hours for all projects based on the number of multiple clients you were running as well. There were a thread or two in their forums complaining about it. Here is my how-to thread for running Goofy work. https://hardforum.com/threads/goofyxgrid-multi-client-setup.1924298/ It was made when they first launched, before they became GCC and before they went back to the Goofy name and split into 2 projects.

Since BOINC.exe has a hard limit of ~1,000 running tasks, you can load up a number of multiple clients based on how many applications the projects you are running provides. For example, at Goofy's NCI project they have 4 applications. So, you would run up to 250 clients if you ran all four. If you just run one application, you could run up to 1,000 clients. On XP (32 bit) we seemed to have a limit around the 100 client limit.

I have much better luck running them outside of the VM's. However, running them inside the VM's cuts down on the whole system getting screwy or locking up due to over taxing it. It is a lot easier to kill the VM.... Also, if your system is beefy enough, you can do the multiple clients on multiple VM's since they are all considered a host.

 

[StefanR5R]

World Community Grid's

• Microbiome Immunity Project, Windows version,

fails with high probability right after the start of each task due to a shared memory allocation problem if it is run in more than one client instance:

Turns out MIP's problem wasn't particularly with my host, but with how I used it. The shared memory allocation error happens when I try to run MIP in more than one client instance at a time. If only one client instance runs MIP, it works. It may furthermore be dependent on the number of client instances active, or on the timing between starting jobs in different instances. (The problem does not exist on Linux.)

 

[StefanR5R]

SZTAKI Desktop Grid collapses all instances into a single host. (Same behavior as GPUGrid.)

 

[StefanR5R]

Yoyo@home collapses client instances from the same host into a single host instance too. (Almost forgot to make a note here.)

 

[StefanR5R]

QuChemPedIA...

...actually works OK with multiple instances, but with a catch: The Linux application¹ uses OpenMPI for inter-thread communication (even if you run it in single-threaded mode), which allocates a TCP port number in the five-digits range.

Now, if you start a new boinc-client instance with a custom TCP port number for the GUI, that may occasionally collide with the port number choice of a currently running QuChemPedIA task. The client will exit shortly after the attempted start and leave something like this in its log: "GUI RPC bind to port 40006 failed: 98"

To work around this, either start all necessary client instances before you start QuChem, or temporarily suspend QuChem in order to start a new client instance, or just use a different port number for the client instance.

----------------
¹) Perhaps the Windows application does so too, but there the worker is wrapped away into a virtual machine, therefore does not interfere with TCP ports on the hypervisor system.