Preguntas frecuentes sobre ZIVIS (Blog de Zivis)

La semana pasada varios miembros del BIFI estuvimos a IBERGRID, un congreso celebrado en Santiago de Compostela que reunió a más de 200 expertos en computación. Allí presentamos Zivis con notable éxito y pudimos comprobar la gran repercusión que el proyecto ha tenido a nivel nacional. También pudimos ver el trabajo de otros grupos en computación voluntaria, como las experiencias de compañeros de la Universidad de Extremadura para introducir la virtualización en sistemas BOINC.

Más información:
http://www.ibergrid.eu
---

Un video de la presentacion inicial en el Ayuntamiento

Presentación de Zivis en TVE1

Zivis. A Ciencia Cierta. Aupazaragoza.com

Zivis en Cuatro. 17-05-2007. Noche

Ahora que estamos mas relajados me he dado un paseo hasta la biblioteca y resulta que habia en el Investigacion y Ciencia un articulo sobre robots por Bill Gates. Ya hablaron de ello en Barrapunto, pero el 30 de Enero, y en ese momento ya no estaba yo (no estabamos, me temo, nadie del equipo) para lecturas de ocio. El caso es que el articulo trae una foto en la que aparecen juntos el Lego Mindstorms y la Roomba. En el caso de Zivis, la primera idea de la categoria "geek" era una Roomba pero, al ver que era dificil traer un ultimo modelo desde USA, se opto por dar un Mindstorms y un Fischertechnik. Incluso pusimos links en la pagina de premios, convencidos de que el Fishertechnick no lo conocia nadie.

Pues bien, el post de Barrrapunto envia a la pagina de robotica de microsoft y alli, lo gracioso es que hay el parrafito dice "Microsoft Robotics Studio is compatible with many third-party robots, including those from fishertechnik, LEGO, irobot, and many others including:...". Sospecha uno que los "many others" son los que han pagado a MicroSoft por salir alli, y los otros los que tienen ya el prestigio ganado.

Asi que ya veis, estamos regalando, despues de todo y sin saberlo, tecnologia a la ultima... recomendada por el propio Gates. En realidad el Lego se programa con una version de LabView, que es un software que se invento para el Macintosh II (de hecho, para el Plus, pero el Mac Plus solo tenia puertos serie). Y el fishertechnik creo que ha llevado de siempre software propio, aunque yo he visto a Daniel Fernandez de Velasco desarrollar controladores desde VIC-20 y Mac para controlar el suyo. Habra que ver si Cuartielles nos cuenta algun dia como controlarlos con Arduino y su soft.

Alejandro

    Un monton, en flickr

 http://www.flickr.com/photos/_bifi_/

Quedan unos pocos dias de calculo para equilibrar el numero de trayectorias calculadas de cada tipo, y luego el proyecto quedara seguramente al ralenti a la espera de mas codigo que correr. Tambien la dedicacion al blog sufrira este ralenti, pero todavia hay unos dias para hacer cosas. Quizas podriamos sacar algun listado de potencia por marcas, a ver a igualdad de OS como queda el comparar Intel contra AMD. Quizas podriamos lanzar un Linpack en modo BOINC autentico, para comparar potencias teoricas y reales.

Actualizacion: de momento, vamos redondeando D0 y D1, que tienen tan solo unas 141898 trayectorias cada una, un orden de magnitud menos que las famosas A0 y A1, y la mitad todavia de las C0 y C1.

Mas actualizacion (16 de Mayo): llevamos  168763 D1,  y la idea es acercarnos lo mas posible a las C1, que son 263195, o a lo que quepa en el disco (que esta al 90% pero es de los grandes), asi que seguira corriendo al menos hasta el viernes y cerraremos jobs en algun momento del fin de semana, dejandolo encendido para que lleguen los retrasados (ahora esta a dos dias de tiempo). Hay que tener en cuenta que la velocidad de recogida actual es pausada, un poco mas de 10 trayectorias D1 por minuto.

