Blog de Ibercivis

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.

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.

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.

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.

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;
}

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.

Etiquetas: Deuvedé, caidas

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.

Etiquetas: Deuvedé, concurso

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.

Etiquetas: Deuvedé, software, web

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.

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.

Etiquetas: Deuvede, web