Just got one, my computer reported minutes ago.

http://setiathome.berkeley.edu/workunit.php?wuid=975800759

So yours is the one with Jason's r557,

yes

against stock? Need to keep an eye on the final outcome of that one.

Will do. Don't think I am going anywhere in the next two weeks, after that not sure yet, waiting for confirmation of scheduled meeting down south, but don't think other party is ready yet.

That task must have validated, as it no longer on the task list. It was there just before maintenance, but not there now. But I have zero invalid or errors.

I did download and run an offline check on that, just one of the 30 repetitive pulses was questionable, so a weakly similar credit grant was certain. The Lunatics FFA code is vectorized while stock isn't, so there will always be some very small differences leading to occasional disagreement.

                                                                   Joe

I have one, Linux stock vs r1305

http://setiathome.berkeley.edu/workunit.php?wuid=986876189

I have one, Linux stock vs r1305

http://setiathome.berkeley.edu/workunit.php?wuid=986876189

Your link points at a wu done by two stock OSX and one NV opencl wingcrew. Is the link correct ?

---

_\|/_
U r s

I have one, Linux stock vs r1305

http://setiathome.berkeley.edu/workunit.php?wuid=986876189

Your link points at a wu done by two stock OSX and one NV opencl wingcrew. Is the link correct ?

Yes, thought it was Linux but it may be OSX.

Another one: wuid=999173464

---

Another one: wuid=999173464

That's fairly unusual:

    single pulses: 30
repetitive pulses: 1

I'll run an offline test on it, most likely there really are many single pulses but even CPU processing can sometimes glitch and manufacture false pulses.

                                                                   Joe

Another one: wuid=999173464

That's fairly unusual:

    single pulses: 30
repetitive pulses: 1

I'll run an offline test on it, most likely there really are many single pulses but even CPU processing can sometimes glitch and manufacture false pulses.

                                                                   Joe

The 3rd task has reported and, surprisingly, all three validated/received credit.

---

Another one: wuid=999173464

That's fairly unusual:

    single pulses: 30
repetitive pulses: 1

I'll run an offline test on it, most likely there really are many single pulses but even CPU processing can sometimes glitch and manufacture false pulses.

                                                                   Joe

The 3rd task has reported and, surprisingly, all three validated/received credit.

Not really surprising, the more signals there are the more likely for a very small difference in calculations to make a difference. My offline run with ap_6.01r557_SSE2_331_AVX.exe finished and found the 30 single and 1 repetitive pulses, the run with stock 6.01 is at about 57% progress and has found 14 single and 1 repetitive all of which match very closely. It should finish about when I get up tomorrow, then I'll check in detail.

                                                                  Joe

scrub this..looked at wrong list.. apologies.

---

Another one: wuid=999173464

That's fairly unusual:

    single pulses: 30
repetitive pulses: 1

I'll run an offline test on it, most likely there really are many single pulses but even CPU processing can sometimes glitch and manufacture false pulses.

                                                                   Joe

The 3rd task has reported and, surprisingly, all three validated/received credit.

Not really surprising, the more signals there are the more likely for a very small difference in calculations to make a difference. My offline run with ap_6.01r557_SSE2_331_AVX.exe finished and found the 30 single and 1 repetitive pulses, the run with stock 6.01 is at about 57% progress and has found 14 single and 1 repetitive all of which match very closely. It should finish about when I get up tomorrow, then I'll check in detail.

                                                                  Joe

As it turned out, the stock app's 26th single pulse was only 0.0036% above threshold, and r557 must have calculated it as just below threshold so didn't report it. That wouldn't directly affect validation because only single pulses which are at least 1% above threshold are considered, but indirectly it meant that the 30th single pulse from stock was only the 29th for r557. So r557 actually analyzed that pulse better, stock quit when it first got above threshold by 0.27% but r557 found it was stronger at a higher dispersion and reported it as about 3% above threshold. The Validator calls that a mismatch since it only considers the r557 version. There was another mismatch because r557's 30th single pulse was 3.25% above threshold so also included in the Validator's checking, so two of the pulses checked from the r557 result weren't found in the stock result. Still, in terms of how the Validator works, 27 of 29 checked signals did match so the r557 result was granted credit as being "weakly similar".

                                                                  Joe

Joe,
Thank you for the explanation!
Stick

As it turned out, the stock app's 26th single pulse was only 0.0036% above threshold, and r557 must have calculated it as just below threshold so didn't report it. That wouldn't directly affect validation because only single pulses which are at least 1% above threshold are considered, but indirectly it meant that the 30th single pulse from stock was only the 29th for r557. So r557 actually analyzed that pulse better, stock quit when it first got above threshold by 0.27% but r557 found it was stronger at a higher dispersion and reported it as about 3% above threshold. The Validator calls that a mismatch since it only considers the r557 version. There was another mismatch because r557's 30th single pulse was 3.25% above threshold so also included in the Validator's checking, so two of the pulses checked from the r557 result weren't found in the stock result. Still, in terms of how the Validator works, 27 of 29 checked signals did match so the r557 result was granted credit as being "weakly similar".

                                                                  Joe

---

Not sure if you're still looking for these, but I have one:

workunit 986977542

Not sure if you're still looking for these, but I have one:

workunit 986977542

If it were practical, we'd analyze all cases of inconclusive results from Lunatics apps. There's too little time and/or equipment for that, but I'll check this one too on general principles. Should be done sometime Sunday. The WU may well be resoved before then and I expect as usual all completed tasks will get credit, but there's always the possibility analysis will point to some lurking bug.

                                                                   Joe

