---

Departament de Química Física - SGI Origin-2000

Fecha de actualización: 26 de Marzo 2002

Aqui tienes la Página en Acrobat en un Fichero PDF

---

 

Descripción

Hardware

    Jifa dispone de 8 procesadores MIPS R10000 a 195MHz . La memoria RAM total del sistema es 2.0GB (512MB por nodo, 2 procesadores por nodo) y el área de disco es de aproximadamente en los scratch de 81GB en /scr1 y 18 GB en /scr2.
 

Software

• Versión 6.5.14 del sistema operativo IRIX.
• Los compiladores (C, C++, Fortran 77 y Fortran 90) se incluyen dentro del paquete SGI Compilers-7.2 (todos ellos debidamente licenciados).
• También se han instalado las herramientas de paralelización más usuales:
• El paralelizador automático (auto_pp) para todos los compiladores.
• Algunas herramientas de desarrollo de SGI (WorkShop, WorkShop MPF y Performance CoPilot).
• Las librerías de paso de mensajes PVM y MPI adaptadas a la arquitectura N²MA de Silicon Graphics.
• En lo que se refiere a software de libre distribución, contamos con:
• Herramientas de compresión/descompresión (gzip).
• Editor Emacs.
• TeX/LaTeX (sólo para un apuro: no es una de las versiones más modernas que he visto y no está especialmente bien configurado).
• GhostScript/Ghostview, etc...
• El sistema de colas Cray NQE/NQS (Versión 3.3.0.10).
• Software de Química Computacional:
• Gaussian94 (/u/util/g94/...)
• Gamess96 (/u/util/gamess/...), versiones paralela y secuencial.
• Gaussian98 y GaussView(?)
• Etc...

Acceso al sistema

Las áreas de scratch

Disponemos de dos áreas de scratch son 2 una de aproximadamente 81GB y otra de 18 GB y denominadas /scr1 y /scr2. Estas áreas están construidas como indica la figura:

    Como se ha dicho, las áreas de scratch están configuradas para obtener velocidad. Esto es incompatible con fiabilidad: recordad que si falla algún disco, todo el contenido del área de scratch se  pierde y no hay backup...

    Todavía no se ha establecido una política de borrado automático de estas áreas. La tolerancia en este aspecto dependerá en gran medida del comportamiento de los usuarios respecto a la basura que generan los cálculos. Por favor, borrad siempre las áreas de scratch al acabar un cálculo, bien de forma automática en el propio script de submisión, bien manualmente en el caso de cálculos fallidos. Este aspecto NO ES RESPONSABILIDAD DEL SISTEMA DE COLAS NI DEL ADMINISTRADOR DEL SISTEMA, así que el buen funcionamiento depende de la actitud individual de los usuarios.

El sistema de colas

    Como en tiberio, sólo existe una cola de submisión (denominada aquí default).  Es necesario, por tanto, especificar lo más detalladamente posible los recursos que empleará el cálculo. De este modo el sistema de colas es capaz de ajustar la demanda a los recursos disponibles, optimizando su uso. Cuanto más detallados estén los recursos, mayor sera la prioridad intracola de un trabajo (ya que, por omision, el sistema asigna el máximo aplicable a la cola).

    Las colas definidas en este momento son:
 

    Hay también definidos una serie de límites globales, cuya misión es la de garantizar que el total de trabajos en ejecución no sobrepase los recursos del sistema:
 

    Las interacciones entre los límites por cola y los límites globales pueden dar lugar a comportamientos 'aparentemente' extraños del sistema de colas, por lo que no es suficiente aplicar la 'lógica simple' si algún trabajo no entra en ejecución instántaneamente...

    En cuanto a la prioridad intracola, se calcula teniendo en cuenta una serie de factores ponderados (scheduling factors).  En este sistema, los pesos asignados son:
 

    Factores de pondereación más grandes implican menor prioridad intracola (excepto el factor Time). En este sistema, como se puede ver en la tabla, el factor crítico es la demanda de memoria.

¿Cómo se submite un trabajo?

   Algunos puntos imprescindibles a la hora de submitir un trabajo son:

