And this known bug will be fixed when ?????


To prevent this from re-occuring again you'll have to check the wu-deadline before going on.

Complain long enough and loud enough, and it will get fixed, sooner or later.

I doubt that very much. After getting some more info from my teammates it's clear the people behind this project lack enough respect for this projects participants imo. And that's more of a disappointment than loss of credits. Bye.

This is an annoying bug from the cruncher's point of view, but it has a very little impact on the project's performance.
Just look at it from the project's point of view:
The first host returned the result after the 5 days deadline, but the workunit was active (because of the reissue), the first result was validated, and credits were granted without any bonus for the first host. After that, the second host's work became redundant, so the second result has no use for the project, therefore its value is zero credits. The project should cancel the workunit on the second host after the first one returns the result. In this case no credits would be granted for the second host, and this would be a much more disappointment for the cruncher. So for this 'bad luck' workunits you should take the normal credit as a compensation for your efforts, but because the result is redundant, it's quite logical not to receive bonus for it. We are here for making progress, not for credits. Credits are meaningless in the end.
I think there is a workaround for this problem: long workunits should not be sent to hosts with low RAC, or hosts with more than 2 user canceled workunits. This would increase the overall throughput of the long queue. I very often get workunits resent 6 times. If the 6th resend fails too, the workunit 'dies', so the previous work with that workunit is lost.

I also have a few ideas for workarounds but I don't expect the researchers will have time, especially when developing new apps.

Basically, no resend's! Tasks that fail are 'rebuilt' rather than rescheduled, and in a way that they are treated as new, high priority tasks. These only go out to clients that can return them in a shorter time. The server would still need to keep track of the tasks, and if they fail say 5 times, don't rebuild them. After each rebuild it could have a shorter deadline. Repeat rebuilds would not count towards errors.
As Boinc works on a per app basis, these could even go into an opt-in resends/rebuilds feeder with some additional credit bonus for returning these WU's. Preferably the opt-in would only be available to systems with high success rates.

The 7.0.2x clients should automatically report completed work for GPUGrid, reducing this problem.

I will move these posts later, to the appropriate thread.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

These types of priority/scheduling schemes were debugged in the 1960s/70s in computer science departments around the globe.
That the research teams involved are not aware of the decades-old elegant solutions is but a black mark on their inter-departmental liaison skills/efforts.

And that contributors have to flail around in the dark to re-invent the obvious s a frustration for me personally, having learned these pragmas from almost infancy.

It doesn't sound the same to me, but did I just become a victim of this same problem?

Workunit 3445340

It doesn't sound the same to me, but did I just become a victim of this same problem?

Workunit 3445340

No, I've received the same credit (53700) as you have.
It seems that these MJHARVEY_MJH120523 workunits give less credit than expected.
5411968
5411890
5411871
5412050

No, I've received the same credit (53700) as you have.
It seems that these MJHARVEY_MJH120523 workunits give less credit than expected.

Okay, thanks, RZ. I don't remember getting any MJHARVEY's in the past and had nothing to compare it too.

Here is number 6 for me:

http://www.gpugrid.net/workunit.php?wuid=3440185

And here is number 7:

http://www.gpugrid.net/workunit.php?wuid=3499241

I don't know that this is the same issue,
but I just completed http://www.gpugrid.net/workunit.php?wuid=3734690

As you can see I was the third computer to receive this task, and I completed it just before 24 hours from when it was originally sent, but I was the first (and only) to complete it

No bonus points awarded... any ideas?

I have no idea why the bonus was not awarded.
The task was even returned within 24h of originally being sent to the first client.
Some glitch in the crediting system.
Are these resends of a previous batch still in the system?

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Are these resends of a previous batch still in the system
I don't know. Is there a way to tell?


It is an odd one isn't it?

This task was created on 25 September, but was not sent until 25 Oct.
Unless the creation date for the task got messed up (possible since the dates are exactly 1 month apart)

