I think that bonus points don't really matter any more.
Because you only get 2 WUs per GPU, if you have fast cards (2XX) you get the bonus. If you have slow cards (9XXX) then you usually do not. There just is not that much room in between.

Looking at the numbers posted on yesterday's returns you are already getting 76% within 24 hours so these people are not the focus.

I don't see any change possible for the 7% that return later than 48 hours as I doubt their cards are actually capable of doing better.

That leaves the 17% that return between 24 and 48 hours.
How best can we help them to return quicker?
Addtional bonus may help but maybe it is just education and giving people guidance on how to set their cache size appropriately.

There are other ways to try and get the bonus but they take more effort than most people are willing to put in and in somecases are detrimental to the goal of reducing overall return times.

I am assuming that most of the WUs were executed by the quicker app and if so then increasing the runtime will make it even more difficult for the people in the 24-48 hour bracket to make enough of a change to come in under 24 hours.

I think if you make really long running wus it will increas the failure and late return rate (do the stats from before the new app upgrade support late return rates have gone down? Error rate might still be high just because it is a new version). Another reason to leave wu lengths short is that, like most crunchers I like to see my numbers move fast, it just makes me feel like I am getting more done :-) If the server can handle the return rate as it is today I would leave the wu size alone or maybe increase it slightly. I do not think wus 2x times longer will work particularly well.

There is a way to make sure your wus get reported as soon as they are complete but most other projects don't like you to do it because reporting causes a heavy database hit.

add this to your cc_config.xml
<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
____________
Thanks - Steve

You might consider how the users configure their rigs...I guess most will just run "straight out of the box" so for a 98 gtx running one WU and having one in the queue the current length and speed makes it possible to hit the deadlines (at least if overclocked).

So, my thought is that rather than define a queue by time perhaps consider defining it by number so that if that number is set at 0.5 the next WU is not downloaded until the WU being worked on has completed 50%

I've pulled a couple of cards from F@H and put on GRID and will continue to do this each time they can't keep their stuff together... It is not leading edge equipment (gx2's) but if such kit were to fall into a second tier of points (read wanted less by GPUGrid) then the incentive to participate 24/7 is diminished.

With regard to the 24hour deadline and larger WU's you will need to decide where to draw the line in the sand ...who will fall into that second tier.

The one concern that really does have to be resolved if you make the move to longer WU's is loss upon a failure. In fah I get credited for the work done so far upon a failure.... here, no such thing ...I ran 2* 260 192's for a while and failures with those....well you know that story...a lot of time effort and money for nothing...not a good thing.

Whatever you decide, make the interface simple...automatic if possible, with options for those who have the time to optimise for their own usage

I wouldn't increase the size unless there is some kind of recovery method after a few crash/error. Increasing the size is equal to increasing the chance of failures.

4xx = .5 day = 75%
2xx = 1day = 50%
9xxx/8xxx = 2 days = 25 %

____________

Clearly this is a call by the project to substantially increase the overall rate of return. I am guessing that this push is centered around the requirements / commitments made as part of the publically funded project GPUGrid recently won. The schiz project is great news for the GPUGrid and proves that what we have all been working towards is worthwhile. We have all spent so much time, equipment, and electricity ... now is the time to rise up and show that we really support what the project needs ... set your BOINC cache to .35
Let's not let them down now!

As a cruncher I really appreciate this conversation. I've flipped my position on WU size. If we go back to the average runtime from before the app upgrade then error rates will likely be the same. No higher, no lower. If the runtimes are extended beyond that it might encourage people to quit messing with their machines and get stable (because otherwise it is too painful if you crash after many hours).

I can also see that if there are new bonus levels added for 12 and 24 hour returns that majority of returns which already happen within 48 hours are done on hardware that is capable of returning quicker if we all set our BOINC cache size to .35 . There is no detriment to people who return between 24 and 48 hours as the bonus level for them stays the same as it is today and if I remember correctly GDF said they would try to make smaller WUs specifically for this group.

Everyone, please set your BOINC cache to .35 so GDF and team can get back to working on the real science.
____________
Thanks - Steve

I wouldn't increase the size unless there is some kind of recovery method after a few crash/error. Increasing the size is equal to increasing the chance of failures.

4xx = .5 day = 75%
2xx = 1day = 50%
9xxx/8xxx = 2 days = 25 %

This is an option.

gdf

Everyone, please set your BOINC cache to .35 so GDF and team can get back to working on the real science.

It looks like your tasks are not doubling up immediately, are you manually managing them now?
____________
Thanks - Steve

No, I do report the odd one manually but it's not that machine which struggles to report within 24hrs.
Because the server polls the machines every 5hrs if you finish the unit just after the machine is polled it sits waiting to be reported for another 5hrs which means you miss the 24hr deadline.
Caches are set 0.01 for max efficiency project wise. I don't believe in building a large cache for any project because it doesn't aid the project especially one like GPUGRID.


____________
Radio Caroline, the world's most famous offshore pirate radio station.
Great music since April 1964. Support Radio Caroline Team -
Radio Caroline

Because the server polls the machines every 5hrs if you finish the unit just after the machine is polled it sits waiting to be reported for another 5hrs which means you miss the 24hr deadline.

Because the server polls the machines every 5hrs if you finish the unit just after the machine is polled it sits waiting to be reported for another 5hrs which means you miss the 24hr deadline.

Most other projects don't like you to use option I'll post below because it is a fairly heavy database call and they like to keep those to a minimum but if you add the ...

<report_results_immediately>1</report_results_immediately>

option to your cc_config file it will force your PC to register the task as complete with the server right after it finishes uploading (within a minute or so). This might help you to make the 24 hour deadline.

This thread is a few years old
Can anyone confirm if this bonus is still in effect?
After missing a deadline by 20 minutes I was looking at changing my work unit buffer anyway.

Yes, still the same.
I finish a Noelias's short WU less then 24h and i receive 31,500.00.
In your case, similar Noelia's WU 21,000.00 after 24h.
____________

After missing a deadline by 20 minutes I was looking at changing my work unit buffer anyway.

Good to know. For a laptop I have a relatively fast crunching GPU, but even on "short" runs the length seems to vary.
I've had some take 8 hours others closer to 20.
The longer ones are credited better, but if they push too long I won't be fast enough to get the bonus.

Currently testing now with a NOELIA task estimated for 36 hours.
Its actually at 13% with 2 hours in, so, if THAT holds steady, it should be done in 16 hours from arrival

On the CPU end, which I use for other projects, the shorter buffer is helping collect a variety of tasks, but it still seems to want to complete shorter deadlines first, and let long deadline projects sit around for days.

The resource share setting seems useless in affecting this, so I'm suspending projects manually if they take too much CPU time