OK, try to pass then that build to Eric with explanation how to setup plan class for run on iGPU and NV. Maybe it's time for online beta indeed. BTW, what if that build will be tried on ATi card? What about speed?

---

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

I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip

I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip

OK, then either send mix you feel is good for beta testing directly to Eric or E-mail me for passing.

---

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

Overflow
r3528 vs. stock Windows CPU = 9 WUs
r3528 vs. Cuda50 = 2 WUs
r3528 vs. r3528 = 2 WUs

I would think that those are the types of Inconclusives that I should keep an eye out for with r3548. Is that a valid assumption?

I think so. Mostly - overflows with CPU and OpenCL NV/ATi included.
Last changes should influence only overflows, validation ratre for non-overflows should remain the same as in r3528.

Just a quick note. The first day with r3548 didn't appear to yield anything significant. Of 431 r3548 results, 5 are currently showing as Inconclusive, but 4 of those are against what appear to be wayward hosts that are returning lots of Invalids. The other one is against an r3528 result, so I don't think there's any conclusion to be drawn with that one, either.

EDIT: FWIW, though, here's the info on that last one.

Workunit 2313958942 (blc3_2bit_guppi_57451_23871_HIP63406_OFF_0016.1842.0.18.27.93.vlar)
Task 5260480445 (S=25, A=0, P=5, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5260480446 (S=28, A=0, P=2, T=0, G=0) SSE3xj Win32 Build 3548

EDIT2: Corrected total count of r3548 results to 431.

I don't think the Intel build will work any better than the ATI5 Build already being used. You can't use very high settings with the Intel build, it will not work correctly with just the -oclfft_tune_gr 128 cmdline. The current ATI5 build seems to be working well even though this machine is running High settings and running three tasks at once, http://setiathome.berkeley.edu/results.php?hostid=6105482. I think the current tested ATI5 App would be a better choice, ATI5r3515&CPUr3344sse41.zip

OK, then either send mix you feel is good for beta testing directly to Eric or E-mail me for passing.

One advantage with the Intel build is the Idle Wake Ups are Low. They are down to around 10-30 with an occasional 60. This is much better than with the NV/SoG builds where they are around 5000-7000+. Apple says 300 is Too High. The older NV builds had Idle Wake Ups reaching up to 40000! It would seem what ever is causing the High Idle Wake Ups is in the NV/SoG path. Also, the CPU use is lower with the Intel build. The SoG App had an average of 70% CPU use with periods of 110% CPU use. The Intel build is averaging around 35% CPU use.

And what those values for ATi build running on NV hardware?

---

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

It seems it's also high with the ATI HD5 path on the nVidia cards. I tried it with the ATI build r3515 and a build from r3551 and it was pretty close with both Apps. The Idle Wake Ups were usually around 8000-9000 with spikes up to 14000. I can't remember how the r3515 build worked on my ATI cards, But, the number 500 sounds familiar. If Chris is around maybe he can report on how r3515 runs on his d700s.

I went back and looked at the old thread. It seems around 500 Idle Wake Ups per second is probably close on the ATI Card, However, Apple says it should be 150 or less. At the time though, 500 was much better than what the other Apps were producing ;-)

The other one is against an r3528 result, so I don't think there's any conclusion to be drawn with that one, either.

EDIT: FWIW, though, here's the info on that last one.

