Blogia

Blog de Ibercivis

Finalizada una de las etapas del proyecto Sanidad

Nos es grato anunciar que una de las partes de las que consta el proyecto SANIDAD , que simula el transporte de partículas por nuestro organismo, a falta de las pertinentes comprobaciones de los resultados, podemos decir que ha finalizado, ya estamos realizando todos los ajustes técnicos para empezar el envío de "work units" de la segunda parte que va a estudiar los mismos aspectos con ligeras modificaciones que la primera, ¡Os iremos informando!

EDGI dará comienzo el próximo 1 de Junio


Si hace dos días comentábamos nuestra inminente expansión americana... lo que tenemos a la vuelta de la esquina es un macroproyecto a nivel europeo denominado EDGI de interconexión de Grids, Desktop Grids y Clouds o en otras palabras, supercomputadores, ordenadores de sobremesa y proyectos de la comunidad científica en dónde Ibercivis participará activamente en el proyecto para dar cuerpo a EDGI. Y... ¿Cuándo se empieza? el 1 de Junio!! para estar informado al 100% te dejamos un video de la presentación del proyecto EDGI gentileza de Peter Kacsuk de SZTAKI uno de los puntos de unión con ibercivis que está en Hungría... Para los que el inglés escrito se os dé mejor, dejamos también 5 diapositivas explicativas del proyecto y para ampliar todavía más la información el link de la página del proyecto EDGI... ahí queda eso.

 

Ibercivis se expande al continente Americano!

Ibercivis se expande al continente Americano!

Igual que se solicitaron unas ayudas al MICINN para trabajar bilateralmente con Cuba y Argentina (estas han sido concedidas, otro día daremos mas información) ahora se ha solicitado al Programa CYTED para crear una red en la que participan España, Portugal, Cuba. México, Brazil y Argentina.

La Red Temática que aquí se presenta constituye un nuevo espacio de debate y de interacción donde cooperar y diseñar de forma conjunta las mejores actuaciones a desarrollar en el marco de la computación voluntaria con el objetivo de optimizar el uso de los recursos informáticos y de aumentar la participación ciudadana en la ciencia. 

Partiendo de lbercivis, los integrantes aportarán aspectos técnicos y sociológicos sobre la computación voluntaria como solución sostenible para la Comunidad Iberoamericana, tanto como recurso computacional como de interacción científica y de integración social en la ciencia.

Os iremos informando puntualmente de los avances de este nuevo proyecto intercontinental!

 

Sanidad, nuevo proyecto.

Hemos lanzado un nuevo proyecto, Sanidad.

Sanidad pretende inicialmente mediante el uso de técnicas de simulación numérica Monte Carlo mejorar el conocimiento y el uso de Radiaciones Ionizantes en el ámbito Sanitario.

Las aplicaciones son múltiples, desde resolución de problemas asociados al diagnóstico por la imagen, pasando por la descripción y mejora del conocimiento de equipos y fuentes radiactivas, hasta la utilización de las Radiaciones en los tratamientos contra el Cáncer.


Más información aquí

Lapack y BLAS en CUDA.

Lapack y BLAS son dos librerías (aunque sería mejor decir que son dos APIs, ya que hay diferentes librerías que implementan las funciones de Lapack y BLAS) para realizar operaciones básicas de algebra lineal. Estas librerías se usan ampliamente en el cálculo científico, de hecho, nvidia incluye una versión de BLAS: cuBLAS. La librería Magma implementa sobre CUDA algunas de las funciones de Lapack.

Hace unos días hemos comenzado a lanzar las primeras pruebas con estas dos librerías, empezando por la plataforma linux 64 bits. Hemos creado una aplicación, magma_test, en la que medimos la velocidad de transferencia entre el host y la GPU, además de realizar diversas operaciones en simple y en doble precisión (no todas las tarjetas soportan doble precisión). Dichas operaciones se realizan tanto en la GPU como en la CPU, para luego comparar los valores obtenidos.

Iremos informando de los resultados logrados.

Concurso creación de vídeo corto para Ibercivis


