Servidores con gráficas:

• ctgpgpu1:
  • Servidor Supermicro X8DTG-D
  • 2 procesadores Intel Xeon E5520
  • 10 GB de memoria RAM (5 DIMM a 1333 MHz)
  • 2 tarjetas Nvidia GF100 [Tesla S2050]
    • Algunas de las tarjetas se encuentra temporalmente en otro servidor para unas pruebas. Por lo tanto, de momento sólo hay una tarjeta disponible.
  • Sistema operativo Ubuntu 10.04
    • CUDA versión 5.0
• ctgpgpu2:
  • Servidor Dell Precision R5400
  • 2 procesadores Intel Xeon E5440
  • 8 GB de memoria RAM (4 DDR2 FB-DIMM a 667 MHz)
  • 1 tarjeta Nvidia GK104 [Geforce GTX 680]
  • Sistema operativo Ubuntu 18.04
    • Slurm (de uso obligatorio para la gestión de trabajos)
    • CUDA 9.2 (repositorio oficial de Nvidia)
    • Docker-ce 18.06 (repositorio oficial de Docker)
    • Nvidia-docker 2.0.3 (repositorio oficial de Nvidia)
    • Nvidia cuDNN v7.2.1 for CUDA 9.2
    • Intel Parallel Studio Professional for C++ 2015 (¡licencia única, avisa si vas a utilizarlo!)
• ctgpgpu3:
  • Servidor PowerEdge R720
  • 1 procesador Intel Xeon E52609
  • 16 GB de memoria RAM (1 DDR3 DIMM a 1600MHz)
  • Conectado a un cajón de gráficas con:
    • Gigabyte GeForce GTX Titan 6GB (2014)
    • Nvidia Titan X Pascal 12GB (2016)
    • Nvidia Titan Xp 12GB (2017)
    • Nvidia Quadro P6000 24GB (2018)
  • Sistema operativo Ubuntu 18.04
    • Slurm (de uso obligatorio para la gestión de trabajos)
    • CUDA 9.2 (repositorio oficial de Nvidia)
    • Docker-ce 18.06 (repositorio oficial de Docker)
    • Nvidia-docker 2.0.3 (repositorio oficial de Nvidia)
    • Nvidia cuDNN v7.2.1 for CUDA 9.2
    • Intel Parallel Studio Professional for C++ 2015 (¡licencia única, avisa si vas a utilizarlo!)
    • ROS Melodic Morenia (repositorio oficial de ROS)
• ctgpgpu4:
  • Servidor PowerEdge R730
  • 2 procesadores Intel Xeon E52623v4
  • 128 GB de memoria RAM (4 DDR4 DIMM a 2400MHz)
  • 2 tarxeta Nvidia GP102GL [Tesla P40]
  • Sistema operativo Centos 7.4
    • docker 17.09 y nvidia-docker 1.0.1
    • OpenCV 2.4.5
    • Dliv, Caffe, Caffe2 y pycaffe
    • Python 3.4: cython, easydict, sonnet
    • TensorFlow
• ctgpgpu5:
  • Servidor PowerEdge R730
  • 2 procesadores Intel Xeon E52623v4
  • 128 GB de memoria RAM (4 DDR4 DIMM a 2400MHz)
  • 2 tarxeta Nvidia GP102GL [Tesla P40]
  • Sistema operativo Ubuntu 16.04
    • Slurm para a xestión de colas de traballo de uso obrigatorio.
    • Modules para la gestión de versiones de bibliotecas.
    • CUDA versión 9.0
    • OpenCV 2.4 y 3.4
    • Atlas 3.10.3
    • MAGMA
    • TensorFlow
    • Caffee

* ctgpgpu6:

• Servidor SIE LADON 4214
• 2 procesadores Intel Xeon Silver 4214
• 192 GB de memoria RAM (12 DDR4 DIMM a 2933MHz)
• Nvidia Quadro P6000 24GB (2018)
• Sistema operativo Centos 7.7
  • Driver Nvidia 418.87.00 para CUDA 10.1
  • Docker 19.03
  • Nvidia-docker

Todos los usuarios del CiTIUS pueden acceder a este servicio, pero para eso deben solicitarlo previamente a través del formulario de incidencias. Mientras no lo hagan, recibirán un mensaje de contraseña incorrecta.

Para conectarse a los servidores, debes hacerlo a través de SSH. El nombre y las direcciones IP de los servidores son las siguientes:

• ctgpgpu1.inv.usc.es - 172.16.242.91:1301
• ctgpgpu2.inv.usc.es - 172.16.242.92:22
• ctgpgpu3.inv.usc.es - 172.16.242.93:22
• ctgpgpu4.inv.usc.es - 172.16.242.201:22
• ctgpgpu5.inv.usc.es - 172.16.242.202:22

La conexión solo está disponible desde la red del centro. Para conectarse desde otras localizaciones o desde la red de la RAI es necesario hacer uso de la VPN o de la parasela SSH.

Los servidores se apagan para ahorrar energía al no detectar actividad alguna durante una hora. Para encenderlos de nuevo, puedes hacer uso de la herramienta de encendido remoto.

Los servidores entienden como actividad:

• cualquier sesión SSH abierta,
• cualquier sesión de screen sin rematar

En ctgpgpu2, en ctgpgpu3 y en ctgpgpu5 hay un gestor de colas instalado para enviar trabajos y así evitar conflictos entre procesos, ya que no se deben ejecutar dos trabajos al mismo tiempo.

Para enviar un trabajo a la cola se utiliza el comando srun:

srun programa_cuda argumentos_programa_cuda

El proceso srun espera a que el trabajo se ejecute para devolver el control al usuario. Si no se quiere esperar, se pueden utilizar gestores de sesiones de consola como screen (hay disponible una guía en vídeo muy sencilla de seguir), y así poder dejar el trabajo a la espera y desconectar la sesión sin preocuparse y recuperar la salida de consola más adelante.

Alternativamente, se puede utilizar nohup y pasar el trabajo a segundo plano con &. En este caso la salida se guarda en el archivo nohup.out:

nohup srun programa_cuda argumentos_programa_cuda &

Para ver el estado de la cola se utiliza el comando squeue. El comando muestra una salida similar a esta:

JOBID PARTITION     NAME     USER  ST       TIME  NODES NODELIST(REASON)
9  servidore ca_water pablo.qu    PD       0:00      1 (Resources)
10 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
11 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
12 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
13 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
14 servidore ca_water pablo.qu    PD       0:00      1 (Priority)
 8 servidore ca_water pablo.qu     R       0:11      1 ctgpgpu2

También se puede obtener una vista interactiva, actualizada cada segundo, con el comando smap:

smap -i 1