Como ya hemos activado Zivis, en la pagina de estadisticas podeis ver clasificaciones a 11:00 am. Tened en cuenta que hay un proceso de eliminar repetidos y no participantes, asi que la lista definitiva saldra por la tarde en otro documento, a falta del premiado via sorteo.

La lista esta medio construida en http://zivis.bifi.unizar.es/premiados.html. Actualizacion: No han hecho falta mas suplentes, Beatriz ya ha construido la lista y ha llamado a todos los premiados, pero como el mantenedor de la web ha estado todo el dia de un lado para otro con recados varios no ha podido actualizarla en la web. Se publicaran los nombres, apellidos y regalo de todos los clasificados no tanto porque haga falta (ya estan contactados por telefono) sino porque el proceso es publico y hay una entrega publica.

A los premiados individuales se les va a pedir 1) identificacion 2) forma de contacto y 3) que nos envien por email una lista de su orden de preferencia de todos los regalos de la bolsa de premios (la que esta en premios.html) de manera que no tengamos que estar recontactando a todos en cada deslizamiento que se produzca.

Actualizacion. Ya se ha producido el sorteo de la ONCE. Asi que el afortunado de categoria C y los dos primeros suplentes serian:

Ganador: Numero: 75438 Participante: 820 puturru

Suplente 1, Numero 05647 : Participante : 62 Horsu

Suplente 2, Numero 22035 : Participante : 240 iber

Actualizacion: seguimos sin localizar a unos cuantos participantes de la parte media de la tabla. Si alguien los conoce, que les avise porque el tiempo se les acaba el viernes a las 11:00 am.

Son: puturru turbo DURAN ARA thanis schamann jmfg josemimf Francisco entropia437 2769485

De la parte cientifica viene una explicacion mas detallada de A B C D:

Estamos tratando de estudiar varios aspectos del confinamiento para diferentes tipos de plasmas que se pueden crear en TJ-II. Están caracterizados por diferentes perfiles de densidad, temperatura y campo eléctrico. La observación más directa que se puede hacer es medir el tiempo de confinamiento, es decir, el tiempo promedio que un ión permanece dando vueltas a TJ-II antes de escapar por efecto de las derivas. Un paso más consistiría en estudiar más en detalle cómo se produce este fenómeno de transporte: estudiar cómo son los flujos de iones en el interior de TJ-II. También una información relevante, de la cual se puede extraer el máximo partido mediante nuestro visualizador 3d, es dónde chocan los iones con la cámara de vacío de TJ-II.

Los plasmas A y B son del tipo ECH (electron-ciclotron resonance). En ellos, los electrones que forman parte del plasma son calentados mediante un haz de radiación microondas. De este modo, se consigue una temperatura electrónica alta. Estos electrones a su vez están en contínuo contacto con los iones, y al colisionar con ellos, les comunican parte de su energía. De este modo se consigue aumentar la temperatura de los iones, o temperatura iónica. Como la densidad de este plasma es pequeña, estas colisiones ión-electrón no son muy frecuentes, y los iones no se calientan demasiado.

El plasma C es de mayor densidad. A estas densidades, la radiación penetra poco en el plasma, de modo que el calentamiento por ECH no es eficiente, y se complementa con inyección de neutros (NBI, neutran beam inyection). El procedimiento consiste en lanzar átomos neutros a gran energía al interior del plasma, estos átomos colisionan con iones del interior y les comunican parte de su energía. De este modo, la velocidad media de los iones, y por tanto la temperatura iónica, aumenta. La temperatura electrónica, por el contrario, será baja.

En estos dos casos, el potencial eléctrico en el interior presenta un mínimo en una región intermedia del plasma. Esto hace que el campo eléctrico frene en parte los iones que están saliendo del plasma por efecto de las derivas,
lo cual contribuye a mejorar el confinamiento. Este campo eléctrico que se mide en TJ-II es el creado por el conjunto de iones y electrones en del plasma

