If there is a problem, the correct thing to do is diagnose and fix it. Your proposed solution (allowing the user to set artificial limits on this or that) creates a whole new set of boundary conditions where the scheduler may not be able to honor resource shares.
It doesn't address the source of the problem, it just throws up some barricades to limit it. The first thing is to *prove* that these "massive downloads" result in missed deadlines. Raistmer is a great example of an "expert" -- he's been around for a long time, and he's sure that BOINC will not settle in to something reasonable, but he won't leave BOINC alone, which prevents it from settling into something reasonable. It's hard to do, especially when it takes days or even weeks of observation -- but the most common complaint is either "too much of project 'a'" or "won't fetch work from project 'b'" and in both cases the complaint comes from looking at the moment, and not considering how things change over time. I'd love to see some sort of pop-up that would explain why BOINC chose a project to download, or why a work unit is running high-priority. Ed A wrote: > 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.
