I've tried to modularize the runtime estimation and credit calculation system (RECCS) in a local branch so we could more easily switch between implementations of different credit systems (on a per app level). But because CreditNew is very deeply involved in several key components I find it hard to establish an interface that is generic enough to decouple the RECCS system from the rest of BOINC.
Such a modularization would also help in building a simulator that can use different strategies (credit/runtime systems) just as they are used in the scheduler. I've halted this for now because of lack of time but I would be willing to share what I have and write a Design document on how to modularize it further. Regards Christian On 15.08.2016 08:18, Jason Groothuis wrote: > I concur with these statements after having studied the mechanism from an > engineering perspective over the last couple of years. Steady state and new > host/app were observed, on seti/seti-beta, along with fresh app launch on > single appversion regimen with the kind help of Albert@home staff (before me > running out of resources to take the study further). > > > The fundamental design concepts weren't found to be problematic, though some > of the implementation assumptions and choices were. Outcomes were that the > dominant instabilities were (engineering) control systems related, and that > characterisation of the existing system (via matching such a simulation to > real-world) would aid communication of the problems and potential solutions. > > > What is a relatively simple engineering task of estimate localisation, is > quickly conflated with passions when Credit is mentioned. That quickly mires > the genuinely solvable issues in Inertia. > > > So In my view, progress could be made by: > > - simulate the existing mechanism, under original CPU-FPUonly state, CPU-SIMD > enabled state, GPU only state, and para-metrically mixed state > > - Use that (refined) simulation as reference comparison to real-world, and to > formalise potential practical solutions. > > - Change the name from CreditNew to 'estimator'; or somesuch > > > > > > > > ------------------------------------------------------------------------------------------------------ > Jason Richard Groothuis > ------------------------------------------------------------------------------------------------------ > > > ________________________________ > From: boinc_dev <[email protected]> on behalf of David > Anderson <[email protected]> > Sent: 15 August 2016 08:14 > To: [email protected] > Subject: Re: [boinc_dev] 4th Gen BOINC credit system > > My thoughts: > > 1) The basic ideas behind the current credit system are sound, > but there seem to be some problems with the details, > in particular what happens when new app versions are added. > > 2) We need a simulator that models credit calculations for various scenarios > (synthetic, or based on trace data from a project). > Such a simulator would help identify the problems with the current system, > or would demonstrate that a new scheme works better. > I don't think we should consider a new system without simulator-based > validation of it. > > -- David > > > On 8/14/2016 9:06 AM, CM wrote: >> Hey, >> >> A '4th gen BOINC credit system' thread was created over at the official BOINC >> forums: https://boinc.berkeley.edu/dev/forum_thread.php?id=10953 > [Discussion] 4th Generation BOINC credit > system<https://boinc.berkeley.edu/dev/forum_thread.php?id=10953> > boinc.berkeley.edu > I originally started a discussion over at cryptocointalk about this: > https://cryptocointalk.com/topic/46130-discussion-3rd-generation-boinc-credit-system/ > > > >> There's been about 77 posts to the thread, the general consensus was that a >> new >> BOINC credit system is a good idea but thus far the definition/specs of such >> a >> next gen system has not been agreed upon. >> >> What are the BOINC dev's thoughts on this topic? I'd love to continue this >> discussion & work towards a next-gen BOINC system. >> >> Cheers guys :) >> >> _______________________________________________ >> 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. _______________________________________________ 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.
