When I connect to my work PC from home using RDC (Remote Desktop Connection), BOINC disables GPU. It is re-enabled when I close RDC.

A few days ago I set up my work PC to allow the ATI GPU to be used. Since then I've been logging in from home and in that time no GPU task has downloaded successfully. Now I'm at work I've had one GPU task successfully download and run so my basic configuration seems O.K.

I expected that when the GPU is disabled, GPU tasks would be suspended, but I think, when the GPU is disabled, Boinc rejects any GPU task in the download queue with a download error (after it's downloaded successfully), which seems silly but liveable with.

However I'm worried that previously downloaded/running GPU tasks are also failed. Does anybody know if this is true?

If this is what does happens, is there some extra configuration options that I have missed to stop this behaviour, or would the latest version of BOINC have different behaviour? I run BOINC 6.10.60.

My work PC runs 24/7 and although I often have to log in to it from home there are many hours when I don't. I treat Seti as a run and forget task but I'm still reluctant to throw away partially completed work. I guess it doesn't matter too much in the greater scheme of things but basically I'd like the GPU to be in use whenever it and GPU tasks are available.

BTW this is a Win7 64 bit PC.

Rick

---

The problem is actually within Microsoft's Remote Desktop Protocol. When you use RDP, it uses it's own video drivers instead of the ones on the system. BOINC sees that the video driver being used (RDP) is not compatible with GPU crunching and therefore disables the GPU crunching function. When you log off of RDP, the system goes back to using the drivers included on the system, and BOINC is able to detect this and resume using the GPU again.


This is not a function or problem with BOINC; this is how RDP is designed. Therefore, no matter which version of BOINC you use, you will always see this behavior until Microsoft changes their program to use the system's drivers (which is unlikely, because Microsoft's RDP video driver is designed to be dynamic, usable over slow and/or high latency connections using video compression if necessary while the local video drivers assume that everything being done is local).


As for the download errors, I believe this is unrelated. Currently we are having what is known as a "shorty storm"; short workunits that complete in a matter of seconds, typically because of too much local noise. Because workunits are completing within seconds, everyone is pounding the servers to return the results and get more, and the servers can't keep up with the demand.

To make matters worse, it appears that one of the download servers is having issues and is not responding to requests, leaving only the single server to service all requests from 500,000+ active computers.

The only solution is to be patient while they get the other server back up, and to wait out the "shorty storm".

Thanks.

I think I have found the cause of the problem. Because I'd assumed that I had a configuration problem with the GPU set up I didn't check the messages to see the sequence of events and when I found I didn't have a configuration problem I'd stopped and started BOINC several times so I thought I'd lost the opportunity to investigate.

But having had a look around I found stdoutdae.txt which showed everything I needed.

When downloading the application parts before downloading the tasks, the download of astropulse_6.04_windows_intelx86__opencl_ati_100.pdb failed with a checksum or signature error. I guess this is why the 2 tasks were rejected.

This download was sent again the next time I received tasks, and again failed with a checksum error. The 4 downloaded tasks were rejected.

Finally this download worked the next time I got a task and the task ran successfully.

Rick

---

Excellent! I'm glad you found the problem. I see that our common suggestion, always have patience, was key in this solution as well.