Folding Forum

I really really really don't think this is a fahclient issue. FAH does not develop windows scheduler. Giving fahcores above normal priority is bad idea, as computer will become unresponsive. Whatever is messed up on ARM windows, is ARM windows issue, and not FAH issue That's exactly how Windows sch...

muziqaz wrote: ↑Sat Jan 17, 2026 12:10 pm today's PR people don't know how to count past FP8

FP8 is so outdated. Everyone knows FP4 is most important

Since my mind reading is strong this year, I guess you have a CPU folding, while your GPU of some kind is not getting any work. My own mind reading suggests me that this user complains about next consecutive work unit being stuck on "assign wait". I might be very wrong though :D Swooferfa...

That's really impressive! I didn't expect E-cores to perform so much better.

I think it would still be more productive to run a 6 thread WU on P-cores and a 4 thread WU on E-cores, but you will actually get less PPD with this setup because of how points system is designed.

foxpy wrote: ↑Sun Dec 14, 2025 2:58 pm It is not hard to check again

I should probably take my words back then

I ran a few quick tests (5-10 frames) using 6, 8, and 10 cores on the same WU. 10 cores was consistently about 20% faster per frame than 6 cores, with 8 cores about half way in between (possibly a bit closer in speed to 1the 10 -core run). I certainly wouldn't want to draw any firm conclusions from...

Good idea. I tested it BRIEFLY, and based on a very small sample of 10 frames in one WU, 6 CPUs took about 20% longer to fold than using all 10 CPUs in the same WU. I'm going to let it run until the end on 6 and see if the time moderates with a larger sample. I wonder: has anyone has done a more ca...

Yeah, the worst thing for FAH is folding on more threads than physically available, your issue was 10 threads crammed into 4 CPUs, leading to almost zero PPD. Glad to hear it works well on your side now! You might also want to benchmark and compare how well 6 threads perform V/s 10 threads. E-cores ...

Windows really likes to schedule background jobs on smaller CPUs. FAH has a fix for MacOS, where is asks MacOS to run stuff on big CPUs, but there is unfortunately nothing like that for Windows. Simply setting thread count to 6 (like in MacOS) won't suffice, you will have to install Process Lasso an...

Not a complaint, just an observation from a WU I had to dump: 16781 had a TPF of nearly 40 minutes and resource utilization was low, indicating that it's not particularly efficient on this GPU compared to other projects of similar atom count and number of steps. I'm sure it will fold with ease when...

Well, it is not quite like NUMA. Yes, synchronization across CCDs can be expensive, but memory access speed should be uniform, if I understand it correctly?

When I pin all threads but one to a single core, the remaining thread drops to around 70%. I believe that is because it exceeds the limit of the load balancer. I'll check the source code to make sure, but I don't think it is using spinlocks. Maybe it doesn't use spinlocks indeed, but still somethin...

Sadly I don't have a Linux machine to test it right now, but try running a WU with 4 threads, and pin them in the following configuration: thread 0 - cpu 0 thread 1 - cpu 1 thread 2 - cpu 2 thread 3 - cpu 2 You will quickly notice that threads 0 and 1 still keep using 100% of CPU time, although comm...

Well, it definitely uses a mutex under the hood for something, but the main question I have: if the quicker threads slow down (which they definitely do, I agree), why do they still run 100% of the time instead of sleeping on a mutex?

The biggest issue in my eyes is that GROMACS threads for some reason just sit in infinite busy poll and wait until all threads finish their slice of work, instead of yielding and waiting on e.g. a mutex. This design choice denies slower threads a chance to access a free/quicker CPU and finish job fa...