To request the addition of a web site to the white-list, see Web proxy

We will use the wget command to retrieve our data from Internet. To use a web proxy with wget, the $http_proxy and $https_proxy environment variables must be defined.

By default, those $http_proxy and $https_proxy environment variables are not set, to avoid any confusion when using http to connect resources inside Grid'5000. Please run the following command to check your current environment :

frontend:

echo http_proxy=$http_proxy ; echo https_proxy=$https_proxy

You should get:

http_proxy=
https_proxy=

For this tutorial we use the web proxy, so we need to set the 2 environment variables:

A ~/hello/ directory has been created in our home directory.
It will be available on every clusters's node of the site because of NFS-mounted home directories.

Warning

If your experiment generate lots of writings, it's advised to do them on local disk space of the nodes instead of your networked-shared home directory.

This way, you will avoid a lot of NFS troubles, such as lags or breakdowns.
Since NFS service is shared among all users and all compute nodes, its performance may vary independently of your experiment.

In order to ensure experiment's reproductibility, be sure to avoid measurements that could depend on the performance of a shared NFS server !

Visualize cluster

Experiment data are now ready. Before running the experiment in a job, we are now going to look at the cluster state, which can be visualized in many ways.

Scheduled or running jobs

oarstat is a command-line tool to view current or planned job submission.

Nodes properties

oarnodes is also a command-line tool. It shows cluster node properties:

frontend:

oarnodes

Among returned information there is current node state. This state is generally Alive or Absent. When nodes are sick, their state is Suspected or Dead.

Pretty output

oarprint is a tool providing a pretty print of a job resources.
The command prints a sorted output of the resources of a job with regard to a key property, with a customisable format.
On a job connection node (where $OAR_RESOURCE_PROPERTIES_FILE is defined):

The following command must be executed in an OAR job (on a compute node)

To ease post-run analysis, OAR will by default redirect standard output and standard error output
into OAR.OAR_JOB_ID.stdout and OAR.OAR_JOB_ID.stderr respectively.

They should be seen in your current working directory after job's end:

OAR.OAR_JOB_ID.stdoutOAR.OAR_JOB_ID.stderr

Thus you can follow the output of your job as it is running:

frontend:

tail -f OAR.OAR_JOB_ID.stdout

OAR lets you to specify output files for standard and error output streams by using options
-O and -E respectively.
For example it is possible to redirect the oarsub output in /dev/null or in other files:

frontend:

oarsub ~/hello/run_hello_mpi -O /dev/null

frontend:

oarsub ~/hello/run_hello_mpi -O ~/hello_mpi.log

Ending

The results of our job are available at the end of the files containing the standard (and error) outputs:

frontend:

tail OAR.OAR_JOB_ID.stdout

Connection to a running job

While a job is running, it is possible to connect inside its environment with -C OAR_JOB_ID option.

frontend:

oarsub -C OAR_JOB_ID

Unless you specify a submission with -t allow_classic_ssh you have to use the OAR shell to connect to
job's nodes: oarsh