bigadv folders

Ryoko

New member
a note for bigadv folders:

on or after 6 jan 2012, bigadv units will no longer be assigned to systems with less than 16 threads. i stopped running bigadv clients in november, so i'm not as worried about it as some, but anyone with i7 processors (or single xeon/magny cours computers) will no longer be able to run bigadv units.
 
Yikes, didn't see this until just now. Read the announcement and relevant thread over at FC, and am still forming my opinion on it.

Will be interesting to see what PPD impact this has on my dual quad server (E5440) and on my home 2600k, both of which use the -bigadv flag. I understand PG wanting to keep BA cutting edge, but this edge is going to cut many ways, including quite possibly cutting contributor numbers ... there is a substantial number of Folders that take F@h performance into consideration when building / upgrading systems, and to remove current high-end systems because they're "deficient" core-wise even though they may be more the sufficient in regard to deadlines is odd.

I also wonder about the focus here - restricting BA to a very select group (how many 16+ core machines are participating in the project anyway?) when one could easily argue that this same group would hugely benefit from a focus on easing mass deployment? What is being gained here, and how does that measure against what might be gained by tweaking the client toward increased ease of use / deployment?

edit: I'll add / clarify that I think core count is a totally bogus metric to use to measure performance. Unfortunately, that's the one they're choosing to use, rather than using deadlines (preferred and otherwise). I'm pretty sure a single overclocked Gulftown can easily run with most 16way server-class boxen.
 
i would guess the issue they're trying to resolve is that they severely underestimated their user's quest for more ppd. leave a piece of meat out for a kitten, and you will soon be feeding a pack of lions. they simply did not have enough projects designed for BigAdv folding.

judging by their reactions to their userbase in the past, this was predictable. instead of fixing the problem (make BigAdv give the same ppd production as SMP, or at least introduce more BigAdv units), they covered over it by insinuating that a highly clocked 2600k or 2700k are somehow slower than a couple low clocked 4c/8t xeons...
 
Yeah, on one hand you have to be at least slightly sympathetic toward PG - because virtually any change gets a significant portion of the user-base red-faced & hollering. On the other, when you're asking people to freely donate both time and money to your project, you really need to go the extra mile to address concerns and needs. And this is where I see PG continuing to fall flat.

I don't mind retiring old systems - its been years since I ran the client on older P4 hardware - it wasn't that their PPD was ever reduced, but simply that they didn't have the HP to push beyond the low triple digits - making the cost / benefit ratio completely untenable. Add the too often seen client instability, and it simply wasn't worth the effort anymore. But those machines were outdated by years when they were no longer project relevant.

While this decision isn't the first of its kind, remember BA already was limited to 8+ cores, this invalidates existing high end systems that currently and easily achieve preferred deadlines. We're used to seeing our systems slowly age out, but this feels arbitrary and is not inline with actual performance. Reading through that FC thread, and probably echoed in team F@h forum threads across the web, you see examples of people who elected to go out and purchase the premium priced 12 threaded processors, or HT versions of more midrange 8 threaded models, specifically because it allowed access to BA WUs and the associated point production. While perhaps a good reminder that one should never buy based on F@h performance (how many times have we been bit now? lol), its a pretty tough pill to swallow. I would be PISSED if I were a F@h contributor and I'd just upgraded to a new 12 threaded proc. Instead, I just get to monitor my existing 8 threaded systems still achieve a sufficient cost/perf ratio to remain in the project.

Though perhaps not at the same level as many, I've supported and participated in the F@h project for years. I am tired of seeing decisions made that reduce enthusiasm and participation, tired of seeing dedicated users throw in the proverbial towel because of unresolved issues (the now standard client beta status and absolute disregard toward the deployment needs of super-folders being the biggest and most disappointing). I'm not throwing in the towel yet, but these decisions continue to curb my enthusiasm, and make me really question PG's decision-making process.
 
a nice clock on a i7 nets 22000 per day smp win7 6.34 . bigadv on same machine was about the same . I understand what u are saying lup just wondering if i missed somthing.
 
a nice clock on a i7 nets 22000 per day smp win7 6.34 . bigadv on same machine was about the same . I understand what u are saying lup just wondering if i missed somthing.
Totally depends on the WU still. Frustratingly, I'm using client v7, so I can't pull WU comparatives between BA & SMP, or different WUs within those series. I do know that my 2600k's production varies wildly, from low teens to upper 20s and higher - but again don't know if that's SMP vs BA making the difference.

Long term - also no idea. Won't really know the effect until after they pull the switch. Until then, anyone who was looking at the possibility of upgrading / changing their F@h hardware should hold off.

I will offer kudos for at least offering the early announcement - PG has a history of not announcing squat in advance, so this is a nice change in that regard. Plus, the announcement was timed before the big holiday shopping season - which was thoughtful to buyers if not sellers lol.
 
a nice clock on a i7 nets 22000 per day smp win7 6.34 . bigadv on same machine was about the same . I understand what u are saying lup just wondering if i missed somthing.

yes. starnet1 for example nets ~29k ppd on most smp work units. crunching 6900s, it hits ~38k ppd. the faster the processor, the larger the gap will be. this hurts 12t cpus the most, because of the BigBeta work units. BigBetas could increase a 3930k from ~35k ppd (smp) to over 100k ppd. after jan 16, that will no longer happen.
 
Ryoko thanks im missing all hardware after the 920 dooing some catch up .
If we could only be so luckey as to get 16T cores from intel about that time. :drool: (non server speaking)
 
If we could only be so luckey as to get 16T cores from intel about that time. :drool: (non server speaking)

Speaking of that, is Ivy Bridging going to have 8-core/2t processors? And are there any 16t desktop processors out now?
 
Speaking of that, is Ivy Bridging going to have 8-core/2t processors? And are there any 16t desktop processors out now?

technically yes and no - the 39xx SB-E processors have 2 cores disabled (yielding 6c/12t instead of 8c/16t). the xeons based on SB-E will have up to 8c/16t, and IB-E will have 8c/16t on desktop CPUs enabled.
 
technically yes and no - the 39xx SB-E processors have 2 cores disabled (yielding 6c/12t instead of 8c/16t). the xeons based on SB-E will have up to 8c/16t, and IB-E will have 8c/16t on desktop CPUs enabled.

Ok so the Xeon E5 series (SB-E) will be available early January, and I read that the IB-E could be available up to 10 cores and 25 MB L3 cache; but won't be out until Q4 2012.

Considering that, I'd say this 16t limit is being pushed too early.
 
Ok so the Xeon E5 series (SB-E) will be available early January, and I read that the IB-E could be available up to 10 cores and 25 MB L3 cache; but won't be out until Q4 2012.

Considering that, I'd say this 16t limit is being pushed too early.

making bigadv 'exclusive' to 2p/4p users?
 
Back
Top