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.
12 comentarios
jordan shoes -
Cheap Jordan shoes -
Cheap Car Hire Alicante Airport -
- Lora
andrea.p -
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 -
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 -
Saludos.
Alejandro Rivero -
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 -
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 -
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 -
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 -
alfonso tarancon -