Theres a message in boinc that says it has reached the limit of tasks in progress. Anyway, what do you need 1000 work unit buffer for? Unnecessary. Reduce your buffer to 0.5 or 1 day instead of 2 or more, problem solved.

I receive a maximum of 50 tasks for pc. This doesn't last long with 2 x Radeon VII's in one pc.
My slower pc's with the Vega 56's and 280X have no issues with keeping work up to them. Currently they all have 50 GPU wu's to complete. Both of the 16 core threadrippers have now run out of GPU work and are sitting idle :(

I've now changed my WCG setting to stop using the CPU. This should start chewing through the 1000 CPU tasks and I imagine will start filling up the GPU work again.

Work is calling... better go. Have a good day/night all.

The statement of keeping the GPU tasks as close to the CPU tasks is correct. This helps in multiple ways. It allows us to verify that things are working as they should without adding too many variables to the mix. These work units use the same method of starting and stopping each job (ligand) in the workunit. All that was modified in the way they were generated was I said assume it's allowed to run 20x longer than CPU. Not much else changed beyond that. Keeping the pipelines from the researchers to us and then to you similar allows for us to decrease the number of variables that we introduce into the equation of differences.

Yes, there are differences in the GPU code that is not the same as CPU, but these were vetted and tested by the researchers before we took the application to grid enable it. There are multiple options that we are in discussions with the researchers about. How long it'll take to get those implemented from the WCG end is unknown. I can not promise when an updated version will be released.

We have heard members commenting on the GPU version using too much IO and other complaints, such as the polar opposite of it causing them to have issues on their displays...Some members commenting on bandwidth usage, etc...

The purpose of this stress test was to determine where some of the bottlenecks were in the system. We have heard the comments and suggestions about the application. We have made changes to our load balancer to help handle a lot more work units. We have identified that the small ligand files cause issues with the inodes of the filesystem filling up. All of these are stresses of the system. Some may be easily addressed, others take lots of time and effort. Releasing a new science application does not come easy and quickly as you would hope, this is distributed to thousands of people and needs to be properly vetted and tested. All of that is to say while supporting and running other application and trying to get some sleep in there.

This stress test has been very exciting for us and our team. We are in constant communication with the researchers and they are also very excited about the test so far. Thank you to everyone for your help on making this a successful test.

Please try to keep comments positive and helpful towards everyone in the forums and not combative. We try to make things run as best as they can, but we do not have unlimited resources.

Thanks,
-Uplinger

I did not do anything, waiting was the solution for me.


I did not check but most likely I did. In any case: above approach worked fine initially. It was only (some time) after starting to run multiple GPU units in parallel that I ran out of work. And then miraculously it was fixed again.

So. the only thing I can think of is that there is some kind of mechanism at server side which distributes work according to previously returned work. And that this mechanism initially did not take into account the GPU speed increase.

ah, his specific error looks to be the default 1000 task limit in BOINC. but there is still the 200 GPU task limit to contend with.

I just tried on my multi-GPU host with 200 already in progress, and I get a similar, but not exactly the same, response from the project.