I think it's really a matter of what sort of post-processing, if any, will eventually be performed against the reported, canonical result. If such post-processing does eventually happen, would it make a different decision about the value of the result if it contained 30 Pulses (which would have happened in this case if the 3rd host had been running SoG) instead of 30 Triplets? Would one just be discarded as "noisy" while the other required further investigation? I certainly don't know the answer to that, but having this kind of inconsistency at the front end doesn't seem to me to be a very good way to pursue a scientific objective.

I think it's really a matter of what sort of post-processing, if any, will eventually be performed against the reported, canonical result. If such post-processing does eventually happen, would it make a different decision about the value of the result if it contained 30 Pulses (which would have happened in this case if the 3rd host had been running SoG) instead of 30 Triplets? Would one just be discarded as "noisy" while the other required further investigation? I certainly don't know the answer to that, but having this kind of inconsistency at the front end doesn't seem to me to be a very good way to pursue a scientific objective.

30 whatever is too much. Someone / a group has decided that. Reporting order does not have anything to do with it.

I could change the final inspection order of the CPU code to report in 'canonical order', and I can, but I will not. It would take a few lines of cut and paste and a 15 seconds of compile time. I like a second opinion on uncertain cases.

The science is good, the 30 limit is not science - is it?

I think it is. 30 something is too much by the decision of the staff. I cannot influence that. I can only show that there are 30 something else at the same time too and probably in other things that are calculated at the same stage (peaks, pulses, gaussians, autocorrelations, triplets). (Not 30 at a chirp but adding up to 30 at the moment in terms of sequential processing.)

EDIT: I think 'they' will not reinspect the 30/30 packets ever.
EDIT2: The 30/30 may be the E.T. calling home packets that are just the very ones that should be checked! ??

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

