Folding Forum

Outside observation:

Seems like the real concern is the points differential between Bigadv and SMP2. Perhaps recurving the top of the bonus formula on SMP2 so that those who have spent big $ + time on dedicated rigs get more points out of their SMP2 jobs on 8-core+ machines is a simple fix?

I could be way off-base.

I think most people understand the points differential between bigadv and smp2 - the smp2 work isn't "big" and thus doesn't get the extra "big" bonus. If "big" work runs out, that's life. I think (again my opinion only) that the bigger issue is the points differential between most smp2 work and the 670x projects. It's been explained already but that doesn't make it much easier to stomach.

Does an 8-core+ machines do the 670x jobs faster than a 4-core at the same clockspeed? (newbie, most of my SMP2 appear to be 670x when I look), if so, recurving the top could still be an answer?

by Punchy » Wed Oct 27, 2010 12:46 pm

I think most people understand the points differential between bigadv and smp2 - the smp2 work isn't "big" and thus doesn't get the extra "big" bonus. If "big" work runs out, that's life. I think (again my opinion only) that the bigger issue is the points differential between most smp2 work and the 670x projects. It's been explained already but that doesn't make it much easier to stomach.

I would have to agree with that one. Since bigadv is a beta project, i would not expect there to be an endless supply of work units. Personally i would rather be folding some work units (whether its 670x or other SMP2 wu's) than none at all, if i had a dedicated bigadv machine.

I understand some people have made decidated systems specifically to do bigadv units - but giving the type of project it is, it looks like there simply isn't always work and other units must be assigned in their place.

However, I also think that there is a point issue with the 670x units. I understand there is variance in PPD for different WU's (especially with early return bonus factored in), but these seem to be consistantly lower yielding than the others. I don't like to get too worried about this, though. I find it's best to look at it this way: I am donating my CPU/GPU time for the science, and i'll leave it up to stanford to use it as required. If they need more 670x WU's processed than so be it! I'm happy either way.

mdk777 wrote:Well, I'll let Road-runner respond if he was satisfied with the rest of your reply.

You didn't see it all. So yes, let's see what he says, not what you say.

@ road-runner, YGPM

Guess I picked a bad time to build an SR-2 with dual hexas.
It'll definitely help chew through the regular WU but I did build it specifically for -bigadv. (actually downgraded from 2 boxen with i7 920s and x58s to the 1 SR-2, and got the hexas on fleabay for too cheap of a price to pass up)

Is the single SR-2 not producing more points than the 2 old boxes, even on regular SMP?

If not more points, then bad timing. If yes and more points, then it's always a good time to upgrade...

Qinsp wrote:Outside observation:

Seems like the real concern is the points differential between Bigadv and SMP2. Perhaps recurving the top of the bonus formula on SMP2 so that those who have spent big $ + time on dedicated rigs get more points out of their SMP2 jobs on 8-core+ machines is a simple fix?

I could be way off-base.

Nope, not off base. And it is clear that this bonus system is still under review according to Dr. Pande's post.

7im: it does...from a % perspective though, it stinks because with the 2 boxen I had a bigger chance of pulling a bigadv, obviously with the SR-2 it's either I do or I don't.
The primary reason though I built it (other than bigadv) was to save a little on the electric bill, and that has so far been the case.

VijayPande wrote:I'm sorry you feel like you don't have enough information about big adv. I think this has been posted in other threads, but perhaps not in a single place. I agree we should have done more to make this more clear. I'll try to summarize it here:

1) There is a problem with the linux core. This is a low level Gromacs issue and isn't obvious how to fix it. If you have any doubts that this is a complex problem, feel free to go to http://www.gromacs.org, get the code, and take a look. it's ~1M lines of code, much of the key parts of it are handwritten assembly. We use it because it is amazingly fast and maximizes donor's output. however, fixing subtle problems is very challenging. This is not like repairing a car of something like that, where there's a standard protocol to fix something.

