Folding Forum

Would it be possible to reduce the work unit size or have a user selectable work unit size available? Maybe offer a variety of work unit sizes for every project and let the user
configure the preferred work units size through the UI of their client?

The reason I'm asking this is that I'm constantly having well over half simulated work units expire and go to waste just because the work units are way too big
and take way too much time for the way I'm running FAH client. Having smaller work units available would make the folding much more efficient by getting rid of
these expired and wasted work units.

This might not be be an issue for someone running simulations 24/7 on their folding farm, but for harnessing those smaller, idle CPU cycles from intermittent folders
like myself, it would be a huge improvement.

I'm running FAH client mostly on my work laptop when I'm away just because the fan makes so much noise and having simulations running on the background does hamper
the performance a bit.


Regards,

Trokari

Welcome

I would recommend you don't fold, it's not for everyone or every situation.
You're running a laptop which means it take longer to process work units anyway, compound that with part-time folding and we end up with expired work units.

Work units have two triggers - timeout and expiry.
Timeout - the server will send out a copy of your work unit to another folder to complete. This means another folder has now been tasked with completing the work that was assigned to you.
Expiry - the client will dump the work unit from your computer. This means the work has been a waste of your compute resources.
Overall this slows down the progress of science as the work assigned to you had to trigger the timeout before it was assigned to someone who could do it in a reasonable amount of time.

I have found that the scientists really only respond to work units which are failing or causing problems to our computers.
They very rarely respond to work units which are underperforming.

you can set max-packet-size to small, but this won't always work. If I understand correctly, the researchers have to activate this manually for every project.

Define "size" ...

- Number of atoms : the more atoms in the WU, the harder it is to compute it. A high number of atoms better utilize the GPUs with high number of SPs or scales to more CPU threads better. Also, the memory requirements increase with the number of atoms.
- Number of steps : the more steps in the WU, the longer the WU will be.
- Transfer size : the amount of data transferred on the network to download the WU or upload results. This is what the max-packet-size parameter was created in the days connections weren't fast or unlimited.

The duration of the WU is a combination of the number of atoms and the number of steps ... and for CPUs, the only thing that the client/server knows is the number of threads that your system have ... there's no way to know the relative performance of the CPU.

If your CPU has more threads than cores, (you have not posted a log so we don't know) you could lower the number of CPUs to the number of cores, that should get you simpler Work Units.

viewtopic.php?f=24&t=26036

On a few of my systems I fold them at night. I have found that limiting my CPU threads to 4 keeps the WU's small and i do not get the large WU that even my 5900x take days to perform.