If validation rate can be improved w/o signaficant performance degradation or development efforts it should be improved IMO.
In this particular case (and this case can't be solved with my proposal of validator change either) CPU would report mix of Pulse and Triplet most probably (so, both GPU apps are "invalid" versus CPU).
But what can be done in few lines of code indeed is to arrange same checking order between pulse, triplet and gaussian inside PoT analyze. This will improve validation rate.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

I was under the impression that the 30-signal limit was originally imposed because of storage constraints for the systems that were running S@h at that time. Hence, the wording of the message: "The number of results detected equals the storage space allocated." Times have changed, RAM is much more plentiful. If storage was the original constraint, perhaps that 30-signal limit is obsolete. I really don't know.

Also, whether having 30 total signals also meant that the results from such WUs would then be ignored in post-processing (seems unlikely), or whether perhaps the WUs might be rerun with higher thresholds to weed out the noise, is something I certainly don't have an answer to. A project scientist would have to explain what the plan, if any, is in that regard.

This also goes back to the "early" versus "late" overflow discussion. Logically, it would seem as if the early overflows are probably just filled with noise, while late overflows might be more likely to have valid data. After all, it's not unusual to see WUs with 28 or 29 signals, which of course don't overflow. What if the overflow limit was 40 signals? How many of those late overflows we see today might actually show signal counts in the 30-39 range, instead of overflowing? Would capturing those additional signals be helpful, or unnecessary?

I think it's really a matter of what sort of post-processing, if any, will eventually be performed against the reported, canonical result. If such post-processing does eventually happen, would it make a different decision about the value of the result if it contained 30 Pulses (which would have happened in this case if the 3rd host had been running SoG) instead of 30 Triplets? Would one just be discarded as "noisy" while the other required further investigation? I certainly don't know the answer to that, but having this kind of inconsistency at the front end doesn't seem to me to be a very good way to pursue a scientific objective.

Jeff: If you managed to save that overflow inconclusive, I'd like to try that one offline after work, please email it to jason underscore groothuis at hotmail dot com.

Ultimately how the overflow results are used down the the line isn't completely known to us yet. My loose understanding is that a fairly coarse overflow match on different beams (i.e. different WUs), in terms of time and sky position, implies genuine terrestrial noise, therefore is [potentially] 'useful'. It's impossible to know at this stage how fine grained that match will need to be initially, considering the tasks as a wide overflow unit, or on an individual signal basis. The second possibility is the rub, and means all of the GPU applications would ultimately require some level of rework toward the pure serial result set. Extreme caution is warranted.

In the meantime my development host went a little bezerk (reasons unknown at this point). 3 weeks ago was a simple case of needing a good cleanout, which was done, and inconclusives reduced to normal <5% of pending. Then this weekend, after some driver updates, inconclusives blew out again (>20%), and I saw my first invalid (concerning), seeing a large number of overflows that looked like they matched stock CPU but didn't. Unfortunately I missed whatever the event was, was too late to grab the affected tasks, and It will take some time to figure out if it was a system, driver, or application problem. [Quick check now, and things seems on the slow mend, and some invalids are percolating through. Time to consider integrating some QA/sanity checks]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Jeff: If you managed to save that overflow inconclusive, I'll like to try that one offline after work, please email it to jason underscore groothuis at hotmail dot com.

Sorry, but no. I don't normally pay close attention to my Inconclusives, since there are usually a lot of them and it's rare that they don't eventually validate. I wasn't aware of this one until it showed up as Invalid and, of course, by then it was too late to grab the WU.

Jeff: If you managed to save that overflow inconclusive, I'll like to try that one offline after work, please email it to jason underscore groothuis at hotmail dot com.

Sorry, but no. I don't normally pay close attention to my Inconclusives, since there are usually a lot of them and it's rare that they don't eventually validate. I wasn't aware of this one until it showed up as Invalid and, of course, by then it was too late to grab the WU.

OK, no problem. I'll do some thinking on the overflow situation after work instead. Probably I'll attempt to merge the baseline and alpha codebases in such a way that a -9 can fallback to more serial code for the last few seconds of processing. At least if I can track down plausible explanations for my system's freakout, and the two issues will play nicely together, probably we're on the 'right track', even if quite a few hurdles to jump through yet.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

Jeff: If you managed to save that overflow inconclusive, I'll like to try that one offline after work, please email it to jason underscore groothuis at hotmail dot com.

Sorry, but no. I don't normally pay close attention to my Inconclusives, since there are usually a lot of them and it's rare that they don't eventually validate. I wasn't aware of this one until it showed up as Invalid and, of course, by then it was too late to grab the WU.

OK, no problem.

I just downloaded Richard's fanout.xls and will see if there's a way I can incorporate the relevant pieces of that macro into the routine that I created a while back to generate a WU/Task list for the current Inconclusives on my boxes. (That's what I used to generate the examples in Message 1820375 and a few earlier posts in this thread.) If I can, then I could just automatically and preemptively grab all the associated WU files "just in case". I usually have more than 100 tasks in an Inconclusive state at any given time (across all my boxes), but I really don't know what the turnover is or how many new ones I'd have to grab on a daily basis.

Say, Jason. I just generated a new list of my current Inconclusive tasks and found a couple that may interest you. In fact, you may already have the file for this first one. :^)

Workunit 2296371421
Task 5223223447 (S=0, A=0, P=30, T=0, G=0) SSE3xj Win32 Build 3528
Task 5223223448 (S=0, A=0, P=30, T=0, G=0) x41zipa3, Cuda 6.50 special

This second one is another 4-bagger, similar to what I posted a few weeks back, with 4 different apps returning 3 different results. My host is the one that will render the 5th opinion. That will run as Cuda50, so my initial thought was that it would probably match with the Cuda32 result. However, I just looked at that host and discovered that it's running an 8400GS that seems to be off the rails, so who knows what I'll get.

Workunit 2294854734
Task 5219994532 (S=2, A=28, P=0, T=0, G=0) v8.00 (cuda32) windows_intelx86
Task 5219994533 (S=29, A=0, P=1, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5222189368 (S=29, A=0, P=1, T=0, G=0) v8.19 (opencl_intel_gpu_sah) windows_intelx86
Task 5223996583 (S=20, A=0, P=9, T=1, G=0) v8.19 (opencl_ati_cat132) windows_intelx86

Cheers, yeah please forward both if you have them. All prior ones (I think which doesn't include either of those, having quickly looked at my bench folders) came with High similarity to CPU reference.

There's a few things for me to nail down here, namely if I can reproduce the dodgy state my host entered over the weekend, and if there are substantial differences between Petri's p3 and my current zipa3 build (other than the lighter synchronisation for older systems I've been working on).

There's a possibility minor stability issues may be, at least capable of, inducing some synchronisation issues within drivers or runtime, that don't appear under bench. Something along these lines could explain why we might see high Q's under bench (i.e. same signal order even though a forefront discussion topic and genuine suspect), but some unacceptable fragility running live.

If I can generate similar High Q's under bench with these new examples, then I'll probably switch focus temporarily, from cross platform build system development, toward some fault detection and tolerance mechanisms. [The throughput is way too high to rely solely on Boinc for the fault tolerance aspects]

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I just downloaded Richard's fanout.xls and will see if there's a way I can incorporate the relevant pieces of that macro ...

The only real heavyweight lifting is to generate the MD5, but there's plenty of code online to do that bit. The rest is to ensure that you have the complete WU - not task - name for MD5ing, and the right characters/modulo for the fanout. Ask if you want to check anything.

And here is CPU code vs two SoGs that are inconclusive:

http://setiathome.berkeley.edu/workunit.php?wuid=2295768996
5221951752 8108844 16 Oct 2016, 10:45:17 UTC 17 Oct 2016, 11:24:57 UTC Completed, validation inconclusive 1,617.93 1,571.58 pending SETI@home v8
Anonymous platform (CPU)
5221951753 7804722 16 Oct 2016, 10:45:20 UTC 16 Oct 2016, 15:08:30 UTC Completed, validation inconclusive 625.20 603.70 pending SETI@home v8 v8.10 (opencl_nvidia_SoG)
x86_64-pc-linux-gnu
5224825595 8060288 17 Oct 2016, 16:47:42 UTC 18 Oct 2016, 3:35:46 UTC Completed, validation inconclusive 826.10 815.27 pending SETI@home v8 v8.19 (opencl_nvidia_SoG)

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

I just downloaded Richard's fanout.xls and will see if there's a way I can incorporate the relevant pieces of that macro ...

The only real heavyweight lifting is to generate the MD5, but there's plenty of code online to do that bit. The rest is to ensure that you have the complete WU - not task - name for MD5ing, and the right characters/modulo for the fanout. Ask if you want to check anything.

Thanks, Richard. I briefly looked at it last evening, but brain was winding down to bedtime so didn't absorb much. My PC programming these days is limited to Delphi 4.0 (Object Pascal, circa 1998) so I need to see if I can convert the VBA or find some callable routines online. When I pulled my Visual Basic 3.0 Language Reference (© 1993) off the shelf a short time ago, it created quite a cloud of dust. ;^)

I just downloaded Richard's fanout.xls and will see if there's a way I can incorporate the relevant pieces of that macro ...

The only real heavyweight lifting is to generate the MD5, but there's plenty of code online to do that bit. The rest is to ensure that you have the complete WU - not task - name for MD5ing, and the right characters/modulo for the fanout. Ask if you want to check anything.

Thanks, Richard. I briefly looked at it last evening, but brain was winding down to bedtime so didn't absorb much. My PC programming these days is limited to Delphi 4.0 (Object Pascal, circa 1998) so I need to see if I can convert the VBA or find some callable routines online. When I pulled my Visual Basic 3.0 Language Reference (© 1993) off the shelf a short time ago, it created quite a cloud of dust. ;^)

I got as far as VB6...

More to the point, I've got some modern visual studio installations working, and I think they still have VB - so maybe I could convert the vba into a standalone commandline?

(but not tonight)

I just downloaded Richard's fanout.xls and will see if there's a way I can incorporate the relevant pieces of that macro ...

The only real heavyweight lifting is to generate the MD5, but there's plenty of code online to do that bit. The rest is to ensure that you have the complete WU - not task - name for MD5ing, and the right characters/modulo for the fanout. Ask if you want to check anything.

Thanks, Richard. I briefly looked at it last evening, but brain was winding down to bedtime so didn't absorb much. My PC programming these days is limited to Delphi 4.0 (Object Pascal, circa 1998) so I need to see if I can convert the VBA or find some callable routines online. When I pulled my Visual Basic 3.0 Language Reference (© 1993) off the shelf a short time ago, it created quite a cloud of dust. ;^)

I got as far as VB6...

More to the point, I've got some modern visual studio installations working, and I think they still have VB - so maybe I could convert the vba into a standalone commandline?

(but not tonight)

Turns out I could've left that dust where it was. After finding a nice MD5 routine for Delphi, I only needed to massage one function from the macro, "fan_from_WU", to extract and transmogrify those three characters from the MD5 hash.

I haven't added the automatic download yet, but my Inconclusives list now returns WUs and tasks with the filename link added, such as:

Workunit 2296449062 (blc3_2bit_guppi_57451_19304_HIP62472_0003.25582.0.17.26.37.vlar)
Task 5223385947 (S=17, A=0, P=13, T=0, G=0) x41zi (baseline v8), Cuda 5.00
Task 5226170762 (S=12, A=0, P=18, T=0, G=0) v8.19 (opencl_ati5_nocal) windows_intelx86
Task 5226940501 (S=8, A=0, P=22, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86

Workunit 2296891126 (13mr09ab.1604.6207.3.30.2)
Task 5224316692 (S=18, A=12, P=0, T=0, G=0) SSE3xj Win32 Build 3528
Task 5224316693 (S=21, A=9, P=0, T=0, G=0) SSE3xj Win64 Build 3330

A full list, in HTML format, should be accessible here, if anyone wants to verify that the generated links are good. However, please note that any WUs that don't show any associated tasks have already validated just in the few hours since my last DB update, so those file links won't work. And any that validate after the list was generated about 45 minutes ago, will also fail. They're moving targets!

Links are good
I can download the datafile

EDIT: A fair few have since then been validated(when you generated the links)

EDIT2: Richard your VBA code to me is giberish since I write and therefore read, Java, Scala and C++

EDIT3: Well time for me to learn VBA then!

This second one is another 4-bagger, similar to what I posted a few weeks back, with 4 different apps returning 3 different results. My host is the one that will render the 5th opinion. That will run as Cuda50, so my initial thought was that it would probably match with the Cuda32 result. However, I just looked at that host and discovered that it's running an 8400GS that seems to be off the rails, so who knows what I'll get.

Workunit 2294854734
Task 5219994532 (S=2, A=28, P=0, T=0, G=0) v8.00 (cuda32) windows_intelx86
Task 5219994533 (S=29, A=0, P=1, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5222189368 (S=29, A=0, P=1, T=0, G=0) v8.19 (opencl_intel_gpu_sah) windows_intelx86
Task 5223996583 (S=20, A=0, P=9, T=1, G=0) v8.19 (opencl_ati_cat132) windows_intelx86

My host, running Cuda50, has now finished with the above WU and I find the results rather interesting. It validated against the SoG host, while the other 3 were declared Invalid. It's not really surprising that the Cuda32 is Invalid, as it's returning a lot of those. The same is probably true for the ATI host. However, the Intel GPU host appeared, at least superficially, as reported in Stderr, to return the same counts as the SoG and Cuda50. Usually it seems like that's good enough on one of these overflow tasks to get a weakly similar validation. Not so in this case, however.

However, the Intel GPU host appeared, at least superficially, as reported in Stderr, to return the same counts as the SoG and Cuda50. Usually it seems like that's good enough on one of these overflow tasks to get a weakly similar validation. Not so in this case, however.

The Intel GPU in question is a HD Graphics 520, from the Skylake generation. They've been a problem for a long time, and Raistmer was on the verge of asking for them to be excluded from work distribution. But Juha posted some key information in this very thread, I bought a tame Skylake for testing, and Raistmer spent the weekend throwing build after build at me until one stuck. Read all about it at Beta.

I'd like a few Beta testers with Windows 10 and a Skylake to pick up the Beta build, please (I've only tested with Windows 7 so far, although the machine is licenced for Windows 10 too), but it's looking good: I hope we can tick another bug off the list soon.

I wonder if this new one might be worth taking a look at. Almost everything lines up, except that 3 out of the 13 Pulses have significantly different peaks and scores in the x41p_zi3j, Cuda 8.00 special app than what the SoG r3528 app shows.

Workunit 2298286101 (blc3_2bit_guppi_57451_20612_HIP62472_0007.24494.416.18.27.131.vlar)
Task 5227261845 (S=17, A=0, P=13, T=0, G=0) x41p_zi3j, Cuda 8.00 special
Task 5227261846 (S=17, A=0, P=13, T=0, G=0) SSE3xj Win32 Build 3528

saved it for a gander. [Edit:] looks like whatever my weekend trouble was, isn't there now, and things are on the slow mend. Food for thought on how things can go wacky.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.