Hi. Our lab should shortly have a new TX1 up and running, flashed with the most recent JetPack 2.3, but none of us are experienced with either TX1 or the TK1 predecessor. Since this is an academic lab, we have multiple potential users who might like to develop on the device while offsite. (One at a time, of course.)
Assume we have a stable, externally accessible IP address. Assume we will have excellent wireless connectivity within the lab, and outstanding wireless connectivity from the lab to the world, and that any bandwidth issues will be at the remote end. Assume we are primarily interested in audio, rather than graphics applications, and that we are interested in deep learning and machine learning approaches, including Caffe, Theano and TensorFlow. (We understand the difficulties TensorFlow has presented thus far; it is at the bottom of the list.)
What are our options for remote development?
A) We need a dedicated Ubuntu machine for remote development sitting in the lab. (If this is the case, can that machine be a server into which people log in remotely and do development?)
B) Anyone in the lab with an Ubuntu machine can use it for remote development, but the machines must all be on the same wireless network.
C) Anyone with an Ubuntu machine and remote (out-of-lab, IP) access to the TX1 can use it for remote development?
A lot of what you’re asking I can’t answer. You’ll probably find it useful to know that the L4T/Ubuntu running on the Jetson is a full Linux distribution, so ethernet connections and WiFi connections (once set up) allow all of the normal things a full Linux computer would allow. This includes remote access via ssh or similar networking to any UNIX-like flavor of computer.
If you want to flash or clone, direct physical access is required, otherwise you can’t put the Jetson in recovery mode.
The case of using Ubuntu for the host and not just any x86_64 Linux is solely for the use of the JetPack front end installer…actual flash directly from the driver package plus sample rootfs does not need JetPack (if you ignore JetPack, then the only host flash requirement is x86_64 Linux). Most of the extra packages which a JetPack can install are also available separately…but installing and configuring those other packages on the host could get rather complicated without JetPack.
If you want to run remote CUDA applications you need to be careful as to how the remote connection is configured. Normally an application and the hardware accelerated drivers both run on one machine. X11 allows the program to run on one machine, while display is on another…this offloads graphics to the desktop’s graphics card (the computer running the application wouldn’t even need a video card for that case). The same thing is likely to happen with any GPU device tied to graphics libraries…if you are not doing it correctly, remote graphics will also transfer CUDA functions to your desktop machine and will not actually run on the Jetson for that case. If your desktop computer has a fast nVidia graphics card with the proper CUDA version installed your only hint will probably a dramatic and amazing performance boost.
To be certain this would not be an issue you probably need to use some form of remote desktop software, i.e., some form of VNC. What this does is create a virtual desktop in a frame buffer on the Jetson, and the CUDA applications think they are rendering directly on the Jetson…and they are…but instead of the frame buffer having a real monitor connected it has an ethernet link to a proxy application on the desktop computer. Neither graphics nor GPU/CUDA would transfer to the desktop and any information or development on the Jetson will be independent of the desktop computer’s graphics. I do not have any advice on the best remote desktop software.
Also, if multiple people are working at the same time from a remote login, things won’t go well for CUDA. Everyone running something requiring GPU will be competing. If you have 256 cores, then just 4 simultaneous logins means only 64 cores per person, but how you’d manage to distribute that fairly I don’t know.