Preguntas frecuentes sobre ZIVIS (Blog de Zivis)

Se muestran los artículos pertenecientes al tema problemas.

14/04/2007

LGV3, y la primera crisis Windows/Linux

Tras la noche de poco dormir ha llegado la mañana movidita. Premio virtual para cherinolero, que observo la diferencia entre Linux y WIndows casi al mismo tiempo que nosotros. Las cinco versiones de lgv2 que llegaron a salir por la madrugada hicieron que al menos algunas de las tareas de windows terminaran, y comparando los casos en los que la misma semilla aleatoria llegaba a un windows y a un linux se veia que de cuando, pero no siempre, en cuando los tiempos discrepaban de forma abultadisima.

Asi que esta mañana a las diez y pico Alfonso nos sacaba de la cama a Fermin a Jose Luis y a mi, ambos equipos cientifico y tecnico. La primera sospecha eran las librerias de windows, pero es que precisamente ¡todo esta diseñado para no utilizar las librerias de windows! Las dos versiones se producen con GCC, y la escasa parte de interaccion con Windows que hay que usar la proporcionan librerias de software libre, MinGW. El equipo cientifico empezo a buscar lo tipico: alguna division por cero, alguna raiz cuadrada negativa, cosas asi... pero que solo se produjeran en la version de windows. Durante un milisegundo hasta se me paso por la cabeza si habriamos pillado otro bug como el del Pentium 100, que linux lo parcheaba y Windows 98 no. Despues de considerar el codigo y volcar algunos resultados, la sospecha de Alfonso y Jose Luis iba mejor dirigida: de alguna manera LGV2 no cargaba correctamente los ficheros de configuracion en Windows. ¿Que es lo que es diferente? Pues algo que casi todos hemos sufrido, y que pertenece a esa "escasa parte de interaccion" que he dicho antes: si se abre un fichero de texto en modo binario, o uno binario en modo texto, no hay garantia de que los resultados sean los mismos en todo sistema operativo. Salvando las distancias, es ese efecto por el cual cuando abres un fichero de un OS en otro te encuentras todo en una sola linea, o por el contrario lineas dobles.

Ocurria que ademas de modificar el sistema de porcentajes y de introducir un corte fijo en el numero de segmentos calculados, habiamos aprovechado para reorganizar los ficheros de input y se nos habia colado un open en el que no especificabamos el formato. En tal caso, GCC da ba por defecto formato de texto, y por tanto lee diferente segun este en Windows o Linux. Como ayer noche todas mis pruebas fueron en Linux (la experiencia con LGV1 me habia dado confianza en que la produccion, salvo la de la parte grafica, era identica) no adverti el problema, y para colmo la cosa dependia de semillas aleatorias.

Asi que bueno, LGV2 esta cancelado y se ira diluyendo a lo largo de este fin de semana, y LGV3 parece que funciona (y hasta Celtar me dice que funciona Smile). Todavia os vais a encotrar con alguna tarea larga, pero ahora se puede usar el porcentaje para saber a que atenerse. En las tareas "*cortas*", el porcentaje nos dice cuanto falta para el peor de los casos (los 15000) segmentos, que en nuestras maquinas es de unos veintipocos minutos. En las tareas que no llevan la palabra "corta" el porcentaje de LGV3_1.01 todavia no es indicativo de nada, se queda en numeros muy bajos.

14/04/2007 17:14 #. Tema: problemas Hay 11 comentarios.

13/04/2007

lgv2

Ireis viendo distintas versiones de lgv2. Nuestro cientifico de a bordo, Jose Luis, despues de analizar una pequeña muestra de las B1cortas y ver el tamaño de los resultados, estimó que poniendo un tope de calculo de 15000 segmentos (ahora no recuerdo cuantos milisegundos de particula es eso) se garantizaria que entrariamos dentro del tope de CPU, porque en el analisis se veian algunas trayectorias de mas de 15000.

