Your reaction is understandable if you perceive any found bug in Petri's app as personal offence. But why so?

When people start posting such carp as "will these problems cause us to miss ET", it's time for a little reality check. Yes, Petri's App occasionally misses the Best Pulse, However, other Apps have similar problems with missing Best Signals. Other Apps have horrendous Inconclusive rates, I don't see people asking about those other problems. There is absolutely Nothing wrong with Petri's App that isn't shared by other Apps. In fact, since Petri's App is quite a bit faster, it might actually Help us find ET. Isn't the Project requesting More Computing power? Well, increasing the speed of the current hardware is in fact the same as adding more users.

I keep hearing accusations the App isn't "accurate" when actually it is Very accurate. Here's the Bench of the task with 21 signals,

---------------------------------------------------
Running app with command : setiathome_x41p_zi3v_x86_64-apple-darwin_cuda90 -device 0
      207.60 real        46.56 user        37.22 sys
Elapsed Time : ……………………………… 208 seconds
Speed compared to default : 3705 %
-----------------
Comparing results
Result      : Strongly similar,  Q= 99.95%
---------------------------------------------------
Done with 22fe07aj.17322.13569.13.40.218.wu

The App was 99.95% similar to the CPU on 21 signals. It doesn't get much more accurate.
The problem with selecting the correct best pulse has nothing to do with "accuracy", it's a simple matter of programming to select the correct result from a number of candidates.

Now that people understand the most widely used Apps at SETI also have occasional problems with Bad Best Signals maybe the wild accusations made recently in this thread will stop?
We can only Hope.
This is merely a reality check. If someone is really concerned about "missing ET' I suggest you also avoid the SoG Apps as they have a similar problem as Petri's App...and definitely avoid the Intel Apps.

The problem with selecting the correct best pulse has nothing to do with "accuracy", it's a simple matter of programming to select the correct result from a number of candidates.

Exactly. So no sense to post 99.7% as response on missing spike or wrong best issue. Those issues not about processing accuracy. Still they are issues.
App's base accuracy is well within expectations range.

Now that people understand the most widely used Apps at SETI also have occasional problems with Bad Best Signals maybe the wild accusations made recently in this thread will stop?

Hm. Accusations? Perhaps we read thread differently.

This is merely a reality check. If someone is really concerned about "missing ET' I suggest you also avoid the SoG Apps as they have a similar problem as Petri's App...and definitely avoid the Intel Apps.

Well, AFAIK Nebula uses only signals, not best signals (so far). It can be changed in future of course.

EDIT: I personally was very concerned about wrong Pulse selection in early builds.
And cause there is no warranty that current wrong best pulse selection and old wrong pulse selection are from different bugs that makes strong willing that this issue be resolved too before any further movement.

NaNs in spikes are so obvious flaws in resume logic that really nothing to add here.

---

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

I guess I'll take the risk of another tirade, but I think a discrepancy between the Cuda 9 zi3v and the Cuda 8 zi3v (on a non-overflow WU) is worth looking at.

Workunit 2752775513 (28mr07am.15114.4162.8.35.134)
Task 6179979325 (S=0, A=1, P=11, T=8, G=0, BS=23.41541, BG=3.899168) x41p_zi3v, Cuda 9.00 special
Task 6179979326 (S=0, A=1, P=10, T=8, G=0, BS=23.41541, BG=3.89917) x41p_zi3v, Cuda 8.00 special

The extra signal reported by the Cuda 9 version is::
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

I guess I'll take the risk of another tirade, but I think a discrepancy between the Cuda 9 zi3v and the Cuda 8 zi3v (on a non-overflow WU) is worth looking at.

Workunit 2752775513 (28mr07am.15114.4162.8.35.134)
Task 6179979325 (S=0, A=1, P=11, T=8, G=0, BS=23.41541, BG=3.899168) x41p_zi3v, Cuda 9.00 special
Task 6179979326 (S=0, A=1, P=10, T=8, G=0, BS=23.41541, BG=3.89917) x41p_zi3v, Cuda 8.00 special

The extra signal reported by the Cuda 9 version is::
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

CPU gave:
Spike count: 0
Autocorr count: 1
Pulse count: 11
Triplet count: 8
Gaussian count: 0

