Ejecutando BOINC en Windows Vista sin que pregunte

Lo cierto es que yo no he probado BOINC en Windows Vista, pero sí que he oido (a David y a otra gente) que el UAC considera que BOINC no es una aplicación "limpia" y pregunta acerca de si se debe ejecutar o no cada vez que arranca.

Pues bien, es un poco pesado, pero en este enlace (http://www.vista4beginners.com/Disable-UAC-for-certain-applications) explican como deshabilitar la pregunta del UAC para una aplicación específica. El método es un poco "laborioso", pero se basa en decir que es una aplicación WinXP válida y que se debe ejecutar con las credenciales del usuario que la lanza, con posibilidad de que acceda al disco y esas cosas.

Total, que lo que se hace es actualizar la BD de aplicaciones de Windows Vista para dar "boinc.exe" como lícita. Eso sí, no se qué ocurrirá cuando boinc haga el "spawn" de la aplicación que debe ejecutar (supongo que habrá alguna forma en los "compatibility fixes" para indicar que puede ejecutar aplicaciones).

Como he dicho antes, yo aún no lo he probado (porque no tengo ningún Vista accesible). Si alguien "se atreve", que lo pruebe y nos cuente sus experiencias... en cualquier caso, yo lo probaré a la vuelta de las vacaciones.

Nuevas aplicaciones: materiales24 y materiales48

Ayer estrenamos nuevas aplicaciones de materiales con tamaños 24 y 48 respectivamente. Aquellos que hayan personalizado sus preferencias de Ibercivis deben acordarse de indicar manualmente que desean recibir trabajos de estas aplicaciones. Para comprobar si puedes recibir trabajo de las aplicaciones visita Ibercivis->Unirte a Ibercivis->Tu cuenta->Subproyectos. En caso de que materiales24 y/o materiales48 aparecieran desmarcaradas puedes marcar haciendo click en el cuadradito al lado de los nombres y luego haciendo click en "Enviar" para hacer efectivos los cambios.

EDIT: Aquellos que admiten trabajo de todas las aplicaciones de materiales anteriores a estas dos, se les han modificado las preferencias de forma automática para que admitan estas dos también. Los que sólo aceptaban algunas aplicaciones de materiales se les enviará nota invitándoles a que las acepten. Los que no aceptaban ninguna aplicación de materiales no han sufrido ningún cambio. Si en tu configuración dispones de diferentes "venues" tampoco se ha realizado ningún cambio.

velocidad*tiempo=credito

En esta grafica se muestra en horizontal el tiempo que ha tardado en terminar una workunit, en la ultima semana, y en vertical la velocidad (o coloquialmente "potencia") del ordenador, entendida como la suma de las dos benchmarks que hace BOINC.

Se puede ver que para los trabajos de m64 el tiempo de calculo y la velocidad de la maquina son inversamente proporcionales. Eso es asi porque estos trabajos estan compartimentados para realizar un numero fijo de operaciones una vez estan termalizados. Y por ello el producto velocidad*tiempo es constante; practicamente igual nos daria dar un "fijo" por workunit que calcular cada vez el crédito a partir de las benchmarks y el tiempo.

Otro cantar son docking e iter. Aunque en promedio son tareas cortas, no se sabe de partida cuanto tiempo van a necesitar. Y como son mucho mas cortas que m64, ni siquiera se llega a apreciar una hiperbola difusa.

Tambien podria ser problematico un subproyecto en el que las benchmarks, que son basicamente un tipo de calculo, no estuvieran siquiera correlacionadas con su duracion. Por ello se hacen dos benchmarks, una de calculo entero y otra de calculo flotante.

En Ibercivis nos resulta conveniente usar un baremo neutral respecto a subproyectos. A la pregunta ¿que me conviene mas, correr A o B?, la respuesta sencilla es que va a dar igual en la misma maquina, dado que vamos a puntuar segun el producto "velocidad*tiempo", con la velocidad dada no por A ni por B sino por la benchmark neutral. Otro asuntillo seria comparar sistematicamente tiempo de cpu con tiempo real transcurrido: esta relacion dependera debilmente de la configuracion de cada maquina. Y naturalmente, un asunto totalmente diferente es la cuestion del tipo de CPU y de sistema operativo, que afecta de manera diferente a cada subproyecto y a los benchmarks; a la gente de CanalBoinc les gusta hilar fino en estos asuntillos.

Tiempos de CPU

Hemos sacado algunos histogramas para ver como iba la duracion de los trabajos respecto a nuestro ideal de 40 minutos. Practicamente todo acaba antes de los 2400 segundos, con dos excepciones en las que se esta trabajando: Materiales 64 y Fusion-iter. Esto es una cierta molestia relativa, dado que cuando se apaga el ordenador es lo mismo que abortar el proceso: el calculo de la workunit (y los creditos) se pierde. Os explico: antiguamente, con windows 95, se diseñaban estos programas para que guardaran continuamente su estado, porque cada vez que el usuario volvia al ordenador el proceso de calculo era terminado fulminantemente. Hoy en dia lo que ocurre es que el proceso se suspende y pasa al swap, a dormir en el disco duro, hasta que vuelve a haber RAM y CPU desocupada. Asi que los desarrolladores no se tienen que preocupar tanto como antiguamente de la recuperacion... a no ser que el proceso dure mucho.

En el caso de "materiales" (vease su blog) la aplicacion ya esta segmentada de forma que cada cuarenta minutos guarda su estado y se da por terminada (de forma que el usuario reciba el credito acumulado). En el caso de "fusion" estan trabajando en ello. Lo que ocurre es que las trajectorias simuladas mas estables duran mucho mas que las que directamente colisionan con las paredes del reactor y aunque muchos de los calculos terminan rapidamente hay un "long tail" de workunits que necesitan horas para terminar.

En cualquier caso, intentamos que los investigadores nos manden trabajos cuyo tiempo medio sea inferior a esos cuarenta minutos prototipicos. Ojo, las aplicaciones que pecan por el lado contrario (demasiado cortas) causan tambien problemas, pero de consumo de ancho de banda y de CPU en los servidores. Esto se equilibra porque ibercivis ajusta los envios de manera que todos los grupos obtengan a la larga el mismo numero de unidades de trabajo, y por tanto los investigadores ya procuran aprovechar el tiempo de cada uno de sus "tickets".

Monitoreando

Los comentarios siguen llegando, pero no se por que el estilo de blogia da problemas y no se visualizan fuera de administracion. Estamos esperando que lo solucionen definitivamente. Hay dos razones para tener el blog fuera: una, no reinventar la rueda. y otra, poder comunicarnos en caso de emergencia de nuestras maquinas o incluso de rediris.

Bueno, a lo que iba. Hoy hemos puesto en la web, en la seccion de estadisticas, los datos "crudos" de ancho de banda y carga de las maquinas. La maquina "lxbifi25" es www, la "lxbifi26" es registro y bajada, la del CETA es subida, y nuestro  escaso java se ejecuta en la 39.  Asi que los mas  interesantes son 25, que hace muchos analisis de la base de datos (recordad que esta fuera del circulo) y 26, que en su papel de "registro" produce trabajos. Las metricas propias tienen la etiqueta icvis_. Otro dia las pondremos mas bonitas, cuando dominemos el rrdtool, y entonces os explicare lo que es cada una. De momento ahi estan.

¿Como va todo?

Dejo aqui esto para que si veis algun problema durante el fin de semana lo comenteis. Los comentarios se leen en admin, aunque por misteriosas razones (tenemos que hablar con el proveedor acerca de ello) no todos se ven aqui.

En particular me hablan de fallos en docking para 64 bits. ¿alguna confirmacion?

El RAID perezoso

Como dijimos, esta parada hemos hecho mas pruebecicas. Hemos mejorado algun que otro acceso a disco, limpiado un par de atime que podrian molestar en sistemas de ficheros ext3 (alguno lo hemos puesto a noatime, otros a relatime), y refinado el my.conf de la base de datos, y parece que se nota. No obstante estoy aun un poco mosca con el raid de discos. Es un raid 1+0 de cuatro discos, y de alguna manera cuando esta en competicion con todo el httpd y el mysqld en marcha no se comporta como debiera. Ahora mismico, un test de bonnie++ ha escupido

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
94650 57 109599 29 16450 3 28923 15 17693 1 171.9 0

A lo que entiendo, Bonnie llama Output a la escritura en disco e Input a la lectura desde disco. Asi que ya veis que no encaja la cosa: ¡109Mbytes de escritura contra apenas (en el peor de los test que he hecho) 18 MB/sec de lectura!. Una confirmacion independiente la da el correr iostat en paralelo con los tests: se puede ver que durante las escrituras el md0 se sube hasta 115MB/seg, que el rewritting mantiene hasta como mucho 34MB/sec en lectura y en escritura... y que la lectura a secas no consigue levantar mas de esto.

En la misma maquina, con el disco duro raiz, que no esta en el raid, se consigue

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
30007 17 29160 6 15809 2 33730 17 39346 3 117.9 0

En teoria, un 1+0 de cuatro discos deberia ser al menos 2 veces mas rapido en escritura que un disco solo,
y cuatro veces mas rapido en lectura. No cuadran las cuentas. Hay que tener en cuenta que aparte del test los discos llevan un trafico majico en registro/bajada de ibercivis, del orden del megabyte por segundo, y algo menos de la mitad para el raiz. Pero los resultados no parecen cambiar demasiado si paro procesos.

Por comparacion, www.ibercivis.es tiene un solo disco con dos particiones lvm, las cuales ademas estan con el journaling simplificado del ext3, "=writeback". Las dos se ponen tranquilamente con el bonnie por encima de los 50 megabytes/sec tanto en lectura como escritura de bloques. Y el journaling no afecta a la lectura, que es lo que esta fallando.

El primer sospechoso es el layout del Raid, "near=2, far=1", con chunks de 64K. Esto es el default, "n2". Que ya sabia uno que no es tan espectacular en los tests como "f2" pero a fin de cuentas tampoco es el servidor web, asi que la escritura es tan importante o mas que la lectura. Pero ni siquiera el obseso de Makarevitch llega a notar diferencias espectaculares.

Volviendo a mirar el iostat, se ve un detalle que ya noto Samuel el otro dia: al hacer las lecturas, un solo disco se esta comiendo todo el marron de su pareja: mientras sde y sdf van a la par, el sdc se come todo el marron que deberia tener sdd. Si el md da 30MB, 15 vienen de cada par, y del par c/d resulta que 14MB vienen del c. El escaqueado es un hitachi de la ostia que compramos hace poco en sustitucion de un failed, pero tambien el sdf es del mismo modelo y mes, y da el callo como el que mas. ¿No sera que el c se pasa de currar y no le deja al otro?

[EDIT, arivero, jul 10 14:52] Hemos cambiado el cable de alimentacion y el cable SATA, y la velocidad de lectura de sdd ha subido del megabyte rancio hasta los nominales 75MB/sec que se esperan de un 500 Gigas. Conjetura: le faltaban amperios.

Para comprobar los discos una herramienta rapida es, quien lo iba a decir, hdparm -A -C -t -T /dev/sda

Hay quien sugiere desactivar el look-ahead del disco para los RAID. De todas formas hay que tener en cuenta que el propio OS tiene otro read ahead, vease blockdev --getra /dev/md0, que en este caso esta ajustado al doble del readahead de sus componentes, blockdev --getra /dev/sdX. Habria que diseñar probatinas especificas de nuestra carga.

 

parada terminada

o casi. Como ya podeis ver, hace una hora que registro.ibercivis.es, bajada.ibercivis.es y subida.ibercivis.es han retornado a la normalidad. Hay dos excepciones: no estoy seguro de que arranquemos los creadores de nuevos trabajos hasta que haya una supervision humana (y por tanto quizas hasta mañana por la mañana) y no se podra activar del todo www y su mapa hasta que no haya alcanzado a los demas, y por algun lio de ficheros se ha quedado muy retrasado y no creo que alcance hasta la madrugada.

Parada de mantenimiento en Ibercivis

(AR edit: paron, paron... mas bien paradica, porque la recepcion, registro y conexion siguen abiertos. Veanse los comentarios para mas info)

Hoy entre las 14:00 y las 20:00 está previsto que hagamos un pequeño parón de mantenimiento forzoso (va a haber un parón de mantenimiento de la red de la Universidad de Zaragoza), tiempo durante el cual no se mandarán trabajos. Durante la mañana aceleraremos la creación de trabajos para que tengáis suficientes para calcular durante el parón.

En el parón intentaremos mejorar varias cosas: mejorar la velocidad de acceso a la base de datos, mejorar el rendimiento de los discos del RAID, resumiendo mejorar el rendimiento general del sistema central para que tengáis la misma experiencia de usuario a pesar del aumento de usuarios y funcionalidades del sistema.

El parón podría prolongarse más allá de las 20h, en ese caso os avisaríamos por aquí con una actualización de la entrada.

 

 

A vueltas con los créditos

(la gráfica muestra en horizontal los Gflops y en vertical los Giops de las máquinas activas ayer en Ibercivis. La línea que cruza es el promedio de ambos; todas las máquinas en esa línea o en alguna paralela obtienen igual puntuación a igual tiempo de CPU)

En Zivis ya notamos que la gente tiende a quejarse de los pocos creditos obtenidos en nuestros proyectos.  Esta vez, hemos echado un vistazo a las estadísticas que da boinstats para acabar constatando, sorprendidos, que no es tal el caso: Rosetta y WCG dan menos créditos que nosotros, y sólo SIMAP y Einstein@home, de entre los mas populares, dan claramente más créditos.

¿Qué pasa entonces? La conjetura es que la queja puede provenir de las máquinas menos potentes: la mayoría de estos proyectos (excepto Rosetta) exigen tres resultados de quorum y suelen mandar más, digamos cuatro o cinco. En tal caso, los créditos concedidos son el promedio de los intermedios, así que la máquina que ha hecho la petición mas baja recibe al final más créditos de los que ha pedido. Estos cálculos los podéis ver explicados aquí http://www.boinc-wiki.info/Credit#Credit_Granting_Rules.

Si miramos la distribución de Gigaflops y Gigaiops de las máquinas activas en Ibercivis, veréis que aunque el promedio es de 4.9 hay una dispersión muy amplia; en la grafica hay 1018 maquinas bajo la línea promedio y 762 por encima. En otros proyectos, los que están por debajo tienen una cierta probabilidad de ser agrupados con los de la parte de arriba y obtener por ello más (?) creditos. En el nuestro, de momento los investigadores están optando por correr sin redundancia (y hacer uso de análisis y postvalidación al recibir), así que el quorum mínimo es de un solo resultado y este beneficio no se produce: obtienen mas crédito las máquinas más potentes a igualdad de tiempo de cálculo. Os recuerdo que la fórmula básica de cálculo dice que el crédito es proporcional a la suma (flops+iops) y al tiempo de cálculo empleado, ya que se supone que un crédito es la producción de un hipotético pentium básico durante un día de cálculo.

¿Qué opináis? ¿Es esto lo que esta ocurriendo, o hay otras causas involucradas? Ahora que lo pienso, he simplificado demasiado porque la discusión anterior no considera que el que tiene menos potencia ha tardado más. ¿Quién está pidiendo más crédito, y quién menos, para una workunit dada... los que tienen más, o los que tienen menos potencia? Precisamente, al no tener casi redundancia, no tenemos ese dato directamente en ibercivis.

 

MySQL y su anillo

En los ultimos dias habreis notado paradas y rearranques de las bases de datos, o de ibercivis completamente, en pequeños lapsos mitad simulacro de emergencias, mitad prueba de parametros. Lo cierto es que no tuvimos Zivis a este nivel de usuarios durante mucho tiempo, asi que tenemos que aprender sobre la marcha. Tambien por eso los tecnicos estamos comodos con este nivel inicial de un par de miles de participantes asiduos.

MySQL es fascinante. Su modo cluster no es aconsejable mas que si de verdad tienes necesidades brutales, pues exige tener toda la base de datos en RAM, y no solo las caches de los indices. Pero entre la base aislada y el cluster tiene unas etapas intermedias muy interesantes. Basicamente, el sistema de copias Maestro->Esclavo puede no solo expandirse en arbol sino tambien cerrarse en circulo, de forma que un "cluster" de baja velocidad se puede formar mediante un circulo de nodos que aceptan escrituras junto con ramificaciones a nodos que solo aceptan lectura.

A la espera de que se pongan de pie las maquinas de nuestros socio, el "circulo" lo forman dos nodos, uno en subida y otro en bajada/registro, y la ramificacion es una copia que sale hacia www y de ahi a modulos.

Un primer descubrimiento, tan obvio que no sale en los manuales, ha sido el que no habia obligacion de tener los mismos indices en cada copia de la tabla. Lo que sí que sale en el manual es que podemos escoger que tablas copiamos a cada rama, pero eso era de esperar .  Total, que resulta que podemos optimizar las copias a las ramas quitando indices que no van a utilizar y añadiendo indices que sí que pueden necesitar. Es de esta manera como conseguimos listar en menos de cinco minutos las actividades de los ultimos cinco minutos .  Otro dia os contare por qué no conseguimos listar las coordenadas de los usarios a la misma velocidad.

Otro descubrimiento, asociado a este, es que las tareas de escritura se repiten en cada nodo. Usease, que realmente el anillo alivia las lecturas, pero las escrituras se las tienen que comer todos como si fuera una base de datos unica. Y obviamente el anillo va a ser tan lento como lo sea su nodo mas debil. Asi que, tirando de ganglia, iostat y lo que se os ocurra, estamos haciendo malabarismos con  la cpy, la memoria y los RAID para ver como optimizarlos, y segun vayamos creciendo habra que ir dejando discos y maquinas completas en exclusiva para el mysql.

Es tambien un poco molesto ver que esta diferencia entre lectura y escritura se entendio a medias del desarrollo de BOINC y hay mucho legacy frenandote. Asi, el php tiene una flag para dar un nodo de lectura diferente que el de escritura pero en realidad no lo usa de forma correcta en todos los db_init y ni siquiera esta documentada. La cosa es grave porque hemos observado, o creido observar, que las oleadas de lecturas bloquean la creacion o borrado de tablas.

A vueltas con el salvapantallas

Ahora que parece que las aplicaciones estan funcionando, en Valencia vamos a volver a trabajar con el salvapantallas. En realidad, en cuanto a programación y funcionamiento básico ya está completamente desarrollado y es funcional en Windows, Linux y Mac. Además, ya lo pasé a la gente que se encarga de los contenidos y han preparado una versión con contenidos iniciales.

Así que tenemos una versión (y hay que remarcar que es inicial, puesto que falta afinar el concepto de los contenidos), que saldrá a la luz dentro de unos días.

La cuestión es que hace tiempo que teníamos en Valencia desarrollado el salvapantallas, pero con el cambio del API gráfica (pequeños, pero que requerían revisar la programación), se retrasó la puesta en marcha, balanceando los esfuerzos hacia la estabilización de las aplicaciones.

En cualquier caso, hemos retomado el desarrollo del salvapantallas y esperamos que en los próximos días podamos dar noticias acerca de él.

Ahora si, validamos fusion

En los últimos días hemos tenido unos problemas con el validador de fusión, que ha hecho que algunos trabajos quedasen pendientes de recibir los créditos. Después de trabajar estos días, ya disponemos de una versión que realizará una validación correcta de los resultados pendientes.

Esto ha ocurrido por una pequeña desincronización de las versiones de las aplicaciones y el validador, que ya hemos solucionado satisfactoriamente.

Para celebrar que España gana... estrenamos version de Fusion

Despues de un tiempo en el que han ocurrido inestabilidades con la aplicación de fusión (el validador dejó de funcionar bien y ocurrían algunos problemas si los usuarios cancelaban los trabajos), finalmente ya tenemos una versión que corrige estos bugs.

Ahora tenemos todas las aplicaciones en pleno funcionamiento, porque parece que materiales y docking van funcionando bastante bien, ¿no? (con la salvedad de este problema que ha surgido con la descarga del archivo de datos de docking en algunas máquinas).

Y mañana tendremos la version de Docking para mac-intel

Pues eso, que mañana por fin tendremos la version de docking para mac-intel que no depende de las librerias dinamicas que incorpora gfortran. Al final, como la opcion -static no esta disponible para el ld de mac (al parecer por motivos de licencias), hemos tenido que enlazar a mano. El mayor problema ha sido encontrar donde estaban los simbolos que ibamos necesitando.

Edit: Devuedé. Pues ya está lista la nueva versión. A ver que tal funciona.

Afinando las aplicaciones

Los investigadores de Materiales han tenido un pequeño problema con sus resultados y es que no se han recogido todos los que se han calculado, por un pequeño fallo. Hoy se ha preparado una solución con una mínima modificación que permitirá recuperar todo lo calculado de una vez... seguramente mañana tendremos la nueva versión lista.

En cuanto a Fusión, también se ha preparado una modificación para evitar algunas incidencias cuando se cancelaban las tareas. Tras unos intercambios de codigos fuentes, también tendremos mañana la nueva versión de Fusión, con el mini-bug solucionado. De todas formas, no os preocupeis porque los resultados que se estaban obteniendo son buenos (a pesar de que el validador haya dicho lo contrario... ya se ha comentado por ahi).

La aplicación de Docking parece que funciona sin demasiados problemas ¿no?

Validación de fusión

Hola a todos. Como ya dije hace unos días, los investigadores de fusión están afinando el simulador. Ayer realizaron una modificación y el validador no reconoce los nuevos resultados. Hasta que me llegue uno nuevo que trate correctamente los nuevos resultados he parado el validador de fusión. Los resultados nuevos se guardarán hasta que llegue.

Mientras tanto, he rastreado los resultados que han sido marcados como validados erroneamente cuando en realidad sí estaban bien, y he asignado 10 créditos a cada uno de esos resultados. Los resultados seguirán marcados como validados erroneamente pero los créditos los tendréis.

Disculpad las molestias. Saludos y gracias por participar.

Evolucion Comparada Zivis-Ibercivis

Aunque sea algo pronto, aqui presentamos los datos de la evolucion
de usuarios en Zivis y en Ibercivis.
Son los datos de numero de personas registradas en la base de datos.
En el caso de ibercvis, el dia del lanzamiento es la fila 4
y en Ibercivis la 23 (asi podreis igualar escalas)
En el fichero de zivis los usuarios son la unica columna, en el
de ibercivis son la segunda.
Cuando haya mas datos de ibercivis los pondremos.

Se puede construir la grafica que adjunto.

Podriamos preguntarnos varias cosas
1) Existe una forma funcional sencilla para las curvas?
2) Es posible preveer la evolucion futura?

