Workunit 3519822979
name blc33_2bit_guppi_58406_31708_HIP20440_0117.5281.818.22.45.29.vlar
application SETI@home v8
created 15 Jun 2019, 11:29:26 UTC
minimum quorum 2
initial replication 3
max # of error/total/success tasks 5, 10, 5
Task
click for details Computer Sent Time reported
or deadline
explain Status Run time
(sec) CPU time
(sec) Credit Application
7772265929 8565391 15 Jun 2019, 16:47:29 UTC 15 Jun 2019, 16:52:39 UTC Completed, validation inconclusive 29.28 15.05 pending SETI@home v8 v8.00 (cuda32)
windows_intelx86
7772265930 6846706 15 Jun 2019, 16:47:32 UTC 16 Jun 2019, 11:44:51 UTC Completed, validation inconclusive 7,928.05 7,560.70 pending SETI@home v8 v8.00
x86_64-pc-linux-gnu

My machine (6846706) ran this task and seemed to work correctly. The other machine (8565391) also ran it, and its stderr file is so completely different that I cannot imagine we ever ran the same task. Yet neither of them seem to have failed. Do results differ this much often?

---

As this work unit has, so far, not been validated (status reports as "Completed, validation inconclusive") I'm not surprised that the stderr are so different.
There are a number of things to consider when looking at stderr, not the least is what applications were being used, the detail of the stderr is very much at the behest of the developers. The other computer has a very high "inconclusive" and "invalid" rates which indicate that computer has an issue, possibly hardware or driver related.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

7772265930 6846706 15 Jun 2019, 16:47:32 UTC 16 Jun 2019, 11:44:51 UTC Completed, validation inconclusive 7,928.05 7,560.70 pending SETI@home v8 v8.00
x86_64-pc-linux-gnu

My machine (6846706) ran this task and seemed to work correctly. The other machine (8565391) also ran it, and its stderr file is so completely different that I cannot imagine we ever ran the same task. Yet neither of them seem to have failed. Do results differ this much often?

validation inconclusive 

Is a pretty common issue although it is not a "high volume" issue.

My understanding is some machines/apps have a lower chance of getting the same calculated results as other machines. That cause's the "validation inconclusive" for both machines.
This causes the Seti scheduler to send out the task again for a "tie breaker".
And eventually everyone gets credit for the crunching (I think).

Tom

---

A proud member of the OFA (Old Farts Association).

Sadly, your wingmate's computer (8565391) is consistently producing rubbish - for the time being, at least.

All tasks for computer 8565391

Look at the number of tasks found to be, first, inconclusive, and ultimately invalid.

That's why every task is sent to two, independent, computers. When rubbish results are encountered, the work is checked a third, fourth, fifth time - as long as it takes (within reason) to be sure that the work is done properly. Your contribution will, most likely, be eventually confirmed by another volunteer and accepted as valid.

I looked up that work unit and its"name"
blc33_2bit_guppi_58406_31708_HIP20440_0117.5281.818.22.45.29.vlar
at the location
https://setiathome.berkeley.edu/workunit.php?wuid=3519822979

All results completed are inconclusive and it is pretty obvious there are huge differences in the results.
The GPU task had info about OpenCL and your CPU one was simpler.

Be interesting to see that the ATI system returns and other systems will probably receive the task if the ATI one is also much different.

If I see a CUDA32 app, I normally immediately discount the machine.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Look at the number of tasks found to be, first, inconclusive, and ultimately invalid.

Very interesting. He certainly has a very fast machine though. Too bad the results seem so often wrong.

State: All (3520) · In progress (25) · Validation pending (1333) · Validation inconclusive (1337) · Valid (33) · Invalid (792) · Error (0)

---

It's not fast, it's just overflowing perfectly good work. ;-)

Cheers.

It's not fast, it's just overflowing perfectly good work. ;-)

Cheers.

Yes, because it is using the CUDA32 application. Unless one knows exactly the specs of their gpu and the status of which deprecated legacy graphics driver to properly run the CUDA32 application, the normal thing to happen is to trash perfectly good work and keep multiple wingmen busy.

In my opinion the CUDA23, CUD32, CUDA42 and CUDA50 apps should all be deprecated since the scheduler can't make a good decision about which compatible app to send to clients anymore. The SoG app should be the one and only gpu application for Multiband.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

It's not fast, it's just overflowing perfectly good work. ;-)

Cheers.

Yes, because it is using the CUDA32 application. Unless one knows exactly the specs of their gpu and the status of which deprecated legacy graphics driver to properly run the CUDA32 application, the normal thing to happen is to trash perfectly good work and keep multiple wingmen busy.

In my opinion the CUDA23, CUD32, CUDA42 and CUDA50 apps should all be deprecated since the scheduler can't make a good decision about which compatible app to send to clients anymore. The SoG app should be the one and only gpu application for Multiband.

And goodness knows when that 10yrs old pre-Fermi card was last cleaned.

Also pre-Fermi GPU's and Win10 are a bad combination considering its poor driver function/support.

Cheers.

Look at the number of tasks found to be, first, inconclusive, and ultimately invalid.

Very interesting. He certainly has a very fast machine though. Too bad the results seem so often wrong.

State: All (3520) · In progress (25) · Validation pending (1333) · Validation inconclusive (1337) · Valid (33) · Invalid (792) · Error (0)

. . The apparent speed of this machine is a deception to a degree because of the mis-operation and rubbish results. If that were resolved its run times would be longer but the results valid.

Stephen

:(