Ed, Based on my observations, 90% of missed deadline issues are self-inflicted -- caused by micro-managing.
It's hard for some people to do: to leave BOINC alone and let it worry about deadlines, and let it meet deadlines and honor resource share. People look at the queue and say "Why doesn't BOINC have 'project x' when it has a 90% share?" and don't want to even consider that adding work when something might run late is a bad idea. Most of the people here have worked on scheduling for years. It's difficult. I can't claim to have contributed much (if anything) to scheduling, but I have gone to the trouble to figure out most of how it works. ... and everyone wants their pet constraint added to a list of highly contradictory requirements. For example, every so often someone says "why doesn't BOINC always process in deadline order, wouldn't that be simpler?" The answer is: "because we tried it, and it failed rather spectacularly." If you feel strongly that BOINC as is is simply unworkable, then writing your own scheduler is an option. I suspect if anyone does that, they'll pretty much converge on what we have now, but if they want to try, it's up to them to maintain their code. But, at the end of the day, unless you're willing to code, the best you can do is try to convince someone that this is a good idea. Yeah, "read the forums" -- I do, Ed. I know what is said. I've even committed some of the sins myself. I've looked at BOINC and said "this really needs my help, it's going to fail miserably." .... and then I said "let's see" -- and every time it's done fine. I understand what Raistmer and you are saying about keeping pairs of science apps. from running at the same time. It'd be nice, but I don't think it's worth the potential heartaches. So, I respectfully disagree. If you want to repeat that I'm not considering your position, be my guest. -- Lynn On 2/12/2010 11:25 AM, Ed A wrote: > Obviously few post their problems here and I think you seriously > underestimate the production of serious BOINC hobbyists. As far as altering > the client, it's been done and clients have been made with improved > capabilities. To keep alternative clients up to date with improvements such > as GPU support etc. is tedious though and do you really want code > branching? Sounds like a nightmare that can easily be avoided. As far as > missing deadlines, it won't happen with power users. Instead the current > situation encourages aborting WUs, resetting projects, resetting debt, > suspending WUs, enabling and disabling work requests, micromanagement, etc. > in order to get the client to run projects in an efficient manner. It's > absolutely necessary in the high resource usage projects mentioned. Most > try those projects and just throw up their hands in frustration and leave > rather than micromanage. Read the forums. It seems so simple just to allow > us to limit the number of instances a project can run on a machine. BOINC > could know this setting and schedule accordingly. Allowing us to set a > maximum number of WUs that a given project can queue would also alleviate > any chance of missing deadlines. The present system is the major cause of > missed deadlines IMO. > > Regards/Ed > > > On Fri, Feb 12, 2010 at 12:59 PM, Lynn W. Taylor<[email protected]> wrote: > >> My comments do not represent the BOINC project, or U.C. Berkeley. >> >> Certainly 1% is an estimate, based on the fact that there are 1.8 >> million people running BOINC, and far less than 18,000 commenting about >> issues. >> >> If all the power users disappeared tomorrow, most of the computing power >> would still be intact -- there would be a dip, but even if you look at >> CPU cycles and not at the raw count, the "power users" are still very >> much a minority. >> >> I'll also point out that BOINC is open source. Someone could if they >> wished toss out the whole scheduler (and resource shares) and replace it >> with something much simpler, that followed only those rules they wanted. >> >> I think that adding another limitation to the existing scheduler, >> especially if it is an absolute limitation (do not ever run two of these >> at once) will make missed deadlines more likely. >> >> The most common complaint/comment is "why did BOINC run this, when I >> think it should be running this other work?" Adding more rules makes >> the scheduler decisions harder to understand. >> >> On 2/12/2010 10:34 AM, Ed A wrote: >>> Where is this< 1% figure coming from? While the percentage of power >> users >>> may by relatively small, their contribution to production is not. To >> ignore >>> the users who produce the most is not wise IMO. As I've mentioned >> before, >>> hide controls that you don't want generally available to the casual user >> in >>> a power user section (or if you must, in the cc_config.xml). The >> unintended >>> result of ignoring the needs of the avid BOINC user is that we have to >> make >>> things work in ways that are probably in some cases not the best for the >>> projects. Please don't ignore the input of those that use BOINC the most >>> and from a user standpoint (and from the standpoint of leading edge >>> equipment usage) know it the best. >>> >>> Regards/Ed >>> >>> >>> On Fri, Feb 12, 2010 at 11:56 AM,<[email protected]> wrote: >>> >>>> When the minority is< 1% is it worth the time and effort (both >>>> constrained), and is it worth the probability of breaking the usefulness >>>> for the 99%? >>>> >>>> jm7 >>>> >>>> >>>> Raistmer >>>> <[email protected] >>>> > >> To >>>> Sent by: "Lynn W. Taylor"<[email protected] >>> , >>>> <boinc_dev-bounce<[email protected]> >>>> [email protected] >> cc >>>> u> >>>> >> Subject >>>> Re: [boinc_dev] 6.10.32 failing >> to >>>> 02/12/2010 12:36 maintain sufficient work >>>> PM >>>> >>>> >>>> >>>> Well, "democracy" not always the best thing. >>>> Even if majority use set-and-forget, MINORITY still doesn't. I heard in >> USA >>>> >>>> is now stylish to care about minorities in some pretty weird areas, >> maybe >>>> it's worth to add BOINC to this too? :P >>>> app_info.xml is used by minority, not majority, too, btw.... >>>> >>>> >>>> ----- Original Message ----- >>>> From: "Lynn W. Taylor"<[email protected]> >>>> To:<[email protected]> >>>> Sent: Friday, February 12, 2010 8:19 PM >>>> Subject: Re: [boinc_dev] 6.10.32 failing to maintain sufficient work >>>> >>>> >>>>> If "operator knowledge" is required, then BOINC is not "set and >> forget." >>>>> >>>>> ... and if the majority of BOINC users are "set and forget" that has to >>>>> drive the feature set. >>>>> >>>>> On 2/12/2010 7:36 AM, Raistmer wrote: >>>>> >>>>>> Actually I don't think it's really complex. All needed is operator >>>>>> knowledge >>>>>> what app performs better paired with what another app. >>>>>> >>>>>> This knowledge can be aquired from simple experiments. >>>>> _______________________________________________ >> >> > _______________________________________________ > 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.
