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.
Benchmarks: alguna sugerencia?
Como quizas sabreis, BOINC se calibra a partir de una variante de las tipicas prubas de velocidad WhetStone y DryStone. Durante este mes pienso lanzar, al menos a los voluntarios beta y a los participantes de concursos, algunas otras medidas de velocidad y no se como decidirme. De momento hay varios conjuntos que podrian sumarse:
- El High Performance Computing (HPC) Challenge de Dongarra et al, que extiende su clasico linpack.
- Las de Stefan Krause, derivadas del Computer Language Benchmark Game, y por ello adaptables a java y a python.
- Las de Kano, tambien orientadas a comparar C con Java. /
- SciMark2, que es para java (otra vez!) pero esta portada a C. Vease aqui
¿Se os ocurre alguna interesante?
Cotización de créditos
Ya están disponibles en la web de Ibercivis la información de cuántos créditos se dan por workunit, así como de un pequeño histórico de la evolución de dicha asignación.
Un link directo aquí
.