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. > _______________________________________________ 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.
