Page 26 of 47

Re: Change in BA requirements

Posted: Thu Jan 02, 2014 8:44 pm
by Adak
There are two topics that need to be addressed:

1) SMP points need to be brought up to scale with the other types of projects. Former BA rigs, should be able to fold at least 50% as many ppd as they previously did.

2) We need a BA threshold changes "roadmap". The two threshold changes within 60 days of each other, with yet another one suggested by next Winter, is causing a lot of anxiety and dissatisfaction.

You know how it is - people have invested a lot into their folding hobby, and seeing them pushed down into regular SMP, with the points scaled the way they are now, is like seeing your folders being pushed off a cliff.

So far, these are the top two problems with the change in BA requirements.

Re: Change in BA requirements

Posted: Thu Jan 02, 2014 10:21 pm
by Bill1024
Why only 50% it is at 50 % on some WUs now.
I think 90% to 100% is more in line with 4P server class hardware. Because they need the SMP WUs to be done and 4P server costs $$ to build and run.
Plus look at the really fast return times. Fast returns is important to PG.

24 core AMD 2.1ghz BA 8101, 28.42TPF, 112976PPD, SMP WU 8558, 3.59TPF 72k PPD
BA 8103 21.32TPF 173838PPD SMP 8562 3.56TPF 74K PPD

48 core AMD 1.7ghz BA 8101 18.36TPF 217K PPD SMP 8560 2.34TPF 141K PPD
BA 8103 13,10TPF 363K PPD SMP 8561 2.38TPF 135K PPD
BA 8104 9.57TPF 366k PPD SMP 8802 2.34TPF 137K PPD

quad core Q6600 @ 3ghz SMP 8561 20,14TPF 6.3K PPD
SMP 8557 18.46TPF 7K PPD

AMD hex core Phenom II 1045T @ 2.7ghz SMP 8557 11.44TPF 14K PPD

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 12:02 am
by Napoleon
Bill1024 wrote:Why only 50% it is at 50 % on some WUs now.
I think 90% to 100% is more in line with 4P server class hardware. Because they need the SMP WUs to be done and 4P server costs $$ to build and run.
Plus look at the really fast return times. Fast returns is important to PG.

48 core AMD 1.7ghz BA 8101 18.36TPF 217K PPD SMP 8560 2.34TPF 141K PPD
BA 8103 13,10TPF 363K PPD SMP 8561 2.38TPF 135K PPD
BA 8104 9.57TPF 366k PPD SMP 8802 2.34TPF 137K PPD
To me, that looks like a scaling issue. Unlike BA, not all of vanilla SMP work scales well for a large number of cores/threads, assuming it actually scales at all, viewtopic.php?f=66&t=23349&p=233160#p233160 for an extreme example.
vvoelz wrote:codysluder is correct to assume that these projects will perform inefficiently on larger numbers of cores, because they have so few atoms. Thus, I wanted to limited these to just 2 cores to avoid such inefficiencies (i.e. low PPD). Also, with more cores, there's a possibility of numerical instability with so few atoms per processor. I'm hoping that these WUs fill a niche with 2-core machines.
Always assuming (near) perfect scaling for arbitrary CPU:n is rather naïve. Things just don't work like that in real world. BA WUs have a humongous number of atoms, and are thus better suited for big iron. Some vanilla SMP projects aren't, and you may simply be folding them inefficiently, in comparison to the (true quadcore) benchmarking CPU. Hence, much lower PPD compared to BA.

Break the 4P down to, say, 4x SMP:12 (one slot for each individual CPU) and see what happens to your throughput... sure, PPD is likely to drop even more, but to get some sense about the "real" performance, you need to compare using TPF, which is a linear metric. This and that many % of PPD is something of a fallacy - PPD with QRB is nonlinear.

Anyway, for the same SMP projects, is CPU:48 TPF anywhere near CPU:12 TPF / 4? If it isn't, you're definitely having scaling issues :arrow: inefficient folding :arrow: justifiably reduced PPD.
Bill1024 wrote:quad core Q6600 @ 3ghz SMP 8561 20,14TPF 6.3K PPD
SMP 8557 18.46TPF 7K PPD
And for a hypothetical 12P Q6600 (48 cores, no HT) & perfect scaling:
  • P8557, 18.46 / 12 TPF == 1.54 TPF == 295.8K PPD
With 12 separate Q6600 setups, you could assume perfect scaling in thoughput, yet only get 12x7K PPD == 84K PPD. Ya I know, fast return (read: low latency) is important, but seriously, always as important as BA PPD suggests? I very much doubt that. Generally speaking, the optimum is a compromise between throughput and latency.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 12:17 am
by Bill1024
I can tell you all 48 cores were folding at 100%, 100% of the time, the Kracken was doing its thing.
If that means anything to you.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 12:22 am
by Bill1024
I had broken it into smp 24 and smp 12 and smp 12. The PPD was half of what SMP 48 was. So that is 1/4 of what that system did with BA WUs.
Not all cores were at 100% Some were 0% that's why I changed it back to smp 48.

