Blogia
Blog de Ibercivis

results en ejecucion

results en ejecucion

Aqui os ponemos la gráfica de la semana con las unidades enviadas a ejecucion (estrictamente, los "results"). Se puede ver la tarea de docking que acabó el martes y tarda un par de dias en terminar de verdad, lo que no es problema para una tarea que dura meses. Se puede ver tambien una ejecucion en "modo de continuidad", que mantiene mas o menos un nivel constante de procesadores trabajando para ella. Y se ven un par de paradas en la verificacion de resultados o en la creacion de nuevas unidades de trabajo, que causan esos picos descendentes de cuando en cuando.

Estamos pensando en poner estas graficas semanales en el nuevo sitio web, pero no tenemos aun claro donde. Seguramente serian capturas de PNGs, en vez de datos sobre los que hacer zoom.

7 comentarios

Air Yeezy -

Man, the servant and interpreter of nature.

DunksNike -

Every day is blue day. If you encounter a setback, please look up to the sky, if only the sky is blue, you don't lose the hope.

Deuvedé -

@EMMANUEL: No tenemos ningún problema en abordar proyectos en cualquiera de las áreas de estudio que mencionas. Sólo hace falta un investigador de esos campos interesado en trabajar con nosotros.

@Jorge Mena: ¡Gracias por la pista! :D El problema parece venir del cálculo del factor de corrección de duración (duration_correction_factor). Habrá que mirar a ver.

Jorge Mena -

Hola, ya he visto donde está el primer problema que os conté en mi anterior comentario.
Si activo un par de flags de debug en el cc_config.xml, obtengo:
[work_fetch_debug] Request work fetch: timer
[work_fetch_debug] compute_work_requests(): start
[work_fetch_debug] compute_work_requests(): cpu_shortfall 1209557.151814, overall urgency Need immediately
[work_fetch_debug] project DCF 100.000000 out of range and have work; skipping

Mirando de donde viene el último mensaje de error, me encuentro:
(boinc 6.2.14 (debian lenny), work_fetch.C, línea 540)
// If the project's DCF is outside of reasonable limits,
// the project's WU FLOP estimates are not useful for predicting
// completion time.
// Switch to a simpler policy: ask for 1 sec of work if
// we don't have any.
if (p->duration_correction_factor duration_correction_factor > 80.0) {
...

Ese comportamiento "comentado" es justo lo que me pasa. No sé si será problema del cliente o de Ibercivis, pero de momento comentando ese "if" mis máquinas vuelven a pedir tareas como debería ser ;-)

Un saludo

EMMANUEL -

¿Porque no poner ciertas actividades de defensa y la aeronautica?Nuevos desarrollos aerodinamicos,desarrollo de turbinas y reactores/scranjets,etc.

Deuvedé -

Ni idea de porqué ocurre esto. Respecto a lo segundo, que yo sepa, no tenemos ningún límite acerca del ancho de banda del usuario, pero es cierto que también ocurre.

Jorge Mena -

Hola, tengo dos problemas con el comportamiento del boinc para pedir nuevas tareas

EL primero:
Mi quadcore deja de solicitar tareas nuevas hasta no haber terminado literalmente todas las que tiene, entonces hace una única petición de trabajo de dos millones y pico de segundos, entregando el trabajo de un día y obteniendo cinco tareas. Pero ya no vuelve a pedir más trabajos hasta no terminar esas cinco tareas.
Si hago una petición manual las hace con 0 segundos, aunque tenga 3 procesadores sin trabajar.
Eso lo hace durante horas hasta que me doy cuenta y reinstalo el boinc (borrando todo).

Una vez reinstalado el boinc, el problema no volvía a aparecer hasta una semana después, pero este fin de semana se bajaba unos 100 trabajos seguidos y volvía a dar el problema.
Hoy ya no hay forma de que el boinc trabaje bien en ese ordenador. Ahora después de reinstalarlo, me baja entre 16 y 18 tareas (sobre una hora de trabajo) antes de dar el problema, y cuando está con el problema sólo recibe un trabajo, así que ya no trabaja más que un procesador.

Tengo otras 3 máquinas más trabajando continuamente y el problema solo afecta a otra pero semanalmente.
En todas ellas se ejecuta Boinc 6.4.5 bajo Debian Testing 64bits (más o menos)

Para descartar causas he probado a ejecutarlo en un chroot con Debian Stable y a usar la versión anterior de Boinc 6.2.18, pero sigue pasando.


Problema segundo:
Otra máquina distinta (curiosamente es a la que le pasa el anterior problema semanalmente) cuando pide nuevas tareas, me sale este error:
"nanoluz requires 1.96 kbps download bandwidth. Your computer has been measured at 1.96 kbps."
La máquina está conectada en red con otros dos ordenadores que no dan ese error, y la conexión a Internet es de 1Mb/300Kb
De momento lo soluciono modificando los campos bwup y bwdown del client_state.xml, les pongo el valor de otros ordenadores de la red, pero es un incordio ya que hay días que tengo que hacerlo varias veces.


Un saludo