Yes I know there is a problem or so you all say, it must be in the results because it ran fine for me on every machine until it was pulled. I realize its complex, but cant it be rewrote like it was at the start? Is anyone working on it or since windows is the #1 O/S it has been put on the back burner? Not all of us can afford to buy Bill Gates crap for ever machine...

VijayPande wrote: 2) The use of big adv depends on having very big simulations to run (i.e. lots of atoms). This will come and go as time goes on. we are working on rolling out new SMP WUs, but most of them are smaller systems at the moment, since that's what's needed right now. I think everyone would agree that big adv should help push the science and not the other way around, i.e. we shouldn't design science purely to keep big adv fed if it's not useful to our cause. With this said, I am looking to see what can work based on what's going on. In hindsight, it is clear that this should have been stressed more from the beginning and this was a mistake on our side.

Yes I am all for pushing the science, as a customer view I would think the bigger WU would do more than the smaller ones? I mean it has to be important to be so big and get a bonus. Put 20 or 30 little ones together and make a big one. Lets get the science rolling...

VijayPande wrote:If you were here day to day and saw what goes on, I think you'd have a radically different point of view in terms of how all of this works. We're here to push science forward and aren't trying to "bait and switch" donors (there's nothing to gain from that). We're trying to push the envelope and try new things, but in the end, we're here to push the science and that always takes precedence. The day when science doesn't take precedence is the day that we stray from our mission and betray our donor base, so it's something we take very seriously around here.

With that said, we do take donor concerns very seriously as well (hence my post) and we are looking to see what we can do on this one.

Yea I probably would but I am not there or at the forum daily so I dont keep up with it that much, you only see me and everyone else complaining when something doesnt seem right on our end. I wish we had already found some cures but we havent, I started in 2003 with everything I can get my hands on due to loosing people and we seem no closer to fixing that today.

My mom has cancer and has under went radiation, chemo etc. about 6 or 8 months ago, then a collapsed lung afterwards, and now fell and broke a hip. I have come and gone when things arent working right here, but I am still contributing to some kind of research to help find some cures. @ mdk777 I have about 75,000 points total also...

zero2dash wrote:7im: it does...from a % perspective though, it stinks because with the 2 boxen I had a bigger chance of pulling a bigadv, obviously with the SR-2 it's either I do or I don't.
The primary reason though I built it (other than bigadv) was to save a little on the electric bill, and that has so far been the case.

Bitter sweet rewards.

And while it may be a challenge to recurve the bonuses, that does seem like a good solution to help offset the points differences between the 2 types of work units. But again, the bonus system is still a work in progress.

Oh well I guess I can keep a positive mind about it and say we may be losing PPD with 6701's and such vs bigadv, but then again we're slicing through at least triple the WU each day so the science gets a boost when the points take a loss. The points are nice but doing my part and marching forward is nicer.

VijayPande wrote:With that said, we do take donor concerns very seriously as well (hence my post) and we are looking to see what we can do on this one.

I believe that the main donor concerns stem from the radical differences between PPD between bigadv and the every-day variety of smp wus. Giving more points to those who undertake more challenging projects with big hardware is an excellent plan but there has to be a better way to do it.

If we look at two projects, both of which run in about 3 days on an i7 why do they get radically different PPDs just because one has a few more atoms than the other. Find some way to make those PPD's slightly higher/lower in proportion to what that particular hardware is actually doing for those particular projects.

Apparently you can't adequately manage the reassignment of every-day smp wus to those who want bigadv by core-count, but let's address the issue of donor complaints. I believe that the intensity of the complaints stems from the radical differences in PPDs. The transition between getting and not getting bigadv should be smoother with changes in the bonus being less radical, particularly for i7-class hardware. The intensity of the complaints will go down with the intensity of the bonus transition.

codysluder wrote:Giving more points to those who undertake more challenging projects with big hardware is an excellent plan but there has to be a better way to do it.