And If "Big Iron" is not good at regular smp, why would PG want us to fold smp with poor production
Why not reward smaller CPUs like 4 , 6, 8, core cpus?

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 2:37 am
by Napoleon
Bill1024 wrote:I can tell you all 48 cores were folding at 100%, 100% of the time, the Kracken was doing its thing.
If that means anything to you.
It does. It also tells us absolutely nothing about how efficiently real work gets done, Kraken or no Kraken. E.g spinwaiting on something can do that too, but nothing useful gets done.
Bill1024 wrote:I had broken it into smp 24 and smp 12 and smp 12. The PPD was half of what SMP 48 was. So that is 1/4 of what that system did with BA WUs.
Not all cores were at 100% Some were 0% that's why I changed it back to smp 48.
I'm not Linux savvy enough to even begin guessing what the problem was with breaking down to smaller slots. Other than that; "I'm Jack's complete lack of surprise." PPD, PPD, PPD... why did you even bother mentioning it again? SMP PPD for BA rigs usually is lousy, we know that already. If someone manages to break down a 24-64 core rig for vanilla SMP in various ways, please give it the whole nine yards and post project numbers and TPF numbers for apples-to-apples comparison. Preferably leave the somewhat controversial PPD numbers out altogether, those who care can punch in the TPF to HFM or Folding@home Bonus Point Calculator. Having said that, I think it would be better to continue this train of thought in viewtopic.php?f=55&t=25444.
Bill1024 wrote:And If "Big Iron" is not good at regular smp, why would PG want us to fold smp with poor production
Why not reward smaller CPUs like 4 , 6, 8, core cpus?
How should I know? Perhaps PG could set up some "sub-BA" SMP projects for BA castouts in the near future? No fanfare, no big announcement, no fancy name like BA for it, just some SMP projects which run reasonably efficiently on Fairly Big Iron and have the core count restricted to, say, 16-30 (31 is prime, 32 is BA already)? Like 7im suggested, such largish SMP projects could/should approach - but not quite reach - BA level rewards. If they can pull it off fairly, that is. No tweaking of points, just some specifically created projects adhering to =work, =pay.

Long sermon, but I actually came up with an idea. How about demoting some of the existing BA projects to SMP on April 17th, giving them high priority on the AS and requiring 16 or more cores to fold them? They would no longer receive the BA-specific 20% bonus, but other than that, business as usual. The projects remaining in BA, and new BA projects launched after April 17th of course, would require 32 or more cores/threads and receive the BA-specific bonus.

Nobody likes pay cuts, so to speak, but I think it might be prudent to set up a poll about it...

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 2:40 am
by Grandpa_01
Napoleon wrote: Anyway, for the same SMP projects, is CPU:48 TPF anywhere near CPU:12 TPF / 4? If it isn't, you're definitely having scaling issues :arrow: inefficient folding :arrow: justifiably reduced PPD.
Bill1024 wrote:quad core Q6600 @ 3ghz SMP 8561 20,14TPF 6.3K PPD
SMP 8557 18.46TPF 7K PPD
And for a hypothetical 12P Q6600 (48 cores, no HT) & perfect scaling:
  • P8557, 18.46 / 12 TPF == 1.54 TPF == 295.8K PPD
