Folding Forum

P5-133XL wrote:PPD's do not accurately the measure of scientific work/value.

I was with you right up to the last statement, but I don't know where you got that idea. I'd phrase it as FLOPS does not measure scientific value.

Suppose I replace 10 machines with a single machine and both produce the same total flops. The 10 machines were producing K WUs per week and maybe each one met the Preferred deadline of, let's say, 7 days. The new machine will complete maybe K WUs per week, but each one is completed in 0.7 days. The total flops completed doesn't change, but the speed at which each WU is completed is 10x faster. In pure baseline points, the PPD is the same, but in QRB terms, the PPD is much higher.

If we were working on a project where every WU could be processed in parallel, then both scenarios complete K WUs in a week -- equal scientific value. FAH has many WUs which must be processed serially, making time an important measurement, hence the QRB formula awards scientific value to speed.

If all K WUs happened to be part of the same trajectory, it would take 10 weeks for the first 10 computers to complete the work because 9 machines wouldn't have a WU to work on, whereas the faster machine can process them one after another and be done in a week.

If flops are the measure of work done, then GPU's should be getting 96% of all the points and clearly they are not which is where I was coming from with that statement.

We are not talking even a 10:1 replacement ratio but closer to 25:1 assuming replacing an average GPU slot with an average CPU slot. I do not know what an average GPU is nor an average SMP slot is but I have a hard time imagining that the average GPU is getting 25x the PPD that the average CPU slot using either base points or base+QRB measure.

You can't use the number of WU's done per week or even just how fast they get returned in isolation because those numbers do not tell how much work was done. The size of a WU can change from very small to very large. That's the whole reason in dealing in PPD as opposed to points or WU's done.

If flops are the measure of work done and GPU's do more flops then GPU's should be getting more points. If the issue is to get work done quickly, then obviously what is needed is smaller WU's for GPU's so that they can complete them faster and get more QRB so that the the total number of points given out matches FLOP ratios. Then everything would make sense.

According to VJ the points values are correct as far as scientific value goes so evidently there is more to it than simply looking at the flops done.

Gramps is correct in that not all FLOPS are created equally, as noted in the FLOPS FAQ. Good general indicator, but not good enough to use as a rule.

I've turned off 100 cores - a drop in the bucket I know. Most of them were BA, some of them were SMP- but if my my BA workers are being given an arbitrary 66% ppd cut, I'm turning them all off - maybe I'll use them to earn money instead of donating money and power.

H.

I was just logging into to have a whine, perfect timing with this thread.

It's a quad-core box, I only run a CPU slot (GPU made it unusable), it's only turned on for ~ 8.5 hours per day, sometimes I have to stop the golfing because it makes the box unresponsive.

The timeout and expiration limits are not sufficient. The current work unit required approximately 32 hours of processing in 6 days before the expiration limit, it's Friday, it's not going to complete. I dumped my previous work unit after a week of processing because it wasn't going to complete before hitting the expiration limit. If it was the occasional WU... that would be O.K., but this is happening far too often.

Some people are looking at my earlier post(s) and interpreting it to mean that their contribution is not valued. They could not be more wrong! There have been many very valuable papers written based on the results from CPU's and bigadv. My point is that FLOPS are not the end-all be-all of work/value. If they were, the point system would be different for it doesn't match FLOPS as a measure.

twizzle wrote:...The timeout and expiration limits are not sufficient. The current work unit required approximately 32 hours of processing in 6 days before the expiration limit, it's Friday, it's not going to complete. I dumped my previous work unit after a week of processing because it wasn't going to complete before hitting the expiration limit. If it was the occasional WU... that would be O.K., but this is happening far too often.

Sorry to hear that you are having issues. Could you please create a new thread and post details about your system (the initial section of the log file is very useful) so we can help you optimize your F@H contribution to your specific needs.

PantherX wrote:

twizzle wrote:...The timeout and expiration limits are not sufficient. The current work unit required approximately 32 hours of processing in 6 days before the expiration limit, it's Friday, it's not going to complete. I dumped my previous work unit after a week of processing because it wasn't going to complete before hitting the expiration limit. If it was the occasional WU... that would be O.K., but this is happening far too often.

