Folding Forum

Core v2.25 is automatically pushed for beta testers also (see my previous post in this thread). If you request only normal WUs, you can probably stay with v2.22 a little while longer.

At least for a low end card like my GT430, P762x WUs have been poor producers to begin with. Starting with 680x projects, the norm has been 4000-5200 PPD for my GT430 depending on project (P8018 produces about 4800 PPD with core v2.22). P762x PPD has been ~3500 PPD with core v2.22, v2.25 produces only ~2500 PPD.

Then again, a couple of years ago I coud still occasionally get small WUs that would produce about 8000 PPD on a GT430, so I figured 762x projects simply follow the trend; bigger cards work better on bigger proteins.

P5-133XL wrote:

sswilson wrote:Would downloading the older 2.22 core and then replacing the v2.25 core with it (in the nvidia / fermi directory) work?

No, these WU's require 2.25 so if the client detects an earlier core it will just be automatically replaced with 2.25. So don't bother.

I've removed the -advmethods flag so there should be no reason for it to assign me one of these WUs which requires the "new" core.

Napoleon wrote:Core v2.25 is automatically pushed for beta testers also (see my previous post in this thread). If you request only normal WUs, you can probably stay with v2.22 a little while longer.

At least for a low end card like my GT430, P762x WUs have been poor producers to begin with. Starting with 680x projects, the norm has been 4000-5200 PPD for my GT430 depending on project (P8018 produces about 4800 PPD with core v2.22). Even with core v2.22, P762x has been only 3500. Core v2.25 doesn't make things that much worse for them anymore, I get about 3000 PPD with it.

Then again, a couple of years ago I coud still occasionally get small WUs that would produce about 8000 PPD on a GT430, so I figured 762x projects simply follow the trend; bigger cards work better on bigger proteins.

Unfortunately, that doesn't appear to be the case. My GTX580 is seeing the same raise in TPF as others have reported.

Apologies for expressing myself unclearly. Bigger cards do better on bigger proteins, but the v2.22 ==> v2.25 TPF increase seems to apply to all cards. In my case it was 35.68% on P8018 WUs.

sswilson wrote:I've removed the -advmethods flag so there should be no reason for it to assign me one of these WUs which requires the "new" core.

That is a good temporary plan but I would not assume that this project won't eventually graduate to general release.

They were full FAH already, IMHO they just got yanked back to advanced to test core v2.25, viewtopic.php?p=218626.

Kind of worst case scenario (PPD wise) testing I suppose: poor PPD WUs & poor PPD core.

Is there a way to tell what version of core you're running without pulling out a hex editor? I dumped everything on one PC in order to load up the new v7 and want to check to see what core it dl'd.

As far as temporary goes... hopefully they'll hold off until we start getting bonus points for GPU WUs, that would take a lot of the sting out of it.

edit: NVM, I see the version in the log.... (2.25 )

edit#2: I'm also going to put on my tin foil hat here and suggest that they "leaked" information about gpu bonus being applied under -advmethods flag in order to trick us into "upgrading" to V2.25. Watch... it'll be another 6 months before we see the bonus points now.

Watch... it'll be another 6 months before we see the bonus points now.

Well, on my latest WU, I'm down to 9893ppd(7min 33 secs) on a 560 TI. In the past, 20,000 ppd were possible on this card....so down by more than a full 50% from previous.

I'd say they better expedite the roll out of the new bonus point system if they don't want to see a significant reversal of participation.

GTX460@800MHz with P7623 only 8200PPD, should be more than 10kPPD regarding to the benchmark schema and was up to more than 15k in past
GTX570@855MHz with P7623 only 7600PPD ?
GTX680@1175MHz with P7626 only 15600PPD

All with core 2.25.

That is in sum the worst PPD for the GPUs ever.

Heiko

sswilson wrote:I'm also going to put on my tin foil hat here and suggest that they "leaked" information about gpu bonus being applied under -advmethods flag in order to trick us into "upgrading" to V2.25.

Where did you see that "leaked" information? I didn't see it and never suspected it might be true. Attributing a trick like that to the Pande Group seems to be fun for some tinfoil hat conspiracy theory folks but I've never found something like that to be true.

When you sign up for advmethods, you accept WUs and FahCores that have had less testing. That's why it's called "late stage beta testing" and by making it optional, anybody with a Kepler could opt-in without making the commitment to joining the beta team (early stage beta testing).

bruce wrote:

sswilson wrote:I'm also going to put on my tin foil hat here and suggest that they "leaked" information about gpu bonus being applied under -advmethods flag in order to trick us into "upgrading" to V2.25.

Where did you see that "leaked" information? I didn't see it and never suspected it might be true. Attributing a trick like that to the Pande Group seems to be fun for some tinfoil hat conspiracy theory folks but I've never found something like that to be true.

When you sign up for advmethods, you accept WUs and FahCores that have had less testing. That's why it's called "late stage beta testing" and by making it optional, anybody with a Kepler could opt-in without making the commitment to joining the beta team (early stage beta testing).

The problem with calling this "late stage beta testing" is that they already had the reports of tpf issues from the original beta run. It should never have been bumped up the chain unless accompanied with some form of official caveat related to the raise in tpf being a known issue. On top of it all, it might allow kepler cards to run non-beta WUs, but it only does so at less than 75% of their potential, so "the pain" for fermi cards doesn't even come with a real solution for kepler cards.

If this is "the way forward" then fine, tell us straight out with an explanation of why we're seeing such a large drop in PPD and we'll be able to decide when/if the PPD/W ratio has hit the tipping point of not being worthwhile.


