Things seem to improve. Look further down and look at my consecutive valid tasks with Petris latest revision.

http://setiathome.berkeley.edu/host_app_versions.php?hostid=8053171

*Thumbs up*

You may give it a thumbs up ATM, but if you have a thorough look, the app still isn't giving a straight out conclusive result against a standard CPU app running on an error free rig, it still needs a 3rd to validate.

It's just something to have a closer look for those interested. ;-)

Cheers.

I've seen some false positive signals i.e. an extra pulse found or a case when the exaclty same pulse (frequency, time and chirp) is found but a different power for the pulse is reported.

a) all setiathome signals so far are false positives. All and every one. Even the WOW signal.

b) A pulse that is at the same frequency, time and chirp is the same pulse by another application. The power of the pulse may be 1/100000 or 1/1e6 different but all signals that are suspected valid are to be rechecked byt seti institution anyway by not with our public software. They'll run a double double precision SW then. The difference in power comes from the different hw architecture, different implementation of calculating the average (that is an estimate at best since the average need a sum of thousands of floating point approximations of a number and can be done in sequential, pairwise, recurring or whatever way and still be 'right') and the different order of doing a+b+c+d vs (a+b)+(c+d) or any other combination of 32 bit floating point arithmetic with rounding errors.

The found pulses should be matched for frequency, time and chirp a priori and with a tolerance for error in the power. (That is what they do now and that is why some results need a third oppinion). An occasional false positive is not a bad thing. They happen with low power signals that are most probably due to noise.


The MAC problem with a certain OS version is not my problem. It affects the OpenCL version too.

---

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

I've seen some false positive signals i.e. an extra pulse found or a case when the exaclty same pulse (time and chirp) is found but a different power for the pulse is reported.

So they are not quite false positive, that just have incorrect power.

a) all setiathome signals so far are false positives. All and every one. Even the WOW signal.

Not correct. One need to clearly distinguish false positive in sense of validator passing and in scientific sense. You used "scientific sense" here but w/o real ground. SETI@home doesn'r look into single signals at all. PErcistency is requirement for anything of near to threshold power. That is, to say if we detected signal or not postprocessing required. And until it will be performed we (no one) can't say that we catch only false positives so far.

b) A pulse that is at the same time and chirp is the same pulse by another application. The power of the pulse may be 1/100000 or 1/1e6 different but all signals that are suspected valid are to be rechecked byt seti institution anyway by not with our public software. They'll run a double double precision SW then. The difference in power comes from the different hw architecture, different implementation of calculating the average (that is an estimate at best since the average need a sum of thousands of floating point approximations of a number and can be done in sequential, pairwise, recurring or whatever way and still be 'right') and the different order of doing a+b+c+d vs (a+b)+(c+d) or any other combination of 32 bit floating point arithmetic with rounding errors.

Our aim on this distributed phase is just make results to pass validator with as low number of resends as possible. No need to mix this task with further stages of signal post-processing.
EDIT: and of course near-to-threshold inconsistency unavoidable in all apps.

The MAC problem with a certain version is not my problem. It affects the OpenCL version too.

Did you see some reports of the same issue for CUDA too?

---

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

The MAC problem with a certain version is not my problem. It affects the OpenCL version too.

Did you see some reports of the same issue for CUDA too?

I think TBar reported just that at this thread or in the 'built some osx apps' thread.

---

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

Our aim on this distributed phase is just make results to pass validator with as low number of resends as possible. No need to mix this task with further stages of signal post-processing.
EDIT: and of course near-to-threshold inconsistency unavoidable in all apps.

And to lower the number of resends 'they' might lower the bar on 'power' just because of the unavoidable inconsistency.

---

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

The MAC problem with a certain version is not my problem. It affects the OpenCL version too.

Did you see some reports of the same issue for CUDA too?

I think TBar reported just that at this thread or in the 'built some osx apps' thread.

Ah, maybe... I thought the same but looked into app names in posted bench saw only vs OpenCL comparison. Of course if OpenCL computes incorrectly any comparison with it just void and has apriory no sense.