El plasma D es todavía de mayor densidad. Para esa densidad de partículas, el calentamiento por ECH no es posible, así que se realiza todo mediante NBI. En consecuencia, la temperatura electrónica será la más baja de los tres casos. En este plasma, el campo eléctrico apunta siempre en la dirección del punto más interno.

De acuerdo al reglamento la tercera plaza del concurso se asigna al azar entre aquellos participantes que hayan aportado al menos 10 creditos. Esto implica que necesitamos un metodo para, partiendo de una semilla aleatoria publicamente verificada, elegir un participante entre aquellos que estando numerados en la primera columna de la lista individual esten tambien por encima de 10 creditos (por cierto si alguien no se encuentra en la lista o no tiene numero y deberia tenerlo solo puede ser porque se ha registrado incorrectamente; nos tendria que avisar por email rapidamente antes de mediodia de este lunes). La semilla publica mas obvia es el sorteo de la ONCE que son 100 000 posibilidades y hay que repartirlas equitativamente entre los mil y pico participantes listados.

Este es un tema que no controlamos demasiado, pero a una semana del final oficial de esta fase de Zivis puede ser interesante hablar no solo de nuestro supercomputador sino del resto de los proyectos BOINC que corren por el mundo, de si funcionan o no, y de como suscribirse a ellos. La idea es que incluso si Zivis continua (ya veis en el programa de actos del sábado que hay una mesa de trabajo sobre este asunto) es posible que pase por fases de mas o menos demanda, como le pasa por ejemplo a LHC@home. Y siempre esta el asunto de tener algo que calcular cuando hay un atasco como el de ayer; de hecho hemos notado que las maquinas que estan en varios proyectos internacionales parece que reaccionaron mas rapido a la hora de reconectar. Por otro lado una maquina que esta en varios proyectos aporta menos a Zivis. Egoistamente prefeririamos que los "locales" tuvieran un setup de 1000% en el "Resource Share" de las "Zivis Preferences" (aqui ).

Los primeros lugares para empezar a mirar otros proyectos a los que unirse son los webs de estadisticas, por ejemplo http://www.boincstats.com/ A partir de alli una buena pista es http://canalboinc.com que incluso tiene en sus foros un ranking de otros teams hispanos.

Quizas los miembros de teams hispanos podrian hacer un poco de propaganda aqui acerca de como unirse a su team y por qué. O quizas podriamos empezar creando un team "[zivis]" (o "[I survived Zivis]" ) para todos los que se agregaran a otros proyectos y no esten adscritos a ningun team.

[04/May/2007:13:48:15 +0200] es la fecha que marca la ultima conexion apache. A las cinco entro a mi turno de tarde y ¡horror! no hay conexion, y la hora es la sospechosa de que algun operario en algun sitio haya dado "off" a un interruptor y se haya ido de fin de semana.

En media hora ya nos hemos convencido de que el error esta en el sistema que enlaza Zivis con la universidad, y que es un link de fibra optica adelantado por Telefonica para el proyecto (un equipamiento ya previsto para la universidad y que nos ha venido muy bien hasta ahora) y unos switches administrados por el SICUZ. Usease que somos tres entidades. Para mi sorpresa todos han reaccionado bien, pero aun asi no hemos encontrado la averia. Nuestros contactos en telefonica han llamado a un tecnico para que midiera los enlaces de fibra a la busqueda de algun corte, y el operador de guardia del SICUZ ha revisado su parte y ha esperado hasta las nueve de la noche a que Telefonica dictaminara (El mayor retraso ha sido conseguir aparcar la furgoneta de Telefonica en Corona de Aragon a las siete y media de un viernes). Pero no hemos encontrado averia en las lineas y no hemos encontrado ningun fallo de configuracion de los equipos (ni nadie que los estuviera manipulando a las dos menos cinco). Y el cable parecia recibir la señal laser tanto de ida como de vuelta, pero indicaba que la transmision estaba caida.

