I'm not really disagreeing with you or Mikus. Mikus says a project with too many participants is in trouble, and he's right.
If every work unit went out, was out for a few hours, and then returned, 24/7/365, the problem I'm talking about does not exist -- the flow is even. It is when you have an outage (including "dumb project level mistakes"), when the flow interrupted and returning work gets backed up, and you have lots of clients out there who are hungry for more work, that's when this becomes an issue. Right now, the BOINC client is going to work very hard to push work to the server(s). As for "all this stuff" -- I think it'd be 20 lines of code in the client, and none at all on the server. I think by default, everything should be as-is. It's a tool that you'd only want in exceptional times, and can ignore the rest of the time. -- Lynn Carl Christensen wrote: > I hate to rain on this exciting topic, but I tend to agree with Mikus. I > don't think we would want to add all this stuff to the client for what is > basically a problem/fault of a project and their servers. BOINC can't forsee > all sorts of problems like this, and for example when I make dumb server or > project-level mistakes that break BOINC then the onus (and shame :-) is on me > to correct things. > > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
