See here for the different limits on combinations of number of nodes and walltime requested.
Use the command
/sara/sw/remotevis/scripts). It will list the current RVS reservations, including information on start and end time, number of nodes, which nodes, etc. You will also see reservations made by other users, which can be useful to judge when reserved cluster nodes will become available again.
paulm@v40-1:~$ rvs_show Remote visualisation service jobs/reservations Job ID Owner Start time End time Nodes Int? Walltime CPU time Mem(max) VMem(max) Node(s) ------------------------------------------------------------------------------------------------------------------------------- 36610 tijs Mon 14 Oct 15:24 Wed 16 Oct 19:24 1 no 49:20:28 00:06:43 149.2MB 1.5GB v41-3 36633 paulm Wed 16 Oct 14:37 Wed 16 Oct 23:37 1 no 02:07:09 00:00:37 323.7MB 45.5GB v42-7 Note: CPU time, Mem(max) and VMem(max) are cumulative over all the nodes in a job
||Overview of RVS reservations|
||Request a VNC session|
||Request a parallel ParaView session|
Submit a job.
||Remove job number <number>|
||Overview of the status of cluster nodes and jobs assigned to them|
See here for documentation on the Torque batch software used. This link actually takes you to the Lisa cluster documentation, so some of it might not be relevant to the RVS cluster.
Yes, use the
-r <w>x<h> option with
rvs_vnc. Another option is to set the environment variable
RVS_VNC_RESOLUTION in your shell's startup script, again to
<w>x<h>, so you don't have to use
-r each time.
module load ..., vglrun ..., etc?
Yes, with the LXDE desktop environment that we provide in VNC sessions there's an option to create desktop icons. For the software modules available on the RVS we provide a number of
XXX.desktop files that you can use for this, these are located in
/sara/sw/remotevis/desktop. By copying/symlinking a selection of files in that directory to your
~/Desktop the relevant icon(s) should appear on your desktop.
You can also use these files to create menu items in LXDE's menu (available through the bottom-left . For this, copy/symlink the relevant file in
~/.local/share/applications and run
lxpanelctl restart in a terminal (the latter to update the menu). Note that all applications are under the
Adding custom icons/menu entries is quite easy, the
XXX.desktop files we provide should give an idea of how to do that.
TurboVNC and TigerVNC are good choices. Of these two, TigerVNC has a nicer GUI and appears to have slightly better performance. In principal any viewer supporting the VNC protocol can be used, but the two mentioned are well maintained and provide good performance. TightVNC will also work, but sometimes seems to have noticeable lower performance (especially on Windows).
Note that "Screen Sharing" on MacOS is not usable as a VNC viewer, at least, not in our tests. Use the TurboVNC viewer package instead.
There should be no interoperability problems with any of these viewers as the underlying VNC protocol is platform-agnostic. We successfully tested simultaneous viewing of a single VNC session from three different systems (TurboVNC 0.6 on a 32-bit Linux system, TigerVNC 1.0.1 on a Windows system, TightVNC 1.3.9 on a 64-bit Linux laptop).
The VNC server used on the RVS nodes is actually TurboVNC.
rvs.surfsara.nl using regular SSH and run
Please always use a VNC password that is different from your SURFsara CUA password
Some VNC viewers (and versions) have problems when you're using Alt-TAB to switch to and from the viewer application. This is probably because the Alt keypress event is captured by the VNC viewer, but the subsequent TAB keypress will take away keyboard focus and so the viewer application never receives a release event for the Alt key, thinking it is still pressed when you switch back to it.
When you find that the Alt-key seems to be "stuck" in your VNC viewer simply press and release Alt. This usually fixes it.
Somebody, in theory, could connect to the VNC server you started on a render node. But:
All in all, the risks should be minimal.
Note, however, that data sent over VNC is not encrypted in any way, in particular key strokes: a password you enter within a VNC session is sniffable in the VNC network traffic. If you are worried about this you can tunnel the VNC connection through an SSH connection, using the
-L option with OpenSSH or TurboVNC's
Yes, this is possible. By default the VNC server allows sharing a VNC session. Note that each user that you want to share a VNC session with has to:
vncpasswdyou can easily change your VNC password into a temporary one used for sharing a session. There is also an option to set a view-only password, see below. Please always use a VNC password that is different from your SURFsara CUA password
Options -> Misc, or you can pass
-sharedon the command-line (this switch is also supported by TurboVNC).
Related to the above is that VNC allows you to set a view-only password. This allows other users to only view your VNC session, while it won't allow them to control the remote keyboard or mouse.
/opt/TurboVNC/bin/vncpasswd allows you to set this password. Users meant to only observe what you're doing then need to log in with the view-only password.
Yes, check the files in the
.vnc directory in your home directory. E.g., for a VNC server running on
It depends on a number of things w.r.t. your use case:
If you're not interested in using Paraview's parallel rendering capability you can simply reserve a single RVS node, start a VNC session and run the Paraview client (GUI), "paraview". This is the simplest usage, where you're just running a visualization application on an RVS node and interact with it remotely using VNC.
If you do want to use Paraview to render parallel on multiple nodes then there are two options:
paraview) in a VNC session on a separate RVS node and run a VNC viewer on your local desktop.
Option 1 has the advantage that the RVS nodes are fully used for visualization/rendering, but you need to have the Paraview client (GUI) installed on your local machine, in a version that matches the binaries on the RVS nodes. Option 2 has the disadvantage of using a single RVS node for just running the Paraview client, but you only need a VNC viewer on your local machine, not a complete Paraview installation.
See here for instructions for option 1. For option 2 the steps are similar, except that you need to run the Paraview client in a VNC session.
If you're not interested in using Visit's parallel rendering capability you can simply reserve a single RVS node, start a VNC session and run the Visit client (GUI). This is the simplest usage, where you're just running a visualization application on an RVS node and interact with it remotely using VNC.
If you do want to use Visit to render parallel on multiple nodes then you have to configure a host profile, in addition to starting the Visit Client as described above. See here for a detailed description
More or less. You can use the
+pr option when starting your OpenGL application with
vglrun +pr paraview. This will periodically produce statistics in the terminal window on
The actual image compression (before network transmission to the VNC client) is performed by the VNC server. There's currently no easy way to get statistics on the compression performance.
Not at the moment. We only provide remote rendering using VNC, but VGL Image Transport might be added in the future.