How can I execute a CUDA code on an NVIDIA card via network using a VPN ?
For information, I’m using Ubuntu 16.04 as an operating system.
Thank you.
You possibly could use ssh for executing CUDA code or otherwise you may use remote desktop if you need GUI.
Were you accessing Jetson from Windows you would use either putty or vnc client. However, using Ubuntu 16.04 as a client you may use directly terminal or vino/vnc or whatever remote desktop client, in my opinion.
The VNC client would be the best choice if you are operating without a monitor on the Jetson. I don’t have any suggestions on which VNC server to use…other users will probably have suggestions on particular “flavors” of VNC.
Thanks for the information, I’ll try VNC as you suggested and return to you if I have some trouble.
Thanks again.
But if you do not need any graphical output from CUDA execution ,a terminal-like ssh connection without GUI would be of better performance than VNC, in my opinion. As a matter of fact VNC is not of very speedy performance, especially if you are accessing the device over the Internet, not from a local network
As you said, I’m using the Internet in order to access the devise. In this case using an ssh connection instead of VNC is better in term of performance, is that what you meant ?
Exactly! Terminal access is thousand times speedy than graphical.
Do you need graphical output at your end or just execution of the code, for example having text or a file as an output?
If you are using GUI delivery over slow Internet you risk to get a slideshow using a remote desktop software.
I may have a file as an output containing for example the executing time of each kernel, In this case what do you suggest ?
Stick to ssh as it will be of better performance, unless you need a graphical output.
Ok than, thanks for your help @Andrey1984.
There can be a bit of a catch with ssh though. If you forward X11 events (versus the frame buffer), then it means part of the computing is being done on the GPU of the machine you have the DISPLAY on. If for example I use “ssh -Y name@host”, then the machine I am sitting at will see any graphical output initiated on the remote system. This may seem to solve the problem, but this may not be what you want.
If you were to run an OpenGL program on the same machine you DISPLAY on, then X11 events are interpreted by the X11 server and executed by the GPU on that server’s hardware/GPU. When you run an OpenGL program on the remote machine, but DISPLAY locally, then X11 events are forwarded and actual GPU and OpenGL libraries are offloaded to the machine you are sitting at. If both machines have OpenGL, and both machines have all needed rendering libraries, then this works well. If it turns out that the machine you are sitting at has a very fast GPU (e.g., Tesla or 1080Ti), and the remote machine is a TX2, you will suddenly see amazing frame rates and performance. But it won’t be the TX2 doing the GPU work, it will be your work station.
The same is true of CUDA. The reason a DISPLAY environment variable is required even with CUDA is that “DISPLAY” really just means “buffer of a given format accessible by rendering hardware”. Nothing has to be displayed at all, it is the buffer which is set up in this way in which the GPU can function. Move the buffer and talk to it by events and the hardware doing the work also migrates.
On the other hand a virtual X display means everything is running on the Jetson. Your remote system is not seeing X events for remote desktop sharing applications, it only sees a description of the frame buffer content. Windows does not understand X (at least not without adding X through something like Cygwin), so a virtual desktop sharing application will work even when remote X offload will not. Rendering, CUDA, and GPU only care where that buffer is…they don’t care if a physical DISPLAY is attached or not. Remote desktop sharing applications are just detachable proxies for a real hardware monitor…there is a real frame buffer though, and it would run on the Jetson regardless of where the frame buffer is viewed from (there are also proxies for mouse and keyboard events).
In a case where you have a given CUDA version on your host (or OpenGL version), and a different CUDA version on your Jetson (or different OpenGL version), you won’t be able to do remote “ssh -Y” forwarding execution…the code on the Jetson would want one version, the host you are using would only be able to provide a different version. You can of course compile both versions if available (a TK1 could only provide CUDA 6.5 though, if your host has CUDA 7/8, this will fail for a TK1), but this kind of defeats the purpose of having the GPU on the Jetson. Remote desktop sharing with the Jetson is fringe computing, ssh forwarding is just a fancy network model to do the GPU work on the host PC.
There would still be CPU tasks the Jetson would perform when doing remote ssh display, but in this case it is the GPU we’re interested in. Virtual desktop sharing does this. I’m sure ssh remote forwarding of X will be astonishing performance when you do a remote display to your 1080Ti (it was one of the more fun mistakes I’ve made, at least till I realized it wasn’t my Jetson doing the work :P ).
It seems reasonable having a powerful GPU at Ubuntu Workstation to run CUDA computations directly locally, because performance of the former would be always better than of a Jetson.
That will work excluding the cases when arm-specific code or Jetson-connected hardware are involved.
The latter could cause need of remote execution. Though if Host PC doesn’t have CUDA compatible GPU the remote execution makes sense as well.
First of all, thanks to both of you.
Currently I’m enrolled in a PhD program in computer science and I need to conduct some experimentation on the latest Jetson which is the TX2 board, unfortunately I couldn’t afford it until a friend of mine in an other university propose to give me access to their TX2 and with the university policies on network access, the use of a VPN is obliged. Honestly I have no experience with VPN, that why I came here in order to learn something.
When you are VPN connected to university network your computer getting ip address of vpn connection that is used to connect remote VPN site aka bridge. Connection established - you can use directly e ip addresses of internal network of the university to access their devices presuming they have access configured and you have credentials/ key based authentication.
Yes, VPN should do the job. The trick is that the Jetson needs to run either a virtual X11 server, or else have someone logged in to an actual GUI session. The former is probably preferable for all kinds of reasons. You might ask him if it has been set up to use with any remote desktop program.
if run TX2 locally without remote control, can we intentionally disable GPU buffer to get better performance?
When I check the usage of GPU, it never exceeds 60%, it seems like GPU display shouldn’t be the factor that slows down the computation, there are still at least 40% of GPU computation power is idle.
But the fact is that using x11 or ssh, the time to run a program is reduced remarkably.