Asi que al final hemos tenido que admitir derrota y pasar al plan de backup, y esperar al lunes para ver si hay fallo de hardware en alguna parte de la ruta. El plan de emergencia es un link inalambrico en vez de uno de fibra, asi que nos quedamos limitados no se si  a 54 Mbits/s o a 27 Mbits/s de entrada de datos y, para felicidad de los sufridores de ADSL, no nos podemos permitir experimentar mucho mas con nuestros superficheros. Sobre todo si tras el fin de semana hay que repartir ese ancho con los usuarios/investigadores del BIFI, que tambien querran poder navegar y leer el email.

El link de emergencia utiliza diferentes IPs, asi que aunque a las nueve y media habiamos levantado ya el sistema, la propagacion del cambio puede haber tardado hasta un par de horas, dependiendo del proveedor de servicio. Afortunadamente hoy en dia ya muy pocos proveedores mantienen caches de IP demasiado largas (con eso del comercio electronico un envenenamiento de DNS puede salir caro).

No ha sido un alarde de rapidez : 3 horas para darnos cuenta (las de la comida) y 4 horas para arreglarlo. Podriamos haber saltado al plan de backup en una hora, claro, pero si hubiera resultado que un click en algun sitio bastaba para arreglarlo habria habido dos cambios consecutivos del registro de DNS, o habriamos tenido que hacer y deshacer rutas provisionales. Asi que hemos alargado lo mas que hemos podido la decision hasta que todo lo que se podia verificar habia sido verificado. Insisto, hay que agradecer la reaccion y paciencia de nuestras contrapartes, tanto Telefonica como Servicio de Comunicaciones de la Universidad.

En la imagen se ve como ha ido el ancho de banda en las ultimas horas hasta el momento del corte. Ayer pausamos por la noche el envio de datos graficos, por si acaso, y lo habiamos vuelto a arrancar por la mañana.

Resumen: en principio, esta todo arriba y funcionando. Las IP de los servidores han cambiado, asi que algunos proveedores tardaran en borrar la cache y encontrar las nuevas IP, o quizas pasa lo mismo en la cache local. En cualquier caso en algun momento de la noche esto caducara y las maquinas volveran a encontrarnos. Algunas ya nos encuentran, asi que por nuestro lado creemos que esta bien.

Nos sugiere un participante que una forma de equilibrar el trabajo ahora que hay tareas muy dispares (poco/mucho ancho de banda, en particular) es solicitar mas trabajos de golpe. Esto es mediante una preferencia general de usuario, en
http://zivis.bifi.unizar.es/prefs.php?subset=global
llamada "Connect to network about every"... y que determina cuantos segundos de trabajo se piden al servidor; hay tambien un maximo de trabajos que se mandan, eso lo controlamos nosotros para todo el proyecto, asi que por mucho que lo subais no recibireis mas de 9 trabajos en una tanda. Pongamos que esos nueve son cinco de los de media hora y cuatro de los de cinco minutos... un intervalo de dos horas y media seria entonces razonable, y ese es el 0.1 dias que se suele sugerir en los defaults. Si teneis una maquina mas lenta, podeis subir el intervalo, pero si lo subis demasiado nos arriesgamos a que el cliente pase un tiempo sin trabajo para ejecutar.

El caso es que este truco permite asegurarse de que seguimos calculando mientras se produce el upload de los ficheros grandes de 250 MB. Pero claro, podria tener el inconveniente de requerir demasiado espacio en disco si se reciben dos o tres de los trabajos que generan estos ficheros.