edit: and yeah, I'm not completely sure where I got the -advmethods = QRB idea, I either read it somewhere on the forums here, somewhere on my own daily forum hangout, or (and this is highly possible) made the assumption myself based on previous experience with the original -advmethods SMP setup. (In my defence, I at least attributed the thinking to having my tin foil hat on.... )

See my comment here: viewtopic.php?f=20&t=22857&p=227747#p227747

Even if I knew what changed (which I don't) I can't predict what the next round of optimizations will do to the TPF of Tesla, Fermi, or Kepler.

It's one thing to be concerned about reduced science (increased TPF) and something entirely different to be concerned about points (reduced PPD). ASSUMING that the increased TPF is the result of a permanent change, the QRB will more than make up for any temporary loss in PPD, no matter what additional optimizations may or may not take place.

Yes, some form of official caveat would have been nice but that doesn't make it the Pande Group's responsibility to accept the blame for widespread disregard for the advmethods caveat.

FACT: The "equal-pay-for-equal-work" initiative requires a newer version of Gromacs so that the GPUs can do explicit solvent calculations.
FACT: v2.22 certainly uses an old version of Gromacs.
UNSUPPORTED GUESS: Maybe the newer version of Gromacs is incorporated into v2.25 and it has to do some additional calculations or maybe it uses GPU hardware in a different way than was required in v2.22.

It's certain that the way forward is to do identical calculations on identical proteins with CUDA and with OpenCL and with SMP and provide equal points. It's not clear which versions of the applicable FahCores have been updated or still need an update to incorporate those changes.

If we assume GPU QRB is soon, the problem is rectified soon.

If we assume GPU QRB is not soon, the problem is still rectified soon. Remember, existing projects were benchmarked on the "faster" v2.22 fahcore. When the current projects end, and new projects start, the new projects will be benched using the new v2.25 "slower" fahcore, so then your PPD will go back to "normal."

bruce wrote: <snip>
Yes, some form of official caveat would have been nice but that doesn't make it the Pande Group's responsibility to accept the blame for widespread disregard for the advmethods caveat.

FACT: The "equal-pay-for-equal-work" initiative requires a newer version of Gromacs so that the GPUs can do explicit solvent calculations.
FACT: v2.22 certainly uses an old version of Gromacs.
UNSUPPORTED GUESS: Maybe the newer version of Gromacs is incorporated into v2.25 and it has to do some additional calculations or maybe it uses GPU hardware in a different way than was required in v2.22.

It's certain that the way forward is to do identical calculations on identical proteins with CUDA and with OpenCL and with SMP and provide equal points. It's not clear which versions of the applicable FahCores have been updated or still need an update to incorporate those changes.

I have also been hoping that your unsupported guess is near the mark, and that 2.25 really does things differently and maybe better for the long term, it certainly acts differently for my Fermi cards, hotter (slightly) and the well noted reduction< edit I mean lengthening > in TPF but also much less tolerance to heat and therefore I suspect overclocking. This may not be a dud core as has been assumed but something entirely different. With the QRB on the horizon this may be part of all this process.
I do understand people's frustration as it appears to do less science eg is slower on the same units, a whole new project being slower is easier for donors to understand, but for a core change to do this so dramatically can be rather disheartening.
Lost one today, reported as NANs I suspect due to environmental heat at 65% (was a hotter than normal day for here) while running on stock that almost never happened on 2.22 when overclocked, this is in my opinion a much bigger hit than slow time frames or low ppd.

bruce wrote:See my comment here: viewtopic.php?f=20&t=22857&p=227747#p227747

Even if I knew what changed (which I don't) I can't predict what the next round of optimizations will do to the TPF of Tesla, Fermi, or Kepler.

It's one thing to be concerned about reduced science (increased TPF) and something entirely different to be concerned about points (reduced PPD). ASSUMING that the increased TPF is the result of a permanent change, the QRB will more than make up for any temporary loss in PPD, no matter what additional optimizations may or may not take place.

Yes, some form of official caveat would have been nice but that doesn't make it the Pande Group's responsibility to accept the blame for widespread disregard for the advmethods caveat.
FACT: The "equal-pay-for-equal-work" initiative requires a newer version of Gromacs so that the GPUs can do explicit solvent calculations.
FACT: v2.22 certainly uses an old version of Gromacs.
UNSUPPORTED GUESS: Maybe the newer version of Gromacs is incorporated into v2.25 and it has to do some additional calculations or maybe it uses GPU hardware in a different way than was required in v2.22.

It's certain that the way forward is to do identical calculations on identical proteins with CUDA and with OpenCL and with SMP and provide equal points. It's not clear which versions of the applicable FahCores have been updated or still need an update to incorporate those changes.

This will be my last comment on the subject here as it serves no purpose other than to fan the flames of discontent, but I couldn't let this statement stand uncontested....

This core version is being pushed to all new installs so in fact has absolutely nothing to do with -advmethods other than as a quicker path to get it if you're already running V2.22. Folks wouldn't be complaining if it was easy to return back to a functioning core.

You cannot go back. This project only moves one direction. Forward. And the FAH goes where the science takes it. Sometimes that means the fahcores get more efficient, sometimes the fahcores have to work harder. In any case, the points always move up or down a little bit over time, but PPD averages out for EVERYONE. Complaining about naturally occuring events is like complaining about the sky being too blue.

Fahcores get updated, and PG always decides when that happens. How do you think we got from fahcore v1.x all the way up to v2.25?