I just returned my result for this interesting workunit where you seem to have all kind of errors in one single workunit. My result is the last one and it was run on my 8800gts, thus using CUDA. My result validated fine against the first result. Then there are 2 CUDA results wich finished with an overflow and there is 1 result which is different but reported no errors, this ran on a MAC.

I can understand that credits are granted for users who are running the very beta-ish performing CUDA and returning invalid results because it's not really their responsibility but I can't quite understand why you would grant credit to a non-CUDA host which returns invalid results(I think it is an invalid result by looking at the stderr out).

I found another strange situation with this workunit where the 3 tasks were granted credit although there doesn't seem to be a matching result between any of them.

Can anyone explain what is going on here?

---

BOINC.BE: The team for Belgians and their friends who love the smell of glowing red cpu's in the morning

Jeff said that he found the bug that was causing this. Don't know if he has put the fix into production yet.

Eric

---

@SETIEric@qoto.org (Mastodon)

8999224 (alpina) wrote:

... I can understand that credits are granted for users who are running the very beta-ish performing CUDA and returning invalid results ...

8999224 (alpina) wrote:

... Then there are 2 CUDA results wich finished with an overflow ...

It seems you think that this two and all other people with this error are responsible for the errors comming up. How do you know this? Please explain that.

---

8999224 (alpina) wrote:

... I can understand that credits are granted for users who are running the very beta-ish performing CUDA and returning invalid results ...

8999224 (alpina) wrote:

... Then there are 2 CUDA results wich finished with an overflow ...

It seems you think that this two and all other people with this error are responsible for the errors comming up. How do you know this? Please explain that.

No, I did not imply that. I said that it's understandable that people who return false results running CUDA get credit since the CUDA application(and every CUDA application) is not yet stable.

Whereas the situation is different with the other applications(windows, mac,linux..) which have been proven to be stable.

---

BOINC.BE: The team for Belgians and their friends who love the smell of glowing red cpu's in the morning

I'm sorry! I had lay wrongly.

---

In every scientific project their is an extremely high priority set on maintaining the integrity of the data. Under no circumstances should bad data be allowed into the data base. But that is in fact what has happened here.

Now nearly 3 weeks after CUDA was released it is proven that bad data from CUDA can and is getting into the scientific master data base. Cuda should have been withdrawn long ago as it never was ready for release. That it is still in use is the responsibility of the project.

Those of us who have used or are currently using CUDA are at some fault also. All of us know the problems with CUDA and many are still using it. We all know that bad data could enter the data base but many continue to use CUDA. To continue to use CUDA would not be what a true scientist would advise.

Returned work that is not valid should not receive credit. Period, end of statement.

---

Boinc....Boinc....Boinc....Boinc....

...Under no circumstances should bad data be allowed into the data base. But that is in fact what has happened here...

What leads you to that assumption? The fact that credits have been granted doesn't mean that the results are transferred to the database.

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours

I am talking about several instances where Cuda work was paired with another cruncher using Cuda and a third using the stock app. The stock app came up with a different answer than the two Cuda work units. The Cuda work was granted credit and one of those made it as the canonical result and went into the master science data base. The exact work unit number has now been removed by the file deleter and cannot be found.

The fact that the Cuda work went into the master science data base is what I am talking about.

---

Boinc....Boinc....Boinc....Boinc....

I am talking about several instances where Cuda work was paired with another cruncher using Cuda and a third using the stock app. The stock app came up with a different answer than the two Cuda work units. The Cuda work was granted credit and one of those made it as the canonical result and went into the master science data base...

Okay, that scenario could cause the wrong result to be stored, but only if the both CUDA hosts return the same erroneous result (not very likely IMO).

What I was saying is that just the fact of credit being granted doesn't mean that the result was accepted, because the granting was possibly done by a script.

Gruß,
Gundolf

---

Computer sind nicht alles im Leben. (Kleiner Scherz)

SETI@home classic workunits 3,758
SETI@home classic CPU time 66,520 hours