Project 18405: Completion Deadline; almost 100% CPU use.

[MarkH]

Hello friends,

Running an i7-series 8-core processor, and received 18405 (14,2,97). WU maxes out my laptop at almost 100%, with a completion time estimate of some 1.6 days (the original run time was 4.00 days (!). I cannot burn out this machine running maxed out and also unusable for daily work; how can I reject/abort this WU (should I just let it expire/time out instead?) , and is there any way to avoid certain WUs going forward? I can and have run other smaller jobs, but 18405 isn't an option. Thanks.

From the log file:
Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
14:52:30: CPU ID: GenuineIntel Family 6 Model 158 Stepping 9
14:52:30: CPUs: 8

Assigned: 2022-09-25T04:18:09Z
Timeout: 2022-09-29T04:18:09Z
Expiration: 2022-09-29T09:06:09Z

Thanks

[Joe_H]

Set your folding to fold on Light or go into FAHControl and set the CPU thread count to be used at 4. This project will not be assigned to 4 threads or less. It will still probably finish before the timeout, the extra processing from the 4 HT threads only reduces processing time by about 15-20%.

As for the initial estimate of 4 days, that is based on the timeout value. Until the client has processed a few percent its estimates will not be accurate on a project it has not downloaded before.

[MarkH]

Hi Joe_H. Thanks for your suggestions. I tried them and after about 2% of the WU completed, the completion time actually dropped to 12H: 55M...later it went back up to 23H:30M, and as of 9/27/2022 at 1959 Central Daylight Time it was at 16H:24M. This is on my daily-use machine; thought I'd have to eject the runaway Warp Core on this one. I think I've run 18405's before, but it might have been the first time I tried maxing out the CPUs to run overnight thinking it would run faster to make the original 4 day estimate. Hoo boy!

[Joe_H]

HT usage can be a bit hard to predict with folding. Each core for 2 threads has a single floating point unit and the F@h code is very heavy on use of FP. So when you use both threads each will have to give up some time to the other thread being processed. Then there is the overhead of calculating the forces between the groups of atoms being done in each thread with the other thread. In practice people testing this in the past saw about 10-20% improved throughput, but it was dependent on which project was being done.

The processing of threads for OS background processes and any foreground processing you are doing while using your computer tends to be more integer and logical unit bound than F@h. But they do cause some delays and synchronizing the slowest F@h thread to other ones cause them to be delayed as well. Personally I have ended up setting my systems to only use a number of threads equal to the number of cores, I leave the extra threads from HT to take care of the OS and my own use. Still see the F@h process slowed down, but not as much. In most cases my CPU is running a bit cooler and may be clocking a bit higher than if I used th HT threads for folding.