... and if you left it alone, it would reach a nice stable equilibrium, with a proper DCF (so it can predict deadlines and request work accurately) but instead you say "oh, no, it's not working!" and make it stop.
Of course BOINC crunches the Einstein work to completion immediately. With a 1000:1 resource share anything else would devote less than two minutes per day, and that isn't enough to MEET DEADLINES. You'd be really angry if deadlines were missed. We also have this amazing ability as crunchers to forget that there are other stakeholders out there -- that the projects themselves are vitally interested in how BOINC works. It's bad enough that a 1000:1 ratio of shares is allowed, because you take up room in the BOINC database at Einstein, but you aren't going to contribute much. We've seen other projects suffer severe loading problems when s...@home is down. It makes their capacity planning difficult, and it aggravates their loyal users when all of the work gets sucked up. The fix would be to limit BOINC to one work unit per project until it has done a dozen or so, but I'm not sure it's worth the code to solve what is really a small problem. If you're willing to add a project as a "backup" you should be willing to do some work for them in exchange for that privilege. Raistmer wrote: > All I know that every time SETI have no work and I activate Einstein > with resource share 1:1000 regarding SETI it download FEW, not one (!) > tasks and immediately starts to crunch them. > If SETI have work it will not go back and return CPU for SETI, it will > crunch all those tasks to completion. > And then SETI can have no work again and again few Einstein tasks will > downloaded and crunched to completion and so on and so on. > True backup project would return CPU to main project and get it back > ONLY if their tasks are REALLY near deadline. > Crunching time for einstein task 6 hours. Deadline - 2 weeks. Then what > the hell it crunches all 6 hours tasks one by one just to download next > ones while it could keep these ones quite until next SETI outage?! > Do you wanna say that 1:1000 just not enough? Or what ? > And, BTW, BOINC _is_ for crunchers. They donate resources and have right > to donate it > 1) EFFECTIVELY. > 2) Accordingly to their preferences. > > My current preferences: > give einstein go only if SETI can't do work. Project shares CAN'T > fullfil this goal. > > ----- Original Message ----- From: "Lynn W. Taylor" <[email protected]> > To: <[email protected]> > Cc: <[email protected]> > Sent: Tuesday, January 26, 2010 9:08 PM > Subject: Re: [boinc_dev] Suggestions > > >> As I understand the concept of a "backup project" it is a last resort, >> when you can't get anything else, do this. >> >> If you have a 1,000,000:1 ratio between projects, it seems IOTTMCO that >> after the first work unit, the project with the lowest share will go for >> years before it fetches ever again. >> >> The only difference between a "true" backup project and a really big >> resource share is that the backup project will only occasionally get >> work, while the one with the high resource share might do one work unit >> once in a while if the "main" projects are always healthy. >> >> We keep coming back to "high priority" as if it's a problem. >> >> If the BOINC client downloads work, it is obligated to return it on >> time, otherwise your waste clock cycles would be wasted, and the project >> would be passing out work with no benefit to the project. >> >> BOINC isn't just for the crunchers. Projects have a say too. I don't >> know why projects would want machines that don't return work except when >> some other project runs dry -- the best that can do is soak up work that >> would have gone to their loyal participants. >> >> As for setting cache sizes and WU limits "by project" that sets too many >> limits on work fetch to be able to follow resource share. >> >> -- Lynn >> >> Raistmer wrote: >>>> Set the resource share of the backup project to be really tiny >>>> compared to >>>> the primary project. A ratio of a million to 1 is possible, and that >>>> would >>>> have the backup project only doing an hour of work every century on its >>>> own, after a few tasks to get it into the overworked state. Set your >>>> "Connect every X" to match reality (0 if you are always connected), and >>>> your "Extra work" to be a couple of days (long enough for most >>>> outages)l. >>>> An overworked project (and the low resource share project in this >>>> case is >>>> almost certainly going to be overworked) will only be asked for work if >>>> the >>>> total queue is < "Connect every X". >>>> >>> No, this will no way be the same as true "backup project" feature. >>> With big difference in resource shares all downloaded work will >>> immediately >>> go into high priority and such project will always do more work when >>> actually needed as it would be only backup project to some other project >>> that time to time out of work. >>> Backup project feature requested many times indeed and very useful and >>> needed feature IMO. >>> >>> _______________________________________________ >>> 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. >> > > _______________________________________________ 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.
