Folding Forum

It does slow down the project. There just aren't any good solutions to the problem, and you know that. Orion, did you have a suggestion, or just more unhelpful sarcasm?


Tear had a good idea that might work in this one example, because this is a single user team.

However, it raises a whole other set of conerns though. Donor Privacy vs. spam concerns, and time management concerns (who sends the email, what does it say, how bad does each problem have to be before PG intervenes, does PG want to open this pandora's box of endless user management, because where do the emails stop down this slippery slope? 1 WU past preferred deadline? 10? 100? 1000? Who monitors for donors like this? Who has the resources? What happens when there are 20 offenders on a team and no single email address?)

Then there is the question of what some would call special treatment for BA users to send this one email...

Pande Group is more than capable of answering all those concerns I raised themselves.... I only raised them so people know there is a lot more to consider than just a few late work units, not to get feedback the concerns. Thanks.

Joe_H wrote:FWIW
Your estimates are off. Most of the WU's listed as done by fac have only been assigned to one other folder. Out of the thousands of WU's done in those projects during that time period they are a small percentage. Your WAG of 50% reduction in productivity is off by at least a factor of 10.

I would question 1000's more like a few hundred the server stats show less than a hundred being returned on any given day. So from the information available to the general public the scenario is quite possible. That information is available in the server stats on the wu rcv column. My WAG was not a complete WAG it is just a given possible scenario with the information available to the folding public.

http://fah-web.stanford.edu/pybeta/serverstat.html

7im, I would say tear has a very good idea and don't see a need to improve on it regardless if some may think that someone else is getting favoritism. They don't need to know what fac is getting for emails from PG...none of their business, yours or mine.

You may see my pondering as unhelpful sarcasm. I'm just looking for consistency in said statements.

Seeing as BA is opt-in and each client has a unique code surely there could be a floor completion rate? Something like if 2 of the 5 most recent WUs or 6 of the latest 10 aren't completed on time that client is allocated back to regular SMP for a period of time?

Obviously it would take each client reporting it's performance factor & the severs to log that for a real solution to occur...

Kakao shows a 30 WU average for FAC over the last 2 weeks.

pybeta shows an average of 675 BA WUs received per day on this one BA server .201 for P810x for the last 7 days.

Even tripled (120/675) for your guess (orig 30, plus 3x reassigns), it was only 18%, based on available facts.

Now with the addition of the mod data, where FAC's WUs were only being reassigned once, we are down to 60/675, or 9% based on available facts.

orion wrote:You may see my pondering as unhelpful sarcasm. I'm just looking for consistency in said statements.

I don't see any inconsistency between the statements "missing the preferred deadline sets the project back" and "missing the deadline on X number of WUs doesn't set the project back that much." It's a matter of scale. PG would like everyone to return every WU on time, hence why they've incentivized doing so, but they know that it's not going to happen. It still doesn't hurt to ask for that while privately acknowledging that X number of missed deadlines is tolerable and keeps the project moving along at an acceptable rate.

I'm going to close this thread.

If "fac" wants our help, he/she is going to have to provide some information from his/her log. Grandpa_01 has brought this potential problem to our attention, but we need information directly from the person themself, like what kind of machine(s) they're running, how many machines they have, what passkey they're using, etc.

As was already said, it does appear that fac added the -bigadv flag and he/she probably has a machine that should be configured for standard smp. They probably got bad advice from somebody and just don't follow their PPD closely enough to realize they've created a problem. Stanford can't be responsible for people who make unwise choices with their hardware -- they just have to make FAH robust enough that it keeps any one person from causing serious damage to overall production.

There was a long forum discussion about whether the AS should use the only data it has (Core count) to exclude all machines that can't meet the preferred deadline, no matter what their clock rate is or if it should include them and make it the responsibility of the Donor to choose to opt-out. The latter was chosen, and apparently this is an example of what can happen.

Have "fac" contact me or one of the Mods by PM if we need to re-open this topic.