Would be good if soem comparison vs known to be OK CPU would made. Cause so far I did not saw definitive reports of CUDA issue for particular OS X versions (TBar, could you clarify this a little?? )

---

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

Our aim on this distributed phase is just make results to pass validator with as low number of resends as possible. No need to mix this task with further stages of signal post-processing.
EDIT: and of course near-to-threshold inconsistency unavoidable in all apps.

And to lower the number of resends 'they' might lower the bar on 'power' just because of the unavoidable inconsistency.

Well, so far tolerance range was OK enough (actually, we in 99+% similarity for all already released apps on working HW/soft combos). This doesn't exclude occasional inconsistencies of course. But to tell if something too bad happens with particular build or just "too near to threshold" case some additional observations required.

---

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

Our aim on this distributed phase is just make results to pass validator with as low number of resends as possible. No need to mix this task with further stages of signal post-processing.
EDIT: and of course near-to-threshold inconsistency unavoidable in all apps.

And to lower the number of resends 'they' might lower the bar on 'power' just because of the unavoidable inconsistency.

Well, so far tolerance range was OK enough (actually, we in 99+% similarity for all already released apps on working HW/soft combos). This doesn't exclude occasional inconsistencies of course. But to tell if something too bad happens with particular build or just "too near to threshold" case some additional observations required.

My latest version (and the previous one too) zi3f-zi3g give 99%+ similarity on tests. One guppi vlar finds an extra signal (low power, low average) and my inconclusives is falling rapidly. The old ones from earlier version do persist a month or so in the inconclusives though until they are validated by a third computer.

---

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

When you will feel ready to wider testing your build should be deployed on SETI beta site for wider testing (both for compatible HW/SW combos designation and for validness). Some preliminary beta testing can be made too but adequate validness checking almost impossible on SETI main (this thread clearly shows what difficulties encountered on main). So, some time shold be spend on beta site too (under anonymous platform or as new stock distribution).
On beta results persist much longer + 3-way validation better shows any issues if any.

---

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

When you will feel ready to wider testing your build should be deployed on SETI beta site for wider testing (both for compatible HW/SW combos designation and for validness). Some preliminary beta testing can be made too but adequate validness checking almost impossible on SETI main (this thread clearly shows what difficulties encountered on main). So, some time shold be spend on beta site too (under anonymous platform or as new stock distribution).
On beta results persist much longer + 3-way validation better shows any issues if any.

I could set mine to run 5% beta. Would that help?

EDIT: When I set it to beta how do I set it up to run my version instead of the downloaded app?

---

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

When you will feel ready to wider testing your build should be deployed on SETI beta site for wider testing (both for compatible HW/SW combos designation and for validness). Some preliminary beta testing can be made too but adequate validness checking almost impossible on SETI main (this thread clearly shows what difficulties encountered on main). So, some time shold be spend on beta site too (under anonymous platform or as new stock distribution).
On beta results persist much longer + 3-way validation better shows any issues if any.

I could set mine to run 5% beta. Would that help?

Well, this will slowly create some set of tasks completed by your app that persists long enough to be analysed. So definitely it would be good thing even if running only on single host.
Would be good if your current alpha-testers will do the same. And if no hazards will be discovered, semi-open or open beta will be the next stage IMHO.
If your app much faster would be good if it will be distributed as wide as possible (after adequate testing of course).

---

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

EDIT: When I set it to beta how do I set it up to run my version instead of the downloaded app?

Just the same way as for main - via app_info.xml and anonymous platform setup.

---

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

If we're about to take the original S@H code today and compare it against all platforms would all variants produce 100% instead of 99+%?

We're talking a bunch of WU's and a whole lot of variants:

Debian, Ubuntu , Arch , Mint etc x32, x64.
Apple variants
Windows Vista,7,8,8.1,10,Server 2008,Server 2012 x32 and x64
Arm Linux, Android etc etc.

There are alot to compare through in a chart to see if the cpu portion of the code works as intended on all platforms with 100% similarity.
If not then i Think s@h themselves need to have a plan to solve this because if the cpu portion of the executables isn't a 100% match how on Earth would we ever get as Close to 100% on GPUs when the problems would be multiplied within the code.

Just a thought and my 2 cents of thinking outside the box now.

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

