Folding Forum

Grandpa_01 wrote:Maybe and maybe not right now there is a pretty big push going on between evga and the [H] in the battle for #1 allot of rigs have started up on both sides starting on Sept 1.

There were some POed folks running BigAdv 8 who went away for a while (just to show they were angry) who are coming back for the competition .

When do fall classes start up again?

Last week

That was rhetorical... like asking when the sub $300 Kepler 660 Ti came out?

I don't think it is quite as frivolous, after all it was a significant factor in storage@home... (section 3.3. - http://ieeexplore.ieee.org/xpl/articleD ... er=4228400)

There was a 6k increase in participation & 100 extra TFLOPs over move-in week and while I am not going to attribute that to resumption of fall classes or a specific battle between two teams, that increase is in the face of a continuing downward trend.

From the spreadsheet, it looks like Ati cards are dropping fast, I guess it is due to the drivers problems?

I guess it is due to the drivers problems?

That is the presumption. However,I have seen large jumps in numbers (+, -) over the years that are not clearly defined.
Possible causes discussed.

1. Testing by rendering farms,/ institutional donors using GPU/CPU acceleration
2. misplaced, mis-attributed /miscalculated FLOPS
3. server reporting / assigning errors.

However, the above usually resulted in large instantaneous dislocations in the reported FLOPS.

Steady trend like this is indeed most likely just that the client isn't working very well.

http://fah-web.stanford.edu/cgi-bin/mai ... e=osstats2

Well, that is one way to approach a numbers problem...change the way you count.

Looks like windows up 4x
AMD GPU up 2x

Interesting, the points on AMD WU did not double, nor I have I seen them run any faster, yet now they produce 2x 86 FLOPS where before they did not.

OH well, definitely should have a discontinuity rather than a straight line on the graph.

Yes, that is the one (and only) way to approach a numbers problem. Fix the problem.

FAHCores and their optimizations in each of the client types have changed many times, and the OS Stats hadn't been updated in a while. V7 probably allows for more accurate collection of that data. Better data, better stats.

See this new blog post about the new server stats page: http://folding.typepad.com/news/2012/11 ... -page.html It's not quite as depressing as the other one.
Are you still using my Java application to pull the stats from the page? If so I'll go modify it to work with http://fah-web.stanford.edu/cgi-bin/mai ... e=osstats2 and the larger table.

V7 probably allows for more accurate collection of that data. Better data, better stats.

No explanation of doubling AMD GPU stats.

cards, WU, architecture , etc, etc. are unchanged.
For years the NVidia GPU was described as a more efficient architecture that achieved multiples of Native TFLOPS to achieve x86 FLOPS .
AMD cards, (Due to their unoptimized for compute architecture) did not achieve these multiples of the Native TFLOPS.

"Instantly" the entire base of installed clients and legacy hardware has now achieved this upgrade.

I see no explanation for this in the blog post.

Looking at the numbers in the new table I get the following. It's telling me:
- there are a lot of single core Windows CPUs (or alternatively a lot of Uniprocessor clients) in use
- Both OSX and Linux are running far fewer Uniprocessor clients
- I would have expected the Linux cores/CPU to be even higher - since this is where all of the Bigadv 16 and up core CPUs live. Maybe there are relatively few of these monsters
- I can't wrap my head around why the Windows GFlop/core is so high relative to the others. Is it that the Linux would have very many cores - probably counting HT threads - but there are only half the FPUs than there are cores?

- for the Nvidia GPUs - this makes sense. The GTX560 and higher and the GTX650Ti and higher are rated at over one TFlop raw. (see Wikipedia article on Comparison of Nvidia graphics processing units)

Windows: 1.25 cores/CPU 3.5 GFlop/core

OSX: 3.3 cores/CPU; 1.2 GFlop/core

Linux: 2.9 cores/CPU; 0.9 GFlop/core

Nvidia: 437 GFLOP/unit

ATI: 399 GFLOP/unit

mdk777 wrote:

V7 probably allows for more accurate collection of that data. Better data, better stats.

No explanation of doubling AMD GPU stats.

cards, WU, architecture , etc, etc. are unchanged.
For years the NVidia GPU was described as a more efficient architecture that achieved multiples of Native TFLOPS to achieve x86 FLOPS .
AMD cards, (Due to their unoptimized for compute architecture) did not achieve these multiples of the Native TFLOPS.

"Instantly" the entire base of installed clients and legacy hardware has now achieved this upgrade.

I see no explanation for this in the blog post.

You look, but do not see. From the new stats page...

The FLOPS per core was last updated based on a FAH core performance report run on Thr, 30 Aug 2012.

The stats page has always been an estimate, updated from time to time to reflect improvements in folding performance as new fahcores get better at folding. No exact numbers were ever expected from this page, and people should update their understanding of these numbers accordingly.

Hi everyone, i created a new spreadsheet since the calculation method has changed, however i didn't include PS3 since it's EOL. Here's the link: https://docs.google.com/spreadsheet/ccc ... nJnUS1CdVE


Warmest regards,

Risto Kantonen

Risme wrote:Hi everyone, i created a new spreadsheet since the calculation method has changed, however i didn't include PS3 since it's EOL. Here's the link: https://docs.google.com/spreadsheet/ccc ... nJnUS1CdVE


Warmest regards,

Risto Kantonen

Thanks Risto, but I was thinking we could modify the existing spreadsheet to hold the new information. This isn't unlike 2009 when they started reporting x86 FLOPS in addition to native. Now they're reporting CPU cores in addition to physical CPUs. As before, we could just add another column ("CPU cores") which contains no values before today. Personally, I think the CPU cores value is more important than the regular CPU number, so we could consider merging the two and just switching over. Just two ideas.