With .24 the GPU debt is tracked apart from the CPU debt. But as I have noted on other messages the debts are co-equal and growing on the 5 projects I have running. The two GPU projects are at +-148670.58
The three CPU projects are a little messier with two projects balancing WCG with WCG now up to +156160.15 and the other two projects -71424.59 and -84735.55 to balance the numbers. In the cases of your scenarios I agree it is to a certain degree much ado about nothing. On the other hand, if we be serious about scheduling projects then we should do it consistently and "correctly" and as we have chosen debt as out model the second alternative is the "better" choice. But, first things first... I cannot for the life of me see how these numbers make sense and how unconstrained (within the limits of MAX) growth is what we want, or, why growing but balanced numbers make sense. On Dec 10, 2009, at 3:02 PM, Richard Haselgrove wrote: > Thinking about this, I think it's a classic "no-win" situation: there is no > right answer. > > Consider the simplest possible case: > Two projects attached - one has work, the other doesn't. > > Under the old scheme, the project without work is pegged to 0 STD. That > means that the running project is pegged, too. > > With the new scheme, the 'no work' project will eventually creep up to the > maximum limit stop, and the running one down to the minimum limit stop. > > So far, so factual. Now apply the human "value judgement" - is either case > "better" than the other? > > I can't answer that. > > I am attached to SETI, because it's lively and interesting, even though it > has no realistic chance of success in my lifetime. But SETI has flaky > servers and frequent downtime, so I'm attached to a second project - > Einstein - which provides solid, reliable but generally boring work. I > prefer the old style - no debt build-up, start from zero if I ever activate > Einstein to cover a SETI outage. > > My identical twin is also attached to SETI for similar reasons, but has > attached to Orbit as the second project. SETI is fun, but Orbit really > matters: it might save my twin's life. But as a BOINC project it sucks - no > work since heaven knows when. So my twin prefers the new scheme - if Orbit > ever issues new work, it gets the highest 'immediate run' priority. > > So I (the real me, not my thought-experiment avatars) can't get too worked > up about this - either will do, and broadly speaking has worked tolerably > enough (if not perfectly) for years past. The one thing which I do feel is a > problem is the 'leakage' of massive amounts of GPU debt into the STD > calculation, where it doesn't belong or have any meaning. > > I'll have the first daily debt graph with v6.10.24 ready in just over an > hour. sneak previews suggest it's OK. But I'm worried about what I may see > when I allow multiple GPU projects into the mix tomorrow night. > > ----- Original Message ----- > From: "David Anderson" <[email protected]> > To: <[email protected]> > Cc: <[email protected]> > Sent: Monday, December 07, 2009 6:53 PM > Subject: Re: [boinc_dev] Short Term Debt. > > >> Actually, looking at the code, we're already doing this. >> The needed change is to not set the STD of non-runnable projects to zero; >> instead, let them float around with the others. >> >> -- David >> >> David Anderson wrote: >> ... >>> >>> An alternative: add the normalizing offset to non-runnable projects. >>> In the above case, C's STD would go to MAX_STD, >>> and it would start off on equal footing with B, >>> which is the correct behavior. >> _______________________________________________ >> 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.