Hemos mandado un email para recordar que la entrada del teatro romano hay que recogerla anticipadamente. Los de PlanetPC se han ofrecido voluntarios para hacer el reparto; si no habeis recibido el email eso es que no estais en la lista, y si no estais en la lista eso es que no os habeis identificado correctamente en el blog municipal. Y si os identificais ahora, se pierden los creditos de fase de concurso (lo cual no es grave si no estais compitiendo, claro) y de todas formas ya hemos bajado el listado a la tienda. Asi que si pensais venir y no os hemos mandado un email ni estais en la lista de PlanetPC escribidnos a zivis@unizar.es y veremos que se puede hacer.

Hay que reservar un tramo horario, por eso del aforo. El programa estara disponible en la web municipal.

Los premios estan expuestos en la tienda, pero os recuerdo que estaban tambien listados en http://zivis.bifi.unizar.es/premios.html .

El paron de comunicaciones del jueves puede ser una oportunidad para que la gente intente encontrar y copiar sus ficheros *_5 y visualizarlos. A tal fin hemos creado un grupo en Flickr:

http://www.flickr.com/groups/boinczivis/pool/

y tambien las tags BOINC zivis, usease

http://www.flickr.com/photos/tags/boinc+zivis/

pero no se por que esto no es instantaneo, en cambio añadirse al grupo y luego enviar las imagenes al grupo resulta casi automatico

Si alguien obtiene una imagen interesante y no tiene cuenta en Flickr, tambien nos la puede mandar directamente a zivis@ unizar es con el subject "foto para el blog" o similar, y nosotros mismos podemos subirla.

Es recomendable experimentar con C0 y no con C1, porque las de C1 son muy grandes. En el caso de caer en la tentacion, siempre se puede truncar el fichero original o el output del od, usando las instrucciones head y tail de unix, o cosas asi.

Ha llegado el siguiente email, y como estamos en veinte ajos a la vez no hemos llegado a contactar con el SICUZ a ver en que nos afectaba y cuanto tiempo:

From: "Pedro Pardos Alda" 
To: , 
Date: Fri, 27 Apr 2007 13:39:46 +0200

 Vuelvo a dirigirme a ti para recordarte que el próximo jueves  3 de mayo está previsto parar  todas las máquinas instaladas en el Centro de Proceso de Datos del SICUZ.

Ello significa que se interrumpirán la gran mayoría de los servicios informáticos y de comunicaciones incluyendo el acceso a internet, todos los servicios de gestión universitaria, el correo electrónico, los servidores de páginas web o los servidores de ficheros e impresión. Se intentará mantener la continuidad del sistema telefónico global de la Universidad pero pudiera haber algún corte, en especial en la comunicación entre centrales y en el acceso al exterior de la Universidad.

La máquinas comenzarán a pararse a las 7:00 horas y esperamos haber recuperado la normalidad aproximadamente a las 12:00 horas.

El motivo de esta interrupción del servicio es realizar modificaciones en la instalación eléctrica del CPD que posibiliten la conexión de los servidores recientemente adquiridos a la vez que se mejora dicha instalación dotándola de mayor seguridad y fiabilidad. Lamentamos las molestias que esta interrupción pueda ocasionar pero, por un lado es inevitable apagar todas las máquinas para modificar la instalación eléctrica y, por otro, es complejo encontrar un momento de mínimo impacto habiendo que coordinar las actuaciones de todas las personas que pueden llegar a intervenir (personal propio, de la UTC, de empresas suministradoras, de RedIRIS, etc.) así como de las aplicaciones informáticas sometidas a plazos de ejecución inalterables (como por ejemplo la nómina)

Reciba un cordial saludo

El primer paso para ver una trayectoria es encontrar un fichero lgv3t_conTr_C0_xxxxx_5 que este terminado pero no lo hayais mandado aun. Un truco es detener comunicaciones mientras se enreda con esto para asegurarse que el fichero no lo acaba enviando boinc y lo perdemos a mitad del juego.

