Configuration changes

Hexagon has got two login nodes with 10Gb network connection. We hope this upgrade will speed up transfers to and from hexagon.

These two nodes are dedicated only for file transfers. Please do not use
them for compiling or running applications.

We remind you that hexagon has HPN enabled OpenSSH. To get the best
possible transfer speeds please consider reading:
Data high performance tools on hexagon

Address to use: hexagon-ftp.bccs.uib.no

To use checkpointing feature application must be compiled with blcr and Cray MPT version 3.0.1 and up:

module load blcr

With loaded module all necessary options will be automatically added to the compiler wrapper. Only MPI and SHMEM programming models are supported.

Job script must have at least the following parameter:
#PBS -c enabled

See man qsub for more parameters.

To checkpoint and hold the job user executes:
qhold JOBID

To continue:
qrls JOBID

The Cray checkpoint/restart solution uses BLCR software from Berkley Lab's and inherits its limitations. For more information, refer to the BLCR documentation: http://upc-bugs.lbl.gov/blcr/doc/html/index.html.

All users when logging into hexagon login nodes automatically will be "niced" to +5, each session on login node is limited to 100 running processes. This is not anyhow reflects on compute nodes. Jobs will not be affected.

This is done primarily to remove effect of one user high CPU tasks affects another users on the same login node.

Please give a feedback via support-uib@notur.no

Fimm home file system performance will be slow for 4-6 hours (specially log in to fimm and ls on /home/fimm), The reason is we are migrating all fimm home file system from current storage system to an other(better) storage system.
We will keep you updated regarding to time window.


23/02 08:00 Update

File system migration is over, now the performance of Fimm home file system is back to normal.

Since /work usage on hexagon continue to rise sharply (also after our request for cleanup) we will be forced to implement automatic deletion in /work starting from October 1st 2009.

The automatic deletion will be done at any time when the /work usage is above 65%. The script will delete files based on age, size and last access - prioritizing oldest files for deletion first. Files newer than 7 days will not be deleted.

Since this deletion process (as well as the high disk usage percent) will take away disk-performance from the running jobs - the best solution is of course for you to remember to clean up after each job.

Remember that /work has no backup and is intended for the input and output data of the current running jobs only.

The policy and thresholds for the disk-cleanup may need to be revised if the /work usage continue to be too high. In that case we will contact hexagon users again.

Please send any questions to support-uib@notur.no.