Folding Forum

bruce wrote:The whole point of bigadv is that a trajectory that goes 48 times as far in a given calendar time discovers important facts that 48 individual trajectories cannot discover. I can't say if it is 48 times as valuable or more valuable by some other factor (i.e.- how should bonus points be computed), but it's certain that without some kind of QRB, the same people running the same hardware would produce less useful science.

here comes a different idea: how about introduce a third class of projects like "small BA" ( a better name is required ). But if regular BA has scaling factor of 48; why not cut it in two half ( 2x 24, k-factor also half ) which should still give lots science value, points between BA and regular CPU, and keep the donors with low BA system in a group feeling adequate compensated. Now could benefit both sides.
This mid class group could have a fixed 8c/16t minimum with also some challenging timelines; but easier compared to classic BA. If once high class desktop CPU sneak in here and can make the timelines: good !

Leonardo wrote:

but I would definitely want to see the total completed work units tally tied to the user rank without starting over at zero.

I suspect there's a problem with that… it's not something the donor has any control, or even influence, over- it's entirely down to the work servers and can give wildly varying results.

For example, the machine I'm typing this on is currently processing a p7647 WU, it'll take around 30 hours and net me ~18,000 points.

Another machine of similar spec is processing a p9003 WU, it'll polish it off in less than two and a half hours for ~1750 points. Over the same period both earn (broadly) the same credit which I would interpret as (broadly) work of the same value to Stanford.

If they belonged to two donors then, depending on luck with the work servers, they could have roughly the same credit but one having processed an order of magnitude more WUs….

