Folding Forum

If I look at the page here https://stats.foldingathome.org/os it seams that the counting power Folding@home have dropped from more the 1 exaFLOP down to 0.2 exaFLOP. Whay is that?

Quite probably because of this: https://foldingathome.org/2020/09/27/up ... pu-counts/

Thank you ajm. So the claim that Folding was a exaflop capable cluster was based on a miscalculation on an order of at least 5 times the real value providing that they got it right this time.

Well, this problem with folding without persistent storage is new. As the name says, Folding@Home is primarily meant for normal folks using their standard PC. But the Covid-19 emergency attracted a new kind of users, whose systems the stats were not meant for analyzing.
Now, I know that some work is been done for setting up a new way to compute those stats. But this is still underway and the stats now published, or rectified, are just a quick fix (as the article above states) - they still don't correspond to some real calculation.

Simplex0 wrote:Thank you ajm. So the claim that Folding was a exaflop capable cluster was based on a miscalculation on an order of at least 5 times the real value providing that they got it right this time.

The way I understand it is that we did have an exaflop in april-may; but the number of folders has reduced since then.

Should you want a semi-independent source:

https://folding.extremeoverclocking.com ... ary.php?s=

Look at weekly or monthly Points or Work Units. and compare them to weekly or monthly Users.

As has been said, they are in the process of updating how they collect this stats information. In the meantime though the OS Stats page still says that it is from active systems over the last 50 days, the actual span is just a day or two at this point. They may also be excluding some results from known users of containers without persistent storage.

As Jonazz has written, the figure from May is from before many of these systems showed up later in the Summer. So while it might not be exact, it would be near the actual figure. The identified sources of most of the recent inflation in the FLOP count started up around the end of June and early July. Essentially they are running non-FAH supplied containers that start up as a new installation each time, run a single WU or so, and next time the container runs it is seen as a new machine.

I do not know when they will have a fully updated method out for collecting this stat, but it is being worked on. I expect when completed it will show something about 2/3 the May level based on the EOC stats linked by JomboPalmer.

The fundamental issue is that FAH is not notified when you take a system off-line, only when a new system is added. How does FAH determine that a system that just received an assignment is still part of the distributed supercomputer?

When WUs often took a week or two to complete, the longer timeframe made some sense, but a multitude of COVID projects are now much, much shorter. Establishing an assumed WU duration, considering the faster GPUs and shorter projects is still a bit of a challenge (and will continue to be) unless someone figures out an alternate way to know when a client has been permanently taken off-line.

When looking over the numbers, I found that the user base in the last few months leading up to the exaflop score, actually shrunk, but their output increased.
I think a lot of late comers to the RTX 2000 craze, while seemingly few new users new (gaming) pcs, and some supercomputers (with a registered 1000 CPUs, of which like mentioned, perhaps more than 2/3rd were containers).
I think fewer people contributed more in points, thanks to faster hardware, and focusing away from x86 to GPU.
We'll see that same spike this coming winter, when our Canadian friends will chime in, many of which will have an RTX 3000 series GPU.

Also note that the recent optimizations due to CUDA on Nvidia GPUs would not have been reflected in the current stats system. Thus, whatever the current Nvidia GPU contribution is, one could theoretically increase it by 15% non-Moonshot WUs) all the way to 100% (Moonshot WUs) thus, there's quite a bit of sliding room so to speak. I do look forward to the new stats once it has been refreshed. In the meantime, F@H does maintain 200,000 compute hours per hour for the last few days (https://apps.foldingathome.org/credit-log).

So I gess the the main reason the flop count have plunged from a top value at 2.6 exaflop down to 0.2 exaflop, a factor of 13, is mainly due to a flawed method to make the calculation and not that the computing power of the cluster have dropped to 1/13 of the power it had recently. imo it is meaningless to present a flop count for the cluster without any estimation of the error in the calculated number.

If I run a container on a preemptable cloud server instance and a preempt destroys it, should it have been counted as available FLOPS or not? ... and for how does FAH determine long was it part of the virtual supercomputer? (That's certainly one source of uncertainty.)

OK ... slightly off topic ... but retrospectively couldn't one look at the download/upload times, an estimate of the amount of processing needed for the wu - to give a flops rating for each completed wu - then use the download/upload times to identify concurrent wus and sum these for a FaH flops figure ... significant compute to do this and still "estimate" but would be and interesting (if in no way worth the effort) exercise

That seems to be the idea:

...Looking ahead, we plan to assess the performance of Folding@home in terms of the amount of simulation data coming into our servers rather than relying on IDs generated by the Folding@home software...

GROMACS and OpenMM both count the actual FLOPs internally and report a total. We plan to use their actual figures instead of estimating anything. We'll be reporting actual PRODUCTIVE work completed although the actual details of the project have yet to be finalized.