Preguntas frecuentes sobre ZIVIS (Blog de Zivis)
Se muestran los artículos pertenecientes al tema concurso.
26/04/2007
Disculpas por nuestra parte, y acuses de recibo varios.
Acusamos recibo de varias quejas, esta vez de la competicion por equipos (colectivos). Se quejan desde Hispalinux de la escasa explicación sobre el paron de ayer, en particular de que debido a su duracion la mayoria de los clientes BOINC bajaron su frecuencia de comunicaciones automaticas con el servidor y aunque no desconectaron del proyecto se quedaron virtualmente en pausa durante mas de 24 horas en algun caso. Quizas tendriamos que haber sido mas extensos en nuestra explicacion sobre los posibles efectos del paro, y nos disculpamos por no haber sido mas detallistas ni en el email semanal de notificacion ni aqui en el blog. En nuestra defensa, decir que el mecanismo es general del sistema boinc y no obedece a ninguna adaptacion especial de Zivis.
Tambien hay recibo de comentarios de los participantes del equipo AupaZaragoza.com, que se encuentran preocupados por las maquinas de la universidad que han pasado recientemente a sumarse en softwarelibre_zgz y queremos de antemano pedir disculpas por nuestra escasa capacidad de maniobra respecto a estas operaciones. Al respecto, el reglamento que nos autoimpusimos -publicado tres dias antes de comenzar el concurso- dice que "Para la participacion individual no se consideraran los creditos recibidos desde ordenadores situados en las instituciones organizadoras. Por otra parte, y dado que estas instituciones promueven el asociacionismo en algunos ambitos, sí que se contabilizaran para la participacion colectiva". Pero no nos hemos dotado de herramientas para hilar mucho fino en la cuestion de cuando se esta promoviendo el asociacionismo; lo unico que hemos aclarado, y anunciado en un post anterior, que las Facultades y Escuelas como tales no forman asociaciones y no participan de los premios para colectivos. Nos gustaria --y sabemos que al final ocurrirá asi-- que se impusiera un cierto sentido etico en cada participante, acerca de en qué manera se esta integrando un colectivo y del por qué. Por ejemplo, no parece adecuado que softwarelibre_zgz acumule puntos a partir de sistemas operativos propietarios, por mucho que los managers de estos sistemas hayan querido asi manifestar su apoyo al software libre; más bien desvirtua el proposito del grupo. Nosotros mismos en Zivis hemos hecho un esfuerzo para no depender de software propietario ni siquiera en el desarrollo de las aplicaciones Windows (usamos compilacion cruzada desde Linux).
En cualquier caso, y para que esten las cosas visibles para todos, la pagina web
http://zivis.bifi.unizar.es/ranking/full.php
tiene ahora una tercera seccion en la que se listan las maquinas que, aunque excluidas de lo individual, podrian estar o estan participando en colectivos.
Ya que hemos ojeado el reglamento, convendria subrayar algun detalle que puede ser fuente de complicacion. La puntuacion de un colectivo se juzga y suma "al final de la fase de concurso". Lo que significa que al igual que los cambios de adscripcion han traido puntos a los colectivos, estos puntos pueden restarse mediante el simple procedimiento de abandonar la adscripcion. Por supuesto, en el caso de participantes que tambien tengan derecho a aparecer en los listados individuales, ese abandono a partir de ahora (de mañana 27 a las 11 para ser concretos) les supondra tambien la penalizacion de perder la puntuacion individual acumulada. Notad ademas que en general a partir de mañana consideraremos cualquier cambio en la pagina de datos personales un "cambio de usuario", a no ser que sea evidente que se trata de una correccion de erratas y en este caso se nos tendra que notificar de antemano; esto afecta tambien a un punto de la normativa individual: el ajuste a cero de los ordenadores que "cambian de usuario".
20/04/2007
Tiempo de CPU II
Efectivamente los tiempos de CPU todavia no estan siendo muy precisos, el limite de 300 creditos era demasiado bajo.
Un participante, Jesus, ha propuesto como ejercicio que le echemos un vistazo al host 2242 que ha sido evaluado con 7 dias y no parece que pueda tenerlos. Y no los tiene. Veamos
Lo primero sacamos del backup todos los resultados que han sido retirados de la base de datos activa por llevar mas de cuatro dias sin alteracion. Estos resultados estan en xml (lo pongo sin los brakets porque blogia los quita):
result_archive_1176991725.xml: result_archive
result_archive_1176991725.xml: hostid 2242 /hostid
result_archive_1176991725.xml: sent_time 1176648072 /sent_time
result_archive_1176991725.xml: cpu_time 1.937385820000000e+02 /cpu_time
result_archive_1176991725.xml: validate_state 1 /validate_state
result_archive_1176991725.xml: /result_archive
etc. En total ese host tiene 84 resultados con validate_state = 1 y sent_time > 1176368365 (el momento de inicio, asi a ojo porque para este ejercicio no lo he buscado en los logs). A esos hay que sumarle 168 resultados validos que estan vivos en la base de datos y son los que vosotros veis en las busquedas (en este caso, SELECT hostid, sent_time, validate_state, cpu_time FROM Zivis.result WHERE hostid=2242). Sumando ambos sectores, tengo 136915,6550450+296006.125904 segundos. Por tanto con exactitud son 5,01 dias de cpu_time y no los siete con los que aparece en el listado.
¿que ocurre? Que el listado, que por algo tiene la palabra "provisional", se calcula mediante un metodo mas rapido que es estadistico. Este metodo comienza a tener validez a partir de muchas horas de cpu acumuladas. Por otro lado es el metodo estandar de BOINC, y no nos hemos atrevido a tocar el codigo fuente para implementar la suma directa, nos limitamos a guardarla y como os digo, a partir de las dos semanas verificaremos con mucho cuidado si el metodo estadistico y la suma coinciden. De momento la primera medida de precaucion fue no admitir a la lista rapida nadie que no tuviera mas de 300 creditos; esta visto que pusimos este limite demasiado bajo, pero en caso contrario las oscilaciones habrian sido mas descaradas.
En resumen, las alternativas eran: a) modificar la base de datos y el codigo de validacion de BOINC para tener el rastro exacto de la CPU en todo momento. b) mantener todos los resultados en la base de datos para poderlos sumar de golpe en cada consulta. c) confiar en el metodo estadistico de BOINC, que lleva años en funcionamiento, y verificar contra los backups. Descarte (a) porque no me atrevi a tocar el codigo de validacion en otros puntos diferentes de los que ya tenemos que tocar para la aplicacion nuestra, y descartamos (b) porque mysql petaria si no sacamos los resultados caducados hacia el backup. Asi que por eliminacion estamos bailando con c. Si despues de dos semanas el metodo estadistico falla entonces sacaremos un script que haga automaticamente lo que acabo de hacer a mano, pero entonces los resultados no seran instantaneos sino que habra que calcularlos cada 6 horas como mucho.
Por cierto, me parece que legalmente (ley organica de proteccion de datos) teneis derecho a pedime que os envie los logs correspondientes a los datos de los cuales seais propietarios... pero porfa de momento no me agobieis en esto, que hay mas cosas que hacer.
Alejandro
18/04/2007
Tiempo de CPU
En estos días se ha podido ver cómo gente que no aparecía en la clasificación por tiempo de CPU ha dado unos saltos enormes en el tiempo o ha aparecido de repente.
El motivo por el que esto ocurre es porque para entrar en la esa lista, se está considerando un mínimo de 300 créditos. Como la cantidad de créditos que se otorga a un trabajo depende de la potencia del ordenador que los realiza, pueden encontrarse situaciones en las que alguien que lleve 5 días con el ordenador encendido a tiempo completo no aparezca de la lista y luego aparezca de repente.
Imaginemos alguien, un usuario A con un ordenador último modelo, por darle un nombre, supongamos que tiene un Core2 Duo, a 3 GHz. E imaginemos a otro usuario B con un ordenador muy viejo, un Pentium III a 1.2 GHz, por ejemplo. ¿Qué ocurriría?
Que debido a la mayor potencia de cálculo del usuario A, podría acumular estos 300 créditos en poco tiempo, 1 día, por ejemplo, entrando en la clasificación con 1 día de CPU y contando a partir de ese punto. El usuario B, sin embargo, no reuniría los 300 créditos mínimos hasta los 6 días, por ejemplo, entrando en la clasificación de repente, con ese tiempo de CPU.
En la gráfica adjunta se intenta aclarar un poco más la idea.
María
14/04/2007
Offsets del concurso
A peticion popular, he aqui un dump del offset de creditos calculados a las 11 de la mañana del dia de comienzo de concurso.
http://zivis.bifi.unizar.es/offsets.txt
En las clasificaciones en la pagina municipal, las del concurso, este offset aparece ya restado. En las estadisticas estandar BOINC, en atencion a los no concursantes, los creditos son los totales desde que empezo el concurso, sin restarlo.
Los creditos y las horas de CPU son *validados*. Esto es, no se contabilizan hasta que el resultado coincide con el enviado a otra maquina. Asi no os extrañe que en diez minutos uno pueda incrementar una hora su CPU, porque es simplemente resultado de que se ha recibido el resultado que la valida.
10/04/2007
Reglamento del concursico
Como veis en la pagina principal, hemos finalmente parido el reglamento del concurso. Lo importante es que se cuentan los creditos desde el dia 12 de abril y estamos a 10, asi que los que vean que su configuracion actual les perjudica tienen un par de dias (bueno, unas horas menos) para ajustarse. Como en cuarenta horas no da tiempo a que los grupos se pongan de acuerdo, estos tienen hasta el 25 de abril para juntarse y escindirse sin penalizacion.