I don't know if it's possible but the idea I've said over at the [H] is that if the client were self-aware and could request WU based on a few factors, it may help out.
Factors such as -
# of cores (this is already done somewhat since bigadv will not work if 8 cores are not found)
Total process time of same or similar WU (this would probably require the client digging into the log files, or keeping track some other way)

I think (on another semi-related note), I wish there was something in place to hurt people who willingly and knowingly delete WU in an attempt to get a "better" one. I won't name names, but there's one major name out there who decided to make up their own team because they were tired of getting questioned and insulted about it (among other things). Stuff like this shouldn't be allowed to happen if there's not already a check or something in place to discourage this. I know the donation of equipment is appreciated, but something should be done to check against passkey, IP address, or WU distributing. IE if a lone machine requests several WU within an hour and hasn't turned any in, clearly that machine either a) isn't stable enough to fold or b) someone's point whoring in an attempt to cherry pick what WU they get. People who do things like this hurt everyone and I think they should be banned or zeroed out or something (if that isn't already the case).

One of our team members brought up a good point about low end bigadv boxen doing regular SMP2 work instead of bigadv, leaving the bigadv for the more powerful machines out there that don't cut the deadline so close. This (IMHO) is a very good idea; obviously some people may be upset that their 4c/8t i7's aren't receiving bigadv anymore, but it would help turnaround bigadv faster and also help initiate more machines towards regular SMP2 work (and probably help cut through all the 6701's more quickly).

I can't speak for everyone obviously, but I will go out on a limb (quite safely, might I add) and say that the [H]orde is arguably the largest install base of SR-2 machines; at current count we have 16, possibly a few more (if people haven't replied yet). The majority of our team also went hog wild on the L5640's on fleabay last month....from a seller who originally had around 50 of them for sale, [H] bought up 42 of them. If you guys want some monster machines to crunch WU on, send 'em over the [H]orde's way, we will sacrifice them without prejudice. We love our 24 core SR-2 beasts.

Punchy wrote:I think most people understand the points differential between bigadv and smp2 - the smp2 work isn't "big" and thus doesn't get the extra "big" bonus. If "big" work runs out, that's life. I think (again my opinion only) that the bigger issue is the points differential between most smp2 work and the 670x projects. It's been explained already but that doesn't make it much easier to stomach.

Agreed with Punchy and Arnette here. Speaking as a 5+ year folder whose computers have crunched over 100,000 work units and one who has put together a couple of multi-CPU builds, I have no issue with getting regular SMP A3 units instead of the requested BigAdvs. I purposely spec'd out these boxes understanding that BigAdvs may not be always available, and that SMP work units in general were fine with me when BigAdvs were scarce.

But, when 80% of the SMP CPU work units that I'm getting lately have been 670x WUs and I see that most of my CPU resources are being woefully underachieving (assuming that points=science) I have to wonder whether or not this was a good investment. As HaloJones said in the "Open Letter" thread, I don't consume less power crunching these units vs. regular SMP A3 units or BigAdvs. I also feel we've been getting deluged with them because other folders were flushing them out when they were first noticed. Correct me if I'm wrong here.

While the best PPD/watt configurations are always changing, when I see that my two newly-built multi-cpu rigs which are consuming nearly 900 watts of power and have 48 usable cores between them are actually achieving fewer points (and assuming more points=science) than the 3 Core I7 quad-core/eight-thread rigs they replaced I am left scratching my head and a bit disheartened. My 3 Core I7 rigs used 900 watts of power and were getting between 65 and 90K PPD with BigAdv, while my two multi-cpu rigs are only getting 80K PPD while crunching 670x units.

Because at the end of the day, the 670x units are the exception, not the rule. There are a huge number of other regular SMP units we could be crunching, and I find it hard to believe 670x units are primarily all that is left to crunch in that category of unit (SMP A3).

EDIT: I also agree with both Codysluder and what zero2dash say above wholeheartedly. Unfortunately the science cannot define the hardware, but the science can be tuned to run on the biggest and best.

I do appreciate your greater participation in these forums though, Vijay, and your insights are always welcome.