Re: [boinc_dev] 4th Gen BOINC credit system

2016-10-07 Thread David Anderson 

Yes, EmBOINC would be useful as a credit simulator.
The current credit system uses databased host info
(e.g. the host_app_version table)
so it would be easiest to have a real BOINC server behind the simulation.

EmBOINC hasn't been used for a while so it would take some
tweaks to make it work again.

-- D

On 10/7/2016 12:54 PM, Juha Sointusalo wrote:
On 15 August 2016 at 01:44, David Anderson > wrote:


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.


Just came across a link to EmBOINC 
 in Trac. From the 
description it sounds like it could form a good basis for such simulator.


-Juha


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-10-07 Thread Juha Sointusalo 
On 15 August 2016 at 01:44, David Anderson  wrote:

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

Just came across a link to EmBOINC
 in Trac. From the
description it sounds like it could form a good basis for such simulator.

-Juha
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-16 Thread Christian Beer 
On 16.08.2016 21:02, David Anderson wrote:
> The credit calculation is encapsulated in a single function,
> assign_credit_set().
> You can change policy by changing or replacing this function.
I didn't come along this function. I need to look it up what it does.
>
> 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. 

My RECCS approach also had the goal to decouple runtime estimation from
the credit system. I didn't make that clear in my email. That's the part
where I struggled, putting the runtime statistics into a module and
feeding it data without knowing what data it needs. If I understand the
CreditNew study right one of the problems is that the Credit system
impacts the runtime estimation which increases the instabilities that
are in the estimation. So I want to have a way to decouple the two systems.

Regards
Christian

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-16 Thread McLeod, John 
There is a problem with credit inflation.  If we change the long term resource 
share to be based on granted credit, then the credit granted will tend to 
normalize.  There are a few open questions on exactly how to do this, but it 
should be possible.  

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of David 
Anderson
Sent: Tuesday, August 16, 2016 3:02 PM
To: Christian Beer <christian.b...@aei.mpg.de>; Jason Groothuis 
<jason_grooth...@hotmail.com>; boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] 4th Gen BOINC credit system

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 <boinc_dev-boun...@ssl.berkeley.edu> on behalf of David 
>> Anderson <da...@ssl.berkeley.edu>
>> Sent: 15 August 2016 08:14
>> To: boinc_dev@ssl.berkeley.edu
>> 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

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-16 Thread David Anderson 

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 <boinc_dev-boun...@ssl.berkeley.edu> on behalf of David Anderson 
<da...@ssl.berkeley.edu>
Sent: 15 August 2016 08:14
To: boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubs

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-16 Thread Christian Beer 
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 <boinc_dev-boun...@ssl.berkeley.edu> on behalf of David 
> Anderson <da...@ssl.berkeley.edu>
> Sent: 15 August 2016 08:14
> To: boinc_dev@ssl.berkeley.edu
> 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
>> boinc_dev@ssl.berkeley.edu
>> 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
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) ent

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-15 Thread Richard Haselgrove 
On Monday, 15 August 2016, 19:55, "McLeod, John"  wrote:


 

 A few notes.
...3)  How do we handle failed / late / invalid tasks?  Ones that have used 
resources, but are not going to generate credit?  Projects with a large % of 
failed / late / invalid tasks on this compute?

Ideally, by having a far more robust than current quota restriction system. 
There's no point in permitting continued 'participation' in a scientific 
research project by a host which is no longer contributing valid science (if it 
ever did) - and whose owner shows no willingness to engage with the project 
administrators or the rest of the volunteer community. We all know who they are 
and where they can be found.
Projects where the scientific administrators show no willingness to engage with 
the rest of the volunteer community are a different kettle of fish entirely.



  
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-15 Thread McLeod, John 
A few notes.
1)  The resource share for what to run next needs to be responsive to what is 
happening on the local computer, and so would have to be based on resource 
usage.
2)  The long term resource share would have to be calculated well after the 
task is completed - after the credit is granted.  This will be anywhere from 
seconds to weeks after the work is done.
3)  How do we handle failed / late / invalid tasks?  Ones that have used 
resources, but are not going to generate credit?  Projects with a large % of 
failed / late / invalid tasks on this compute?

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Eric 
Korpela
Sent: Monday, August 15, 2016 2:37 PM
To: CM <cont...@grcnode.co.uk>
Cc: BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] 4th Gen BOINC credit system

There are a few major issues with the current credit system (credit_new).

The first is that nobody uses it.  Most projects (possibly all but SETI@home,
if what I'm told is correct) stayed with the old system.

The second is that there is still no consistency between projects, and that
wouldn't be fixed even if everyone used credit_new.

Which gets us to the third issue.  There is no longer any significant cross
project relationship between credit and work done.  The relationship was
tenuous a decade ago when SETI@home was the only project that actually
calculated how many FLOPs were being done, now it's nearly entirely gone.
The people who volunteer only to boost their RAC will happily migrate to
the project with the highest credit grants and the FLOPs shown at stats
sites are likely to have no relationship to reality.

There are ways that the system could be stabilized.  One way would be to
tie resource shares to RAC rather than wall time.  (I was involved in a
project with a 4% resource share.  It would typically supply 50% of my
total RAC, because its credit grants were in now way tied to actual work
done.)

If resource share was time to RAC, a project with 4% resourcre share would
create 4% of the RAC. If a project wanted to increase the number of
participant, it could increase the credit it offered, but that would reduce
the net resource share from people who participate in multiple projects.
Currently there is no penalty for increasing the credit offered.




On Sun, Aug 14, 2016 at 9:06 AM, CM <cont...@grcnode.co.uk> 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
>
> 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
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>



-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-15 Thread Eric Korpela 
There are a few major issues with the current credit system (credit_new).

The first is that nobody uses it.  Most projects (possibly all but SETI@home,
if what I'm told is correct) stayed with the old system.

The second is that there is still no consistency between projects, and that
wouldn't be fixed even if everyone used credit_new.

Which gets us to the third issue.  There is no longer any significant cross
project relationship between credit and work done.  The relationship was
tenuous a decade ago when SETI@home was the only project that actually
calculated how many FLOPs were being done, now it's nearly entirely gone.
The people who volunteer only to boost their RAC will happily migrate to
the project with the highest credit grants and the FLOPs shown at stats
sites are likely to have no relationship to reality.

There are ways that the system could be stabilized.  One way would be to
tie resource shares to RAC rather than wall time.  (I was involved in a
project with a 4% resource share.  It would typically supply 50% of my
total RAC, because its credit grants were in now way tied to actual work
done.)

If resource share was time to RAC, a project with 4% resourcre share would
create 4% of the RAC. If a project wanted to increase the number of
participant, it could increase the credit it offered, but that would reduce
the net resource share from people who participate in multiple projects.
Currently there is no penalty for increasing the credit offered.




On Sun, Aug 14, 2016 at 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
>
> 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
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
>



-- 
Eric Korpela
korp...@ssl.berkeley.edu
AST:7731^29u18e3
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-15 Thread Jason Groothuis 
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 <boinc_dev-boun...@ssl.berkeley.edu> on behalf of David 
Anderson <da...@ssl.berkeley.edu>
Sent: 15 August 2016 08:14
To: boinc_dev@ssl.berkeley.edu
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
> boinc_dev@ssl.berkeley.edu
> 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
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Re: [boinc_dev] 4th Gen BOINC credit system

2016-08-14 Thread David Anderson 

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


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
boinc_dev@ssl.berkeley.edu
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
boinc_dev@ssl.berkeley.edu
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] 4th Gen BOINC credit system

2016-08-14 Thread CM 

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


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
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.