Would it be possible for the powers that be to check their programming. I have my home preference setup to get SG LLR CPU, CW Sieve Cuda and PPS Sieve Cuda and I keep getting pps sieve CPU jobs. This of course is killing my SG work.

Thanks Rick

If this does not work, you can try the anon platform via an App_info file.
____________
Best wishes. Knowledge is power. by jjwhalen

Yeah, if you're willing to look at some of the higher-maintenance options available, you could also set your BOINC client to completely forbid CPU processing altogether, and then run a VM with a second BOINC client to run the CPU tasks.

The two clients could utilize different locales with different settings. There are some drawbacks with this method having to do with efficiency, memory usage, and the potential for the VM starving the GPU of CPU cycles, thus slowing it down sometimes.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I set my default and home preferences to be exactly the same. SGS for CPU, PPS Sieve for GPU, send tasks from any if out = yes. On my "home" computer in the last few days, I have received two PPS Sieve CPU units, one of which burned for 11+ hours (~60%) before I noticed it, the other, almost 2 hours. Arrgh, sigh, the "default == home" trick did *not* work for me. Thanks for the suggestion though.

I've deleted my "home" preferences and just let the "home" computer use the default. Will try that for a while.

About the only way I can think of that is guaranteed to work around this would be to download a big cache of CPU work that I want (but no more than I can crunch before it times out) and then change prefs to disallow CPU work completely. This would have to be repeated every few days of course.

--Gary

send tasks from any if out = yes

Not sure who programmed up the preference page and then applied that to the actual work flow

Gary Craig wrote:

send tasks from any if out = yes

IMO, means if the server has no gpu-work or the server found not fast enough a gpu-unit to send, he send cpu-work instead to answer the work request.
Like said before, i would use the anon platform mechanism. The last app-changes (a smaller sieve-file for TRPsieve) was on june, 26th...

Gary, setting that flag to YES means you may get any type of WU at all. At PrimeGrid, "may" actually means "definitely will, sooner or later".

You have two choices: set that flag to YES and live with occaisionally getting WUs you don't want.

~or~

Set the flag to NO and live with your CPU or GPU going idle.

Especially during their "summer hours" vacation, I wouldn't be surprised if some of the queues ran dry or broke for some reason. When that happens, there's two choices: either you get a different kind of WU, or you get no WU at all. You chose to get a different kind of WU.

It should be noted that (unless I'm wrong) having the queue run dry isn't the only reason for you getting a random WU. There are other, more esoteric conditions that can prevent a WU from being sent to you, and those conditions therefore will also cause you to receive other types of WU if you have the flag set to YES.

So, if you don't want to ever receive a random WU, turn that flag off. The worst that will happen is that you'll temporarily reduce your carbon footprint. :)

I know you downloaded WUs before and after the unwanted WU, but there could have been a transient condition that only prevented the desired WUs from being delivered for a short period of time. I'm not saying that is what happened, but it's possible. Or it could just be a bug.
____________
My lucky number is 75898⁵²⁴²⁸⁸+1

I'm going to go with the "bug" theory; whenever the unwanted WUs arrive, they are always the CPU version of the GPU task I have selected, not some random other subproject (which BTW I wouldn't mind). IMHO it happens too often (roughly daily) to be a coincidence.

All of that aside, I have come across a solution which is working on Mac and Linux. It causes the unwanted PPS Sieve CPU work to error-out quickly, without manual intervention. GPU WUs, and CPU WUs from other subprojects, continue to download, run, report, and validate a-ok, both for WUs in progress at the time, and those received later. The trick is to remove execute permission from the tpsieve executable, CPU version. On Mac and Linux these are primegrid_tpsieve_1.39_x86_64-apple-darwin and primegrid_tpsieve_1.39_x86_64-pc-linux-gnu respectively (your app names may vary if you're running 32 bit or an older version). For those of you comfortable with the unix shell, that's just a "chmod 444" on the files in question. Don't change the owner/group, as that will cause the boinc manager to complain on startup and tell you to "reinstall boinc". Don't completely remove the executables, as they will just be re-fetched (I think). As the CPU tpsieve executable is only used for PPS Sieve, other CPU work (from other subprojects) that you actually requested won't be affected.

This tweak won't prevent you from being sent the errant CPU tasks in the first place, but they will error-out quickly consuming basically no resources even on an unattended computer. They are quickly re-sent to other hosts, as either CPU or GPU tasks. My main goal here is just to not "accidentally" crunch work on CPU where the GPU is so much more efficient.

I have only verified this change works on Mac OS X (snow leopard) and Linux (ubuntu 10.10), using BOINC 6.10.58 on both. Sorry my Windows knowledge is limited to the "user" level, and I don't have a convenient test platform, so I'm not comfortable advising anyone in that realm.

--Gary