Assign Wait

[calxalot]

If you have a cpu WU running, please consider setting Finish and set cpus zero after the work uploads.

[arisu]

Speed of the CPU is not an issue. People assigning 1-2 CPUs to a GPU is an issue

It seems like there are a lot of issues with the way resources are handled in v8. I get that it's supposed to theoretically allow more complexity but it also allows weird and inefficient configurations like several CPU WUs on a single machine, GPU WUs sharing hardware threads with CPU WUs, multiple hardware threads for a single GPU like you pointed out etc. One might say that it's useful for obscure configurations, but regular users are being told that the proper way to pause individual WUs is to enable resource groups and open themselves up to the extra complexity and bugs.

The extra complexity adds more possible machine state which makes it harder to find and fix bugs too. I am working right now on a nasty bug where, if a GPU WU has no assignments, then when the next CPU WU finishes, it doesn't bring the number of free CPUs back to the maximum. So instead of asking the WS for "anything for $mygpu or $mycpu with 16 threads" it continues to ask "anything for $mygpu or $mycpu with 0 threads".

I know it won't be possible, but I wish the entire concept of resource groups got axed and replaced with something simpler. Just allow selecting (max) number of hardware threads, enable or disable various GPUs, and let the client deal with it from there. But I know that it's intentional not to allow pausing individual WUs within a resource group so there's no real point in bringing that up on GitHub anyway. So the extra complexity is by design unfortunately.

[calxalot]

Originally, there were no resource groups and the client and server were supposed to work out the optimal use of allocated resources.

There was also a hope to support future cores that could use both CPUs and gpus on the same WU.

Resource groups were created because of bugs and a desire for more control by some users.

[calxalot]

The pause and finish flags are on the group, which I think is the only reason individual WUs cannot be paused.

[arisu]

Resource groups were created because of bugs and a desire for more control by some users.

That extra control comes with a lot of pitfalls that the average user will succumb to. That's fine if it's an "advanced" feature for people who know what they are doing, but it is also the only way to change the state of individual WUs (pause, unpause, finish etc). So users who want to have a standard amount of control are forced to use a configuration that has many pitfalls that cause confusion for them.

Sadly the inability to pause and unpause individual WUs is "by design" so there's no point in making a PR.

[calxalot]

v7 had slots, which also confused people.

Please feel free to propose a new design.

[arisu]

I think that adding the ability to pause and unpause individual WUs would fix the majority of problems, freeing up resource groups to be used by people who know what they're doing and letting almost everyone do what they need with the default resource group. But like I said, that's "by design" apparently.

[calxalot]

Inability to control state of individual units I would argue are not by design but are an artifact of historical design mutation.

[calxalot]

Hidden groups managed by the client could be the simplest alternative.

[arisu]

Inability to control state of individual units I would argue are not by design but are an artifact of historical design mutation.

https://github.com/FoldingAtHome/fah-cl ... issues/300

Here is where it ways said to be intentional. The proposed solution was to enable resource groups and to keep in mind information that the average user should never need to know. If the issue was kept open and the response was just "submit a PR if you want this" that would be acceptable and I don't expect a single busy dev to treat every request as a priority, but it was closed as by design.

Hidden groups managed by the client could be the simplest alternative.

I thought that's essentially what it does? Or maybe I misunderstand.

[calxalot]

There is only the default group “” by default.
Extra groups are exclusively created by the user.

[muziqaz]

All GPU assignments have min cpus 0, max 1.
So it should work.
There has been a recent report of this no longer working. It is possible you need to use a separate resource group for GPU folding with no CPUs. Or there could be a configuration problem on servers.

Do GPU projects have CPU thread count related constraints? I never seen it, unless it is globally set by Joe, and not researchers.

[muziqaz]

It should have been disabled.
Joe, I pushed for that
Problem is that a lot of people who switched to v8 and read the client's install guide interpreted guidance wrong and gave GPU slots 1 or 2 CPU threads, instead of leave them free. For some reason client fails a CPU WU if it is downloaded that way.
This weekend I will try reproducing the issue, and see if the restrictions can be removed for at least 2 threads.

I think I'm being bitten by this. I set 2 CPU threads so that I could GPU fold. Should I have not done this? What was the correct setting to only GPU fold on my discrete graphics card? My CPU isn't worth folding on, what setting should have I used to only GPU fold? I'm confused.

GPU wants a free CPU thread, it does not need to be assigned to it though, as long as nothing uses that one thread/core, GPU is happy. CPU slider should be set to zero, unless you want to fold on the CPU

[kwerboom]

Just an update. I set the CPU slider to zero and F@H started working correctly again. I'm happy again.

As a side note, could somebody please update the F@H Ver. 8 Guide or FAQ? Somewhere it really needs to explicitly state for GPU Only Folding that the CPU slider should be set to zero. It should also be more clearly stated that one shouldn't GPU Fold while doing tasks that put 100% on the CPU and that setting the CPU slider to one doesn't reserve a thread for GPU Folding. The CPU slider is only for CPU Folding. Just a though. Thanks.

[arisu]

Just an update. I set the CPU slider to zero and F@H started working correctly again. I'm happy again.

As a side note, could somebody please update the F@H Ver. 8 Guide or FAQ? Somewhere it really needs to explicitly state for GPU Only Folding that the CPU slider should be set to zero. It should also be more clearly stated that one shouldn't GPU Fold while doing tasks that put 100% on the CPU and that setting the CPU slider to one doesn't reserve a thread for GPU Folding. The CPU slider is only for CPU Folding. Just a though. Thanks.

Not only in the guide, but in the info dialog in the v8 web client itself. The info box recommends that people folding on GPUs should leave aside a few CPUs which could be interpreted as enabling a few CPUs.