So seems it's missing 11th pulse instead of extra one.
In CPU it:
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

---

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

Look at it now, https://setiathome.berkeley.edu/workunit.php?wuid=2752595674
The tie-breaker was sent to another SoG App, and Yes, they validated each other.
So....my Correct result, that matched a CPU, was over-ruled by two SoG Apps known to produce Bad Best Gaussians.
Who'd a thunk it? Well, anyone not in severe denial would have seen that coming.
I wonder how many times that has happened in the past year or so...

I got another one, https://setiathome.berkeley.edu/workunit.php?wuid=2752595674 It looked the same, I decided to run it.

CUDA Special 9.0;
Best spike: peak=25.70546, time=85.56, d_freq=1420565431.23, chirp=90.947, fft_len=32k
Best autocorr: peak=18.00695, time=100.7, delay=4.8311, d_freq=1420567715.68, chirp=13.008, fft_len=128k
Best gaussian: peak=3.818873, mean=0.5320869, ChiSq=1.266398, time=26, d_freq=1420563643.87,
score=0.9975023, null_hyp=2.222546, chirp=-36.341, fft_len=16k
Best pulse: peak=5.220406, time=46.27, period=1.73, d_freq=1420565622.82, score=1.009, chirp=-68.462, fft_len=512
Best triplet: peak=0, time=-2.12e+11, period=0, d_freq=0, chirp=0, fft_len=0

Windows SoG 3584;
Best spike: peak=25.70546, time=85.56, d_freq=1420565431.23, chirp=90.947, fft_len=32k
Best autocorr: peak=18.00693, time=100.7, delay=4.8311, d_freq=1420567715.68, chirp=13.008, fft_len=128k
Best gaussian: peak=3.664716, mean=0.5392017, ChiSq=1.408692, time=27.68, d_freq=1420563582.9,
score=0.614264, null_hyp=2.284244, chirp=-36.341, fft_len=16k
Best pulse: peak=5.22041, time=46.27, period=1.73, d_freq=1420565622.82, score=1.009, chirp=-68.462, fft_len=512
Best triplet: peak=0, time=-2.12e+011, period=0, d_freq=0, chirp=0, fft_len=0

CPU 3711;
Best spike: peak=25.70545, time=85.56, d_freq=1420565431.23, chirp=90.947, fft_len=32k
Best autocorr: peak=18.00695, time=100.7, delay=4.8311, d_freq=1420567715.68, chirp=13.008, fft_len=128k
Best gaussian: peak=3.818873, mean=0.5320868, ChiSq=1.2664, time=26, d_freq=1420563643.87,
score=0.9975224, null_hyp=2.222548, chirp=-36.341, fft_len=16k
Best pulse: peak=5.220407, time=46.27, period=1.73, d_freq=1420565622.82, score=1.009, chirp=-68.462, fft_len=512
Best triplet: peak=0, time=-2.12e+11, period=0, d_freq=0, chirp=0, fft_len=0

This looks to be a pretty common problem. This Host had ZERO Inconclusive results before, https://setiathome.berkeley.edu/results.php?hostid=8282042
I'll bet he has more Bad Gaussians, they are just not showing up because the other SoG Hosts are validating with the same Bad Gaussians. He obviously isn't being introduced to mister Bad Wingman either...I wonder Why?
I just found Two examples of the Bad Best Results....and I wasn't even trying.

I guess I'll take the risk of another tirade, but I think a discrepancy between the Cuda 9 zi3v and the Cuda 8 zi3v (on a non-overflow WU) is worth looking at.

Workunit 2752775513 (28mr07am.15114.4162.8.35.134)
Task 6179979325 (S=0, A=1, P=11, T=8, G=0, BS=23.41541, BG=3.899168) x41p_zi3v, Cuda 9.00 special
Task 6179979326 (S=0, A=1, P=10, T=8, G=0, BS=23.41541, BG=3.89917) x41p_zi3v, Cuda 8.00 special

The extra signal reported by the Cuda 9 version is::
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

CPU gave:
Spike count: 0
Autocorr count: 1
Pulse count: 11
Triplet count: 8
Gaussian count: 0