La estimacion se ha quedado un poco corta, asi que he aumentado el tope de CPU en un 50%. Entre eso y el tope de calculo, las tareas de sabado y domingo deberian ir dejando poco a poco de dar errores (todavia hay muchas tareas viejas en la cola). Pero de momento la relacion es 1:4, que es bastante molesto, una de cada 5 tareas golpeando el limite de CPU.

Cientificamente no es un problema, porque es la cola de la distribucion. Os puede sonar la "Long tail", un concepto que el año pasado estuvo muy de moda en los libros de autoayuda para financieros modernos, especialmente para aquellos que planean negocios en internet. La cola de la distribucion contiene, en porcentaje, pocas trayectorias, pero con las cantidad ingente que calculamos pues es logico que nos tropecemos con ella y tenemos que ir estimando cuanta CPU tardamos en darnos el "coletazo".

Si estais ya con la version 2.1 de lgv2, podeis ver que el campo de progreso no va de 0 a 100 porque se me olvido decirle a JL que el manager boinc lo espera como un tanto por 1... pero se supone que en el caso de B1cortas el 100% (el 10000%) serian los 15000 segmentos. En el caso de B0 hay un cero mas, dado que el 100% serian 10 trayectorias. Naturalmente, lo normal es que la particula choque con la pared del reactor antes de llegar a los 15000 segmentos, asi que ahora el porcentaje no es una estimacion realista, pero al menos es mejor que tenerlo en el 0% de antes.

ACTUALIZACION: Teneis razon, las B0 tambien agotan la CPU. Las he dejado de producir, pero habra por ahi coleando unas cuantas. A ver si lo conseguimos controlar durante el fin de semana.

OTRA ACTUALIZACION.

Voy a repetir yo la cuenta. En mi maquina la B1corta tarda en llegar al 5.00% 1 minuto y 40 seg. Eso significa que el 100.00% lo alcanzaria en unos 33 minutos. En el cliente boinc, el menu avanzado->pruebas de rendimiento da vueltas un ratito y me informa de que mi maquina tiene 1215 "floating MIPS": Por tanto al cabo de 33 minutos mi maquina habria podido hacer 2 430 000 000 000 operaciones. En notacion cientifica, 2.4 E12, y esta es la cantidad que se usa para poner el "CPU limit" que nos esta dando tantos quebraderos de cabeza. En la configuracion de las workunits yo puse por lo tanto fpops_est=2e11 (el "promedio" esperado) y fpops_bound=6e12, el doble de lo necesario. ¿Y aun asi revientan algunos B1 tambien?

Bueno, lo he subido a 9e12. Dandole la vuelta, eso significa que mi maquina estara procesando durante 9 000 000 000 000 / 1 215 000 000 = 7407 segundos = 2.05 horas. Es cuatro veces el tiempo que, segun el porcentaje, deberia tardar en acabar en el peor peor de los casos.

13/04/2007 21:10 #. Tema: problemas Hay 8 comentarios.

07/04/2007

¿Como cambiar/establecer el password de la cuenta?

Desde el manager, pulsando en el icono de proyecto en la vista simple (o en el boton Zivis de la etiqueta de Proyectos en la vista avanzada) se lanza automaticamente una pagina web. De ahi se navega a Your Account y de ahi a opciones para "Change" de password y demas.

07/04/2007 22:34 #. Tema: problemas No hay comentarios. Comentar.

02/04/2007

Tengo otra duda sobre Zivis ¿Dónde pregunto?

Hay cuenta de email general, zivis@unizar.es. Alternativamente, se pueden dejar comentarios en esta primera entradilla del blog y nosotros los iremos recortando y atendiendo en su caso. Es mejor que intenteis usar el sistema de comentarios para no sobrecargarnos. Insito: ES MUCHO MUCHO MEJOR que intenteis usar el sistema de comentarios; nos llega email igualmente y hay la posibilidad de que otros usuarios ayuden.
02/04/2007 22:09 #. Tema: problemas Hay 31 comentarios.
BIFI - CIEMAT - Ay. de Zaragoza / © Ayuntamiento de Zaragoza / webmunicipal@zaragoza.es / Mapa Web / Miembro W3c / XHTML 1.0 / CSS 2.0 / Accesibilidad