El BIFI convoca un concurso público para la creación de un vídeo que tenga relación con el proyecto Ibercivis. Se pretende que este video pueda servir como respuesta (amigable y jocosa) a un video sketch que apareció en el programa de “Oregón Televisión” emitido por Aragón Televisión el pasado fin de semana.

Temática: Ibercivis, ciencia, voluntarios, Oregón televisión...
Modalidad: Corto, sketch, anuncio, viral...
Restricciones:
• Duración máxima: 2 minutos
• El título del vídeo (la cabecera en youtube) debe contener la palabra Ibercivis
• El idioma puede ser cualquiera, pero en caso de no ser español los subtítulos deberán estar obligatoriamente en español
• Durante el vídeo se debe escuchar la palabra “ibercivis” o leer “ibercivis” en los subtítulos o ver el logotipo de ibercivis

Formato de entrega:
• Los candidatos deberá subir los videos a youtube. Siempre que sea posible, se deberá subir el video como respuesta al vídeo de “Oregon Televisión” anteriormente citado.
• Además, deberá obligatoriamente mandar un mail a secretaria@bifi.es indicando en el asunto “Concurso video Ibercivis” y, en el cuerpo del mensaje, el nombre del autor, telefono, dirección postal y el enlace al vídeo de youtube.
• Los vídeos deberán estar subidos a youtube y los mails deberán ser enviados antes del 10 de marzo de 2010

Proceso de selección: entre todos los candidatos un jurado interno del BIFI elegirá un ganador y se lo comunicará antes del 12 de marzo de 2010. El premio puede quedar desierto.

El ganador recibirá como premio un aparato electrónico o informático de valor inferior a 300€ (que podrá elegir el ganador).

Hoy pasa algo raro

Los dos schedulers parece que desde el sabado estan considerando no enviar trabajo a la mayoria de las maquinas. He subido 24 horas los tiempos limite a ver si era eso, pero no lo creo. Los logs muestran todo el rato algo asi:

