I noticed that my folder updates are now instantaneous. Sure enough, all the OpenCL WUs have been replaced with CUDA, but not short run times (almost an hour @ 0.403 core.)

Guys, it looks as if I'm going to be "somewhat random" over the next few days - I've just had a long conversation with work and I've got to head off to cover fr someone who has just suffered "a bit of a domestic crisis" (not life threatening, but not good either)
I'll have to put this trial on ice until the storm settles and I can devote a few hours to it later in the week.

(Now frantically throwing things in a bag, ready for the off in about 8 hours and one sleep's time...)

Could you next time you see such freeze in Explorer try to look what task performed on GPU connected to monitor. VLAR or not and what AR if not?

Application			SETI@home v8 8.06 (opencl_nvidia_sah)
Name				06ap11ag.11253.1294.15.49.90
State				Running
Received			17/01/2016 8:11:39 AM
Report deadline			11/03/2016 4:53:45 AM
Resources			0.403 CPUs + 1 NVIDIA GPU (device 0)
Estimated computation size	186,149 GFLOPs
CPU time at last checkpoint	00:07:33
CPU time			00:08:27
Elapsed time			00:09:09
Estimated time remaining	00:02:08
Fraction done			83.358%
Virtual memory size		132.30 MB
Working set size		100.20 MB
Directory			slots/8
Process ID			7244
Progress rate			9.426% per minute
Executable			setiathome_8.06_windows_intelx86_opencl_nvidia_sah.exe

Also the freezes happen always whenever I do any Explorer change (since I started Beta and ran any OpenCL work.) This only affect changes I do... if I download a file through Firefox, for example, the folder window updates immediately with the new file. So it's only a minor inconvenience although others may find it annoying if they are doing many changes in Windows Explorer and don't know the cause.

try to troubleshoot this via -period_iterations_num N -sbs N parameters change until acceptable Explorer refreshing will be found.
Perhaps defaults should be changed for NB build cause it's apparent NV cards can't deal with PulseFind as good as ATi's one do.

---

News about SETI opt app releases: https://twitter.com/Raistmer

How can these two results have two results in one stderr? I've seen the same in many WU's run with (opencl_atiapu_sah)

And the two results in the same stderr, are different too, in the same stderr...

Scroll down in the stderrs, and you'll see two different results in the same stderr:

https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039477
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039478

How can these two results have two results in one stderr? I've seen the same in many WU's run with (opencl_atiapu_sah)

And the two results in the same stderr, are different two, in the same stderr...

Scroll down in the stderrs:

https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039477
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039478

Overflow was found in triplet logging then GPU was queried for spikes results and spikes were reported too. It's pecularity of SoG build.

---

News about SETI opt app releases: https://twitter.com/Raistmer

How can these two results have two results in one stderr? I've seen the same in many WU's run with (opencl_atiapu_sah)

And the two results in the same stderr, are different two, in the same stderr...

Scroll down in the stderrs:

https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039477
https://setiweb.ssl.berkeley.edu/beta/result.php?resultid=22039478

Overflow was found in triplet logging then GPU was queried for spikes results and spikes were reported too. It's pecularity of SoG build.

Heh, thanks. Yeah peculiarity it was indeed :-)

My CUDA was kicked out as invalid though, when it reported just:

Spike count: 30
Autocorr count: 0
Pulse count: 0
Triplet count: 0
Gaussian count: 0
.

Both apps most probably reported valid subset of whole signals that that task contains. They just picked them in different orders hence different subsets.
Next SoG build will have more "traditional" signals ordering. Though this issue can be properly handled only on validator level.

---

News about SETI opt app releases: https://twitter.com/Raistmer

And on this one https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7985228 , my CUDA did not report anything else than:

Find triplets Cuda kernel encountered too many triplets, or bins above threshold, reprocessing this PoT on CPU...
cudaAcc_free() called...
cudaAcc_free() running...
cudaAcc_free() PulseFind freed...
cudaAcc_free() Gaussfit freed...
cudaAcc_free() AutoCorrelation freed...
cudaAcc_free() DONE.
Cuda sync'd & freed.
Preemptively acknowledging a safe Exit. ->
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Flopcounter: 206561637.989259

Spike count: 0
Autocorr count: 0
Pulse count: 0
Triplet count: 30
Gaussian count: 0

While the other two reported:

Spike count: 0
Autocorr count: 0
Pulse count: 16
Triplet count: 14
Gaussian count: 0

Seems as if CUDA v8, isn't really ready for main....

Well the 266.58 whql(cuda 32) on a dirty Zotac(EVGA firmware) GTX580 Infinity @ 700MHz is validating and someone said something about needing 350+ Nvidia driver under Windows 7 Pro sp1 x64.

My results as of this moment in time:

(614) · In progress (1) · Validation pending (5) · Validation inconclusive (2) · Valid (606) · Invalid (0) · Error (0)
Application: All (891) · AstroPulse v7 (0) · SETI@home v7 (277) · SETI@home v8 (614)