Sorry to hear that you are having issues. Could you please create a new thread and post details about your system (the initial section of the log file is very useful) so we can help you optimize your F@H contribution to your specific needs.

... and, of course, the next work unit had a long timeout/expiry (many days) but completed within four hours.

Active folders (CPUs) is down 62,606 since january 2, Native TFLOPS down 212, and X86 TFLOPS is down 140. Since early desember 2013 is active folders (CPUs) down almost 90,000. One example of team that almost have been halved in PPD since the year changed to 2014 is [H]ardOCP which for a long time has been the biggest team in the world folding for Folding@Home. More team shows tendencies, albeit not many, and the reason is probably that the team [H]ardOCP has been the team with the most ba-folders, and it seems that many of them are now really pissed if I interpret the signals right. This is how I see it, a rather sad development for us that for a long time has felt for what Folding@Home is accounted for, but PG has only themselves to blame for this negative trend. Though not for long time ahead, I will most likely do the same as BA-folders at the [H]ardOCP done.

It was just what I wanted to say, and I guess I will not be surprised if my remark here will be refused in the near future.

It's useful to put your numbers above in perspective. Saying that the "X86 TFLOPS is down 140" sounds like a lot, but not if you consider it's at 15,568, of which 140 is only a very small percentage (less than 1%) of the FLOPs. It's probably much more useful to talk in percentages here.

Also, we're seeing a trend that people are moving away from low-core CPUs to many-core CPUs or GPUs. Many donors are replacing multiple low-core CPU boxes with one GPU box with multiple GPUs. These sorts of changes bring down the CPU count but doesn't really mean we're having less performance, just different (more GPUs, fewer low-core CPUs).

VijayPande wrote:Also, we're seeing a trend that people are moving away from low-core CPUs to many-core CPUs or GPUs. Many donors are replacing multiple low-core CPU boxes with one GPU box with multiple GPUs. These sorts of changes bring down the CPU count but doesn't really mean we're having less performance, just different (more GPUs, fewer low-core CPUs).

Perhaps you all have access to data that we don't, but from the OS stats, there doesn't appear to be that much of a change in the average number of cores per CPU, at least in Windows. If you graph the number of Windows cores vs. CPUs as collated here, you currently get a figure of around 1.8. This figure has never been higher than 2.0 in the past year+, and that high occurred in August. I would think that replacing low-core boxes with either a high-core box and/or a GPU box would raise the average, unless there are just that many uniprocessor clients still running, which seems sort of impossible what with the uniprocessor-only projects ending several months ago. Are there really that many uniprocessor clients/slots still running?

The switch to GPUs is borne out by the data, however, at least on the Nvidia side. AMD GPUs is sitting at a rather paltry 300, vs. 18,000 Nvidia cards. Is it possible that a bunch of AMD cards are being counted as Nvidia? I realize cryptocoin mining greatly favors AMD, and that some people may have switched over to that once some of the non-bitcoin cryptos started becoming profitable, but it seems unlikely to me that 95% of the AMD cards that were around in early November have left since then with almost no one to replace them, especially since Nvidia cards have shot up by close to 30% over that same time span.

PS The ATI numbers are being under-reported due to a change in the stats system some time ago. We've been working on that issue. You should expect to see a big bump there soon when the system gets updated.

Consider the influence from the V7 Windows client on the Average Core counts when the client installer reserves a CPU core for the GPU. N-1 cores for every V7 installation with a GPU.

All those Core 2 Duos with a GPU (like one I have) now look like single core computers. Not an explanation, just a contributing factor.

Grandpa_01 wrote:According to VJ the points values are correct as far as scientific value goes so evidently there is more to it than simply looking at the flops done.

I think by far the most significant metric is base points per day (ignoring all bonuses). That way you track the actual work being completed aside from the return speed.

It also stays completely relevant across the years. Maybe there's a way to convert that number into "processing days thided" (maybe it was 10K 10 years ago and now it's 10M).

Then you could dump that into a nice graph.

Tflops is significant but 99% of the population doesn't understand that term.

I'd go with # of people who have contributed n days of work today. Not a final idea but certainly worth exploring from there.