Well, OK, I will try EXACTLY that config. Will report Einstein's RAC/SETI's RAC on that host cause it will be good indicator for if project shares are obeyed or not What BOINC version intended to work correctly with project shares? I use 6.10.16 on that host, to what build I should upgrade if should?
----- Original Message ----- From: <[email protected]> To: "Ed A" <[email protected]> Cc: <[email protected]>; <[email protected]> Sent: Tuesday, January 26, 2010 10:52 PM Subject: Re: [boinc_dev] Suggestions > EDF is NOT a problem. Deadlines must be met once the task is on the > computer. EDF is not going away. > > Have you actually tried my suggestion with the current code? The current > code does work differently than somewhat older code. > > s...@h at 1,0000,000, Einstein at 1, "Connect Every X at 0, and Extra work at > 2. Then leave it alone for several weeks to see what happens. Einstein > will start off by doing about a days worth of work to prime the system. > What happens after that? If it really down loads a huge amount of work > after the first day from Einstein, then there is a bug someplace. > > jm7 > > > > Ed A > <canoebey...@gmai > l.com> To > Sent by: [email protected] > <boinc_dev-bounce cc > [email protected] > u> Subject > Re: [boinc_dev] Suggestions > > 01/26/2010 02:39 > PM > > > > > > > > Unfortunately this solution is not a solution. What too often happens is > that the primary project will run out of work for an instant and the > "backup > project" then DLs massive amounts of work that has to be aborted or will > go > into panic mode because of the low resource share. The situation is > completely untenable for projects that allow only limted WU downloads > (like > Yoyo ECM, MilkyWay, GPUGRID, etc). Many of us have tried workarounds for > years and the only solution that ever worked was to use an alternate BOINC > clone such as BoincStudio. These options should be simple to add as > they've > been implemented by hobbyists before. If you don't want them to be > generally available to novice users simply put them in an "expert" section > or implement them in one of the text files if you must. Even that would > be > better than the current situation. > > Please don't get me wrong, I feel that BOINC has been a great > accomplishment. It's getting better and better. Most recently the ATI > support has been a wonderful addition. There is a lot of grumbling out > there among the experienced users though and almost all of it has to do > with > the inability to manually control the application better. > > Regards/Ed > > > 2010/1/26 <[email protected]> > >> >> 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". >> >> jm7 >> >> > _______________________________________________ > 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.