Seems as if CUDA v8, isn't really ready for main....

nothing to do with v8. the problem has been a longstanding one and results from vastly different processing orders on CPU and GPU. Raistmer has tried to get his app to report the same subset as the CPU would find, so you find those apps agree. usually the sets match enough to get credit, you were unlucky t have sucha disjunct set, that the validator threw it out.

To make a graphic approximation of the problem:

Imagine you and a collegue are sent ou to check the roads for potholes and to report the exact location of each. if there are only a few potholes, you'll come back with the same numbers (give or take). now imagine you have a pothole riddled road, but only space for 30 holes on your sheet (and no spares). now if you and you collegue start on different ends of the road you may find you've run out of space before you even reached the bit your mate was checking. The boss doesn't know who reported the right holes, so he sends a third guy. and that guy starts where your mate was. so boss tells you 'sorry yours can't be right, the other two guys are giving me completely different numbers.'

bad luck, and something that will need addressing [is on the list for being addressed], but not when we are working like crazy to get a version update released.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

Please note that this problem is (almost exclusively) prevalent when there are a huge number of signals at the very start of processing. In the example WU 7985228 Tutankhamon discussed, nobody spent more than 30 seconds on the task - the first user (using CPU only) would have spent over four hours working on it if the WU hadn't suffered RFI.

Thanks William, and Richard for the explanation. I'll just lean back and relax then....:-)

My GTX260 host:

SETI@home v8 8.00 windows_intelx86 (cuda23)
Number of tasks completed 61
Max tasks per day 95
Number of tasks today 5
Consecutive valid tasks 62
Average processing rate 94.51 GFLOPS
Average turnaround time 0.37 days
SETI@home v8 8.00 windows_intelx86 (cuda32)
Number of tasks completed 90
Max tasks per day 124
Number of tasks today 1
Consecutive valid tasks 91
Average processing rate 85.52 GFLOPS
Average turnaround time 0.61 days
SETI@home v8 8.00 windows_intelx86 (cuda42)
Number of tasks completed 33
Max tasks per day 68
Number of tasks today 1
Consecutive valid tasks 35
Average processing rate 70.06 GFLOPS
Average turnaround time 0.63 days
SETI@home v8 8.00 windows_intelx86 (cuda50)
Number of tasks completed 42
Max tasks per day 77
Number of tasks today 0
Consecutive valid tasks 44
Average processing rate 79.46 GFLOPS
Average turnaround time 0.65 days

So, APR correctly shows CUDA23 as fastest for this GPU (it was for v7 in all offline benchmarks before).
But full mix of tasks still on host. It will be interesting to observe how and when BOINC will be able to select best one. At least it's on rihgt way now. For MB v7 it wasn't able to select right build.

---

News about SETI opt app releases: https://twitter.com/Raistmer

Eric,

About the result_overflow not always turning into runtime_outlier.

The validator checks for overflow only when it's still searching for the canonical result. The weakly similar tests are missing the checks.

Calls to check_overflow_result() need to go inside the loop that starts at line 263 and in to check_pair() around line 418.

Also, the v6/v7 cheater check is misplaced in check_pair(), it should go after the if (retval) block, not inside it. The check is also completely missing from the weakly similar test loop that starts at line 263.

Thanks! Glad other eyes are looking at this.

---

Which file does that go in Mike and is it all one line or two?

mb_cmdline_win_x86_SSE3_OpenCL_NV.txt

Its one line.
Just make sure there is a space in front of the first char.

If you experience issues remove _no_cpu_lock switch.

please elaborate on 'make sure there is a space in front of the first char'

do you mean
- start the entry with a ' '
- make sure there are ' ' between different '-' entries
- something else

anything that's not straightforward needs to go into the documentation we are currently finalising.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)

I was just testing that. With intel_gpu, -v 0 (with no space at the beginning of the line) was recognised and acted upon correctly.

William is right, there needs to be a space between each separate switch (and if the switch needs a number or numbers as well, like -v, they should always be present).

Today I've had a flurry of tasks (12 so far over 5 hosts (4 Windows, 1 Android), both CPU and GPU), that have reported Completed, marked as invalid, despite them completing and validating for the two other wingmen.

Anyone else seen anything similar?

Not sure if this link will work http://setiweb.ssl.berkeley.edu/beta/results.php?userid=14462&offset=0&show_names=0&state=5&appid=

That was due to the validator problem Juha found. I've triggered the validator to run again on all the invalid result that came in in the past few days. It should mark any that caught the bug as valid.

---

That was due to the validator problem Juha found. I've triggered the validator to run again on all the invalid result that came in in the past few days. It should mark any that caught the bug as valid.

Umm, no, sorry, not really like that. The bug was there already but now that you moved the v6/v7/v8 cheater check in check_pair() the bug is really exposed.

The invalids I checked are all overflow results and the third result to come in. You forgot to add the call to check_overflow_result() into check_pair() . It needs to go before the cheater check since the cheater check needs to know if the result was an overflow one.