2010-01-31 15:26:23.4518 [PID=28376]   Request: [USER#28xxx] [HOST#75xxx] [IP xxx] client 6.10.18
2010-01-31 15:26:23.4519 [PID=28376]    [send] effective_ncpus 1 max_jobs_on_host_cpu 999999 max_jobs_on_host 999999
2010-01-31 15:26:23.4519 [PID=28376]    [send] effective_ngpus 0 max_jobs_on_host_gpu 999999
2010-01-31 15:26:23.4519 [PID=28376]    [send] Not using matchmaker scheduling; Not using EDF sim
2010-01-31 15:26:23.4519 [PID=28376]    [send] CPU: req 21600.00 sec, 0.00 instances; est delay 0.00
2010-01-31 15:26:23.4519 [PID=28376]    [send] ATI: req 0.00 sec, 0.00 instances; est delay 0.00
2010-01-31 15:26:23.4519 [PID=28376]    [send] work_req_seconds: 21600.00 secs
2010-01-31 15:26:23.4519 [PID=28376]    [send] available disk 9.92 GB, work_buf_min 17280
2010-01-31 15:26:23.4519 [PID=28376]    [send] active_frac 0.540796 on_frac 0.361309 DCF 4.335088
2010-01-31 15:26:23.4519 [PID=28376]    [send] [HOST#75xxx] is reliable
2010-01-31 15:26:23.4520 [PID=28376]    [send] set_trust: random choice for error rate 0.000010: yes
2010-01-31 15:26:23.4622 [PID=28376]    Sending reply to [HOST#75xxx]: 0 results, delay req 626.20
2010-01-31 15:26:23.4622 [PID=28376]    Scheduler ran 0.406 seconds

Y que si quieres arroz catalina. Igual tenermos que resetear las preferencias de los usuarios el lunes :-(

Cuanticables, nuevo proyecto.

Hoy hemos sacado a producción Cuanticables.

Cuanticables es un proyecto desarrollado en la Universidad de Buenos Aires por el área de Materia Condensada - Sistemas Mesoscópicos. La aplicación consiste en el cálculo de propiedades de transporte electrónico en sistemas nanoscópicos desordenados. Básicamente se trata, mediante la realización de sistemas con desorden aleatorio, determinar las propiedades estadísticas de la conductancia de un sistema de muchos canales sobre el que se induce transporte electrónico mediante la aplicación de una diferencia de voltaje. Hay mas información en www.ibercivis.es

 

La base actual de ibercivis

El dato concreto, maquinas que se conectaron en los ultimos 7 dias (el total acumulado de usuarios es bastante mayor):

mysql> select p_ncpus, count(*), AVG(p_iops)/1E9, AVG(p_fpops)/1E9, SUM(serialnum regexp "CUDA") as CUDA, SUM(serialnum regexp "ATI") as ATI from host where rpc_time > UNIX_TIMESTAMP()-3600*24*7  group by p_ncpus;


+---------+----------+-----------------+------------------+------+------+
| p_ncpus | count(*) | AVG(p_iops)/1E9 | AVG(p_fpops)/1E9 | CUDA | ATI  |
+---------+----------+-----------------+------------------+------+------+
|       1 |     1206 | 2.7561012142131 |  1.4241654654338 |    4 |    3 |
|       2 |     2983 | 4.3431943244639 |  1.9450714006494 |   78 |   21 |
|       3 |       22 |  5.611652419765 |  2.3400212082121 |    2 |    2 |
|       4 |      790 | 5.9690432937058 |  2.3902272839693 |   68 |   15 |
|       8 |      128 |  7.744158168674 |  2.6107819954947 |   13 |    6 |
|      16 |        5 | 4.1289920559084 |  2.1392497037435 |    0 |    0 |
+---------+----------+-----------------+------------------+------+------+

Sin nunguna benchmark especifica, simplemente tal y como informa el cliente BOINC.

Ya que estamos, las sumas "pico" de los contactados en la ultima semana son 23.9 Teraflops, que naturalmente se reparten entre diversos proyectos BOINC y el hecho de que los usuarios tambien emplean el ordenador para ellos. El contacto en las ultimas 24 horas suma 16.7 Teraflops.

Respecto a las GPUs, no todas son de ultima generacion, tan solo la mitad son recientillas. Con estos datos se podria arguir que el uso inmediato de las GPUs multiplicaria por dos la potencia total de ibercivis, si un investigador nos pasa un codigo tan optimo que le sacamos 100 gigaflops a cada tarjeta, de promedio. Seria cuestion de ver como apañarse (openGL y openGLoquesea) para evitar el tener que hacer doble porting (triple, si tenemos que portar a ATI por separado). Lo cierto es que un factor dos no es despreciable, asi que es cosa de ir tocando a los investigadores a ver si tienen codigo disponible.

Incidentalmente, Anderson le esta dando muchas vueltas ultimamente a la medida de creditos y potencia:

http://boinc.berkeley.edu/trac/wiki/CreditNew

GPUs?

Nos preguntais en algunos comentarios por las GPUs. Lo estamos mirando pero no me decido. Las ventajas son claras. Los inconvenientes, el que necesita desarrollo aparte --no es tan trivial como decir gcc -target cuda-- y el que habria que ver cuantos participantes estan dispuestos a que las usemos... sobre todo por la noche cuando estan durmiendo y pongamos los ventiladores a todo tren. Un dato de interes seria saber cuantos apagan BOINC para jugar y cuantos lo dejan funcionando; precisamente el hecho de que los juegos usen sobre todo la GPU nos permite estar calculando mientras el usuario esta saltando de asesinato en asesinato por Venecia (bueno, vale, ese no esta para PC). En cambio, lo que es seguro es que como nos pongamos a usar la GPU en medio de un salto y se pare el juego a la siguiente nos echan.

Otra cuestion es como de realista es nuestra base de GPUs disponibles. De los 5098 ordenadores que se conectaron la semana pasada, 164 anunciaban tener CUDA ready para boinc y 55 anunciaban ATIs. El problema puede estar en que solo las versiones de BOINC mas recientes anuncian la disponibilidad de GPU. Podriamos lanzar una workunit especifica para comprobarlo de forma mas fiable.

como termina un job

como termina un job

Aqui seria interesante postular el modelo matematico y ver como encaja la curva. El caso es que esta semana hemos pillado a la vez dos terminaciones de jobs, que estaban calculados mas o menos para el verano. Ya lo he contado antes: un job no acaba de golpe sino que decae en lo que parece una exponencial, que depende de tiempos de caducidad y de duracion de las workunits. Cuando detectamos el modo de terminacion comenzamos a mandar cada seis horas una segunda copia de los trabajos que no han terminado, eso ayuda un poco. Si os fijais con lupa, se puede apreciar un poco despues de la medianoche del lunes y del viernes. No obstante, sigue siendo cierto que un trabajo de unas 20000 workunits tarda dos dias en terminar, eso haria mas apropiada la Grid que BOINC para los trabajos "cortos", digamos de hasta 64Kcpus. o Kprocesos.

¿Cómo evitar las paradas?

La gran cosa de que BOINC sea multiproyecto es que aun cayendo Ibercivis los clientes pueden seguir calculando en otros puntos hasta que volvemos a estar arriba. Ahora, ¿Como evitar estas caidas? No nos sirve da nada tener hardware de alta disponibilidad, porque lo que se desconecta son habitaciones o lineas de comunicacion completas. Por ello desde un principio optamos por nodos distribuidos, pero eso no resuelve el asunto.

¿Por qué? Porque si el scheduler (que podriamos tener duplicado en otro nodo) sigue activo, puede seguir recibiendo confirmaciones de entrega y mandando nuevos resultados. Y aqui tenemos dos problemas;

  • si al validador se le informa que hay datos preparados para validar pero estos han sido recibidos en uno de los nodos caidos, entonces el validador da un falso error de validacion.
  • si al cliente se le informa de una nueva workunit para calcular pero sus ficheros de input estan solo en una de las unidades caidas, el cliente no puede leerlas y se atasca.

Por ello, un sistema de ficheros distribuido es solo ser parte de la solucion y quizas ni siquiera la unica. Se puede retrasar el arranque de validadores a traves de un programa de control intermedio, el "transitioner". Y los datos de input se pueden duplicar desde el principio. Pero despues de más un año de funcionamiento no tenemos aun claro cual es la mejor idea para automatizar el proceso.

Transicion a modo vacaciones?

Transicion a modo vacaciones?

He aqui la grafica de results en ejecucion en estos ultimos dias. Causas hay: que se ha acabado el concurso, que se ha acabado el raid de CanalBoinc, y que empiezan las vacaciones. Espero que no haya ninguna averia colateral. A fecha de ahora no se pueden entregar, hasta el lunes, resultados de docking pero esa parada empezo el viernes de madrugada y no deberia atascar el proceso de otros subproyectos.

Durante el verano tenemos asegurado docking y bastante de materiales. Tambien comenzaremos a hacer pruebas de cara a una segunda fase de BOINC, con pseudocodigo para python o java, y tendiendo a facilitar a los investigadores la vida, vamos que el modo de trabajo se parezca mas a un cluster local.

Ajustes en las tablas y calendario de actuacion.

Un usuario tenia sistematicamente mas de 24 horas de CPU todos los dias. Tras examinar su configuracion y solicitarle datos de su maquina, el resto de las herramientas del sistema, incluido ps aux, tambien daban los mismos datos: porcentajes de utilizacion de CPU de hasta el 300%. Al parecer es un problema del nucleo de linux cuando esta a su vez multihilado, multinucleo y preemptivo... es un problema general, pero no demasiado. En Ibercivis, tan solo un una maquina de cada mil muestra "eficiencias" por encima del 100%.

En el caso que nos ocupa, las eficiencias muestreadas durante el mes de concurso han sido, en tanto por uno: 3.1, 3.47, 1.89, 1.73, 2.73. Hemos determinado pues aplicar a esa maquina un factor de correccion de 2.62.

Sí alguno de vosotros podeis reproducir el problema con fiabilidad (no hace falta tener Ibercivis ni BOINC, basta con fijarse en el ps, aunque puede que solo ocurra en procesos multihilo corriendo con un nice alto) nos gustaria tener noticias de ello. Me dicen los de grid que ya hubo un debate parecido cuando el Pentium 4 comenzo a incorporar funcionalidades multihilo.

En cuanto al resto de los concursantes, encontramos que cumplen la normativa, aplicadas las penalizaciones correspondientes. Con ello, el calendario que seguiremos sera publicar mañana las listas -provisionales- de la asignacion de boletos para los sorteos y de los premios directos, y publicar el dia 5 la lista completa de premiados para contactar con ellos. Os recordamos que en los casos de concursos locales hay que certificar la afiliacion.

Actualización: La distribucion preliminar por la ley de hont era erronea en el caso de los dos concursos individuales que la usaban y ha sido sustituida por la -esperamos- correcta. Y en los tres concursos, el orden era exactamente el inverso del especificado en las bases, asi que ha habido que republicar las listas corregidas. Al final de la jornada laboral se comunicará por email a los interesados su rango de numeros.

Explicación: El objetivo de las reglas de los concursos individuales era poder premiar la dedicación pero sin dejar de lado la potencia. Asi la dedicación al concurso, prestando atencion a que las maquinas esten activas, es lo que te da valor para entrar en el corte de sorteo de los diez primeros y una vez ahi el reparto corresponde a la potencia, usease el total de creditos.

Preparando los sorteos.

Hoy termina la fase de concurso. En los proximos dias se resolveran las reclamaciones y se asignaran numeros para el sorteo. La forma de asignar numeros sera el siguiente programita. Una vez ejecutado, comunicaremos publicamente y personalmente los numeros asignados para cada sorteo. Todo esto se anunciara en la web corporativa, aqui lo que os pongo es el codigo de reparto para que os hagais a la idea y aviseis si veis algun fallo Una salvedad: los comentarios dicen "crédito" pero como caracter general, como podrian ser "derechos", "votos", o en este caso horas y minutos de cpu.

#include
#include

// Se aplica la ley D’Hont para repartir NB boletos entre NP participantes
// atendiendo al número de créditos nc[].
// Se consideran todos lo cocientes nc[i]/n, con n natural, y se van asignando
// créditos por orden de cociente decreciente. En caso de cocientes iguales
// se da prioridad al que tiene un número de créditos mayor, y si hubiera
// coincidencia al que esté primero en lista.

#define NB 100000   // número de boletos
#define NP 10      // número de participantes

int nc[NP]; // número de créditos de cada participante
int nb[NP]; // número de boletos para cada participante

int main(void)
{
  int i,j,jmax,sum;
  double r,rmax;

  FILE *Finput;

  if ((Finput=fopen("lista.txt","rt"))==NULL){
    printf("No existe lista.txtn");
    exit(1);
  }

  for (i=0;i
    if (fscanf(Finput,"%d",&nc[i])!=1){
      printf("Sólo hay %d números en la lista de créditosn",i);
      exit(1);
    }
    nb[i]=0;
  }
 
  for (i=1;i<=NB;i++){
    rmax=0;
    jmax=0;
    for (j=0;j
      r=nc[j]/(nb[j]+1.);
      if (r>rmax || (r==rmax && (nc[j]>nc[jmax]))) {
    rmax=r;
    jmax=j;
      }
    }
    nb[jmax]++;
#if (NB<=10) // para debug
    printf("%2d %f=%d/%dn",jmax,rmax,nc[jmax],nb[jmax]);
#endif
  }
  sum=0;
  printf("Participante créditos  boletos     rangon");
  for (j=0;j
    if (nb[j])
      printf("%6d %13d %8d    %04d-%04dn",
         j+1,nc[j],nb[j],sum,sum+nb[j]-1);

    sum+=nb[j]; 
  }
  return 0;
}

Pequeña sobrecarga en recepción

Uno de los servidores de recepción se ha saturado y ha habido que pararlo. En breve levantamos un backup para que podáis devolver los trabajos. La validación de materiales y fusión estará parada hasta levantar el servidor principal. No os preocupéis por el tema de las horas, porque el tiempo lo contamos del día en el que el trabajo se recibe, no en el día en que se valida. Así que no pasa nada, si los resultados que devolváis hoy se validan mañana.

Propuesta de corte de tramposos

Al implementar la norma de que niguna maquina puede superar
las 24 de horas de CPU al dia se considerara que hay maquinas
que no estaran conectadas de forma continua, con lo cual un
dia podrian reportar menos de 24 horas y al siguiente mas.
Esto implica que el corte a 24 horas se realizara en periodos
no de un dia sino mas largos, en concreto hemos acordado que
cada dia se considerara el total de los 7 dias anteriores
de concurso; se comenzara pasada una semana del mismo.

Por otro lado, debido a los criterios de asignacion de creditos
a los jobs, al tipo de arquitectura de maquina y a otros factores
una maquina puede exceder ligeramente las 24 horas en un dia.
Por tanto en el periodo anterior de una semana, el tiempo en horas
de cada dia podra exceder de 24; hemos decidido que el tiempo
maximo por dia a efectos de media sea de 26 horas.

Dicho esto, el criterio de corte para eliminar maquinas con un
exceso de horas sera el siguiente.

Para cada dia y usuario se consideraran todas sus maquinas y tiempos
de CPU. De todas ellas, se considera la mejor.
Diariamente se sumaran las mejores maquinas de cada dia de los ultimos
7 dias.
Si la suma excediera de 26*7, se tomara la maquina con mas horas
de entre las consideradas para la suma y dicha maquina se reducira
a 24horas de forma definitiva.
Se procedera a realizar todo el proceso de nuevo. Si el numero de
horas resultara mayor de 26*7, se repetira el corte con la actual
maquina con mayor horas y asi sucesivamente.

Clientes nuevos que no pueden pedir trabajo (arreglado)

En primer lugar, sentimos las molestias que haya podido ocasionar. El problema ha venido de declarar obsoleto http://registro.ibercivis.es/, con lo que no se podía descargar la lista del schedulers. La lista ya está reparada y funciona correctamente.

En la web podeis encontrar en vuestra cuenta, subpestaña de "Gráfica personal", un desglose de vuestras máquinas y su aporte al concurso. De forma similar, en las clasificaciones se ha añadido un hipervínculo para poder consultar el tiempo de CPU aportado por cada máquina de los usuarios.

Implementacion de la regla de maximo de horas

La competicion de tiempo de CPU esta pensada para premiar la dedicacion, mas que la potencia, e incentivar la participacion de maquinas pequeñas. Asi, se dio la siguiente regla:

"Para cada participante se contabilizará el tiempo de CPU en trabajos validados en su ordenador durante el periodo del concurso. En caso de que un usuario posea más de una máquina, se le contabilizará únicamente la mejor máquina de cada día. Este tiempo se dividirá por el número de procesadores de dicha máquina. De esta forma, a plena potencia, nunca se producirá más de 24 horas de CPU al día."

El numero de procesadores se irá verificando durante el concurso y en el caso de detectar manipulaciones se procedería a descalificar al participante. La norma de no producir más de 24 horas al dia es un poco mas sútil porque, como se ha notado en otro comentario, el intervalo de producción no coincide con el de validación (que se hace en las máquinas de ibercivis, tras la notificación de entrega). Asi pues, lo que se aplicará, a partir del próximo lunes, es una verificación de media movil de siete dias, y en el caso de que algun participante tenga una media superior a 24 horas (con un pequeño multiplicador de correccion que calcularemos internamente) no se le contabilizara tiempo durante el dia siguiente. Si el exceso -sumados los siete dias- fuera superior al de un dia completo de trabajo, o si el fenomeno ocurre repetidamente, se aplicarian otras medidas punitivas.

Web en inglés y más contenidos

La web de Ibercivis (www.ibercivis.es) ya está disponible en inglés. Además, en la parte de "Estadisticas" podéis visitar nuevos contenidos con información acerca de los créditos y tiempo de CPU de los diferentes proyectos.

Ibercivis web (www.ibercivis.es) is now available in English. Moreover, in the "Statistics" section you will find new contents with information of the credits and CPU time of the various projects.

The web is in Spanish by default, so for non-English foreigners that want to visit the English version, please add English language in your language settings (below your own language, of course) on your navigator.