• Ajustar lo más finamente posible el límite de memoria empleando la directiva #QSUB -lM xxxmb(límite por Job). Si el Job consta de más de un proceso, se puede especificar la memoria máxima que cada uno puede utilizar mediante la directiva #QSUB -lm xxxmb (límite por Proceso). El límite per Proc (-lm) tiene poco sentido dado el tipo de trabajos que corren en esta instalación, por lo que lo mejor es poner el mismo límite en ambas directivas.
• Especificar el consumo de CPU total mediante la directiva #QSUB -lT hh:mm:ss. En el caso de que el Job conste de más de un proceso es posible limitar el tiempo máximo de CPU por proceso mediante la directiva #QSUB -lt hh:mm:ss. El funcionamiento de ambos límites es el siguiente:
• La suma del tiempo consumido por todos los procesos dentro de un Job nunca superará el límite per Job (-lT).
• Un proceso individual nuncá superará el tiempo especificado en el límite per Proc (-lt). Si un proceso alcanza este límite, será interrumpido y el Job continuará con el siguiente proceso... y así hasta acabar de forma natural o alcanzar el límite per Job.
En el caso de cálculos paralelos, también puede ser interesante especificar el tiempo de CPU por PE (Proccesor Element, es decir, CPU) mediante la directiva #QSUB -l p_mpp_t=hh:mm:ss, junto con el tiempo de CPU total de todos los PE's mediante la directiva #QSUB -l mpp_t=hh:mm:ss. Más abajo se indica en detalle cómo calcular estos valores mediante un ejemplo.
• Utilizar la directiva #QSUB -ro para que funcione correctamente el Checkpoint/Restart de NQE/NQS. También es adecuado utilizar la directiva #QSUB -eo (que redirecciona el Standard Output y el Standard Error al mismo fichero). El Checkpoint  funciona en todas las aplicaciones secuenciales y paralelas (incluyendo Gaussian94).
• Para cálculos paralelos, es necesario especificar el número de PE's que se quiere utilizar mediante la directiva #QSUB -l mpp_p=n (2 <= n <= 4). Observad que en esta configuración no existe la distinción entre colas paralelas y secuenciales, por lo que en cálculos paralelos es necesario solicitar el número de procesadores que se quiere utilizar. Si no se especifica ningún límite, el sistema considerará que el Job es secuencial y sólo le asignará un procesador (Nota: este punto ha cambiado desde la última revisión del sistema de colas). Recordad que vuestro Job no utilizará n procesadores sólo por el hecho de que hagáis la correspondiente reserva de PE's en el sistema de colas: es responsabilidad de la aplicación (y del usuario) hacer uso del paralelismo.

    (*) ¿Por qué estos números? Veamos una explicación detallada:

• Calculamos que el trabajo necesitará unas 40 horas de CPU. Por precaución, sobreestimamos un poco el tiempo y solicitamos un límite de 45 horas.

 
• Hemos estimado,  a partir de un cálculo anterior similar pero más corto, que el speedup que conseguimos es del orden de 2.9 y la eficiencia es del orden del 73%. Para ello, hemos tomado los tiempos user y real obtenidos mediante el comando time (al final del fichero .log de Gaussian94) y los hemos dividido. Después hemos multiplicado por el factor de corrección 0.8 (determinado empíricamente), ya que el número que obtenemos por este método no es más que una aproximación al speedup real. En detalle:
Real:  7:26:35.06 = 26795.06s
User: 27:10:01.96 = 97801.96s

User/Real = 97801.96 / 26795.06 = 3.65
Speedup= (User/Real) * 0.8 = 2.92
Eficiencia = Speedup / num_proc = 2.92 / 4 = 0.73
 

• A partir de estos valores, calculamos el tiempo que empleará cada uno de los threads del cálculo paralelo. Para ello sólo tenemos que dividir el tiempo total estimado entre el número de procesadores y dividir el resultado por la Eficiencia:
Tiempo estimado  = 45:00:00 = 162000.00s
Tiempo por Proc. = (162000.00 / ( 4 * 0.73)) = 55479.5 = 15:24:39.50
 
Puesto que el número es aproximado, conviene sobreestimarlo en, digamos, un 10% (este número dependerá de cada caso: la experiencia manda), así que finalmente hemos decidido poner un límite por PE de 17:00:00.
 
• Como se puede observar, estimar estos valores es trivial y sólo es necesario prestar un poco de atención a los cálculos que estamos realizando para obtener un buen rendimiento del sistema y de paso aumentar la prioridad intracola de nuestros trabajos.