Thanks again. I think that I've fixed it now.

---

Thanks again. I think that I've fixed it now.

Boom, zero invalids, down from ~6 per each of 3 hosts

---

Chaos: When the present determines the future, but the approximate present does not approximately determine the future.
Edward Lorenz

All 3 of my CUDA invalids went poof, gone.
Nice....

Edit: Strange, two of them just came back as invalid....

Got up to 14, but all gone now. Think you've got it this time :-)

Thanks

Thanks again. I think that I've fixed it now.

Looks good now. Glad to help.


@Tutankhamon

In 7987027 you found 30 spikes and others found 6 pulses and 24 triplets.
In 7985228 you found 30 triplets and others found 16 pulses and 14 triplets.

When a task contains a humongous amount of potential signals different apps may select different subsets of those signals. You just got bitten by that.

Jason can give much more details than you ever wanted to know. :)

Thanks again. I think that I've fixed it now.

Looks good now. Glad to help.


@Tutankhamon

In 7987027 you found 30 spikes and others found 6 pulses and 24 triplets.
In 7985228 you found 30 triplets and others found 16 pulses and 14 triplets.

When a task contains a humongous amount of potential signals different apps may select different subsets of those signals. You just got bitten by that.

Jason can give much more details than you ever wanted to know. :)

Yeah, William and Richard explained it pretty good, earlier in this thread. I can live with 2 invalids out of thousands of valid CUDA WUs. I think the project can live with it too :-)

When a task contains a humongous amount of potential signals different apps may select different subsets of those signals. You just got bitten by that.

Jason can give much more details than you ever wanted to know. :)

Still working on a fix for that one.

---

When a task contains a humongous amount of potential signals different apps may select different subsets of those signals. You just got bitten by that.

Jason can give much more details than you ever wanted to know. :)

Still working on a fix for that one.

Yes, hmmm, previous long term goals app side included to eventually reduce overflow Signal ordering to CPU serial, as the reference.

Initial Cuda builds by NV started a minor ordering difference there, with triplets and pulses, that never really showed as a big problem by itself.

Bigger, newer technology wants more parallelism though, and serialisation of results is expensive and can be complex. I don't mind either way which is the desired or required approach for future Cuda builds, though some way for the validator to say 'this overflow result set stars the same, then goes in a different detection order than the other one' seems doable as a heuristic.

More than you wanted to know indeed :P

[Edit:]

In 7987027 you found 30 spikes and others found 6 pulses and 24 triplets.
In 7985228 you found 30 triplets and others found 16 pulses and 14 triplets.

First case appears to be some other failure, perhaps heat or memory glitch [induced by cosmic ray or somesuch, assuming Non-ECC], since spike ordering was never changed in the Cuda builds, compared to CPU processign order. The second, on the other hand, definitely looks like the reordering in the Cuda builds, present since the first Cuda builds.

---

Chaos: When the present determines the future, but the approximate present does not approximately determine the future.
Edward Lorenz

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.

Are you counting and calculating all those numbers by hand, or are they online somewhere?

I've been doing just cursory observation of the different types of GPU tasks on my two boxes (I just added Beta to the one that does only GPU on its GT 630, no CPU). Overall, my impression is that opencl is the fastest.

Among cuda apps, it seems that the 32s have slightly shorter run times than 42 and 50s, but considerably higher CPU times. Anyone else seeing that trend?

Also, how can I set myself up to run two at a time on the GPU? I don't want to fiddle with any other settings. I have Main set for two at a time, but its within the lengthy and complicated app_something.xml. What I'm asking for is the bare minimum version of that file to do two at once here at Beta. (I want this for both boxes, so it needs to allow the other one to do CPU.) I was reading the thread at Main NC and my eyes glazed over.

---

David
signature sent back to alpha testing

Hello folks,

I recently bought a new computer and as it is my first system with integrated Intel GPU I decided to give it a try over here.
I noticed that most of my tasks were marked as inconclusive before being validated. A closer look revealed that in nearly all of the cases the number of signals reported (spike, autocorr, pulse, triplet, gaussian) did not match the numbers reported by both wingmen. Examples:

https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8003833
https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8003866
https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8003935
https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=8003778
https://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=7981741

In none of these cases there were 30 or more total signals reported.
The first unit in the list above even had a different number of triplets compared to another Intel GPU (although they were different versions: HD Graphics 4000 vs HD Graphics 530).

Is there a problem with the Intel GPU app ? I remember that in the past a fair number of inconclusives I had (with v7 over on main) on my NVidia card were against wingmen running Intel GPU.

Tom

@David,
To run two GPU tasks put this in app_config.xml in your setiweb.ssl.berkeley.edu_beta folder.

<app_config>

<app>
<name>setiathome_v8</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.4</cpu_usage>
</gpu_versions>
</app>

</app_config>

To get your application info ... When you see your computers listed,
click details
click application Details

And you will see how each application is performing.

I'm running the same Intel GPU app that is being tested here, under Anonymous Platform at the Main project.