Hay mas preguntas, que espero planteeis y respondais.

 

Datos de Zivis

0
18
46
383
730
928
1091
1160
1207
1288
1353
1501
1604
1669
1718
1769
1815
1926
2012
2100
2200
2262
2311
2370
2432
2481
2551
2589
2613
2644
2665
2694
2716
2733
2748
2765
2791
2810
2818
2834
2851
2874
2888
2905
2917
2955
2963
3011
3039
3059
3073
3087
3096
3105

3112

Los datos de Ibercivis

1212132840 263
1212133078 263
1212393086 277
1212398254 278
1212444147 286
1212530504 412
1212565686 415
1212616930 433
1212704444 445
1212789791 455
1212876189 461
1212962591 465
1213048934 475
1213135411 479
1213221785 489
1213308193 491
1213481392 501
1213567759 502
1213653848 503
1213740253 536
1213826603 550
1213913441 566
1213999972 758
1214086535 1602
1214178633 2096
1214264103 2720

Aqui un archivo para visualizarlos en gnuplot y generar el archivo users.gif

set term gif font 'l047013t'
set xlabel "días"
set ylabel "Usuarios registrados"

set output "users.gif"
p "zivis_users.txt" u ($0-2):1 w l lw 4 t "Zivis",
  "users.txt" u ($0-21):2 w l lw 4 t "Ibercivis"

 

 