EDIT: When I set it to beta how do I set it up to run my version instead of the downloaded app?

Just the same way as for main - via app_info.xml and anonymous platform setup.

Thanks, I'm running now some blc7_guppi_57449 v 8.10 tasks on beta.
EDIT: http://setiweb.ssl.berkeley.edu/beta/hosts_user.php?userid=17240

---

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 we're about to take the original S@H code today and compare it against all platforms would all variants produce 100% instead of 99+%?

Of course they will be 99+%. You just listed reasons why and nobody expects 100% similarity and never expected. That's why validator has some validation tolerance range (!) (and, btw, it quite wider than our Lunatics 99+ standart).
But if validator marks result as inconclusive, especially for new quite re-designed build, we need to establish the reason why and how often this happens.
Nothing new here, all apps passed and still passing through the same testing.

---

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

EDIT: When I set it to beta how do I set it up to run my version instead of the downloaded app?

Just the same way as for main - via app_info.xml and anonymous platform setup.

Thanks, I'm running now some blc7_guppi_57449 v 8.10 tasks on beta.
EDIT: http://setiweb.ssl.berkeley.edu/beta/hosts_user.php?userid=17240

Thanks for link, this will simplify testing analyse for those who interested.

---

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

Has anyone the knowledge exactly how the validator works? I mean how much is the tolerance, does it compare spikes, tripplets, gaussians and pulses with exactly the same tolerance in percentage?
How much is the +/- percentage even what it consider a mismatch and why does it later on even validate the result when it first marked it with a invalid.
Whats the difference there first and second time?

EDIT: Could perhaps look at the server portion of the code if its public available

---

_________________________________________________________________________
Addicted to SETI crunching!
Founder of GPU Users Group

EDIT: Could perhaps look at the server portion of the code if its public available

yep, it's publicly available and in the same repository as all SETI code.

Why validated later, simple example:

1 and 3 - differs by 2.
But {1,2,3} 2 differs only by 1 to 3 and to 1, 1 differs only by 1 to 2 the same for 3 - all passed validation.
It's quite rough example of course.

---

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

Look the the rescmpv on lunatics, they include the source code that is used for the server.

EDIT: also on the repo for all seti code

The MAC problem with a certain version is not my problem. It affects the OpenCL version too.

Did you see some reports of the same issue for CUDA too?

I think TBar reported just that at this thread or in the 'built some osx apps' thread.

Ah, maybe... I thought the same but looked into app names in posted bench saw only vs OpenCL comparison. Of course if OpenCL computes incorrectly any comparison with it just void and has apriory no sense.

Would be good if soem comparison vs known to be OK CPU would made. Cause so far I did not saw definitive reports of CUDA issue for particular OS X versions (TBar, could you clarify this a little?? )

For Petri's Apps the only problems I've noted are also present in Linux. But it Appears those problems may have been Solved with the latest version x41p_zi3g. So far, running zi3g in Darwin 14.5 with CUDA driver 7.5.27 has been trouble free. Items that Appear to have been fixed are;
1) Runs with the 7.5.x driver without causing the 750Ti to Stall
2) Occasional reports of ...exited with zero status but no 'finished' file, Gone
3) Extreme Autocorrelation Peaks Non-existent

So Far, So Good.

The other problem with the Baseline Apps only affect the Laptops Occasionally.
That is a problem with the Baseline code, which I think Jason controls.
Petri's App doesn't work on those Laptops.


Hmmm, just noticed an Invalid overflow with x41p_zi3g, http://setiathome.berkeley.edu/result.php?resultid=5139355961
Looking at the time, Received: 6 Sep 2016, 5:31:32 UTC, that must have been one of the first tasks run with x41p_zi3g, and it was on the 750Ti. We'll have to see if anymore appear.
I suppose the next thing to do would be to build a Linux version. This should be fun, since the last Linux build I've installed a clean system.

Not good, another Overflow on the 750Ti that the WingPerson doesn't agree with, http://setiathome.berkeley.edu/workunit.php?wuid=2257472392
Seems there is still no love for the 750Ti with driver 7.5.x, although it has Not Stalled.