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?
). 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. 
