Folding Forum

PantherX wrote:The reason for the above breakdown is that some SMP Projects are limited to 12 CPUs or 16 CPUs, etc. The reason is that they can't scale up to bigger values since the atom count is too small or some other factors. With the above breakdown, you cover a huge range of SMP Projects.

Uhm, does this basically mean if a 64-core computer configured for SMP-64 (or BigAdv) for some reason can't get a 64-core wu but instead only gets an 8-core wu, 56 of the cores will be idle?

QRB is based on how fast a WU is returned. A 24, 32, 48 or a 64 core should be sending them back real fast.
More so than a Q6600 would. Just figure a way to make it so a 48 4P will be close to PPD doing either SMP or bigadv.
Say 2 x base value for 24 hours, 3 x for 18 hours, 3x for 12 hours, 4x for 8............8x for 2 hours, bonus 20 x for under 30 minutes.

Make it so for every 3 big adv you fold you have to fold 1 SMP,
I like it that everyone is throwing some ideas around.

Bill1024 wrote:QRB is based on how fast a WU is returned. A 24, 32, 48 or a 64 core should be sending them back real fast.
More so than a Q6600 would. Just figure a way to make it so a 48 4P will be close to PPD doing either SMP or bigadv.
Say 2 x base value for 24 hours, 3 x for 18 hours, 3x for 12 hours, 4x for 8............8x for 2 hours, bonus 20 x for under 30 minutes.

Make it so for every 3 big adv you fold you have to fold 1 SMP,
I like it that everyone is throwing some ideas around.

Does absolutely nothing about the root problem. Which is that SMP units take far too long and pay too little to be worth the electricity on the 1P desktops that 99.99% of the world run on....That Stanford's best folding practices imply we should run last I knew.

well again, I am not trying to be contrary just for the sake of it...
But I have to agree with Tear.
Bruce has made a highly educated GUESS (by his own admission in several posts) as to the underlying rational for the announcement.

While many are very quick to agree and encourage participation in a rally of support...

Isn't this exactly what we have been working to avoid?

making allocation and resource choices based on our best guess?

Perhaps Bruce is 100% correct in his analysis.

I would still be happier with direct confirmation and elaboration by PG.

Skripka wrote:

Bill1024 wrote:QRB is based on how fast a WU is returned. A 24, 32, 48 or a 64 core should be sending them back real fast.
More so than a Q6600 would. Just figure a way to make it so a 48 4P will be close to PPD doing either SMP or bigadv.
Say 2 x base value for 24 hours, 3 x for 18 hours, 3x for 12 hours, 4x for 8............8x for 2 hours, bonus 20 x for under 30 minutes.

Make it so for every 3 big adv you fold you have to fold 1 SMP,
I like it that everyone is throwing some ideas around.

Does absolutely nothing about the root problem. Which is that SMP units take far too long and pay too little to be worth the electricity on the 1P desktops that 99.99% of the world run on....That Stanford's best folding practices imply we should run last I knew.

Yes it does. In a nut shell make the bonus multiplier go up and the return time goes down to the point where a 4P can get close to the same PPD.
The more powerful system you build will return SMP wus faster.
Just an idea I tossed out there. The DRs and PHDs can't make it perfect, this dummy can't either.

Rattledagger wrote:...Uhm, does this basically mean if a 64-core computer configured for SMP-64 (or BigAdv) for some reason can't get a 64-core wu but instead only gets an 8-core wu, 56 of the cores will be idle?

Nope, it just means that if you have 64 CPUs and are requesting a SMP WU, the AS will look at it's table of SMP WUs and see which Project is able to run on 64 CPUs. If there is a project that fits that criteria, you will get a WU that will use 64 CPUs. If there are Projects that are limited to 4 CPUs, 8 CPUs, 12 CPUs, etc, you will not be assigned any of them since they don't match your criteria. Thus, you get Empty Work Server Message as no Projects fit your particular hardware/software requirement.

Skripka wrote:...Hell given the ludicrous TPFs for smp on 1p, they should call it BigAdv-Long. As the TPFs on 1p SMP are twice what they are doing BigAdv on 4p. That fundamentally is the problem and reason why we have a "backlog" of SMP units. For 1p folders the TPFs for SMP are too massive for the WUs to be completed in a reasonable amount of time, and the returns are crap even if you have a 100% folding and nothing else 1p desktop SMP system. And guess what? Donors put their money and effort into systems that get better yield and for the electrical bill-a FAR FAR better yield per Watt than SMP.

