Blogia
Blog de Ibercivis

velocidad*tiempo=credito

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.

¿Y esta publicidad? Puedes eliminarla si quieres

12 comentarios

jordan shoes -

El reloj de arena recuerda el momento en que perdió!

Cheap Jordan shoes -

Les paroles représente. Très bien. Grâce à votre parler, je suis vu une vertu à maints égards.

Cheap Car Hire Alicante Airport -

I had been arguing with my close friend on this issue for quite a while, base on your ideas prove that I am right, let me show him your webpage then I am sure it must make him buy me a drink, lol, thanks.

- Lora

andrea.p -

Y si alquien, sistemáticamente, aborta unidades por capricho, con cortarle el grifo...

También, como dice Algol, se tendría que tomar demasiadas molestias para gestionar el "solamente ejecutar las mejores unidades". No le compensaría.

Saludos.

José Luis Poveda

algol -

Hola.

Con respecto a abortar unidades puede haber dos problemas.

Uno es hacerlo antes de procesarlas, pero si no se puede saber a priori cuánto va a durar una unidad, no se podrían "elegir" las que van a durar menos y descartar las que duren más.

El otro es esperar a ver cuánto dura la unidad. Pero como bien dice José Luis, en una unidad pequeña el hecho de esperar para ver si se pasa de la media o no para abortarla creo que es flaco negocio para el que lo haga, pues desperdicia mucho más tiempo de proceso del que "gana", aparte que sería muy tedioso y el número de unidades que podrían verse afectadas por esta práctica sería muy pequeña.

Salu2.

Fer.

andrea.p -

Abortar un trabajo porque dure mucho tiempo se podría dar en caso de unidades con varios días de proceso. Ninguna de las de Ibercivis se encuentra en esta categoría y, si fuera necesario usarlas en algún proyecto nuevo, siempre se podría ir dando "puntuación a cuenta" en momentos puntuales, sin necesidad de haber acabado el proceso.

Saludos.


¿Y esta publicidad? Puedes eliminarla si quieres

Alejandro Rivero -

Hay un mecanismo de "fijo+variable" que va como sigue: internamente se siguen calculando los creditos de la manera habitual y se emplean para calcular un "credito promedio por workunit". Cuando se comienza una aplicacion nueva, la puntuacion es un 100% clasica y 0% de ese credito promedio. Cuando se han calculado las primeras 10000 unidades uno va poniendo digamos 50% clasico, 50% promedio, y al cabo de un par de semanas, ya con los datos promedio, se asigna ya el 100% con el credito fijo.

Incluso aplicaciones como materiales tienen su puntito de injusticia con el credito fijo, dado que cuando materiales termaliza necesita unas cuantas operaciones mas (la segunda mancha verde en hiperbola, arriba hacia el centro, que solo se ejecuta sin error en maquinas muy potentes)

De todas formas, la mayor prevencion que que le tengo a los creditos fijos es que se pueda cojer el vicio de abortar los que duren mas, aun sabiendo que entonces ya no cobras el credito.

andrea.p -

Hola.

Abundo en lo indicado por mi compañero Algol, más que en el nivel comparativo entre proyectos BOINC me preocupa que exista discriminación por CPU y o Sistema Operativo. La puntuación fija evita agravios y corruptelas. Más adelante se podría discutir si es conveniente converger entre proyectos, ahora ni me lo planteo, hay muchos otros problemas a solucionar.

Promediar con sesgo docking y fusión me parece una idea a estudiar, conseguir una óptima correlación duración-puntuaje haría el proyecto más justo.

Saludos.

JlPoveda.

algol -

Hola.

Tienes razón, este es un hilo mucho más "al respecto" que el anterior, mea culpa. Mi intención era llamar la atención de que un sistema de crédito fijo sería más justo por varios motivos, como te comenté en persona el día de la inauguración. Así que el tramposo me vino de perlas. No creo que sea necesario crear un hilo de alertas de trampas, aunque si se permite que algunos puntúen con ventaja se fomenta que el resto no tenga muchas trabas morales en hacer lo mismo, pues al fin y al cabo no es algo que afecte a la calidad científica de los resultados. Por eso creo que sería ideal llevar adelante lo que comentas del crédito fijo, independientemente de que haya concursos.

Como decías, en materiales es fácil hacerlo, y sería un sistema justo por lo comentado y además porque las aplicaciones windows son más rápidas que las linux en este proyecto, pero normalmente los ordenadores linux dan más crédito porque sus clientes BOINC dan benchmarks más elevados. Es decir, es más recompensado el ordenador que entrega menos resultados al día, lo cual no es justo.

Y ante la complicación de docking y fusión no me parece mala idea la estrategia del promedio y el plus. En varios proyectos BOINC ya asignan un crédito fijo a cada unidad de trabajo basándose en un promedio (y son mayoría los que usan sistema de crédito fijo). En este caso puedes tener unidades con tiempos muy dispares, pero a medida que vayas acumulando unidades procesadas te acercarás al promedio fijado.

Salu2.

Fer.

Alejandro Rivero -

Lo que quizas habria sido mas informativo (pero mas dificil de entender a nivel no profesional) es un log-log. Ahi se puede ver que fusion (los granates) y docking (los azules) tambien tienen comportamientos hiperbolicos, y que su numero total de operaciones es mas pequeño y mas disperso que el de materiales.

Quizas lo que debamos hacer en temporadas de concurso, si queremos un concurso de productividad (yo prefiero los de atencion, que puntuan solo tiempos de cpu por host) es asignar creditos mediante la estrategia de un fijo correspondiente al promedio y quizas un plus, separado de lso creditos BOINC, por los trabajos largos.

Alejandro RIvero -

No te preocupes, que las curvas las hemos dibujado con las tres posibilidades (benchmark entero, flotante, y mezcla) y tienen todos el mismo aspecto. Es cierto que el entero añade ruido, debido sobre todo al sistema operativo, pero no demasiado.

alfonso tarancon -

En Docking y en Fusion todo el calculo (relevante) es en coma flotante. Las curvas para estas aplicaciones son confusas. Tal vez se podrian rehacer poniendo en el eje de las x la potencia en coma flotante solamente, no la suma de coma flotante y calculo entero, que quizas añada ruido a la grafica.
¿Y esta publicidad? Puedes eliminarla si quieres