El segundo paso es conseguir que el formato pase a ser ascii. El fichero es una secuencia de vectores (X,Y,Z,v) en floats (de 4 bytes, por tanto 16 bytes por dato) y ademas tiene un vector cero cada 1000 pasos. Un truco en unix, aprovechando que la linea es de 16 bytes, es usar directamente od -An -tf4 lgv3t_conTr_C0_30-06-27-15-84_0_5 | grep -v 0.000 Ya lo siento Razorblade, pero desde windows tendreis que buscaros algun otro comando o escribir un programita de pasar binario a texto.

El fichero texto producido se puede poner directamente en gnuplot. De hecho en unix no se necesita ni usar un fichero de texto intermedio. Podemos llamar a gnuplot y dar por ejemplo la orden

gnuplot> splot ’< od -An -tf4 resultados/lgv3t_conTr_C0_30-06-27-15-84_0_5 | grep -v 0.000’ using 1:2:3

y esa linea hace todo el trabajo! Ademas, es posible rotar la imagen con el raton.

    Estamos  lanzando un pequeño batch de tareas con dibujo completo de la trayectoria (no en el salvapantallas, sino en disco duro) a ver como reaccionan los equipos. Eso significara un aumento apreciable del uso de disco duro y un aumento apreciable tambien, sospechamos, del uso de ancho de banda de upload. A los que necesitan ese ancho de banda les puede convenir ajustar las preferencias en las paginas web de configuracion (no en las del ayuntamiento, sino en las de zivis.bifi.unizar.es).

De momento ya hemos visto que las trayectorias mas largas no tenian suficiente disco duro asi que habra un par de RESOURCE LIMIT EXCEEDED o algo asi en los logs.

Por cierto el fichero que se crea en disco se puede visualizar con el GNU Plot. Luego mas tarde os lo contamos, si quereis. 

El crash de esta madrugada ha sido un asunto interno nuestro, tan solo agravado un poco por la velocidad de respuesta. El validador nuevo se quedaba calado y aunque el cron lo relanza cada cinco minutos eso solo servia para revisar unas pocas workunits antes de cascar de nuevo. El motivo: un acceso a puntero nulo.

Fragmento de codigo:

retval = get_output_file_paths(result, output_file_names);
int noutputs = output_file_names.size();
fprintf(stderr, "Hay %d outputsn",noutputs);

fprintf(stderr, "Accedo al primer fichero---------------------------n");
if (retval) return retval;
fprintf(stderr, "Accediendo al fichero %sn",output_file_names[0].c_str());
... = try_fopen(output_file_names[0].c_str(), f, "r");

¿Lo veis? cuando no hay ficheros en el resultado, retval no devuelve error, y simplemente noutputs vale 0. Pero claro, como solo nos preocupamos de retval nos vamos a la lineas siguientes y voila, intentamos leer un campo de output_file_names[0], que por supuesto no existe. De hecho, el sistema se queda colgado antes de try_fopen, en el fprintf del log.

Luego un poco mas adelante el problema se repite, cuando analizamos el siquiente fichero de la respuesta sin asegurarnos de que noutputs > 1:

fprintf(stderr, "Accediendo al fichero %sn",output_file_names[1].c_str());
retval = try_fopen(output_file_names[1].c_str(), f2, "r");

El problema de fondo ha sido que en el diseño de este nuevo validator ya nos conociamos BOINC lo suficiente, creiamos, para estar seguros de que si todos los ficheros obligatorios no estaban presentes el resultado nunca seria "Success" y por tanto no entraria ni siquiera a validacion. Y hemos visto ahora que no, que en algunos casos (un centenar teniamos ahora en la base de datos) se nos entrega solo un fichero o ninguno, con los datos incompletos, y que a pesar de eso el client state afirma ser "Success". Por cierto que estos casos tienen una pequeña interseccion con otros de los que se quejaba J, aquellos de CPU cero o muy corta. Asi que en quitando el bug y verificando no solo la existencia del primer fichero sino tambien de los restantes es bastante posible que estemos matando dos pajaros de un tiro.