... fourth is credit based on runtime (a new one implemented recently by DA for the cases where creditnew doesn't work well)."

go read the docs...

Link to doc (or other source) for #4, please? I don't recognise it.

well, i don't read those docs - you'll have to ask Teemu what he meant..

55 credits for 36 hours. Oh how we laughed.

looks like you managed to draw a blank in credit-lotto.. :(

Quoth DA:

The goals of CreditNew involve long-term averages. It makes no promises about individual jobs or about credit/hour.

CreditNew = apparently random credits to individual users. IOW, be lucky or be screwed.

---

Reno, NV
Team: SETI.USA

Hot news! Hold the front page! A new winner!

http://stat.la.asu.edu/NumberFields/result.php?resultid=573572

41 credits for 49 hours!

Rejoice! Rejoice! For CreditNew hath shown us The New Way! Let the first-born child of every family bring a goat for sacrifice to to sacred altar of Fairness!

Al.

CreditNew = apparently random credits to individual users. IOW, be lucky or be screwed.

I know which group I fall into :)

Al.

@Al

All of your WUs with improper (too high/too low) credit have one thing in common: all show up with a run time of 0.00 sec.

I would guess this is (part of) the problem!

All of your WUs with improper (too high/too low) credit have one thing in common: all show up with a run time of 0.00 sec.

Ah, I hadn't made that connection. It's odd that some WUs show zero, others don't. I've used a dozen different hosts, but ATM I'm using 7 similar ones all running BOINC 5.10.45.

I'll see if I can find out what's going on, though I suspect it is the WUs themsleves rather than the hosts. Thanks for the heads-up :)

Al.

@Al

All of your WUs with improper (too high/too low) credit have one thing in common: all show up with a run time of 0.00 sec.

I would guess this is (part of) the problem!

good point!

older boinc-clients to not ptoperly report run time and cpu time. looks like creditnew has fallen into another pit dug out in boinc-central..

older boinc-clients to not ptoperly report run time and cpu time. looks like creditnew has fallen into another pit dug out in boinc-central..

Yes, I got bitten on the a4se by another project like that. Hmmm. I'll screen-scrape all of my results into Excel and look for the pattern.

One thing's for sure though, I'm not installing BOINC 6.x on anything else. I have to use it on a couple of machines and I hate it :(

Al.

@Al

All of your WUs with improper (too high/too low) credit have one thing in common: all show up with a run time of 0.00 sec.

I would guess this is (part of) the problem!

Good catch Senilix.

The app also measures its own elapsed time internally, and this agrees with Al's cpu time.

It's not *quite* as simple as it seems though. I've grabbed all of my results and put them in a spreadsheet so that I can sort/filter them.

Observations:

1) Those with spectacularly poor credit have a zero run time, those are four V2.02 and one V2.03 (5 WUs)

2) Of those with a zero run time (21 WUs), 5 have low credit (see above), 1 has 'sensible' credit, 10 have BIG credit and 5 have *OMFG* credit. All of these are V2.02 but one. Seems that zero run time is responsible for random credit rather than CreditNew (can't believe I'm saying that!).

3) CreditNew seems to have actually settled down. Credits were higher when I started around 17th/18th and seem to level out a day of so later. Maybe CreditNew works? (*stabs self in eye with fork*). Later WUs with non-zero run times seem to give pretty constitent credit (*pinches self*).

I can, as yet see no other patterns. Would love to able to predict if my current long-runners are going to be winners or losers in the lottery :)

Al.

Oh yeah, sample size was 232 WUs. Removed 2 from my set of 234 as they were <1 second and didn't really fit in with anything (rounding errors etc).

Also, thumbs up to @Senilix for spotting the underlying problem :)

Al.

Also, thumbs up to @Senilix for spotting the underlying problem :)

YUP!

what's rock proof by now:

creditnew is using elapsed time not cpu time - that's where you earned your merits.
this was introduced probably when AQUA showed up with MT-apps and the client reported cpu time of a single core. crazy enough, because elapsed time can be about everything + cpu time. just think about virtual machines..


creditnew is still using those faulty benchmarks to calculate credits, so it's totally open for cheating.


creditnew will not work for projects that have WU's with largely various runtimes. it will simply continue to grant random credits and send way too much or way too few WU's and by that foul up everything hostside.

Hi,
As this project does not grand above normal credits, i am out of here.
Good look with participants, that are simply interested in the project.
Given equal credits, i rather crunch other projects.
This one is not that interesting.

Not sure how to "get rid of it", as it's embedded in the latest server code.

yes it is - the default.

but, taken from the MOOwarp boards:

"There's actually four credit systems* in the BOINC validator code by default. First is that dynamic scheme for "device neutrality", second one is to get credit from WU (which is what we use), third is to grant no credit (instead trickle calls can grant credit) during validation and fourth is credit based on runtime (a new one implemented recently by DA for the cases where creditnew doesn't work well)."

go read the docs...

I went ahead and implemented the "--credit_from_runtime X" option in the validator. Now we wait to see if this fixes the problem with CreditNew...

Funny how quiet it gets in here when credit is going back up again :-)


(Direct link)

I went ahead and implemented the "--credit_from_runtime X" option in the validator. Now we wait to see if this fixes the problem with CreditNew...

Does this mean that my 5.10.45 clients will now get sensible credit? If so, I'll start crunching this project again :)

Al.

I went ahead and implemented the "--credit_from_runtime X" option in the validator. Now we wait to see if this fixes the problem with CreditNew...

Does this mean that my 5.10.45 clients will now get sensible credit? If so, I'll start crunching this project again :)

at least i think so - give it a try.

oh - and be careful not to take the real long WU's for the slow hosts!

---

be careful not to take the real long WU's for the slow hosts!

Yeah, I'll go for bounded ones initially :)

Al.

I went ahead and implemented the "--credit_from_runtime X" option in the validator. Now we wait to see if this fixes the problem with CreditNew...

Does this mean that my 5.10.45 clients will now get sensible credit? If so, I'll start crunching this project again :)

Al.

Sorry, I've been awol the whole day.

Yes, the credit problem was fixed several months ago. I have had no complaints since then.

Yes, the credit problem was fixed several months ago. I have had no complaints since then.

No complaints here either - Predictable credit on every WU so far :)

It's a pity that the estimated runtimes of the bounded WUs are way too high, and actual runtimes are so variable, makes it difficult to keep full caches. At least it's worth crunching them now though :)

Cheers,

Al.