So seems it's missing 11th pulse instead of extra one.
In CPU it:
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

Well, I guess it's time to post the CUDA 9 version. It does seem to produce better results.
Do everyone a favor and update to the New and Improved version of x41p_zi3v, it's in the same location;
Linux_zi3v-CUDA90_Special App
...for fewer Inconclusive Results

BTW, the Default CPU App is now SSE41 with FFTW 3.3.7. On my machine it's just a couple percent better than the old ssse3 App, YMMV.

CPU gave:
Spike count: 0
Autocorr count: 1
Pulse count: 11
Triplet count: 8
Gaussian count: 0

So seems it's missing 11th pulse instead of extra one.
In CPU it:
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

Well, I guess it's time to post the CUDA 9 version. It does seem to produce better results.
Do everyone a favor and update to the New and Improved version of x41p_zi3v, it's in the same location;
Linux_zi3v-CUDA90_Special App
...for fewer Inconclusive Results

BTW, the Default CPU App is now SSE41 with FFTW 3.3.7. On my machine it's just a couple percent better than the old ssse3 App, YMMV.

. . Hi TBar,

. . Are there any further hardware restrictions with the Cuda90 version? Is it OK with Maxwell as well as Pascal cards?

Stephen

??

I guess I'll take the risk of another tirade, but I think a discrepancy between the Cuda 9 zi3v and the Cuda 8 zi3v (on a non-overflow WU) is worth looking at.

Workunit 2752775513 (28mr07am.15114.4162.8.35.134)
Task 6179979325 (S=0, A=1, P=11, T=8, G=0, BS=23.41541, BG=3.899168) x41p_zi3v, Cuda 9.00 special
Task 6179979326 (S=0, A=1, P=10, T=8, G=0, BS=23.41541, BG=3.89917) x41p_zi3v, Cuda 8.00 special

The extra signal reported by the Cuda 9 version is::
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

CPU gave:
Spike count: 0
Autocorr count: 1
Pulse count: 11
Triplet count: 8
Gaussian count: 0

So seems it's missing 11th pulse instead of extra one.
In CPU it:
Pulse: peak=1.497699, time=67.72, period=0.3382, d_freq=1418807571.33, score=1.009, chirp=75.027, fft_len=8

So, compiling zi3v as Cuda 9 gives a more accurate result than the Cuda 8 version. That's good to know. Might be good to know why that happens, too, since I assume the underlying code is still the same, just linking to different libraries.

Looking at some results it appears the AMD CPUs still don't like the CPU App. It seems better than the ssse3 version, but still giving errors. I'm going to add a folder to the download with an App compiled just for AMD CPUs and see if that works better. If you have an AMD CPU just move the CPU App from the folder to the root level replacing the existing CPU App. Since it's flagged for AMD, it won't work on my Intels, so, you're on your own. The current SSE41 App works fine on my Intel CPUs.

The only difference with the zi3v GPU App is it uses the gaussfit & autocorr from zi3x, so, it is a little different from just zi3v compiled with CUDA 9 and might show some slight difference, hopefully for the better. It seems to work better on my machines anyway.

The new file has been uploaded, if you have an AMD CPU download Linux_zi3v-CUDA90_Special.7z again.

Thanks TBar, I was about to shoot you a PM asking about the sigsegv errors with the r3711 app. Never had an issue with either the r3345 or r3306 apps previously. Just installed the made for AMD version. Will continue to monitor.

---

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

A proud member of the OFA (Old Farts Association)

Well, I guess it's time to post the CUDA 9 version. It does seem to produce better results.
Do everyone a favor and update to the New and Improved version of x41p_zi3v, it's in the same location;
Linux_zi3v-CUDA90_Special App
...for fewer Inconclusive Results

BTW, the Default CPU App is now SSE41 with FFTW 3.3.7. On my machine it's just a couple percent better than the old ssse3 App, YMMV.

OK wanted to try the cuda9 app and of course, since this is Linux, things isn't going well...

No problem uninstalling the repo drivers and installing the newest Nvidia drivers, vent well, but there is 2 problems,

Most important, now BOINC only sees the 1080 GPU, the 970 GPU is not even mentioned in the repo BOINC event log.

