Core a7 and resource usage problem.

[FrancoV78]

Hello.
I encountered a problem with the core a7. After starting the viewer and I don't know exactly if the problem arose when it closed, I noticed that the core a7 no longer correctly uses all the resources as before and in fact there has been a significant increase in the estimated time for the end of the work . As you can see from the image in the link https://ibb.co/L1bNyLp the core a7 uses only 6.5% when the use of the cpu is at 17% and is set to use 19 threads.
Sincerely.

[FrancoV78]

I understood by myself. The a7 core is doing without you knowing about the work units set for the single processor core, so it uses the single thread to do them because now I have hyper-threading enabled. So all right.
Best regards yet.

[JimboPalmer]

You do NOT want 19 slots of 1 thread each. Get rid of those slots as you can.

Build a slot with 16 'CPUs' and a slot with 3 'CPUs'.
See if that does not perform MUCH better.

(F@H 'hates large primes, 16 is not prime, and 3 is not large)

[FrancoV78]

Hello.
I've already got rid of it. I have 19 threads for the cpu and 1 for the gpu and I like it.
I believe that there is something wrong with software. Because normally when I activate only one work unit with 19 threads with hyper-threading active and the job is not finished, but I remove the cpu for reason of change of configuration from "Configure client folding slots" the work unit even if not finished is canceled. In practice I had added 8 single-core work units with hyper-threading disabled. Then I restarted with active hyper-threading and set up a work unit with 19 threads, deleting the cpus set to 1 that were paused from the "Configure client folding slots" menu but the work to be done remained as it should not happen.
My version of the software is 7.4.4 and I don't think there is a correction of this kind in 7.5.1.

[Joe_H]

WU's downloaded for a certain CPU setting will not run at a higher setting. They can be reduced in CPU thread count and then be returned to the original. But if you downloaded a number of WU's with the CPU slot set at 1 thread, they will not use any more than that.

WU's that can be processed by another existing slot will not be deleted.

This is not a bug, and is inherent in the WU's as downloaded from the current versions of the WS software. The client setting can not override the setting that come from the WS. It is strongly recommended that you upgrade if possible to the current client, there are a number of other fixes and settings built into it that reflect many changes made in the years since 7.4.4 was released.

[FrancoV78]

You advised me to update the software version. I have already tried 7.5.1 and the link where "project" is written that displays the web page of the work in progress no longer worked.
I kept this version because I saw that the corrected bugs were not for Windows but for other operating systems, if I'm not mistaken there was nothing important for Windows and the software cores that are very important are still updated to the latest version too in 7.4.4.

[JimboPalmer]

7.5.1 does do a better job of avoiding large primes like 19 CPUs. It does so by ignoring 3 CPU threads. My advice (which works on 7.4.4 and 7.5.1) also avoids large primes and uses all 19 available CPU threads.

It will produce more science for F@H, and more points for you.

[Joe_H]

Which link to "Project" are you saying does no work? It may have been fixed long ago as they finished setting up the servers through foldingathome.org instead of most being at Stanford. The older 7.4.4 client only works because of redirects from the old stanford.edu sites that will not be in place forever.

As for the corrected bugs, there are a long list of ones for Windows that were fixed as well. To see them all would take going through all of the release notes for the intervening beta test releases between 7.4.4 and 7.5.1 and reading the change logs.

[bruce]

The GROMACS software which is used in FAHCore_a7 does have a number of limitations to how CPUs can be allocated. Two of those limitations is that you cannot arbitrarily allocate large prime number of CPUs (such as 19) and you cannot INCREASE the number of CPUs beyond the value that is in effect when the WU is downloaded.

Suppose you have allocated, say 9 slots with 2 CPUs each for a total of 18 CPUs, FAH will download WUs that are designed to run on slots with 2 CPUs or less each. If you later modify the number of WUs allocated to say 1 slot with 18 CPUs, you will still have WUs that are designed to run with a maximum of 2 CPUs and they will continue to use 2 CPUs (or you could migrate that WU to a slot that uses only 1 CPU). If you download a WU into a slot with 19 CPUs, you will receive a single assignment which can run with UP TO 18 CPUs. (Since 19 is a large prime number, there are no WUs which are designed to run with 19 CPUs so FAH reduces that allocation to 18.) (A WU that is designed to run with 2 CPUs will likely fail if you happen to migrate it to a slot with 18 CPUs.)

I recommend you allocate as few as possible slots with larger numbers of CPUs that have factors of (2**M * 3**N) for your choice of M and N and leave those allocations alone.

Please post the segment of FAH's log showing the slot allocation when the WU 14175 (0,50,26) was downloaded and any modifications you made to that slot AFTER it was downloaded.

These limitations were designed specifically to avoid processing failures of WUs with numbers of CPUs which are known to be failure-prone. A WU designed to run on 2 CPUs be assigned if

[FrancoV78]

Yes, exactly Bruce. I noticed the mistake, I didn't realize that 19 was a prime number. Now I have assigned 18 threads to the cpu and 1 threads to the gpu.

[FrancoV78]

I could do two slots for the CPU. So one of 10 threads and one of 9 threads for the cpu and make a 1 threads slot for the gpu. But I still have to prove how useful the operating system is in this way. Now I let the work on the work units finish.

[FrancoV78]

I configured the 20 threads this way. 9 threads for one work unit and 10 for another work unit and 1 threads for the gpu. Monitoring with gpu-z the GPU works perfectly. The "Advenced Control" interface only becomes unresponsive. While with the "Web Control" interface there is absolutely no problem.
Software version used, 7.5.1.
However I used 19 threads for the cpu and 1 for the gpu because at the first launch of the program it automatically configured itself with this configuration and I didn't realize how I already said that 19 was a prime number.
Greetings.