It seems that a replication of 2 doesn't have any bonus credit. Is this by design?

WU:
1212022
1179453
1174203
1194905
1208413
1200051
1178736

---

It looks like GPUGrid is still using the old rules to send out duplicate WUs when it looks like the original will not get processed in time.
Because most WUs are using the new app there are more returning in the gap between when they send out the second copy and when that second copy is completed but from the original issue it is not inside the bonus window. This odd scenario has been around since bonus time was started but was never particularly common, where it is becoming so now. I have had it happen a few times myself but was trying to be patient and let GPUGrid tweak their project settings to produce the best results for them.

So ... GDF, how about a review of the bonus rules or maybe extend the timeout on the first issue of a WU before sending the second?

Just out of curiosity what is the overall time to return percentage breakdown?
How many in 24 hours, 48 hours, etc.

---

Thanks - Steve

anyone from the staff?

i've been aborting task that has replication of 2.

---

The design here is that a second copy of the WU is send out (to a fast card?) when there is no reply within the first two days. Reason being that the project heavily depends on a fast turnaround of the results to advance.
The credit given still runs along the old logic:
- if the second fast card replies first and within the two days of its deadline it will get the fixed and bonus credit
- if however the first card replies first (but after more than two days) it will only get the fixed credit and automaticaly set a cap on the max credit for that WU. So when then the second fast card comes back it will only get the capped credit, even if it's reply is within the two day timeframe that normally grants the bonus.

No fun I know, but remember it is the best interest of the project.

Kind regards

Alain

It would be in the best interest of the project to change that system!

We are looking into the code, as it should work.

gdf

The problem is that once a canonical result has been chosen, the credits are not computed in the standard way but just assigned as the credits of the canonical result.
I am looking if we can do anything about that.

gdf

The problem is that once a canonical result has been chosen, the credits are not computed in the standard way but just assigned as the credits of the canonical result.
I am looking if we can do anything about that.

gdf

Any updates on this?

Fast returner got no bonus; Slow returner got bonus. Seems like a good idea for slow returner to have bonus.
Here's the example of piggybacking:
2030062
2030049

Its unfair for fast returner to not have a bonus and also for someone to get a bonus (piggybacking the fast returner).

---

We have worked out a fix.
It will be tested out tomorrow and then if it works used on the main server.

gdf

We have worked out a fix.
It will be tested out tomorrow and then if it works used on the main server.

gdf

That's good news, Thanks!

---

We have worked out a fix.
It will be tested out tomorrow and then if it works used on the main server.

gdf

Any news about the fix?

(I'm "not amused" about this one: Workunit 1292423 :credit: 7,954.42

Yesterday I got 11,931.63 for (nearly) the same runtime (same card, same WU-type) Workunit 1295734)

We have patched the software related to this problem. Please check it out.

gdf

I haven´t gotten the full credit bonus, because the first client had errored out.

See this WU: minor bonus WU

Can you fix that?

looks right ot me ... perhaps GDF hopped in and fixed it already?
Claimed: 3,977.21
Granted: 5,965.82

---

Thanks - Steve

Sorry!
Snow Crash your right!
My disorientation came from the run time of the WU. I had a WU with nearly the same runtime which had about 1800 credits more (s. here). But here it is a problem with the granted credit, not with the bonus calculation.
It´s my fault, so please forget my last post.