2nd not that important but very annoying, the cinnamon desktop in Mint 18.1 crashes on every boot resulting in bad low res desktop. Had the same problem when I first installed Mint and using the repo drivers, it solved itself by chance when I ran the cool-bits command line thingy, but it doesn't work now. Think it's something with the x server not running but not sure.

Have no idea what to do other than trying going back to the repo drivers, if that works...

Which Nvidia driver are you trying to use? From where did you source it? I just used the Synaptic Package Manager and chose the 384.90 driver. I had previously used the graphics driver PPA and installed the 387.12 driver but as soon as I saw the normal 384.90 driver show up in the repository, I backleveled to the repository version to make things simpler. The 384.90 is the lowest Linux version that has support for CUDA 9.0 as far as I know.

I have had issues with the Xorg.conf file getting overwritten from new installs and I always make sure I have a backup of the file ready to use. When I have found myself with a low resolution desktop I have been able to go back through the grub recovery menu and choose the backup Xorg server file settings and that has gotten me squared away again.

I don't remember what Mint uses for the X-server. I have been able to stop the lightdm service from the alt-console and restart it when things got really hosed in Ubuntu. Have you tried similar in Mint?

---

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

A proud member of the OFA (Old Farts Association)

Do you have the <use_all_gpus>1</use_all_gpus> setting in cc_config.xml? The 1080 and 970 are sufficiently different enough that BOINC will only use the most capable 1080 without the setting.

---

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

A proud member of the OFA (Old Farts Association)

...resulting in bad low res desktop.

One of my machines reverts to 640x480, with no other options, after making any driver or GPU change. It's actually the coolbits tweak that overwrites the xorg.conf file and screws it up.

What works for me is to manually edit the xorg.conf file to add the additional display modes. Each Monitor section then looks like:

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    Modeline "1024x768_60.00" 63.50 1024 1072 1176 1328 768 771 775 798 -hsync +vsync
    Option "PreferredMode" "1024x768_60.00"
EndSection

...and each Screen section looks like:

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Coolbits" "28"
SubSection     "Display"
Depth 8
Modes "1024x768" "1280x1024" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 16
Modes "1024x768" "1280x1024" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768" "1280x1024" "800x600" "640x480"
EndSubSection
EndSection

Now, that's for Ubuntu 14.04, so whether something like that would work for Mint is unknown.

I used the 384.98 drivers from the Nvidia site, using the repo 384.90 drives would be better I guess. I'll try that before anything else.

Yes I have enabled the use_all_gpus option.

The 384.90 is the lowest Linux version that has support for CUDA 9.0 as far as I know.

Driver 384.59, downloaded from Nvidia, appears to be working okay on the one machine I'm trying it on. So perhaps that's the lowest one that works. I found out that 375.66 doesn't.

Thanks for the correction, Jeff.

---

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

A proud member of the OFA (Old Farts Association)

Uninstalled drivers from nvidia site and installed the repo 384.90 drives. Now BOINC finds NO GPUs, but x server settings does report both GPUs.

btw the cinnamon desktop works.

You may want to move to a newer version of Mint, say 18.2. Some Machines and OSes don't respond well to the CUDA 9.0 drivers. I still can't use the CUDA 9 drivers with my older machines using Kernel 4.10. They work fine with Kernels below 4.10 with the CUDA 9 drivers. Your case may be the opposite, you may need to use a newer Kernel with your newer CPU.

Another disagreement between the old and new. Seems to be a few of them; https://setiathome.berkeley.edu/workunit.php?wuid=2756047877

setiathome v8 enhanced x41p_zi3v, Cuda 8.00 special
Spike count: 28
Autocorr count: 1
Pulse count: 1
Triplet count: 0
Gaussian count: 0

setiathome v8 enhanced x41p_zi3v, Cuda 9.00 special
Spike count: 27
Autocorr count: 1
Pulse count: 2
Triplet count: 0
Gaussian count: 0

SSE4.1xjf OS X 64bit Build 3344
Spike count: 27
Autocorr count: 1
Pulse count: 2
Triplet count: 0
Gaussian count: 0

One of those late overflows.