CUDA and Remote Desktop |
![]() |
| log in |
Questions and Answers : GPU applications : CUDA and Remote Desktop
| Author | Message |
|---|---|
|
I do not know if this the real reason of some of my problems, but here is the case: | |
| ID: 936648 · | |
Remedies (other than not using remote desktop...)? I'm afraid that's the only solution (for now). Are the[re] other people reporting this same problem using remote desktop? Try an Advanced search of the forum for "remote desk" over at least six months. Gruß, Gundolf ____________ Computer sind nicht alles im Leben. (Kleiner Scherz) SETI@home classic workunits 3,758 SETI@home classic CPU time 66,520 hours | |
| ID: 936654 · | |
|
Or as from my FAQ on CUDA: | |
| ID: 936663 · | |
Or as from my FAQ on CUDA: Yes, I already know about this (also by the hard way!) since long time. But this is not the main problem I am trying to address, though they may well be correlated. As also in the following, the issue is mostly claimed as BOINC (or whatever) not to be able to recognise the CUDA card due to the bad handling of the video driver by RDP. This is not far from BOINC switching from CUDA aware and not aware also while running, but I seem not to have read it explicitly written (I maybe wrong, apologies in advance). In short, I hoped that once BOINC is tricked that there is a CUDA card available, then that would be stable and launching BOINC from VNC rather than RDP would be sufficient. In fact, it seems not to be and harder solutions have to be found. As often happens, RDP is convenient since it is available in all Win based PCs in the world (Microsoft Empire...), and relying on products such as TeamViewer (I will try it though, good advice!) may not be always available. It maybe a very good solutions for my own PCs, though. Unfortunately, though I am a user of VNC since primordial times (and I still use it, even from by PDA), it seems now to have a slower response time respect RDP (I write it with sadness) and hence my preference for RDP. Anyway, I have read your FAQs now, which I had not yet stumbled on and they are quite interesting. Also, I thought I had read all in the forums, which I regularly follow and doing a better search I actually found some more information. In my judgement, this is the most interesting, though I have not tried it yet. It requires some hacking of the system, though: http://setiathome.berkeley.edu/forum_thread.php?id=53068 Thank you for your advices and I will try to figure something out to solve the problem! Sleepy ____________ | |
| ID: 936670 · | |
|
Today I tried Teamviewer and it did not work well at all. | |
| ID: 936936 · | |
|
Hmmm............. | |
| ID: 936985 · | |
|
I wrote too quickly. I should have experimented (and think about what I was doing) longer. | |
| ID: 937004 · | |
|
I may be wrong, but if I understood correctly, some of the new features included in BOINC 6.10.13 (beta) may at least alleviate the problems I was fighting against. | |
| ID: 938132 · | |
|
Indeed, BOINC 6.10.13 Beta behaves better towards CUDA and RDP. It is not perfect yet, but at least we can avoid the worst effects. | |
| ID: 939079 · | |
But at least initiating BOINC from RDP does not produce the deletion of any (completed, running, or ready to run) CUDA tasks and all related applications and DLLs. Simply the CUDA tasks are not performed or are performed by the CPU. Um... then that's a bug or an undocumented feature. As per the code change for 6.10.13 the behaviour should be: - client: better behavior if a GPU goes away: ____________ Jord - BOINC FAQ Service - BOINC User Wiki Real is just a matter of perception. | |
| ID: 939084 · | |
Um... then that's a bug or an undocumented feature. It's an undocumented feature of the Seti CUDA application. What happens is that you RDP into a machine that has got BOINC running already. At that time the CUDA enabled driver will go missing, but since BOINC is already running it won't redetect if the correct Nvidia library is available or not. The CUDA application, when it starts, will just not find a CUDA capable GPU in the system and drop down to using the CPU as the next best thing. As soon as your stop using RDP, the next time the CUDA application starts on a new task, it'll continue running on the CUDA capable GPU it will find again. Yet... should you RDP into one of those machines and exit and restart BOINC, you'll find it will abort all your CUDA work as the Nvidia library needed for the CUDA GPU to be detected cannot be found again. ____________ Jord - BOINC FAQ Service - BOINC User Wiki Real is just a matter of perception. | |
| ID: 939323 · | |
Um... then that's a bug or an undocumented feature. The news is that with BOINC 6.10.13 this does not happen any more. You can just have fall back to CPU as previously reported and described or simply BOINC tries without success to reconnect to the clients etc (nothing starts, nothing gets deleted), but tasks and applications are not deleted or aborted. And if you exit (form RDP or whatever) and restart BOINC from VNC or similar everything restarts seamlessly the way you hope. Not perfect, but a big improvement in protecting your work. At least, a small mistake does not lead to drop a lot of work and settings in the dustbin! Cheers, Sleepy ____________ | |
| ID: 939335 · | |
..or simply BOINC tries without success to reconnect to the clients etc (nothing starts, nothing gets deleted)... And that's better how, exactly? If BOINC Manager cannot connect to a client, it's usually because the client isn't running. And if you exit (form RDP or whatever) and restart BOINC from VNC or similar everything restarts seamlessly the way you hope. So you exit RDP and then use VNC to restart BOINC. ... ____________ Jord - BOINC FAQ Service - BOINC User Wiki Real is just a matter of perception. | |
| ID: 939336 · | |
It is better not because you are crunching any faster. :-) It is just a sort of protection. Either you start with no CUDA, with or without CPU fallback, or nothing (not even crunching) happens. But if you have 300 CUDA tasks to report, they do not get deleted and lost. And you do not need to reinstall the CUDA specific applications and DLLs. So you exit RDP and then use VNC to restart BOINC. ... Exactly. You do your business with RDP, and if in the meantime something wrong has happened (not necessarily) you enter VNC and put things right again. No reboot, no lost tasks, no software to be installed again. I would prefer that BOINC managed even not to care about the "lost" CUDA drivers and kept on crunching with CUDA, but at least in this way the danger is limited respect to previous versions. Cheers, Sleepy [/quote] | |
| ID: 939366 · | |
I would prefer that BOINC managed even not to care about the "lost" CUDA drivers and kept on crunching with CUDA, but at least in this way the danger is limited respect to previous versions. That would be a major problem. BOINC doesn't know the difference between being used at the keyboard, via RDP or VNC. If BOINC was designed to continue crunching with CUDA despite a missing driver, what if I decided to uninstall nVidia and install and ATi card? All the workunits would be trashed. ____________ | |
| ID: 939372 · | |
|
Latest checkin on this subject: - client: on startup, if a coproc needed by a job is missing, set a "coproc_missing" flag rather than aborting the job. If user removes a GPU board while there's a large queue of GPU jobs, they'll stay queued (until their deadline passes). ____________ Jord - BOINC FAQ Service - BOINC User Wiki Real is just a matter of perception. | |
| ID: 939399 · | |
|
On my Win2008 servers I have set up a local 'Remote' user and go in as a non-Admin (no /console flag.) The Remote user is set as a system Admin, and as a BOINC Admin, so I can do what I need to do without affecting the currently logged on 'console' that has the NVidia drivers loaded. | |
| ID: 941488 · | |
|
I would confirm that presently BOINC 6.10.17 works nicely with Remote Desktop. | |
| ID: 951349 · | |
|
Personally I use LogMeIn and then you don't have that issue. | |
| ID: 953825 · | |
Questions and Answers : GPU applications : CUDA and Remote Desktop
| Copyright © 2013 University of California |