They need BigAdv clients to do SMP because Stanford has gone and made the SMP units ludicrously big and long (larger in TPF than bigadv for a 1p at stock)....and surprise surprise....the SMP clients online cannot finish them fast enough, and when they do the points are a joke. Only the 2p and 4p and higher server blades normally doing bigadv have enough computational power to calculate SMP WUs in a reasonable amount of time.

Can you please provide more information about which SMP Projects have this issue? AFAIK, the only problematic set-up is a Single CPU Slot which may or may not get WUs. FahCore_78 hasn't reappeared for a while and FahCore_a4 is used from single Core upwards.

On my Intel Pentium Dual-Core CPU E5400 @ 2.70GHz which is a non-dedicated and folds 24/7, the longest TPF of a project is Project 7041:

Min. Time / Frame : 00:35:37 - 3,411.58 PPD
Avg. Time / Frame : 00:44:41 - 2,427.82 PPD

Given that I can easily finish this WU in under 3 days and the Preferred Timeout of 33.3 Days (Final Deadline of 72.1 Days), I can assume that almost all systems can easily meet the deadline if folding 24/7. However, if the system fold for only few hours a day, am not sure how many hours it needs to successfully fold the WU. Moreover, the Project 7501 which has a Preferred Deadline of only 2.2 Days (the shortest one that was assigned to me), has the following TPF:

Min. Time / Frame : 00:09:50 - 2,900.82 PPD
Avg. Time / Frame : 00:10:57 - 2,468.60 PPD

Thus, it too can successfully finish the WU in roughly 19 hours which is within the deadline.

In total, my system has been assigned WUs from 27 different Projects and in all cases, I was able to successfully complete the assigned WUs.

I am aware that in the past, some SMP Projects had their deadline too short for some systems to complete but AFAIK, that was adjusted.

PantherX wrote:Nope, it just means that if you have 64 CPUs and are requesting a SMP WU, the AS will look at it's table of SMP WUs and see which Project is able to run on 64 CPUs. If there is a project that fits that criteria, you will get a WU that will use 64 CPUs. If there are Projects that are limited to 4 CPUs, 8 CPUs, 12 CPUs, etc, you will not be assigned any of them since they don't match your criteria. Thus, you get Empty Work Server Message as no Projects fit your particular hardware/software requirement.

Ah, even worse, so instead of 56 idle cores you'll have 64 idle cores.

Now, a quick look on the server-status-page, only showing SMP, of all the projects having atleast 1000 wu's to send-out, all has either 1 or 2 as minimum SMP-count. Maybe I've overlooked something but AFAIK I've not seen anything about max cpu-count...

PantherX wrote:Nope, it just means that if you have 64 CPUs and are requesting a SMP WU, the AS will look at it's table of SMP WUs and see which Project is able to run on 64 CPUs. If there is a project that fits that criteria, you will get a WU that will use 64 CPUs. If there are Projects that are limited to 4 CPUs, 8 CPUs, 12 CPUs, etc, you will not be assigned any of them since they don't match your criteria. Thus, you get Empty Work Server Message as no Projects fit your particular hardware/software requirement.

If that were true, we wouldn't get so many reports about BA machines running out of work and getting SMP work instead. And it's not a hardware requirement, it's a hardware preference, just like BA is a preference.

None of your 64 cores will be idle if you use cpu:64 or -smp 64. You simply won't be assigned any projects that have an upper limit on the number of threads that is less than 64 but there are other smp projects that can and will use all 64.

A few regular SMP projects have been done on my 64 core. According to HFM they received ~180K PPD.

On the very rare occasions that there were no bigadv WUs available the 64 core setup has had no problems getting and processing a regular smp work unit.

Rattledagger wrote:...Maybe I've overlooked something but AFAIK I've not seen anything about max cpu-count...