There is nothing unusual about this. The NATHAN_RPS units have 60,900 credits with the 24 hour bonus. They take a little over 5 hours to complete on my computers. See examples below:

http://www.gpugrid.net/workunit.php?wuid=3786901

http://www.gpugrid.net/workunit.php?wuid=3786456

http://www.gpugrid.net/workunit.php?wuid=3785935

http://www.gpugrid.net/workunit.php?wuid=3785733

You aren't being short changed.

It's not one of those units though.

it took 46225sec to complete.

It's weird, if you look at the creation date of the workunit,
it was over a month ago, yet was only sent out for the first time
2 days ago.

anyway, I don't really mind, just thought I would let the admins
know in case there was a wider issue with a batch of old
workunits appearing in the system.

It's not one of those units though.

It is one of those units..... and you got full bonus for it.

I see what the issue is; it ran using the old cuda3.1 app,

I2R96-NATHAN_RPS1120528-65-166-RND2961
5970734 128855 26 Oct 2012 | 7:03:20 UTC 26 Oct 2012 | 20:16:32 UTC Completed and validated 46,225.16 1,619.07 60,900.00 Long runs (8-12 hours on fastest card) v6.16 (cuda31)

There are several Nathan tasks of different run times,
I4R49-NATHAN_RPS1120801_N-59-111-RND7357_0 3777104 20 Oct 2012 | 9:22:23 UTC 20 Oct 2012 | 20:05:32 UTC Completed and validated 36,696.43 1,252.14 91,200.00 Long runs (8-12 hours on fastest card) v6.16 (cuda42)

I1R25-NATHAN_RPS1120913_respawn2-23-100-RND7674_0 3773979 18 Oct 2012 | 6:06:18 UTC 18 Oct 2012 | 17:48:51 UTC Completed and validated 40,229.50 1,414.98 101,400.00 Long runs (8-12 hours on fastest card) v6.16 (cuda42)

I3R143-NATHAN_RPS1120528-75-166-RND3071_0 3721689 27 Oct 2012 | 5:53:08 UTC 27 Oct 2012 | 13:04:28 UTC Completed and validated 24,182.60 924.84 60,900.00 Long runs (8-12 hours on fastest card) v6.16 (cuda42)

This must have been one of the last type, but just ran slower on the 3.1 app.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Forgive my stupidity but do you get the bonus for your gpu completing it within 24 hours run time or do you get the bonus for completing it within 24 hours from the date it was downloaded?

The 24h is from download time to Report time.

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

Just got one from the ultra-long NOELIAs "18x30_17-NOELIA_hfXA_long-0-2-RND2102_1"
(http://www.gpugrid.net/workunit.php?wuid=3975643)
A little bit frustrating after 11.4 hours of crunching and always babysitting the up-load. But we keep the spirits up!

It looks like we are over the hill with this batch of tasks; the number of tasks on the server has been falling for a couple of days, which means we are more than half way through the batch. In about a week we should start to see the last of the batch, and within a fortnight most resends will be back. At that stage we might see some other tasks while the researchers analyse the performance of this new type of research method. After that, a similar or modified version of this type of batch might turn up, or not, depending on the methods performance...

---

FAQ's

HOW TO:
- Opt out of Beta Tests
- Ask for Help

My "Long runs" cases:

Task 6295312 - received 5 Jan 2013 | 4:09:59 UTC -
reported 5 Jan 2013 | 19:03:15 UTC
that is only 15 hours for 90100 credits

task 6291504 - received 4 Jan 2013 | 4:19:15 UTC -
reported 4 Jan 2013 | 21:31:16 UTC
that is few minutes after 17 hours for 135150 credits

task 6281411 - received 31 Dec 2012 | 23:02:42 UTC
reported 1 Jan 2013 | 23:06:06 UTC
that is 24 hours for 112625 credits

Every task used near 36000 seconds (35735 - 35965)

There is no correlation between those cases !!!!!