Here's one from me too...
http://setiathome.berkeley.edu/workunit.php?wuid=997551999

---

PROUD MEMBER OF Team Starfire World BOINC

Not sure if you're still looking for these, but I have one:

workunit 986977542

If it were practical, we'd analyze all cases of inconclusive results from Lunatics apps. There's too little time and/or equipment for that, but I'll check this one too on general principles. Should be done sometime Sunday. The WU may well be resoved before then and I expect as usual all completed tasks will get credit, but there's always the possibility analysis will point to some lurking bug.

                                                                   Joe

That one turned out to be simple to analyze, the stock app found one more repetitive pulse than optimized. The peak power was 5170.0068359375 and the threshold 5170 (FFA thresholds are truncated to integer values). So it's just one of the inevitable cases where a tiny difference in calculation is enough to cause an inconclusive validation.

                                                                   Joe

I couldn't read the whole thread but...

I have 3 APv6 with 30 repetitive pulses that are inconclusive
http://setiathome.berkeley.edu/workunit.php?wuid=997100145
http://setiathome.berkeley.edu/workunit.php?wuid=1008642492
http://setiathome.berkeley.edu/workunit.php?wuid=1007059107

And one was marked invalid after being sent to a 3rd wingman
http://setiathome.berkeley.edu/workunit.php?wuid=1005838187

There are also two others with 30 repetitive pulses that are awaiting validation, and these are all out of only 8 that are listed with AstroPulse v6 Anonymous platform, something seems a little glitchy

---

I couldn't read the whole thread but...

I have 3 APv6 with 30 repetitive pulses that are inconclusive
http://setiathome.berkeley.edu/workunit.php?wuid=997100145
http://setiathome.berkeley.edu/workunit.php?wuid=1008642492
http://setiathome.berkeley.edu/workunit.php?wuid=1007059107

And one was marked invalid after being sent to a 3rd wingman
http://setiathome.berkeley.edu/workunit.php?wuid=1005838187

There are also two others with 30 repetitive pulses that are awaiting validation, and these are all out of only 8 that are listed with AstroPulse v6 Anonymous platform, something seems a little glitchy

Although the r555 ATi OpenCL application has been reliable on most systems, there are exceptions. You might be able to stabilize processing by tuning voltages, clock rates, or command line parameters.

                                                                   Joe

That one turned out to be simple to analyze, the stock app found one more repetitive pulse than optimized. The peak power was 5170.0068359375 and the threshold 5170 (FFA thresholds are truncated to integer values). So it's just one of the inevitable cases where a tiny difference in calculation is enough to cause an inconclusive validation.
Joe

Thanks for the analysis - thought it might be something like that since I ususally don't lose when results go inconclusive. I probably won't have any more for a while. I've stopped fetching AP6 until I can figure out what's causing errors with zero runtime - have hit 4 in the past few days and I'm in troubleshoot mode. May open a thread if I don't find a problem

---

Another Fred
Support SETI@home when you search the Web with GoodSearch or shop online with GoodShop.

Over the past couple of months, I've also been trying to make sense out of the increasing occurrences of invalid results due to returning 30 repetitive pulses. In fact, aside from my main host (running AP/OpenCL on a HD 6950), I think all of my GPU-related AP work-units are returning 30 repetitive pulse results, which I find quite worrying. Especially since I generally don't over-clock and am pretty sure the hosts are otherwise stable. It seems very unlikely to me that so many hosts would start failing simultaneously.

I tried doing a full shut-down, rest, and cold boot on some of the affected hosts, as suggested elsewhere for flushing the GPU RAM - there doesn't seem to be new AP work being generated at the moment, so will have to wait to see if that makes any difference.

Host 1504137
Main machine, currently only host consistently returning valid AP results. Radeon HD 6950 running OpenCL r555, ironically the only AP-related GPU being over-clocked (albeit very modestly).

Host 6077487
A machine I made for my brother, was previously running Brook r555 on a Radeon HD 4850 at factory clock rates. Seemed stable in APv5 era, but have now switched to AP SSE2 r557. Has been returning valid AP work-units since.

Host 4462068
A 2008 laptop, was previously running Brook r555 on a Mobility Radeon HD 2600. Again, was fine in APv5 era, but even if it hadn't started generating lots of 30 repetitive pulse results, I would have switched to AP SSE2 r557 anyway because the heat pipe cooling the GPU no longer seems effective (CPU is cooled, but GPU overheats with anything more strenuous than processing a video and shuts everything down).

Host 6649080
A fairly new host, albeit older hardware, running OpenCL r555 on HD 4670. Was returning good results initially, but now I notice it is returning mostly 30 repetitive pulses, which mostly seem to be marked as invalid.

Host 6692553
Another new host running OpenCL r555 on a Fusion C-50. Before anyone questions whether it's worth the bother on such a low-power machine, I think 20 hours is a big improvement on 100+ hours on an Atom. Anyway, only the first AP work-unit was valid, subsequent results seem to exhibit 30 repetitive pulses. Has also been unlucky with regards to CPU time - a lot of high blanking percentage work-units there.

So, basically, I'm not sure what's going on, so was trying to search the forums for any clue on why I'm getting so many 30 repetitive pulse results.

---

Soli Deo Gloria

There was bugfix in r1305 that potentially can improve app precision.
All who participate please upgrade to "stock" 6.03 binary for AP (it's rev1305 binary).
All who dont' run beta - await for binary update...