Application details for host 7118033
(scroll to the very bottom for v8 on Intel GPU)

Currently showing: 220 consecutive valid tasks, and no errors.

From what I've been able to see, the application is fine, but it may have another of these unresolved driver dependencies. I'm running an HD 4600 with driver 10.18.10.3621 (Release Date: May 21, 2014): that has proved to be the gold standard driver since we first started running on these devices.

Are you counting and calculating all those numbers by hand, or are they online somewhere?

Here is yours: http://setiweb.ssl.berkeley.edu/beta/host_app_versions.php?hostid=77749

---

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

Among cuda apps, it seems that the 32s have slightly shorter run times than 42 and 50s, but considerably higher CPU times. Anyone else seeing that trend?

System and application settung dependant, but can be. The main changes between 3.2 and 4.2 involve a complete compiler replacement that tends to favour performance on Kepler onwards, and Cuda 3.2 older technology tends to be a tad lower optimised in the drivers (CPU bits). Not sure where a 630 fits in the scheme of things.

For the time being, choices between OpenCL and Cudas are likely to come down to exactly your own situation and goals (e.g. single instance, fast as possible versus multiple instances low impact preferred). That's a kindof flexibility by having choices I hope to capture. To be able to make configurable within some single future application. But we are talking next generation, and looking what works in different situations, first.

I'm certain once initial v8 is rolled out and any problems nailed flat, that all the applications begin to change with what we learn.

---

Chaos: When the present determines the future, but the approximate present does not approximately determine the future.
Edward Lorenz

Not sure where a 630 fits in the scheme of things.

And I'm not surprised.

According to the standard Wiki reference list, some 630s are GF108-based (Fermi - take your pick of DDR3 or GDDR5), some GK107 (baby Kepler), and some GK208 (big Kepler).

Not sure where a 630 fits in the scheme of things.

And I'm not surprised.

According to the standard Wiki reference list, some 630s are GF108-based (Fermi - take your pick of DDR3 or GDDR5), some GK107 (baby Kepler), and some GK208 (big Kepler).

I did some Beta testing on an old IBM ThinkCentre with one of the GK208 630s. It's a nice little passively cooled GPU with low wattage that's just right for that old box. In fact, that's also what's running here on my daily driver.

The scheduler only sent cuda42 and cuda50, never any cuda32, and if you look at the Application details, it would appear that the cuda42 is faster. However, I think those APRs are misleading because only cuda50 got VLARs. Looking at normal and higher ARs, I found that cuda50 had a slight edge, both in Run Time and CPU Time.

I'm running the same Intel GPU app that is being tested here, under Anonymous Platform at the Main project.

Application details for host 7118033
(scroll to the very bottom for v8 on Intel GPU)

Currently showing: 220 consecutive valid tasks, and no errors.

From what I've been able to see, the application is fine, but it may have another of these unresolved driver dependencies. I'm running an HD 4600 with driver 10.18.10.3621 (Release Date: May 21, 2014): that has proved to be the gold standard driver since we first started running on these devices.

Hello Richard,

Thanks for the feedback. I don't think your driver version supports my Skylake processor. I was using the driver version that was installed with Windows 10, but I now downloaded the latest driver from Intel. I hope that will improve things ...
One thing that worries me is that probably most people will be using the driver version installed with Windows.

Tom

app_config>

<app>
<name>setiathome_v8</name>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.4</cpu_usage>
</gpu_versions>
</app>

</app_config>

not working

I'm running 1 video card (at 37%) running SETI@home V8 8.00 from the beta test server. I get 1 WU at a time.

Is the beta system limiting downloades or should I look for a config prob on my computer?

Ed F

---

According to the standard Wiki reference list, some 630s are GF108-based (Fermi - take your pick of DDR3 or GDDR5), some GK107 (baby Kepler), and some GK208 (big Kepler).

GK208 is still pretty 'small' - just a slight refinement over earlier Kepler GPUs analogous to how GK110 got a slight revision in the form of GK210.

But your point is still valid, the model number GT 630 is comprised of a crazy jumble of Fermi and Kepler GPUs.

I'm running the same Intel GPU app that is being tested here, under Anonymous Platform at the Main project.

Application details for host 7118033
(scroll to the very bottom for v8 on Intel GPU)

Currently showing: 220 consecutive valid tasks, and no errors.

From what I've been able to see, the application is fine, but it may have another of these unresolved driver dependencies. I'm running an HD 4600 with driver 10.18.10.3621 (Release Date: May 21, 2014): that has proved to be the gold standard driver since we first started running on these devices.

Hello Richard,

Thanks for the feedback. I don't think your driver version supports my Skylake processor. I was using the driver version that was installed with Windows 10, but I now downloaded the latest driver from Intel. I hope that will improve things ...
One thing that worries me is that probably most people will be using the driver version installed with Windows.

Tom

I've had issues which I put down to Intel's drivers for the HD Graphics 530. I have tried 4 different drivers so far and get a few invalids here but not as many since recent validator and 8.06 app change. Happens here and at Einstein. Hopefully they will get their act together soon.