Oh my.... seems another Fermi card has hooked up with the CUDA 75 App, which we know isn't supposed to work. Unfortunately, it seems you can't block the older cards from being sent the CUDA 75 App, just as you can't block the ATI HD4 cards from being sent the HD5 App. The Fermi cards are supposed to be blocked from the CUDA 75 App. Anyway, it seems some of the tasks are Validating somehow, and since the times are better, somehow, than the OpenCL App the server insists on sending the CUDA App instead. I'm not real sure how some tasks are validating, the results only display Errors. Really strange stuff going on here, https://setiathome.berkeley.edu/results.php?hostid=7568678&offset=440

I'm unable to download any new tasks. Just updated to the new bionic program, same results. Been down for awhile now. Any ideas as to what I should do?

---

Hmmmm, the amount of Memory Booster needed to fix that post would probably pose a health risk. Perhaps you should ask Raistmer where he was getting all those Mac Apps he passed on to Eric.

Well, what reminder actually I need is do we had any of Petri's builds on beta already or still not?
For OpenCL issues on Mac there could be good solution to abandon OpenCL in favor of Petri's CUDA special (and this requires passing through beta). At least for NV.

---

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

At this time there isn't a CUDA Special App at Beta. I do think the current v0.98b1 would be an excellent candidate though. The VRAM requirements have been lowered to where it will work acceptably on the many 2 GB GPUs. Also, the problem with the Arecibo tasks has been greatly reduced to where there are very few bad best pulses on the VHAR tasks while the speed on the VLARs is much better. The problem might be trying to block the older pre-Maxwell GPUs. As we've just seen, apparently it isn't possible to block the pre-Kepler GPUs from the Old CUDA 75 App. If it isn't possible to block the Older CUDA cards from the Special App it could be a horrible display of failed tasks. There is an 'updated' version 0.99 of the Special App in the works, however, the more I think about it the less I think it's 'features' would be desirable on the SETI Server. There are problems with the Mac 0.98 version right now, but the Linux version appears to be ready for Beta, IMO. Provided the older GPUs could be blocked from being sent the App.

I'm not sure whether Eric has preferred to specify plan classes in XML or plan classes in C++. If the former, he'd have to switch to C++, but then there'd be no problem in specifying both the minimum and maximum compute capability: for NVidia, that's enough to pick out card generations precisely. You can set min display driver version and min video RAM as well, of course.

The only thing that's needed is for the developer to make it explicitly clear what the requirements of his or her application are, so that Eric can deploy it properly.

Edit - the big problem comes in when a user has both a new generation card and an older generation card in the same computer, and manually sets BOINC to use all GPUs. The plan class mechanism can't overrule the user's choices, to keep the restricted application off the lesser card.

Edit - the big problem comes in when a user has both a new generation card and an older generation card in the same computer, and manually sets BOINC to use all GPUs. The plan class mechanism can't overrule the user's choices, to keep the restricted application off the lesser card.

BOINC client could obey plan class restrictions too. Actually it knows all needed info. It's client who reports precise host info to server to make choice what to send and what not to send.
In return client recives plan class along with its restrictions. Why not doing correct scheduling then?....

I think app itself should have fail-safe measures like those I embed in OpenCL apps. App checks GPU compatibility. And then should just end with error code instead of providing wrong results.
It will be problem on mixed GPU hosts still, but at least will not resut in any problems with reported results validity.

---

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

Actually, not. The client knows everything about your machine, but it only reports the best bits.

If I look inside the sched_request file on this machine, it starts

<coproc_cuda>
   <count>2</count>
   <name>GeForce GTX 970</name>
   <available_ram>3215065088.000000</available_ram>
...

- but actually, that's one GTX 970 and one GTX 750 Ti. There's no mention of the 750 Ti in any of the information which the server uses to decide on work allocation.

David made that design decision way back before GPU computing was first launched in 2008, and by the time of the 2014 BOINC Workshop in Budapest, he was acknowledging in public that it was a mistake. But it would be a huge job to rectify it in both client and server now, and I don't think anybody has the strength to tackle it. So, for the foreseeable future, we have to work around and with what we've got, and try not to fight against it.

it seems that this IS the problem on these
two new hosts https://setiathome.berkeley.edu/forum_thread.php?id=69782&postid=1991790#1991790

bad app selected .

---

it seems that this IS the problem on these
two new hosts https://setiathome.berkeley.edu/forum_thread.php?id=69782&postid=1991790#1991790

bad app selected .

No, neither of those - they each have just the one (mobile) GPU. There must be a reason they're getting a bad app, but it can't be because a good GPU and a bad GPU (in app terms) are being muddled up in the work allocation process.

Perhaps the slightly different specs of the mobile versions (they tend to have less dedicated memory?) weren't taken account of when the plan class limits were being drawn up for stock deployment?

...Well, what reminder actually I need is do we had any of Petri's builds on beta already or still not?

It appears we've narrowed down one of the last problems, where the App selects the wrong Best Pulse when running the Arecibo VHAR tasks. Seems the determining factor is how many Compute Units the GPU has. In offline tests it was noticed the GPU with 8 CUs always selected the correct Best Pulse whereas the GPUs with 5 or 6 CUs tended to select the Wrong Pulse as Best. Since running the GPU with 8 CUs at Beta the Bad Best Pulses have disappeared and the only Inconclusive results are from the Quick Overflows and "misbehaving apps/machines". Notice the difference when changing from a 750 Ti with 5 CUs to a 960 with 8 CUs, https://setiweb.ssl.berkeley.edu/beta/results.php?hostid=72229&state=3 As soon as that is fixed...