I hope to be able to restart the system with a new project at the beginning of August.

TN-Grid limits the total number of workunits per host (regardless of its core count) to help maximize the total output of the project by spreading the work between as many hosts as possible, regardless of their core counts. Hosts with large core conts finish work more frequently, thus they have better chance to download work during a shortage.

This means that your host can queue 33% more work than before the change.

That's no problem (both for you and for the project) provided that your host *always* have *some* work in its queue. As every workunit is a piece in a chain of 58 workunits, workunits that just sitting in a computer's queue holds back the completion of the entire chain. The more core a host have the more chains it can put on hold. The reason for limiting the total number of workunits is limiting the number of chains a host can put on hold, without reducing the host's througput.

BTW your hosts are a nice example to show why *not* to crunch on virtual cores:
Your 13 years old AMD Phenom II 1090T X6 CPU can finish a longer VV workunit in 13.100 seconds,
while your 4 year old AMD Ryzen 9 3900X CPU can finish the same workunit in 12.000 seconds. Of course, it can finish twice as much workunits under the same time than the older CPU (so it's RAC is higher), but I guess it could do the same amount of work (or even a little more) if you would limit the number of tasks to the number of cores (6). Depending on the extra cache misses the extra task per core inflict, the performance running limited number of tasks simultaneously can be better.

There are 600 chunks in the "normal" workunits (1-76), the last one has 400 chunks (judging by the ratio of their runtime).
If that's the case, there are 46000 chunks total (76*600=45600, 45600+400=46000).

46000|2 23000|2 11500|2 5750|2 2875|5 575|5 115|5 23|23 1|

It's not practical to double the number of chunks, as in this case the last workunit will be the half of the present ones.
I suggest to have 1000 chunks in a workunit, as in this case the workunits will be 2/3 longer than the present ones, and the last one will be the same length.

1000*46 (2*2*2*5*5*5)*(2*23) 920*50 (2*2*2*5*23)*(2*5*5)

The other possibility is to have 920 chunks, in this case every gene expansion would made up by 50 workunits.

Looks like we will finish up this group of work in the next 12 to 24 hours. I hope Denis has a group to distribute while waiting on new work here.

I think we have 8 days' work left. (710 genes/isoforms left, the present rate is 87/day)

If you don't want to reduce the number of tasks queued on your host by limiting the number of CPU cores generally in BOINC, you can use the app_config.xml file to limit the number of simultaneous tasks for each project.

A little correction: this method (just like setting a global limit on the usable CPU cores in BOINC) limits the number of tasks queued. (I've set up my host like that to verify it).

The main message of this experiment is that one should not crunch (single-threaded apps) on the "virtual" (hyper-threaded) cores to achieve short runtimes. (Running too many of these tasks makes them wait for each other's FP operations, it could also easily fill up the last level cache of the CPU, resulting in increased cache misses and much slower memory transfers.)