Workunit 2313958942 (blc3_2bit_guppi_57451_23871_HIP63406_OFF_0016.1842.0.18.27.93.vlar)
Task 5260480445 (S=25, A=0, P=5, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5260480446 (S=28, A=0, P=2, T=0, G=0) SSE3xj Win32 Build 3548

Well, that r3548 from last evening is now Inconclusive against a second r3528, which is starting to make it look more interesting.
Workunit 2313958942 (blc3_2bit_guppi_57451_23871_HIP63406_OFF_0016.1842.0.18.27.93.vlar)
Task 5260480445 (S=25, A=0, P=5, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5260480446 (S=28, A=0, P=2, T=0, G=0) SSE3xj Win32 Build 3548
Task 5262508797 (S=27, A=0, P=3, T=0, G=0) v8.19 (opencl_nvidia_SoG) windows_intelx86

The potential tiebreaker is now assigned to a host running stock v8.00 windows_intelx86, so I think it will be worth watching to see which, if any, of the SoG results it agrees with.

Another WU worth watching, I think, is this one:
Workunit 2313383895 (20ja16ab.4615.8247.3.30.97)
Task 5259241898 (S=10, A=1, P=18, T=0, G=1) v8.00 windows_intelx86
Task 5259241899 (S=2, A=1, P=26, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5260485168 (S=3, A=1, P=25, T=0, G=1) v8.10 (opencl_nvidia_SoG) x86_64-pc-linux-gnu
Task 5261912074 (S=0, A=1, P=28, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86

The potential tiebreaker is assigned to my host that's running r3548 and should run sometime tonight. Ideally, I suppose it should match with the stock Windows CPU result, which appears to come from a reliable host. We'll see.

On another track, I also noticed a Petri Special x41p_zi3k result that disagrees with a stock Windows CPU result. The counts are the same, so figuring out what the difference is would probably require someone running an offline test to find out the details of what the stock app is reporting.

Workunit 2314163650 (blc3_2bit_guppi_57451_24929_HIP63406_0019.6510.831.18.27.140.vlar)
Task 5260902641 (S=3, A=0, P=8, T=3, G=0) v8.00 windows_intelx86
Task 5260902642 (S=3, A=0, P=8, T=3, G=0) x41p_zi3k, Cuda 8.00 special

The potential tiebreaker will run on one of my hosts under Cuda50.

On another track, I also noticed a Petri Special x41p_zi3k result that disagrees with a stock Windows CPU result. The counts are the same, so figuring out what the difference is would probably require someone running an offline test to find out the details of what the stock app is reporting.

Workunit 2314163650 (blc3_2bit_guppi_57451_24929_HIP63406_0019.6510.831.18.27.140.vlar)
Task 5260902641 (S=3, A=0, P=8, T=3, G=0) v8.00 windows_intelx86
Task 5260902642 (S=3, A=0, P=8, T=3, G=0) x41p_zi3k, Cuda 8.00 special

The potential tiebreaker will run on one of my hosts under Cuda50.

It's non-overflow one.
x41p_zi3k results are:
Pulse: peak=1.226719, time=45.86, period=1.49, d_freq=1668592615.71, score=1.001, chirp=-11.481, fft_len=1024
Pulse: peak=6.817526, time=45.86, period=17.76, d_freq=1668589891.72, score=1.051, chirp=-23.846, fft_len=1024
Spike: peak=24.15228, time=5.727, d_freq=1668594582.93, chirp=26.807, fft_len=128k
Spike: peak=24.9091, time=5.727, d_freq=1668594582.92, chirp=26.821, fft_len=128k
Spike: peak=24.9591, time=5.727, d_freq=1668594582.93, chirp=26.822, fft_len=128k
Pulse: peak=1.082263, time=45.84, period=1.235, d_freq=1668594359.79, score=1.04, chirp=-30.734, fft_len=512
Triplet: peak=10.06536, time=50.06, period=25.57, d_freq=1668594490.91, chirp=46.808, fft_len=512
Triplet: peak=11.66693, time=34.18, period=3.579, d_freq=1668599352.79, chirp=-48.729, fft_len=4k
Pulse: peak=6.493984, time=45.9, period=15.39, d_freq=1668597587.71, score=1.03, chirp=48.884, fft_len=2k
Pulse: peak=6.051346, time=46.17, period=15.39, d_freq=1668597119.45, score=1.011, chirp=76.46, fft_len=8k
Pulse: peak=4.242765, time=45.99, period=9.962, d_freq=1668598651.91, score=1.004, chirp=85.049, fft_len=4k
Triplet: peak=11.845, time=51.19, period=19.02, d_freq=1668599959.19, chirp=-89.73, fft_len=128
Pulse: peak=2.303323, time=45.9, period=4.217, d_freq=1668594260.01, score=1.051, chirp=92.159, fft_len=2k
Pulse: peak=4.356801, time=45.9, period=10.14, d_freq=1668598243.86, score=1.005, chirp=95.073, fft_len=2k

Best spike: peak=24.9591, time=5.727, d_freq=1668594582.93, chirp=26.822, fft_len=128k
Best autocorr: peak=16.87552, time=74.45, delay=5.2873, d_freq=1668595826.5, chirp=19.694, fft_len=128k
Best gaussian: peak=0, mean=0, ChiSq=0, time=-2.123e+11, d_freq=0,
score=-12, null_hyp=0, chirp=0, fft_len=0
Best pulse: peak=6.817526, time=45.86, period=17.76, d_freq=1668589891.72, score=1.051, chirp=-23.846, fft_len=1024
Best triplet: peak=11.845, time=51.19, period=19.02, d_freq=1668599959.19, chirp=-89.73, fft_len=128

---

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

Another WU worth watching, I think, is this one:
Workunit 2313383895 (20ja16ab.4615.8247.3.30.97)
Task 5259241898 (S=10, A=1, P=18, T=0, G=1) v8.00 windows_intelx86
Task 5259241899 (S=2, A=1, P=26, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86
Task 5260485168 (S=3, A=1, P=25, T=0, G=1) v8.10 (opencl_nvidia_SoG) x86_64-pc-linux-gnu
Task 5261912074 (S=0, A=1, P=28, T=0, G=1) v8.19 (opencl_nvidia_SoG) windows_intelx86

The potential tiebreaker is assigned to my host that's running r3548 and should run sometime tonight. Ideally, I suppose it should match with the stock Windows CPU result, which appears to come from a reliable host. We'll see.

Maybe you could speedup its arrival by some micromanaging of that host?

---

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

10-1-18-1 so matched CPU. Seems we are ready to start new beta.

---

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

The potential tiebreaker will run on one of my hosts under Cuda50.

And cause CUDA 5 zi has no signal printing that gave us nothing. All 3 validated eventually and got credits.
So bug if any was hided.

Offline re-run (by smth more debug-friendly than zi) required in this case and then comparison with saved signal printing.

---

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

10-1-18-1 so matched CPU. Seems we are ready to start new beta.

Excellent! For the other WU I mentioned in that post, 2313958942, the stock CPU app also reported a match to the r3548 (S=28, A=0, P=2, T=0, G=0), not the two r3528 results (although they also got credit).

That's only two examples, or course, but it seems that both got exactly the desired results. That's very encouraging.

I had been focusing on how r3548 matched up against the stock Windows CPU app, but just now took a little time to go back and look at how it measured up against a few of the other stock apps.

In WU 2314812653, r3528 (S=11, A=0, P=19, T=0, G=0) disagreed with a Mac stock v8.03 x86_64-apple-darwin (S=16, A=0, P=14, T=0, G=0). My r3548 result agreed with the stock Mac counts, not with r3528.

In WU 2314750568, r3528 (S=19, A=1, P=8, T=2, G=0) disagreed with a Linux stock v8.00 x86_64-pc-linux-gnu (S=20, A=1, P=7, T=2, G=0). Again, my r3548 result agreed with the stock Linux counts, not with r3528.

That looks very positive to me.

Here's another one of those very subtle Inconclusives with the x41p_zi3k special app, similar to the one I had posted a couple weeks ago in Message 1825787.
Workunit 2316205882 (blc3_2bit_guppi_57451_27034_HIP69732_0025.16354.831.17.26.69.vlar)
Task 5265227923 (S=0, A=0, P=29, T=1, G=0) v8.19 (opencl_ati5_nocal) windows_intelx86
Task 5265227924 (S=0, A=0, P=29, T=1, G=0) x41p_zi3k, Cuda 8.00 special

The counts are identical and the "best" signals are essentially the same. All but one of the Pulses show peaks that match to 3 decimal places, with identical periods and scores. Only the very last Pulse seems to be off kilter ever so slightly.

x41p_zi3k: Pulse: peak=10.72607, time=45.86, period=27.2, d_freq=1647270240.2, score=1.08, chirp=84.573, fft_len=1024
opencl_ati5_nocal: Pulse: peak=10.78494, time=45.86, period=27.25, d_freq=1647270240.2, score=1.086, chirp=84.573, fft_len=1024

One of my hosts has the potential tiebreaker, but that will run as Cuda50 so it won't provide any signal detail.

I also have an r3548 that's Inconclusive against the stock Windows app, but it's more of an "instant" overflow, not one of the Late Stage ones.
Workunit 2316218881 (01fe09ac.3129.481.5.32.12)
Task 5265255473 (S=18, A=12, P=0, T=0, G=0) SSE3xj Win32 Build 3548
Task 5265255474 (S=21, A=9, P=0, T=0, G=0) v8.00 windows_intelx86

On first look, those were the only two WUs that caught my eye on this evening's list.

Only the very last Pulse seems to be off kilter ever so slightly.

x41p_zi3k: Pulse: peak=10.72607, time=45.86, period=27.2, d_freq=1647270240.2, score=1.08, chirp=84.573, fft_len=1024
opencl_ati5_nocal: Pulse: peak=10.78494, time=45.86, period=27.25, d_freq=1647270240.2, score=1.086, chirp=84.573, fft_len=1024

Same signature of the issue as before - difference in periods.
It's more severe than just difference in peak powers if peak power strong enough.

I also have an r3548 that's Inconclusive against the stock Windows app, but it's more of an "instant" overflow, not one of the Late Stage ones.
Workunit 2316218881 (01fe09ac.3129.481.5.32.12)
Task 5265255473 (S=18, A=12, P=0, T=0, G=0) SSE3xj Win32 Build 3548
Task 5265255474 (S=21, A=9, P=0, T=0, G=0) v8.00 windows_intelx86

These ones don't affected last changes cause both spikes and autocorrs are in SoG area.

---

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

One of my hosts has the potential tiebreaker, but that will run as Cuda50 so it won't provide any signal detail.

Signals are signals, and the cuda app will certainly provide them - that's the whole point of the exercise. It simply doesn't write a duplicate copy into stderr.

First, make that task run at a time when you're around to manage things. Then disable networking while it's running, and copy the result file somewhere else before it uploads. Then set BOINC back to normal and let it do its thing.

Second, I once wrote a little tool which I called a 'Summariser' - it should be somewhere in the downloads area at Lunatics. It takes a result file in scientific (XML) format, and spits out the (limited subset of) values in a layout more easily comparable with Raistmer's stderr summary - using text manipulation only, so it doesn't introduce any additional maths errors (though that does mean that over-length values are truncated, not rounded). That certainly leaves enough data to spot the >1% validator-busting discrepancies.

A rather different problem, but it's my thread, and since this is where most of the discussion is...

Found one of my SoG machines chewing on task 5266682445 just now. This is what BOINC thought it was doing:



- but notice no checkpoint. In reality, it hadn't even reached first base. Here is stderr.txt, complete and unedited:

Priority of worker thread raised successfully
Priority of process adjusted successfully, below normal priority class used
OpenCL platform detected: NVIDIA Corporation
BOINC assigns device 0
Info: BOINC provided OpenCL device ID used

By comparison, here's a more normal display for a task approaching completion:



but note it is 'waiting to run' - I suspect it got interrupted by a driver restart.

This machine currently hosts my original GTX 470 Fermi card - the BIOS wouldn't accept a GTX 750 Ti when I tried to upgrade a couple of years ago. I had to update the driver to match minimum SoG requirements - I'm currently using v350.12, which is frankly too new for an ordinary Fermi without gaming, and it's been troublesome ever since I installed it - I've had another driver crash since I started typing this note, and I usually have to snooze SoG processing simply to get any work done at all.

so what is wrong here?
driver restart leads to context destruction.
If Runtime would return last call to it app would do temporary exit.
But there is no return from last call to runtime hence app never got control back.
Nothing new, such behavior observed since first OpenCL app introduction many years ago.

---

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

Here https://cloud.mail.ru/public/2G3G/aj9aBpWaY is update for ATi and NV SoG builds that pass last overflow testcase versus Akv8 CPU.

Spike: peak=27.31194, time=41.94, d_freq=1420115137.4, chirp=0, fft_len=32k
Spike: peak=25.00008, time=3.355, d_freq=1420115137.4, chirp=0, fft_len=64k
Spike: peak=25.94571, time=30.2, d_freq=1420114782.9, chirp=0, fft_len=64k
Spike: peak=27.34232, time=36.91, d_freq=1420115491.9, chirp=0, fft_len=64k
Spike: peak=34.62092, time=43.62, d_freq=1420115137.4, chirp=0, fft_len=64k
Spike: peak=25.59552, time=70.46, d_freq=1420114782.9, chirp=0, fft_len=64k
Spike: peak=30.29927, time=77.18, d_freq=1420114782.9, chirp=0, fft_len=64k
Spike: peak=26.13545, time=90.6, d_freq=1420114782.9, chirp=0, fft_len=64k
Spike: peak=36.72305, time=97.31, d_freq=1420114782.9, chirp=0, fft_len=64k
Spike: peak=25.87768, time=104, d_freq=1420114428.4, chirp=0, fft_len=64k
Spike: peak=49.95021, time=6.711, d_freq=1420113648.55, chirp=0, fft_len=128k
Autocorr: peak=28.35732, time=6.711, delay=0.33853, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=32.8986, time=20.13, d_freq=1420113294.05, chirp=0, fft_len=128k
Autocorr: peak=25.26725, time=20.13, delay=0.64881, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=40.69257, time=33.55, d_freq=1420113648.55, chirp=0, fft_len=128k
Autocorr: peak=28.97728, time=33.55, delay=0.67707, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=44.54146, time=46.98, d_freq=1420113294.05, chirp=0, fft_len=128k
Autocorr: peak=26.62384, time=46.98, delay=2.8492, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=47.76031, time=60.4, d_freq=1420113294.05, chirp=0, fft_len=128k
Autocorr: peak=23.55849, time=60.4, delay=0.028262, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=55.79382, time=73.82, d_freq=1420114782.9, chirp=0, fft_len=128k
Spike: peak=45.39939, time=87.24, d_freq=1420114782.9, chirp=0, fft_len=128k
Autocorr: peak=22.59298, time=87.24, delay=3.1877, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=46.46297, time=100.7, d_freq=1420114782.9, chirp=0, fft_len=128k
Autocorr: peak=26.174, time=100.7, delay=1.8618, d_freq=1420117187.5, chirp=0, fft_len=128k
Spike: peak=47.66999, time=6.711, d_freq=1420113648.55, chirp=0.00092426, fft_len=128k
Autocorr: peak=28.4676, time=6.711, delay=0.33853, d_freq=1420117187.51, chirp=0.00092426, fft_len=128k
Spike: peak=32.71175, time=20.13, d_freq=1420113294.07, chirp=0.00092426, fft_len=128k
Autocorr: peak=25.06184, time=20.13, delay=0.64881, d_freq=1420117187.52, chirp=0.00092426, fft_len=128k
Spike: peak=38.69695, time=33.55, d_freq=1420115491.85, chirp=0.00092426, fft_len=128k
OpenCL queue synchronized
SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected equals the storage space allocated.

Best spike: peak=55.79382, time=73.82, d_freq=1420114782.9, chirp=0, fft_len=128k
Best autocorr: peak=28.97728, time=33.55, delay=0.67707, d_freq=1420117187.5, chirp=0, fft_len=128k
Best gaussian: peak=2.695171, mean=0.6666403, ChiSq=1.315266, time=39.43, d_freq=1420115566.25,
score=-8.416527, null_hyp=1.685485, chirp=0, fft_len=16k
Best pulse: peak=4.163178, time=65.89, period=1.258, d_freq=1420118560.79, score=0.9425, chirp=0, fft_len=64
Best triplet: peak=0, time=-2.121e+011, period=0, d_freq=0, chirp=0, fft_len=0


Flopcounter: 10790871916.090950

Spike count: 21
Autocorr count: 9
Pulse count: 0
Triplet count: 0
Gaussian count: 0


Please, test more thoroughly.

---

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