Thanks. Still need to read it... Repo version is in sync enough?

Cuda multibeam Alpha, Updated client/alpha to Petri's zi3v. Addresses the pulse race condition. Some questions about best Gaussian are being investigated.

While I'm certainly eagerly awaiting a Windows version of the Special App (I view my Linux excursion as merely a temporary visit to a carnival funhouse), I surely hope you don't have to end up in the unemployment line to make it happen. ;^)

As for 1Mb cards, couldn't that be coded? If Vram<1200mb -> set unroll=1

Problems with restarts have existed forever with Petri's App. Since his tasks finish in under a few minutes I don't think he uses checkpoints.

But he's not just coding for himself. Or is he?

...
To make it even more bizarre, there were 5 Spikes reported before the shutdown and those appear to match the wingmen's reports. But 5 + 27 should equal 32, whereas the reported Spike count for the -9 Overflow is still just 30.

@SETIEric If a 'best Gaussian' looks more 'Guassianey' than the reportables, why may it not necessarily be reportable ?

A Gaussian has to pass 3 thresholds. 1. A power threshold for the fit to even occur 2. A chisqr "gaussianness" thresholld and

3. A null chisqr "integrated power" threshold. The "Best Gaussian" is chosen by a score computed from chisqr and nullchisqr.

But for best Gaussian, the thresolds are lower than for reported Gaussians, especially early in the run (we always want a best Gaussian)

So it's possible for a high scoring Gaussian not to meet the chisqr threshold and not be reported.

Thanks for the detailed responses :D. Context is we currently have different apps doing different things. Can now compare against intent.

Ah, but I guess I have one more post to make before cutting some ZZZs. And back on topic, too. After 14+ hours my Windows CPU (setiathome_8.00_windows_intelx86) bench of 23se08ac.6875.22968.6.33.135 just finished. TBar had indicated that he thought this WU was a bit of a problem case. He may have been right. My original post:

Workunit 2573263722 (23se08ac.6875.22968.6.33.135)
Task 5805117074 (S=3, A=0, P=1, T=3, G=0) x41p_zi3t2b, Cuda 8.00 special
Task 5805117075 (S=3, A=0, P=1, T=3, G=0) v8.22 (opencl_nvidia_SoG) windows_intelx86

Cuda 8.00 special - Best gaussian: peak=3.252388, mean=0.5397108, ChiSq=1.344394, time=14.26, d_freq=1418816790.11,
score=-1.169299, null_hyp=2.144445, chirp=-39.071, fft_len=16k
v8.22 SoG - Best gaussian: peak=3.76217, mean=0.5480909, ChiSq=1.226871, time=39.43, d_freq=1418822660.68,
score=-1.169124, null_hyp=2.078196, chirp=43.425, fft_len=16k

Well, it seems that in this case the "gold standard" agrees with SoG:
<best_gaussian>
<peak_power>3.7621715068817</peak_power>

G'night.

Oh you'd be surprised [as I was]. The immediacy bypasses all sorts of tradition and other impediments. Eliminates the old 'Chinese Whispers' (aka Fake news)

TraDITION! Oh great, first Flying Toasters and now Fiddler on the Roof flashbacks. I think it's past my bedtime.

Tweeted Eric:

@SETIEric If a 'best Gaussian' looks more 'Guassianey' than the reportables, why may it not necessarily be reportable ?

Heh, I suppose it's just my old age, but I tend to have a hard time keeping a straight face when I read that somebody "Tweeted" something. It always seems about as frivolous as, oh I dunno, flying toasters perhaps! ;^D

@SETIEric If a 'best Gaussian' looks more 'Guassianey' than the reportables, why may it not necessarily be reportable ?

How there can be a "best" signal that isn't worth reporting (when there are apparently 3 inferior signals that are) is beyond me, but that's apparently the standard. :^)

For best there is a check, added ~2011, of the CHiSq fit ('i.e. 'Gaussian-ness') , in addition to the score used for reporting. My cursory reading suggests the Best may be reportable, maybe not, though yet to do a full line by line analysis. The suspected variation is in the multiple different implementations in that logic in the different branches, though that doesn't rule out other bugs or cumulative error

I mean, I can understand situations where the "best" signal, of any type, still wouldn't be good enough to "report" as worthy of further investigation. However, it seems to me that if one or more signals do achieve that reportable threshold, that the "best" signal should be one of those. If it's not, it just seems really screwy to me. Out of sync, I guess. Perhaps the dictionary the scientists use has a different definition of "best" than the one most of us common folk use. ;^)

How there can be a "best" signal that isn't worth reporting (when there are apparently 3 inferior signals that are) is beyond me, but that's apparently the standard. :^)

...All those people testing these Apps at Beta and no one picked this up? Nevermind.

Still don't know how to do a Cuda bench run, but I did run what I think is the Windows stock CPU app today, setiathome_8.00_windows_intelx86. The numbers in the results file (<peak_power>0.46856832504272</peak_power>, etc.) appear to match the opencl_ati_cat132 and r3330 results (allowing for the fact that I don't know how to convert that "time" value, and the "score" has a value of 0).

FWIW, today's run reminded me of why I haven't run stock CPU in a long time. It took about 6 hours and 45 minutes, versus 3 hours and 13 minutes for the r3330 I ran yesterday!

..
Another re-re-processing could be done. But I really would like to know why it happens in the first place...