Se muestran los artículos pertenecientes a Junio de 2009.
Resumen
- 01/06/2009 10:54 - Ajetreo de concursos
- 01/06/2009 16:41 - Cotización de créditos
- 01/06/2009 18:22 - Benchmarks: alguna sugerencia?
- 03/06/2009 13:50 - Web en inglés y más contenidos
- 03/06/2009 19:12 - Implementacion de la regla de maximo de horas
- 05/06/2009 11:25 - Clientes nuevos que no pueden pedir trabajo (arreglado)
- 09/06/2009 11:05 - Propuesta de corte de tramposos
- 09/06/2009 12:29 - Pequeña sobrecarga en recepción
- 30/06/2009 20:45 - Preparando los sorteos.
Ajetreo de concursos
Hoy es un dia ajetreado. Estamos añadiendo a los equipos que piden participar en los concursos, pero no os preocupeis que todos cuentan desde el punto de inicio del concurso, esto es desde hoy a la una. Me explico: hemos arrancado con todas las unidades recibidas a partir de las 01:00 del 1 de Junio, y recogeremos todo lo que se entregue hasta las 24:00 del dia 30. Esta era una de las alternativas posibles; internamente habiamos discutido otras para manejar el problema del trabajo acumulado del dia anterior, en particular habiamos pensado no dar creditos durante las horas previas al inicio de concurso pero ello habria afectado a las BoincStats de los no participantes y a otros desafios.
Hay alguna sutileza mas, sobre todo en el tiempo de CPU: se divide por el numero de cores, lo que afecta a los de muchos nucleos (que a cambio tienen mejor posibilidad en los equipos por creditos) pero ayuda a los que estan en casa poniendo atencion. Y cuando hay varias maquinas de un solo usuario se cuenta la mejor CPU de cada dia, que no tiene por que ser la misma. Finalmente, en muchos concursos el tiempo de CPU no fija el orden absolutamente, sino el derecho a entrar en el sorteo de los premios.
Tenemos pendiente bastante cosa que ira saliendo durante el dia: fijar los creditos de las aplicaciones y el anunciarlos dia a dia, informar de la duracion esperada y media de cada aplicacion, y añadir mas informacion general sobre el estado del sistema. Ademas de traducir al ingles. De hecho cuando traduzcamos al ingles desaparecera la pagina "de plantilla BOINC" y redirigirá a www.ibercivis.es.
A ver que tal se nos da el mes. Un saludo,
Alejandro.
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í
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?
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.
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.
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.
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.
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.
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;
}