Datos de Ibercivis

Sobre los mapas

En la web de Ibercivis se pueden encontrar dos mapas principales de monitorización.

El primero de ellos es el de la introducción. Es estático, y en él se muestran todos los usuarios de Ibercivis. En color azul aparecen los que nos han proporcinado sus coordenadas, y en naranja aparecen los que no se han geoposicionado, que son colocados aleatoriamente alrededor de la Península ibérica.

El segundo es el mapa de actividades. Lo podemos encontrar en la subsección "Mapas" de la sección "Clasificaciones". En él se muestran también todos los usuarios de ibercivis de la misma forma que en el mapa de usuarios, pero además también se muestran animaciones que representan el envío (desde el Bifi hasta los usuarios), recepción (desde los usuarios hasta CetaCiemat) y validación (desde CetaCiemat al Bifi) de trabajos entre usuarios y servidores con un retraso de 5 minutos. Los haces de color verde representan trabajos de "Docking", los azules de materiales, y los rojos son de fusión.

Para introducir las coordenadas hay que dirigirse a: Ibercivis -> Unirte a Ibercivis -> Tu cuenta. Una vez allí, si rellenamos nuestros datos correctamente, se calcularán nuestras coordenadas automáticamente, aunque también se puede hacer manualmente clicando directamente sobre el mapa, para lo que no hace falta facilitar ningún dato. Podemos corregir la posición volviendo a clicar en otro lugar del mapa o arrastrando el marcador. Para borrar las coordenadas basta con clicar sobre el marcador.

Docking... ya esta aqui la version de Windows

Estos últimos días se hubo de desactivar la versión de Docking para Windows, porque no teníamos bien perfilada la versión de Win64.

En realidad la aplicacion no funcionaba por una serie de circunstancias encadenadas, pero el codigo esta muy bien preparado para funcionar en multiplataforma.

Ahora ya la tenemos y en breve empezareis a recibir trabajos de docking para la gente de Windows.

Nota: La mala noticia es que no hemos podido solucionar de momento el problema de las librerias compartidas de fortran en Mac.