AFAIK, it isn't available on the Server Status. However, you can find it if the Researcher states that in the announcement of the Project during the Beta phase:
Projects 9005 to 9007 -> 1 to 24 CPUs (viewtopic.php?p=254147#p254147)
Projects 9002 to 9004 -> 2 to 24 CPUs (viewtopic.php?p=250596#p250596)
Projects 10141 to 10149 -> 1 to 8 CPUs (viewtopic.php?p=249695#p249695)

Of course, there are instances where once the Project was released, it was discovered that it would fail with 5 or 7 CPUs and thus, the assignment rules were adjusted. Not all researchers post the CPU limits and sometimes, they can change the CPU limits without an announcement.

As bollix47 confirms, you will get WUs that can fold successfully on your system. You will not get the above Projects on your 64 CPUs system unless the assignment rules were changed. If you want to get these SMP Projects, then you may break down your single 64 CPU Slot into multiple ones to ensure that they can fold successfully on your system.

I must admit that the Grinch in me didn't expect my "Please" request to work. In some cases I was right and in some cases (thankfully) people are cooperating. I don't have any good way to measure how much difference this is making.

As I'm sure you realize, the projects are divided into several sectors with hard boundaries. GPU WUs cannot be run on SMP without the PI starting a new project. Then the results must be integrated and if there are any anomalies or if there are none, it must be explained in the associated paper. The partition between the bA and the SMP sectors is somewhat soft. The core-count requirements are an approximation of the distinction between BA and standard SMP which is enforced by deadlines, but those who have built 4P systems often refuse to run SMP work even when it's assigned. There was another hard boundary separating PS3 WUs from the others, but that sector has been deprecated now.

Within each sector FAH has the tools to manage priories so there's no need to tell you that Project XXXX needs more work and Project YYYY does not if they both happen to be in the same sector. The PG cannot force anybody to buy GPUs if that sector is in need, but the real problem I'm suggesting might need help is in reallocating BA resources to SMP. My suggestions were reasonable, and for those of you who are adding to that list, thank you.

My theory is based on the fact that we do see the PG altering the incentives/disincentives so there must be a scientific reason behind it, even though they have not said that's a fact. Their objective is always science, which means they don't necessarily see things the way the Donors do. Nevertheless I think it makes sense to discuss it and offer suggestions.

Bill1024 wrote:

Skripka wrote:

Bill1024 wrote:QRB is based on how fast a WU is returned. A 24, 32, 48 or a 64 core should be sending them back real fast.
More so than a Q6600 would. Just figure a way to make it so a 48 4P will be close to PPD doing either SMP or bigadv.
Say 2 x base value for 24 hours, 3 x for 18 hours, 3x for 12 hours, 4x for 8............8x for 2 hours, bonus 20 x for under 30 minutes.

Make it so for every 3 big adv you fold you have to fold 1 SMP,
I like it that everyone is throwing some ideas around.

Does absolutely nothing about the root problem. Which is that SMP units take far too long and pay too little to be worth the electricity on the 1P desktops that 99.99% of the world run on....That Stanford's best folding practices imply we should run last I knew.

Yes it does. In a nut shell make the bonus multiplier go up and the return time goes down to the point where a 4P can get close to the same PPD.
The more powerful system you build will return SMP wus faster.
Just an idea I tossed out there. The DRs and PHDs can't make it perfect, this dummy can't either.

Not even close you get about 1/2 the PPD on the best smp vs bigadv and around 1/3 the PPD on the worst. that is a diffrence of 350k to 500k PPD on my rigs

So I see a few of trends in this thread.

1. Communication regarding the 'roadmap', which may always be too short from the donors perspective, and too long from PG's? In addition, it's often only when an 'event' happens like the change in minimum core counts & deadlines that underlying sentiments get brought to the surface. That is in the absence if events people just get on with getting on, but dissatisfaction remains.

2. The method of delivery of information. Lets be honest, we can always demand and expect better, but there is cost involved. Money spent on communications is money diverted from the science and I believe it wouldn't be insignificant because of university protocols. There are some moves towards providing better communication (core_17 IRC channel), but more can be done.

3. The difficulty at present as the degree of incentive between BA and SMP. On the one hand, the 'bonus' differential is suppose to reward donors for investing in that class, knowing that due to increasing requirements they may not stay there (similar in my mind to investment rates). On the other hand, it disincentives regular SMP and causes people to be unhappy with the point drop when they fall below the minimum requirements.

In each case I think the difficulty is finding a happy medium?

Just trying to understand things from both points of view.

bruce wrote:I must admit that the Grinch in me didn't expect my "Please" request to work. In some cases I was right and in some cases (thankfully) people are cooperating.

Did you make that request on behalf of Vijay Pande or your own (just to demonstrate excellent *cough* leadership) ?

I can't follow requests from you as you don't represent or make any decisions in the project (despite keeping appearances of the contrary).

Same goes with any discussion on issues (whatever they are) with crediting or any topic whatsoever.
Having been here long enough I *know* you don't and can't make things happen.

Talking with you hoping to get things done/problems solved is a futile effort.
Some haven't but I have heard this record in the past, multiple times.


P.S.. This post has been preemptively recorded so evidence of tampering, if any, can be provided.