Page 1 of 1
F@H efficiency limit
Posted: Sun Apr 11, 2021 2:06 am
by sekramer10
Is there a point where the number of machines running F@H begins to limit the speed of the system? As in, the resources required to manage the system slows it down more than the speed benefit of the added machines?
My question is basically, is it worth adding many small devices... is there a computational power minimum for added devices such that below that power it is not worth adding the machine? Is a slow device worth adding?
Re: F@H efficiency limit
Posted: Sun Apr 11, 2021 6:51 am
by bruce
Not exactly what you asked, but there is a minimum computational ability. though I can't give you an actual number.
Each protein has a certain number of atoms and to calculate where each atom will go next, you need to calculate the sum of all the forces attracting/repelling that atom. You figure out all those forces and you apply all those forces and compute the acceleration of each atom so you can figure out where that atom will go next. You have to do it for the entire protein. After some simulated time passes, you know a new shape.
Your hardware speed is rated in the number of nanoseconds per day it can compute. Compare that to the length of the trajectory that needs to be computed and you can come up with the number of hours/days/years/lifetimes it will take to understand that particular protein.
A huge number of very slow devices aren't useful because you need to solve the motions of all of the atoms in that protein.
Re: F@H efficiency limit
Posted: Sun Apr 11, 2021 5:20 pm
by MeeLee
For ARM, you want a Cortex A70 (not A7) series CPU, as the A50, A30 and below are just too slow).
For GPUs you are limited by a lot of things, like CPU threads, PCIE speeds. Generally speaking RTX GPUs are the standard nowadays in terms of efficiency.
That includes RTX 2060 all the way to RTX 3090.
Any older, higher end GTX 1000-series GPUs (like the GTX 1070 Ti, or 1080 series) still fold well, but consume about 25% more power to do the same thing (or more).
For CPUs it is best to not add any additional CPUs. Folding on Dual CPU server systems actually slows down the folding process over running them each in their own motherboard.
For RAM, you just have to make sure your RAM usage is below 75-80% of max RAM.
In most cases 4 to 8 GB is sufficient.
On high end systems (with powerful GPUs, or many (24+) CPU threads, 8 to 16 GB of RAM is recommended.
Re: F@H efficiency limit
Posted: Sun Apr 11, 2021 11:54 pm
by sekramer10
Thanks, but what I was thinking is like is it worth it to F@H to add any old computer, some laptop from 10-20 years ago for instance, or is it not even worth the overhead it will generate to F@H to have to manage it? If we add many old slower laptops will it possibly slow F@H down instead of speed it up?
Re: F@H efficiency limit
Posted: Mon Apr 12, 2021 12:19 am
by MeeLee
You'll need a dual core 1,4Ghz CPU, to meet the deadline. But preferably a 2Ghz CPU.
For a GPU, the newest GT730 of 5 years ago, is about the slowest GPU to finish WUs on time.
Both of them aren't very efficient (they're very slow) and often finish WUs in 1/10th to 1/20th of what a more modern CPU/GPU can do, while consuming 1/8th to equal power consumption.
Re: F@H efficiency limit
Posted: Mon Apr 12, 2021 8:56 am
by ComputerUser
Keep in mind that you need to return the assigned WU before timeout (not expiration) or slighly after to be useful. If the WU is not returned after timeout, it will be reassigned to another system to be completed. If you return your WU first, it will be used to generate the next gen WU. If the other system returns first, you still get points, but the results are no longer needed. I used to fold on a Pentium E5800 on 2 cores, which gave around 3000 PPD, but many WUs were reassigned and completed by someone else before my WU got uploaded. There used to be many projects with timeout of 3 days or more, but nowadays you may end up with 1 day or less.
Cheers,
Computeruser
Re: F@H efficiency limit
Posted: Mon Apr 12, 2021 9:22 pm
by BobWilliams757
sekramer10 wrote:Thanks, but what I was thinking is like is it worth it to F@H to add any old computer, some laptop from 10-20 years ago for instance, or is it not even worth the overhead it will generate to F@H to have to manage it? If we add many old slower laptops will it possibly slow F@H down instead of speed it up?
If the system meets the timeout assigned by FAH, then it uses no more resources than if a faster system is assigned the same work unit. If it fails to meet the timeout and it is reassigned, then it is using more of the FAH resource pool.
Quite a few people use older systems to fold if they still meet the timeouts, and only retire them when they fail to do so. Though they are slower and less energy efficient, the owners can decide if the energy cost is worth it. And it often adds some life to systems that might not get used otherwise.
Re: F@H efficiency limit
Posted: Mon Apr 12, 2021 9:34 pm
by JimboPalmer
I no longer fold on Core2Duo laptops. I am currently folding on Core i3 and i5 laptops. (and desktops)
For GPUs, I would guess that cards with under 384 shaders will not fold in time. And you need OpenCL 1.2 and 64 bit floating point math. (Double Precision)
Folding on 8 PCs (11 slots) does not impact my ISP.
Re: F@H efficiency limit
Posted: Tue Apr 13, 2021 7:01 pm
by bruce
I, too, fold on some older equipment. There is no explicit warning when a client starts missing the timeout so you have to check periodically.
FAH's QuickReturnBonus is designed to encourage the use of faster equipment but it doesn't work for everybody. What's needed here is a sense of reasonableness rather than a specific set of global restrictions.
Older equipment does delay any trajectory that it works on by increasing the cumulative processing time even if every GEN processed DOES meet the timeout.
What can FAH do to convince people like me to retire the oldest equipment in my stable based on when the completion of the ultimate GEN of a trajectory will be "late"? One such answer is to arbitrarily reduce the timeout with or without notice. This does increase the total wasted processing time by increasing the frequency of WU duplication. Faster WU turn-arounds are a good thing; more WU turn-arounds are a good thing.
FAH can choose that value, but it's not easy to find the proper balance/tradeoff associated with defining the timeout value for every project.