(I'm assuming that the servers don't make any attempt to "even out" the allocation of WUs; I've never seen any indication that anything other than chance is involved in this.)



edit to add- Whilst I think it likely that the WU allocations do, in practice, more or less "even out" I'd rather not have my past work value recorded with a number including a significant element of chance. Even if it happened to work in my favour!

billford wrote:I suspect there's a problem with that… it's not something the donor has any control, or even influence, over- it's entirely down to the work servers and can give wildly varying results.

Users have some control over work-assignments.

If not mistaken where's currently 5 BigAdv-projects, ranging 1.8 - 2.4 days in deadline, so let's say a computer capable of running these will use 1.5 - 2 days per wu.
On the same computer, SMP will probably be 0.1 - 0.4 days. For GPU, a high-end GPU will maybe be around 0.17 days per wu.

Meaning, even the worse-case SMP and best-case BigAdv, the same computer will do 4x more wu/day running SMP.

While on the BigAdv-capable computer it's difficult to choose between SMP and GPU since here it's luck-of-the-draw, on normal home-computers a high-end GPU will have the advantage since nearly all SMP-wu's will be longer.

Accepting that, it seems that any donor control is largely exercised by the hardware they've chosen to invest in… which would bring this topic pretty much full circle

it seems that any donor control is largely exercised by the hardware they've chosen to invest in… which would bring this topic pretty much full circle

Indeed.
My point was not that the number of work units completed would determine a user's rank, just that the work units completed would be cumulative, and would not start from zero if the current points awarding system were scrapped and a new points baseline came into being. Just as it is today, the points - measure of production (faulty or not), determines rank, not the number of work units completed. Again, I must stress that I am probably not objective. The points and competition are lots of fun, but the work units completed give me great satisfaction even if no one else notices.

Lets say some one wants to future proof their investment for a few years to come.
There are 10 core 20 thread Intel chips coming out that can do 4 processors for a 80 core system.
Gromacsis the software behind SMP and bigadv right?
Is there a limit to Gromacs software or any limit any where as to how many cores can fold?
Can we have 120 core 4p in the spring when the new chips hit the stores?

tear wrote:

P5-133XL wrote:

kasson wrote:The conversation about what the role of BA is in the project is a good one to have. The BA program has been of particular scientific benefit to my research group, but the FAH project as a whole has needed to position BA within a broad range of scientific needs.

Data that helped inform where to place the new thresholds:
~5% of active FAH machines with SMP>2 are at least 24 cores
~4% of active FAH machines with SMP>2 are at least 32 cores

Adjusting deadlines to match new hardware requirements will be a necessity. This is something we will have to calibrate carefully, and we unfortunately cannot state what those deadlines will be now. Our goal will be to allow reasonable 24-core and 32-core machines to make the deadlines. So the bottom line is that there will be deadline changes effective Feb 17 and Apr 17, precise nature TBD based on calibration experiments.

Those numbers are useful to put a scale of bigadv against all SMP but I think more useful would be:

total # of active FAH machines running bigadv
# of active FAH machines running bigadv >24 cores
# of active FAH machines running bigadv >32 cores

Then they can be converted to percentages.

The reason those numbers are more useful is that it tells you better how many machines you are actually affecting when you institute your new policy. What you need to know is if you are affecting 5% of bigadv's or 50% of those machines when you go from 16 to 24/32.

^^ +1
Performance (average bigadv WU processing time) vs number-of-hosts histogram would be even better.

And few more thoughts:

0. While I understand that it may be difficult to provide new deadlines today, I urge that data are provided ahead
  the change date.

1. Someone mentioned the need for roadmaps et al. and that is very valid point.

  Try walking in shoes of someone who just obtained a BA-capable system (which is usually purchased using
  donor's own funds and nearly as often donors have _alternative_ spending choices but they decide to help;
  they decide to help this project.... think about it, let it sink for a while).

  Anyway, this announcement tells the donor that his/her contribution will be worth (yes, points == worth) less in 2 months
  and, had the donor known, perhaps he/she would have made different choice?
  Two months is pretty short of an advance, would you not think?

  Also, from my perspective, the requirement change looks rushed/chaotic to me. There have been no changes for very,
  very long time and now we get two over the course of four months. To me it looks like no one was paying
  attention to bigadv performance for a long time, just recently decided to check up on it and realized that performance
  isn't where it needs to be. Seems like a panic reaction to something that should've been monitored on regular basis.
  Of course, that may not be the truth, but that's how donors *may* see it.

  How about PG sets two dates per year when revisions of BA requirements will be permitted (instead of 2
  revisions within one quarter -- sic!). Each change would be announced 6 months ahead of time, too and
  would be accompanied by statistical data to explain/support the change.

  For instance, on Feb 15 you announce a change that's effective Aug 15 while providing explanation/data
  on why it's being done. Similar thing happens on Aug 15:
  (a) changes announced previous Feb become effective
  (b) the project announces changes for next Feb together with supporting arguments and data

  Yes, that means more work for the project but doing this will ultimately yield gains (if executed properly).
  Higher donor satisfaction == more contributions.

2. Another item that surfaced is lowered gratification when given hardware ceases to be bigadv-capable

  On one hand, the project needs to accelerate (that's the biggest argument), on the other, people don't enjoy
  the feeling of being "less useful".

  While current approach (advanced notice) is not, in principle, bad (I think), it could have been executed
  better (vide item 1 above).

  I would honestly give a chance to/seek feedback on:
  (a) suggestion from #1 -- predefine two dates when changes will be announced/allowed
  (b) honest, upfront and advance information (a message from server to the client? sticky post in the bigadv
     subforum? both?) that prepares donors for _inevitable_ bigadv-obsolescence
     EDIT: there is also way of telling who's folding bigadv units -- you can use passkey to subsequently retrieve
          donors' e-mails -- why not communicate over e-mail with bigadv donors?

  Perhaps (a) (which gives de-facto guarantee of 6 month bigadv-usefulness span) combined with (b)
  (being upfront and down to earth about bigadv-obsolescence) would be acceptable?

Leonardo wrote:Just as it is today, the points - measure of production (faulty or not), determines rank, not the number of work units completed.

The Stanford stats do maintain a count of the number of WUs completed. Would it be helpful if there was a stats page giving a ranking by number of WUs completed? You or your team might be more interested in that as a measure of work completed rather than the number of points. (Nobody alleges that either measure is perfect but if you prefer the other ranking, you'd be able to use that method.)

Bill1024 wrote:...Gromacsis the software behind SMP and bigadv right?
Is there a limit to Gromacs software or any limit any where as to how many cores can fold?
Can we have 120 core 4p in the spring when the new chips hit the stores?

Correct, GROMACS is used on all CPU FahCores currently available.

When it comes to limits, there are two different limits:
GROMACS -> AFAIK, there isn't any and I think I have read about it scaling up to 128 CPUs without any issues. Usually, the system is dedicated to that GROMACS task so you get complete CPU Count, i.e. there isn't any testing done of 62 CPUs on a 64 CPUs system.
FahCore -> Another limit which is implemented by PG. The reason is that donor's system may not be dedicated to F@H so any bad values are blacklisted and are mapped down to ensure that the value is able to decompose without any issues on a large number of projects, thus, can fold WUs.

Assuming that those CPUs and motherboards are released, I don't see why not. Except that the cost would be prohibitively expensive.

Thank you for your reply.

tear wrote:[
     EDIT: there is also way of telling who's folding bigadv units -- you can use passkey to subsequently retrieve
          donors' e-mails -- why not communicate over e-mail with bigadv donors?

Agree to everything your wrote, except the email thing for BA donors; while it would be good for active BA donors the same information is even more important for "want-to-be BA donors" like myself.

An overly broad assumption is being made by tear that knowing a passkey will map to an email address. I assume he is extrapolating from the fact that using the same username and email address will get you the same passkey sent back to you if they are used to request one. However, it is also possible that a one-way hash is being used to generate a passkey. Thus, it may not be able to reverse the hash with a passkey and get an email address to send to.

Just ask the NSA...they know

I agree with tear's comments about upfront announcements - for a project that's in it for the long term, to give a deadline of just two months, which will have a significant downgrading effect on a number of users* (particularly the 'enthusiast' community), does a lot of damage to the project, and suggests poor planning, or last-minute dissemination of information to the donor community.

Last time the BA changes were made, we lost key members of our Folding team - this time round, comments have already been made about additional people leaving ..... it doesn't have to be this way with some thought-out planning which is shared with the community!!

A roadmap, for example, doesn't have to be set in stone, but could give donors a flavour of what's being considered down the line, whether it works out or not (after all, it's not commerically sensitive information is it ....?!).

* I should add that I am not affected by this particular announcement, but I can imagine the frustation of those who are. (The effect of the current dearth of Core17 WU's, on the the other hand, ...... )

Two months? Try two years! Two years ago it was clearly stated that BA was an experimental program and that it would be reassessed from time to time. And a year ago, it was changed. And again the message about future revisions were to be expected was repeated. I would call two years worth of notice to be very upfront. Not at all last minute as you seem to think.

As for a better roadmap, yes, I would like to see that as well. But fah's ability to do that is very limited because we're all a slave to the PC hardware development cycle. Fah can no more predict the exact date the next GTX 790 will hit the street than NV can. Or when NV might get their JIT software working and double the speed of GPU folding. Anyone here know those dates?