thanks for showing up richard!

your charts look pretty similar to what i remember from AQUA.

it was quite freaky at first, looked like it had setteld and then - you know the story..

Yes, I remember the story - I was there, and got the virtual T-shirt.

The relevant lesson for Eric here is always to double-check <rsc_fpops_est>. AQUA's final nova was detonated by loading a test app with an estimated runtime of 1 million fpops - of the order of a millisecond. In fact, they took of the order of 20 minutes, or 1,000 seconds - so the estimate was out by a factor of a million. BOINC imploded, credit exploded, and according to the official histories the fact that the project folded a couple of months later was pure coincidence.

Thanks for the analysis, Richard.

The is currently set at 7E13 (about 10 hours on a 2Gflops host).
I think this is close to the average. Any WU faster than .5 hours is flagged as an outlier, so doesn't contribute to the stats. I am open to suggestions regarding these parameters, or any other config item I can adjust to make things "better".

Eric

that did not help - my PHENOMII running @ 3.3 GHz shows up on the project with
Average processing rate 35481.973041909 - OMFG..

I don't know what happened, but over the past 6 hours, my average cr/hr per WU dropped by about 2/3rds. From around 90cr/hr to around 30cr/hr. Gotta love CreditNew - NOT.

I don't know what happened...

I think what happened was V2.03 of the application :)

V2.02 was giving higher (although still inconsistant) credit.

Way back in the beginning the credit was about half of the 'standard' BOINC granting level. I think it was probably the lowest granting project for a while. Also we had all of the computation errors, which didn't help.

I came back to the project a few days ago and the credit seemed to be on average about 6 times higher than 'standard'. Not the highest granting project, but certainly up there in the top 6 for CPU projects. Which was nice ;)

Currently the credit seems about 'standard' - I hesitate to use the word 'right' ;) Maybe it's still a little high, I need to get some more results to be sure.

At least things are still better than they were in the beginning :)

Al.

I think what happened was V2.03 of the application :)

yup - credit-lotto starts from scratch..

it's about time to get rid of creditnew!

an old single core sempron getting ~500 credits per hour while current I7's get 20 per core.

this is way too crazy..

Looks like almost all the tasks isued since the switch to v2.03 have been of the "under 30 minutes - outlier" variety. According to the application details for host 1289, she's completed 53 tasks so far but not a single one of them has run long enough to count towards re-establiching an APR.

Looks like almost all the tasks isued since the switch to v2.03 have been of the "under 30 minutes - outlier" variety. According to the application details for host 1289, she's completed 53 tasks so far but not a single one of them has run long enough to count towards re-establiching an APR.

exactly the same over here - except a single one which ran for 17256 seconds and got 104 credits. :(

does not look like a working solution..

Most (probably all) of my hosts are now clogged up with long running 2.03 WUs - The short ones seem to have gone.

Still got some ultra-long 2.02's - Hoping they'll pay a decent credit. Knowing my luck with this project they'll all error out after several days crunching ;)

Al.

Most (probably all) of my hosts are now clogged up with long running 2.03 WUs - The short ones seem to have gone.

Still got some ultra-long 2.02's - Hoping they'll pay a decent credit. Knowing my luck with this project they'll all error out after several days crunching ;)

Al.

I can't guarantee the credits, that's up to CreditNew; however, I can tell you that I fixed all the other issues that were causing seg faults. I also fixed the resource limit errors by adjusting the rsc_fpops config items. So I wouldn't worry too much about them erroring out.

Eric

I can't guarantee the credits, that's up to CreditNew

Hehe. This one just finished:

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

Yes, that's right. 55 credits for 36 hours. Oh how we laughed.

Al.

55 credits for 36 hours. Oh how we laughed.

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

New record!

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

49 credits for 41 hours crunching :)

They'll be dancing in the streets of London, throwing their hats in the air while quaffing ale and praising the All New CreditNew, our saviour in these dark times! Hoorah for CreditNew!

Al.

New record!

49 credits for 41 hours crunching :)

They'll be dancing in the streets of London, throwing their hats in the air while quaffing ale and praising the All New CreditNew, our saviour in these dark times! Hoorah for CreditNew!

one thing for sure - creditnew just not managed to rip of your humour. ;)

but seriously - i do not think this can go on.

about time eric get's rid of it before all the happy campers have made their decisions..

New record!

49 credits for 41 hours crunching :)

They'll be dancing in the streets of London, throwing their hats in the air while quaffing ale and praising the All New CreditNew, our saviour in these dark times! Hoorah for CreditNew!

one thing for sure - creditnew just not managed to rip of your humour. ;)

but seriously - i do not think this can go on.

about time eric get's rid of it before all the happy campers have made their decisions..

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

Part of the reason for the high credits several weeks ago was that was set too high. I think I will adjust that up a little to increase the credits. I will also mark the really long WU's as outliers, as these are probably skewing the stats and making the host appear slower than it really is.

I just looked at the last 100 results returned and it looks like most users are getting between 20 and 40 credits per hour. Al, is it possible your benchmarks are screwy? Maybe you could try re-running them to see if that helps.

Eric

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

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

Al, is it possible your benchmarks are screwy? Maybe you could try re-running them to see if that helps.

I could try, but the other project that I'm running alongside this one (AlmereGrid Boinc Grid) is working perfectly.

I think this project doesn't like me. I got so depressed earlier that I threw myself off of the top of a 100 foot tall building. Unfortunately the <rsc_fpops_est> were wrong for the building and I fell 2 inches. Nearly broke a fingernail ;)

Al.

p.s. For the imperial measurement 'challenged', 100 foot is about 30 metres. Or, under CreditNew either 37Km or 2mm, but never the same twice :)