The credit calculation is encapsulated in a single function,
assign_credit_set().
You can change policy by changing or replacing this function.
Maintaining runtime statistics (the host_app_version table) is used for
job runtime estimation as well as the credit system.
It needs to stay even if you change credit.
-- David
On 8/16/2016 7:40 AM, Christian Beer wrote:
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.
