Lo primero, pido disculpas por no postear antes con esto. Estos días hemos días hemos estado levantando la máquina que se cayó a principios de mes y no ha habido día que no haya pasado algo.
Esta aplicación, con Protomol, son aplicaciones con las que colabora el CSIC. La aplicación de nanoluz investiga acerca de la transmisión de luz a escalas nanométricas.
---[version française ci-dessous]---
---[version francesa más abajo]---
Como ya llevamos unos cuantos días de competición entre estos dos importantes grupos os mostramos aquí la evolución de los créditos de cada uno de los grupos desde el 20 de Junio (día cero en el eje de las x). La gráfica es elocuente de cómo ha sido la evolución de cada grupo.
También se pueden ver dos incidencias leves: en torno al día 23 se ve un pico debido a un error de validación que fue luego corregido y en torno al día 132 se ve una zona plana que se corresponde con unos días en los que no se validaron los resultados.
Esta competición está siendo muy interesante para el proyecto Ibercivis . Todos queremos agradecer la colaboración y la participación de ambos equipos que ha significado un aporte muy importante de maquinas y CPU para el proyecto.
¿Quien ganará? En este caso todos ganamos.
---[version française]---
---[version francesa ]---
Il y a quelques jours la compétition entre ces deux importants groupes a commencé. L’Alliance Francophone VS CANAL@Boinc. Nous vous montrons ici l’évolution des crédits de chacun des groupes depuis le 20 juin (jour zéro dans l’axe des abcisses). Cette courbe est éloquente de comment elle a été l’évolution de chaque groupe.
On peut aussi voir deux légères incidences: autour du jour 23 on voit un pic correspondant à une erreur de validation qui a été ensuite corrigé et autour du jour 132 on voit une zone plate qui se correspond avec des jours où on n’a pas validé les résultats.
Cette compétition est très intéressante pour le projet Ibercivis. Tous nous voulons remercier pour la collaboration et pour la participation des deux équipeeqs qu’a signifiés un apport très important machines et de CPU pour le projet.
Qui gagnera? Dans ce cas nous gagnons tous.
Comenzamos lentamente a restablecer la configuración normal. Hemos arrancado esta mañana los validadores con algún que otro tropiezo, pero a esta hora parece que todo va bien y se están dando puntos de todos los trabajos desde la caída del sábado.
Fusión ya está disponible en Windows y docking, tras encontrar el fallo en el validador, también.
A todos aquellos que hayan marcado la casilla de probar aplicaciones beta, hoy estrenamos la beta de la aplicación de un nuevo proyecto de investigación en Ibercivis. De momento no puedo dar muchos detalles porque aun no hay anuncio oficial. Durante estos días estaremos lanzando pequeñas pruebas con los inputs que los investigadores nos vayan facilitando.
La última de las aplicaciones de materiales está por fin disponible para Windows. A ver si en breve puedo poner fusión también y vamos volviendo a la normalidad.
A estas alturas ya os habreis dado cuenta de que el servidor subida.ibercivis.es está caído. Hemos puesto a funcionar una máquina de backup que hace las veces de subida, mientras el auténtico servidor de subida se vuelve a levantar. La cuestión es que hemos detectado algún cliente que se queda bloqueado intentando enviar resultados al auténtico servidor de subida. Si vuestro cliente tiene algún envío pendiente que no sale y en la zona de mensajes véis "http error", probablemente este sea vuestro caso. La solución es sencilla: reiniciad el cliente para que vuelva a consulta la IP.
¿Habéis oído alguna vez la expresión: "La explicación más simple suele ser la correcta"? Pues eso nos ha pasado. Teníamos el problema de que en Windows las aplicaciones iban 4 o 5 veces más lentas que en Linux, sin razón aparente. Nos volvimos locos conjeturando acerca de las opciones de optimización, indicando a mano la arquitectura de la máquina y escarbando en las opciones más oscuras del gcc. Al final, tras hacer pruebas con benchmarks (el whetstone y el dhrystone, ¿le suenan a alguien?) en una máquina con arranque dual Linux y Windows, hemos llegado a la conclusión de que la razón por la que las aplicaciones iban 4 o 5 veces más lentas en Windows era porque las máquinas donde estabamos probando las versiones de windows eran, efectivamente, entre 4 y 5 veces más lentas que las máquinas de Linux. ¡Quién lo iba a decir! 
Una de las máquinas tenía poca memoria (256 MB de RAM) y enseguida empezaba usar el swap lo que la ralentizaba mucho. La cuestión es que el problema se repetía en otra máquina con 2 GB de RAM y un Core Duo a 2,2 Ghz (una máquina supuestamente potente) y eso nos despistó.
A ver si el lunes o el martes podemos tener listas versiones para Windows de materiales128 y fusión_2.0, y ya volvemos a la normalidad.
Ahora paso a comentar las nuevas versiones.
Habréis observado hoy que hemos lanzado unas cuantas miles de workunits de prueba de docking. En Linux funcionan correctamente y no hay ningún problema. Sin embargo, los resultados que devuelven los Windows son rechazados por el validador, aunque la aplicación se ejecuta de forma correcta. En las pruebas en local iba bien, así que habrá que investigarlo.
En fusión también hay novedades. Tras encontrar un molesto bug que hacia fallar a la aplicación en los Linux de 32 bits, los investigadores de fusión han actualizado los parámetros de la simulación. Ahora, uno de los archivos de input (que sólo hay que descargarse la primera vez), ocupa el nada desdeñable tamaño de 73 MB. Si esto es mucho o poco, os toca a vosotros decidirlo. También ha habido que añadir una restricción a la memoria disponible en la template de la workunit. La exigencia en recuros de la aplicación es mayor también y he restringido el envío a máquinas que dispongan de, al menos, 500 MB de RAM para el proyecto libres.
Los usuarios de Windows habreis notado que, desde ayer a las 8 de la mañana, se nos acabaron las workunits. Ahora mismo estamos cambiando la plataforma de compilación para usar compiladores libres (gcc), y todavía no están listas las nuevas versiones de las aplicaciones para Windows. Llevamos algo de retraso porque vamos justos de recursos y, además, hemos atendido otras incidencias.
A ver si podemos tener lista alguna aplicación en los próximos días.
Los que teneis nuestra DNS aun en el cache estais entrando, los que tienen que consultarla fallan. Esto es, ha fallado algo en el servicio DNS del minorista al que le tenemos comprado, el dominio ibercivis.es, y que no voy a mencionar de momento, a no ser que tarden mas de doce horas en arreglarlo.
Podeis ver que estamos vivos si usais la IP o el nombre real de la maquina, a saber http://lxbifi26.bifi.unizar.es/, pero no servira de nada si no os funciona registro.ibercivis.es, dado que es este nombre (y otros) los que realmente dirigen el trafico de workunits: las unidades se recogen de bajada.ibercivis.es, se envian a subida.ibercivis.es y se notifican a registro.ibercivis.es
Aparte de esto, en efecto ha habido un lapso esta tarde en la que el buffer de trabajos se ha vaciado y ha tenido que empezar a tomar carrera. A ver si conseguimos compilar nuevas versiones de todas las plataformas, y asi estara la cosa mas repartida durante el resto del raid de la Aliance. A los que recomiendo la lectura de "Rollan a Saragossa" para que se pongan en ambiente :-D.
Esta es la grafica de cores. Es muy similara a la de usuarios.
Ver los comentarios en la entrada anterior.
Alfonso
Aqui os presentamos algunas graficas comparativas con datos recientes
entre Zivis e Ibercivis.
En esta entrada adjuntamos una grafica del numero total de usuarios.
(En la entrada siguiente esta la grafica con los cores)
Comento algunas conclusiones a la vista de las curvas, aunque estoy
seguro que ojos mas avispados podran ver alguna mas.
La primera subida fuerte corresponde al impacto de la presentacion en
los medios de difusion. Ibercivis se presento en Madrid, Zivis en
Zaragoza y eso hace una buena diferencia, pero no tanto como uno
se esperaria. Aunque Zivis fue local, su penetracion en Aragon fue mayor.
El efecto del impacto inicial dura 4 dias. Tras ellos cambia la pendiente
de forma continua (disminuyendo). Al llegar sobre los 24 dias de la
presentacion la curva se hace lineal y la pendiente es identica en el
caso de Ibercivis y Zivis. Sin presion mediatica, el numero de adeptos
que se unen son gente proxima a los proyectos BOINC y al mundo de la
investigacion para los que no es relevante si el proyecto es local o
nacional ni si sale en los medios o no.
Tras el verano, en septiembre comienza de nuevo un goteo de noticias en
medios de comunicacion nacionales y especialmente locales.
Se incorporan algunas comunidades de BOINC de fuera de españa, se hacen
actos de promocion de ibercivis.
Todo esto implica que la pendiente cambia nuevamente, crece, y comienza
un aumento mas rapido de participantes.
Por ello, la conclusion es que hay dos perfiles de participantes
A) Personas cercanas a la investigacion, a BOINC, y comunidades similares
que se incorporan al proyecto de forma continuada, independiente (casi) de
la presion mediatica
B) Un grupo de personas, interesada en general en colaborar con la ciencia
cuya incorporacion es proporcional al numero e intensidad de las apariciones
en los medios.
El grupo A ahora se nutre de personas de fuera de España especialmente
(probablemente en España en este grupo hemos tocado techo, o casi)
El grupo B se nutre especialmente de españoles, y es nuestro gran deposito
al que debemos llegar haciendo actividades publicas y promociones.
La mejora de la pagina web, actos publicos, premios, etc... seguramente
hara cambiar de nuevo la pendiente en las proximas semanas.
Alfonso
Por turnos parece que van fallando todos nuestros proveedores de conectividad. Esta madrugada a las 00:30 ha sido el SICUZ el que ha tenido un apagon: www.unizar.es no tiene ya nombre en muchos sitios, el correo vaya usted a saber si se recibe, y nuestra area no tiene trafico IP.
Nuestro plan de contingencia, que ya aplicamos el mes pasado, es cambiar de host si tarda mas de 24 horas en reactivarse el camino al actual. Asi que a la espera estamos. Pero son fiestas en Zaragoza...
Hola,
Este fin de semana ha sido especialmente desastroso. Una configuracion que en las pruebas andaba justo en los limites de lo posible ha resultado estar más alla del limite. Y como esta semana, a la espera de docking, solo esta saliendo materiales, lo habeis sufrido al 100%.
La perdida de CPU bueno, es parte del juego de la investigación. Al menos no es un fallo que te retrasa cuatro meses el experimento. Pero en cuanto a la perdida de creditos, supongo que podemos dar una compensacion a los que se han bajado unidades durante todo el fin de semana pero han fallado. Digo "supongo" porque no sé como lo veis los diferentes equipos, desde el punto de vista de etiqueta de BOINC. Lo que sea, hay que decidirlo en 24 horas, antes de que la gente desaparezca de la base de datos hacia el backup xml.
Un truco interesante de mysql, que aun no hemos implementado pero que lo vamos a pensar.
Ahora mismo, ya lo he dicho antes, el esqueleto de ibercivis son seis maquinas: cuatro de ellas forman un circulo mysql db0, db1, db2, db3 y vuelta a db0 en cuanto a actualizaciones de la base de datos; y otras dos forman una rama dbweb y dbusers donde se copian los datos que son de solo lectura en las consultas via web. La rama sale de una de las del circulo, digamos db0.
Una de las maquinas del circulo no esta propiamente en los centros de los investigadores sino en instalaciones de rediris. De hecho nos pillo el apagon de Telvent el lunes pasado. Al estar lejos de la tentacion de los investigadores es pues un buen candidato para todas las tareas de gestion: backup de la base de datos, purgado de workunits antiguas y esas cosas. El problema es que estas tareas crean Locks en la base de datos y por tanto retrasan la propagacion a traves del circulo; por ello nuestra solucion y supongo que la de casi todo el mundo es repartirse estas tareas entre todas las maquinas dbN.
Pues bien, resulta que ya va para dos años que se sabe una forma de tener dos masters con un solo esclavo en MySql. Tan solo he encontrado en la web un documento que lo explica: http://www.shinguz.ch/MySQL/mm-single-slave-repl.pdf El truco esta en que en la maquina esclavo deben correr dos esclavos: el de verdad, que apunta al master que mas trafico tenga, y el secundario, que apunta al otro master y ¡no tiene tablas propias, sino federadas!
El resto del truco es tan trivial que ya ni lo dicen: tan solo uno de los masters, el que va al esclavo principal, debe tener activado el log-slave-updates, pues de lo contrario al volver a unirse los flujos se duplicarian todos los updates que vienen del aguas arriba. Tambien hay que tener en cuenta el server_id y sospecho que otros detallitos por investigar. Pero la solucion es interesante. El "circulo" final tendria las replicaciones:
| db0------>db1 | db1-------->db2 | db2----->db3 | db3---->db0’ | db0’ ---fed--->db0 |
| db2------------------------------------------------->db0 | ||||
y podriamos hacer consultas "bloqueantes" en db3 sin que se interrumpiera la propagacion de cambios. No asi en db0’, pues no es mas que un acceso disfrazado a db0.
¿por qué no se explica esto en el manual? Supongo que no es porque no funcione, sino porque la posibilidad de paradas de la circulación aumenta mucho: db3 podria escribir sobre fichas que luego no existen en db0 porque ya ha llegado alli una señal de borrado que en db3 estaba atascada, o cosas asi. En tal caso, la replicacion se para y el sysadmin se gana el sueldo. Pero si uno tiene claro que db3 solo va a escribir o borrar cosas que no van a desaparecer por culpa de otro nodo, (o al menos no en las proximas horas), este tipo de operacion "en el anden auxiliar" es posible. Otro problema es que, como dicen en el articulo, "there isn't the safety net", aunque en el ejemplo nuestro sí que la hay, en el sentido de que todo esta en algun log y puede repetirse si ha fallado.
Otro uso creativo que le veo, mas que la replicacion síncrona, es la replicacion todos a todos. Sin pasarse, digamos para tres nodos: En cada nodo corren dos mysqld en federacion, dbN y dbN', los dos con el "log-slave-updates" quitado, y cada uno se hace esclavo de uno de los otros dos nodos. Resultado: tres nodos replicados sin que el bloqueo de uno fastidie a los otros dos. ¿alguien tiene esto montado? ¿le funciona?
O como un avión. El hecho de que incluso en esta fase de apenas unas millares de CPUS hayamos tenido que marcar tasas de creacion de unidades de 2 y 3 por segundo me lleva a pensar que tal se comportan las bases de datos en otros negocios. La mayor parte de los webs se basa en mysql pero en el fondo son de muchas lecturas y pocas escrituras. En nuestro caso la vida de una ficha incluye mas escrituras que lecturas, y ademas creamos muchas. Una situacion equivalente que he encontrado, en cuanto a escala, son las bases de datos de las reservas de viajes:
A dos viajeros por segundo, en un año gestionariamos 63 millones de viajeros.
Renfe factura en media y larga distancia entre 30 y 40 millones de viajeros al año.
Ryanair afirma tener 50 millones de pasajeros; Iberia unos 27, y el record europeo lo marca Lufthansa con unos 75 millones. Las alianzas suman pasajeros hasta por ejemplo los 400 millones que declara Star Alliance, pero no tengo claro que impliquen una unificación real de las bases de datos.
Naturalmente, estamos lejos de la banca: las tarjetas de credito inglesas, en Diciembre, promedian las 250 transacciones por segundo. Y desde luego en USA los ordenes de magnitud de las operaciones bancarias son mucho mas gordos. Hay un Top de ordenadores de banca:
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
que se mide en transacciones por minuto; los ordenadores mas brutos superan el millon de transacciones por minuto con maquinas de 32 o 64 cores y, esto es importante, otros tantos terminales enviando datos. Si nos ponemos a hilar fino y contamos cada acceso atomico, nosotros podriamos hablar de entre unas 1600 y 2000 por minuto ahora, con un par de cores. Aunque la creación de datos es mas compleja en nuestro caso, pues no la hacen los terminales sino que cuesta tiempo de CPU en el core.
PS: lo que me esta resultando mas dificil de encontrar son los datos del numero de llamadas telefonicas anuales de distintas compañias. Lyman y Varian hicieron en el año 2000 una estimación muy citada sobre el volumen total de información intercambiada en el mundo, pero sin entrar es este detalle fino del "numero de fichas".
Ya se han publicado online los pdf y videos del cuarto encuentro pangalactico de plataformas BOINC.
http://boinc.berkeley.edu/trac/wiki/WS08/WorkshopProceedings
Estamos ampliando el sistema con dos nodos nuevos, uno en el CSIC y otro en RedIris, que complementan a los del Bifi y el Ceta. Ya hemos puesto el primero en el circulo de la base de datos -asi que ahora es un triangulo- y nos queda por poner el segundo, dentro de un par de dias.
De momento las nuevas maquinas estan descargando a las antiguas de algunos trabajos de mantenimiento y backup, pero asumiran tanto el respaldo en averias y picos puntuales como la creación de trabajos de los nuevos proyectos.
Entretanto, ayer tuvimos un incremento de visitas, sospecho que por parte de la alianza francófona pero no lo he verificado en los logs. El caso es que por primera vez el sistema de recepcion estuvo un buen rato colgado en el tope de procesos de apache. Hoy estamos mandando trabajos de proyectos mas largos, y la cosa esta mas suave.
Habiamos esperado que con la busqueda del primer tomo de docking llegaba hasta fin de mes pero nos hemos quedado cortos en cuatro dias! Asi que esta ibercivis con un periodo de relajo hasta la semana que viene. Luego en el mes de Septiembre esperamos que se incorporen otros cuatro grupos de investigacion.
EDIT: añado el plot de workunits creados en agosto; el de resultados recibidos es algo mayor, pero aqui se ven las pautas de parada en envio que tambien han ido ocurriendo. La unidad es un poco rara, porque en vez de por hora es por 5 minutos, asi que multiplicad por 12 para obtener workunits/hora. Naturalmente, estan mezcladas las de los tres subproyectos.
De cuando en cuanto sale la discusion (afortunadamente cada vez menos) del coste real de una plataforma BOINC comparado con la compra de sistemas propios. Es una discusion viciada por muchos lados: un sistema propio es claramente mas polivalente (para empezar, admite paralelismo si pones una red decente entre los nodos locales); los dos sistemas tienen un coste de I+D que normalmente se considera amortizado para simplificar; los costes de los ordenadores caseros no estan claros, BOINC se utiliza de lado a la vez que otras tareas (por ejemplo descargas online), etc.
Una "simplificacion" más de esta evaluacion era acudir al precio de mercado de la ejecucion remota. Lamentablemente esto hasta hace poco significaba tiempo de renderizacion en ordenadores de Bolliwood, un mercado muy especializado y por tanto poco realista. Ahora, parece que Amazon y Google estan fijando los precios de cloud computing: 10 centavos la hora de cpu. O al menos, eso es en las maquinas de las que tengo noticia.
Google tarifica "gratis", ahora que estan en beta, los primeros doscientos millones de megaciclos ¡de cada dia!, usease practicamente 20 horas de un core de 2.83 GHz, pero este numero puede bajar, quizas a 5 horas, una vez salgan de beta y empieze el cobro. En cierto modo es el entorno cloud mas parecido, en esfuerzo de I+D, a una aplicacion boinc; en este caso son ficheros python con unas condiciones especificas, que se ejecutan en clientes disponibles dentro del cluster de google.
Luego estan, claro, los impagables: el que se forme una comunidad alrededor del calculo cientifico, las repercusiones que esto tiene en divulgacion...