Question about how CPU work units are assigned

[mwroggenbuck]

I run my computer with one slot of 16 threads. It seemed to work fine for quite some time. However, over the last couple of days, I frequently get "No WUs available for this configuration" for hours at a time. When I do get an assignment, the server will usually drop the number of threads from 16 to 9 for that WU.

Do the servers assign different projects to clients with a bigger (or smaller) number of threads? Would I be better off creating two 8 thread slots? Is there some shortage of CPU WUs?

[JimboPalmer]

Would I be better off creating two 8 thread slots?

[I am just a user like you, this is unoffical but quicker]

Almost never. Since F@H assigns points based on how quickly a WU is returned, one slot with all your CPU threads is 'best'. (Windows has issues with more than 32 threads, so multiple slots may be needed if you have more than 32 threads and run Windows)

The rules to which CPUs get which WUs are both arcane and undocumented. Every time someone discovers a repeated pattern of "this CPU (or GPU) dislikes this family of WUs", the 'best' solution is to block that CPU (or GPU) from downloading that WU series. So there is a semi-infinite list of exceptions.

[Neil-B]

I have seen a few recent comments here and on discord ... my guess is that the current general availability wus for cpus have limits on certain core counts - and so it may just be a bit of a lean period for cpu wus ... having said that my 24 and 32 slots are not being impacted so there should be some more projects coming out of beta that aren't restricted to smaller core counts ... if I were you I wouldn't alter your setup - shortages that lead to AS allocating lower core count wus are relatively rare and short lived so you should be back to full load soon.

[bruce]

The rules are not documented AND they're different for FAHCore_a7 and for FAHCore_a8.

For a number of years, assignments to "large prime numbers of cores" was avoided because they had high failure rates. FAH attempted to block assignments to 7, 11, 13, 17, 19, 23... but alternate values were worked out so that if you happened to have a slot with 13 cores, the server would assign a WU with 12 cores. Other reassignments were complex. These external rules still apply to FAHCore_a7.

With the advent of FAHCore_a8, the management of core counts was moved internal to that FAHCore, itself and it does a much better job of assigning WUs with lower failure rates.

There's also some practical considerations based on the atom-count in the protein. Most small proteins are inefficient when running with large numbers of threads so such assignments are often avoided when possible. I have not figured out the differences between FAHCore_a7 and *_a8 yet.

During the internal testing that is done before a new project is released to beta-testing or even sometimes during beta-testing events are discovered that lead to specific restrictions when the project is ready for a full release. If you decide to reduce the number of threads of a particular project after it has been assigned, you may encounter conditions that are known to be troublesome so it is still possible for you to increase the probability of a WU crashing, resulting it zero points and producing project delays, so do so at your own risk.

[mwroggenbuck]

I appreciate all the comments. Things have been going better recently. I don't have to wait for WUs. The a8 jobs I get seem to want to reduce the number of threads, but these jobs are so short it really does not matter. I was mostly curious if assignment would be more regular if I went to two slots versus one slot. Sounds like that is not the case, and that what I was seeing was transitory. I am still using one slot of 16 threads.