This just looks strange to me. Two work units which had validated, then the WU is sent to me where the result is deemed invalid.
Questions is why was the WU sent out again? and could this be some sort of bad validation?
https://setiathome.berkeley.edu/workunit.php?wuid=3808043165

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Please see this thread. The quorum on -9 overflows is now 3 (possibly even 4) due to all of the AMD RX series cards cross-validating incorrect -9 results.

---

Yes but that thread is discussing AMD GPUs. My example is between three NVIDIA GPUs?
And the three WUs did not validate.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

OK, that looks like a problem.

1) A third wingmate for checking purposes after overflow is what Eric introduced because of the AMD problem. But I think it applies to all WUs, not just those allocated to AMD cards.
2) The first two NVidia cards are both running special sauce - I think it's been acknowledged that this has problems on overflows. But they were so far out of tolerance that your CPU (not NVidia - only two of those) wasn't even weakly similar? That's bad. You found a pulse that the others missed.

The change is for all -9s. The validator has no capacity to evaluate what platform complete the task. The thread merely explains why this is being done.
Edit: @Richard Did TBar indicate that his newest 10.2 compile improve pulse-finding to reduce the Inconclusives? I seem to remember that.

---

@Richard Did TBar indicate that his newest 10.2 compile improve pulse-finding to reduce the Inconclusives? I seem to remember that.

I read that too.

But in this case the first is a 101 built by TBar, and the second was a mutex build by Ian. Sounds like it's one that should be checked on the bench, but the data file won't be available now validation has concluded. It probably should have gone to a fourth wingmate, and then we could have caught it for forensic dissection.

Sorry that I missed the fact that I was doing the WU on the CPU.
I thought is looked strange in any case and it just might be.
Thanks for looking.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

this is a function of how CUDA vs other apps go about finding signals combined with the limit of 30 signals before exit.

Looks like you have 2 systems running the special app vs a CPU app on a noisy WU.

the CUDA apps find triplets first, hitting 30, then exiting.

the CPU app looks for pulses first, finding 29, moving to triplets, finds another, then exiting. So in this case, the two CUDA apps agree and get the credit. say if the limit was 100 or 1000, then maybe we would see less resends due to noisy WUs. but I understand needing a limit somewhere.

---

Seti@Home classic workunits: 29,492 CPU time: 134,419 hours

@Richard Did TBar indicate that his newest 10.2 compile improve pulse-finding to reduce the Inconclusives? I seem to remember that.

I read that too.

But in this case the first is a 101 built by TBar, and the second was a mutex build by Ian. Sounds like it's one that should be checked on the bench, but the data file won't be available now validation has concluded. It probably should have gone to a fourth wingmate, and then we could have caught it for forensic dissection.

If you check it on the bench you will find that All CUDA Apps, even the Baseline CUDA App built by nVidia in 2007, will give that result. A few years ago when most results were coming from the Window's CUDA App that result would have been deemed "normal" and valid.