With 12 separate Q6600 setups, you could assume perfect scaling in thoughput, yet only get 12x7K PPD == 84K PPD. Ya I know, fast return (read: low latency) is important, but seriously, always as important as BA PPD suggests? I very much doubt that. Generally speaking, the optimum is a compromise between throughput and latency.
I have not ran a 8557 but I have run several 8585 (which is the same family and approx. size but may run differently) at 3Ghz on 48 cores = 1:33 = 298,845 so the scaling would appear to be pretty good on 48 cores also 64 cores on an 8585 @ 3.175Ghz = 1:19 = 381,878 which is 628,000 less than I make on a 8104 on the same 64 core rig.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 3:08 am
by gimpy
bruce wrote:About 5 pages ago, I made this post: Take a break or inject new ideas
bruce wrote:
ChristianVirtual wrote:....
And dear mods; please keep it open ... in general this discussion is not bad to have.
I support that idea. For those of you who have posted several times and done an adequate job of expressing your point of view, repeating yourself again won't be useful, so take a break. I'll leave it open for new ideas from folks who have not posted.
Now I have to ask myself how much of those 5 pages consists of people repeating themselves and how much is actual new ideas from folks who had not posted. Yes, it has been a mixture, of course, but it seems to be migrating more and more toward repetition. Apparently some folks believe that by filling up 5 more pages with comments that have already been made actually accomplishes something that will change the eventual outcome. The "broken record" approach just frustrates me and is more likely to alienate me than to convert me to your way of thinking (no matter which side you're supporting). I doubt that's a unique reaction.

I called for a time-out and for a while, I got one. Then what happened?
bruce wrote:
kerryd wrote:Bruce do what you got to do.
The only thing I feel I've got to do is ask for a more Peaceful forum.

I'm doing the same thing you're doing. I'm simply pointing out that I'm not being listened to (suprise, suprise) and that dialogue is a two way street. No matter what I ACTUALLY say, folks will pop up on the forum and call me derogatory names -- never mind that I'm actually being polite to everyone, no matter what point of view they express.

... Just watch it happen again.
tear wrote:Dude, relax. People want to talk, let them talk. This is not congressional hearing, there is no time limit
or fixed agenda here.

Don't take away their right to talk even if YOU believe everything that could be said, has been said.
Who knows, maybe it has, maybe it hasn't.

You certainly won't earn any respect points by squelching folks.


P.S.
This post has been preemptively recorded so evidence of tampering, if any, can be provided.
May I ask BEFOREHAND what I might be able to say? I try my best to NOT be... but I have emotions,political,scientific,philosophical views. (You know what makes me human)..I mean unacceptable. I invite ALL to read my posts to see for themselves,why I'm sensored? I really thought I had a good contribution to topic,now not sure? Bruce? Tell all why I'm censored?

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 3:44 am
by Bill1024
To me, that looks like a scaling issue. ............... Total speculation on your part. If you don't know don't answer.
I'm not Linux savvy enough to even begin guessing ........ If you don't know don't answer.
How should I know? Perhaps PG could set up some "sub-BA" SMP projects for BA castouts in the near future........ If you don't know don't answer.
PPD, PPD, PPD... why did you even bother mentioning it again?.............. Because a MOD here suggested that people break down large number cores into a few smaller number of cores, not a great idea.
Long sermon, but I actually came up with an idea...................I do not want ideas from you. I want to hear from PG. Thanks any way.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 5:17 am
by Grandpa_01
There is no scalling issue that I can see.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 5:23 am
by bruce
This post has been preemptively recorded so evidence of tampering, if any, can be provided.
That is an unnecessary precaution. Ideas expressed by individuals regarding FAH are NOT censored.

This is a moderated forum. If you disagree with someone's posted ideas, you're free to state your own opinion but you are not free to attack them for expressing their idea.

Posts may be edited if they violate the published forum policies such as flaming an individual, team recruiting, etc. All of your questions are answered if you read the forum policies.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 5:41 am
by Napoleon
Grandpa_01, I stand corrected about scaling, at least for certain SMP projects. Your 3GHz 48-core result was amazingly close to what I extrapolated from Bill1024's 3GHz Q6600 non-HT quadcore for an equivalent 48-core setup. And it makes sense as long as you stick to SMP. After all, the yardstick is an i5 750 non-HT quadcore at stock 2.67GHz according to FAQ pages - not too different from the Q6600 @3GHz.

So much for my earlier attempts to extend that "=pay 4 =work" logic to BA, though. Apparently the BA game is played with entirely different rules/points system. I can only wish best of luck to the PR person whose job it will be to deal with the situation. Definitely "one to watch".

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 6:11 am
by Adak
@Bill1024:

By 50% I mean if the current drop from BA rigs being pushed down into SMP folding, is say, a 60% drop, then let's request it be changed to a minimum of no more than 60/2 = a 30% drop, instead of a 60% drop.

Barring evidence to the contrary, I believe there is no scaling issue.

Can we agree to stop this subject in this thread?
This post has been preemptively recorded so evidence of tampering, if any, can be provided.
It raises a "posters vs. moderators" attitude that makes cooperation much harder than it should be. I've had posts edited by a moderator, and I'm not in the least bugged about it. I mentioned someone's name in a bit of humorous aside, and it violated forum policy. It did not change anything that I wanted to communicate. I see this "posters vs. moderators", as a long tunnel, with no light at the end of it. We can't work like that, and get anything done.

Please, leave this line behind. If you want to preserve your original posts, by all means do so, but let's leave it off this thread, at least.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 6:36 am
by Bill1024
Adak meet in the middle 80%+

There are quite a few helping with the Kill The SMP Backlog drive. I am pleased with the effort.
We should make it a contest between teams. Who can fold the most SMP WUs in 5 days.

Re: Change in BA requirements

Posted: Fri Jan 03, 2014 6:45 am
by Grandpa_01
Bill1024 wrote:Adak meet in the middle 80%+

There are quite a few helping with the Kill The SMP Backlog drive. I am pleased with the effort.
We should make it a contest between teams. Who can fold the most SMP WUs in 5 days.
ME, I have done 375 in 5 days :mrgreen: