L'Alliance Francophone > Stats

[Discussions permamentes] Le système des crédits BOINC/PROJETS

(1/72) > >>

Black Hole Sun:
:hello:

Certains d'entre vous sont au courant : sous l'impulsion de David Anderson (responsable de la plateforme BOINC), plusieurs projets sont actuellement sommés de revoir les crédits qu'ils attribuent à la baisse. C'est notamment le cas du projet QMC@Home qui a déjà entrepris une première baisse de 25% du crédit/heure alloué.

Pour ceux des projets qui ne se conformeraient pas à la régle, David Anderson s'est mis en rapport avec les principaux sites de stats et en collaboration avec eux, les crédits sur les projets ne respectant pas une valeur de crédit/heure dans la norme seront pondérés directement par les sites de stats.

On peut polémiquer à l'envie sur la décision de David Anderson / sites de stats, mais cela ne fera pas avancer le débat.
Donc, vous êtes priés de ne pas commenter ce point précis :jap:


Comprendre le système de comparaison des crédits entre projets :
- les hôtes servant à la mesure doivent tourner sur au moins 2 projets (de cette manière, il s'agit bien de la même machine (oc ou pas), du même os et de la même architecture 32/64 bits)
- la mesure effectuée est simple : on compare le rendement horaire en crédit des hôtes sélectionnés sur les 2 projets (ou plus). Le crédit / heure de chaque hôte peut ainsi être facilement comparé entre les projets.

L'objectif de l'équipe de BOINC est donc de ramener les projets sur un même pied d'égalité afin que chacun d'eux bénéficie de l'intérêt des volontaires que nous sommes non pas en fonction du crédit accordé mais en fonction de l'intérêt scientifique (ou autre) que chacun de nous y trouve.

Jusque là, dans l'intérêt de la science et des projets, voire même dans notre intérêt, l'intention est parfaitement louable. C'est en revanche au niveau de l'application que se concentrent les problèmes.


Les obstacles :
1. Les projets sont tous différents et font appel à des instructions ou des ressources machines différentes. Ainsi, Seti@Home dans sa version officielle (non optimisée) ne fait pratiquement pas appel au cache du processeur, contrairement à QMC@Home qui l'utilise de manière très intensive. De même, ABC@Home fait appel de manière très intensive à l'unité de calculs flottants du processeur et le rendement d'une machine ne sera pas du tout le même que le cpu soit un Core2Duo ou un K6 AMD (par exemple, vu que ce processeur est connu pour sa faiblesse dans ce domaine).

2. Tous les projets ne proposent pas des clients pour toutes les plateformes (Linux 64, Linux 32, Windows 32, Windows 64, Mac Intel, Mac PPC, PS3 ....) d'où des comparaisons de fait partielles entre les projets. Car tous les projets sont loin de fournir toutes les applications pour fonctionner sur toutes les machines. Nous en savons quelque chose puisque nous sommes en pleine préparation d'un RAID et que nous sommes confrontés à ce problème :o

3. Tous les projets n'exploitent pas les ressources matérielles de manière optimale. C'est une évidence : nombreux sont les projets qui ne prennent pas la peine d'écrire de vraies applications 64 bits (par exemple). Nous avons parfois droit à une simple compilation native 64 bits, souvent à une bidouille plus ou moins heureuse pour assurer un mode de compatibilité, et dans une grande proportion, nous n'avons tout simplement pas de client.

4. Tous les projets n'utilisent pas le système de crédits fixes par unité de travail. Certains récalcitrants font encore appel aux benchmarks et sont donc des cibles potentielles privilégiées pour la triche. L'excuse officielle avancée par ces projets est la suivante : leurs unités de calcul ont des durées d'exécution très variables et le système de crédit fixes est trop complexe à mettre en place :sarcastic: .


Voila donc le problème qui est posé. Les discussions sur ce thème ne se tiennent pas de manière publique et sont disséminées un peu partout sur différents forums de projets et servent essentiellement à des posts enflammés pour ou contre la décision de David Anderson (noms d'oiseaux compris). Mais absolument rien de concret n'en ressort.

J'ai proposé à David Anderson de faire réfléchir les membres de l'Alliance Francophone à ce sujet et de lui soumettre le résultat de nos débats sous forme d'une proposition qu'il sera libre d'intégrer ou pas à ses propres réflexions sur le sujet.
Car il me semble que nous sommes concernés au premier chef (de même que les projets), or nous sommes pour le moment tenus à l'écart des discussions. Or sans nous, les projets ne sont rien et je ne vois pas de quel droit nous, les volontaires, n'aurions pas notre mot à dire. Autant remédier à cela de notre propre initiative en mettant en place un débat constructif visant à faire une proposition sérieuse à David Anderson.

Nous disposons d'autant de temps qu'on veut pour ficeler une proposition. Il faudrait tout de même qu'on parvienne à quelque chose dans un délai raisonnable. Pour moi, raisonnable signifie avant la fin du mois.

:bounce: A vos claviers :bounce:


Centralisation des idées :

Rom_185 :
De manière aléatoire mais régulière, chaque projet envoie une wu de bench non identifiable. Cette wu permet d'étalonner la puissance de l'hôte.
Avantage : bien qu'il s'agisse d'un bench côté utilisateur, le risque de triche est pratiquement inexistant (comme baisser la vitesse du processeur le temps du bench pour la remettre à fond ensuite et sur-créditer).
Inconvénient : nécessite la mise en place par tous les projets de ces wus bench et de leur envoi automatique régulier à chaque hôte.
Autre inconvénient : les projets à wus très longues comme CPDN. Dans ce cas, le bench devra intervenir en cours de calcul de la wu (ie, être intégré dans l'unité elle-même).

Black Hole Sun:
Pour ma part, je me suis déjà livré à quelques réflexions sur le sujet :

Point 2. Forcer tous les projets à proposer des compilations natives pour les 5 principales plateformes logicielles : Windows 32, Windows 64, Linux 32, Linux 64 et Mac Intel.

Point 1 et 3. Forcer tous les projets qui déclarent publier les résultats de nos calculs à davantage de transparence. En effet, parmi le très faible nombre de projets qui publient les sources de leurs applications, hormis Seti, les autres projets ne les publient pas. Eventuellement, ils en publient une partie, mais en aucun cas les sources mises à disposition ne permettent de compiler et de recréer leur application. En résumé : nous ne savons pas ce que nous calculons hormis nous fier aveuglément à ce que les projets veulent bien nous dire.
Ceci permettrait notamment à des volontaires de proposer aux projets le support de leurs applications à d'autres plateformes logicielles ou matérielles, et de les optimiser. Toutefois, il faudrait dans ce cas restreindre l'usage de ces versions "optimisées" aux projets (en clair, plus de versions "Lunatics" ou "Crunch3r" qui se baladent sur le web).

Point 4. La triche a été et reste un grave problème. Le système de crédit fixe par wu devrait être rendu obligatoire à TOUS les projets. Pour ceux dont la durée des unités de calcul varie fortement, il suffirait de mettre un système simple en place à base de paliers :
- de 0 à 1.000 secondes => n points
- de 1.000 à 10.000 secondes => n*x points

Etc... avec des paliers à fixer selon les projets.

XTC_ZeuZ:
Pour le système de crédit pourquoi ne pas faire comme ABC, ils n'ont pas de crédit qui varient en fonction du benchmark, ils sont fixe mais varie en fonction de l'unité, un fix variable quoi, qui ne tient pas compte du benchmark, faudrai voir comment il procède pour déterminer les crédits suivant telles ou telles unités

Je trouve cette initiative interessante, j'avoue ne pas aller sur certain projet parce qu'ils créditent trop peu, ça me saoule un peu de calculer comme un bourrin avec mes modestes moyens et ne pas voir mes stats avancer, mettre tout les projets sur un même pied d'égalité règlerai ce problème :p

Autre chose, j'espère qu'ils vont tenir compte des configs qui tournent en 64bits, par ex ABC qui tourne 2 fois plus vite sous un win 64bits qu'un win32 , il ne faudrai pas se faire avoir là dessu, si je calcul en 64bits et que ça réduite la durée de calcul par deux, je veux avoir 2 fois plus de crédit que si je calculais en 32bits pour un temps T donné, si je calcul 2h en 32bits je dois avoir les mêmes points que si je calculais 1h en 64

Je pense à ça, pour déterminer la vrai puissance d'un cpu, il n'est pas possible de crééer une wu bidon qui ferai office d'échantillon et qui serai envoyée sur différente archi de processeur pour faire un étallonage des performances?

Black Hole Sun:
Alors, le système de comparaison utilisé compare un même hôte sur 2 projets. Donc, la même machine sur ABC 32 et Seti 32 par exemple. Puis sous ABC 64 et Seti 64.

C'est là que se situe le coeur du problème : ABC a fait l'effort de développer une appli 64 bits très performante qui exploite toutes les ressources apportées par le 64 bits. En revanche, c'est parce que le type de calculs d'ABC s'y prête tout particulièrement. Un autre projet qui utilise des types de calculs différents ne gagnera peut être rien du tout à proposer une appli 64 bits.

Il est donc difficile d'avoir 2 poids 2 mesures pour un même projet : le crédit / heure pour un projet donné devrait être le même quelque soit l'architecture matérielle et logicielle utilisée. Le corollaire est malheureusement que les projets dont les calculs ne tirent pas partie du 64 bits ne feront aucun effort pour proposer une application pour cette plateforme :(

Pour le système de crédits fixes, ABC doit avoir des wus dont la durée est proche et peut donc créer des "lots" (telle fournée à x crédits, telle autre à y crédits). Certains projets ont des wus qui sont systématiquement de durées différentes, et avec de très grosses variations. Le système devient alors assez contraignant car chaque wu doit être calibrée.

En ce qui concerne une wu de référence, le problème est qu'elle ne peut pas correspondre à tous les types de calculs utilisés par tous les projets. De ce fait, une telle wu ne peut exister, sachant de plus qu'elle devrait être recomposée à chaque arrivée de nouveau projet sous BOINC et que tout le système de crédit inter-projet devrait être revu et mis à jour.

xipehuz:
Edit : Je viens de me relire et je réalise que j'ai dit une bétise. ça paraissait clair dans mon esprit, mais quand je l'écris, ça va pas. Il faut encore que je réfléchisse un peu plus. J'efface donc le début de mon post.

Pour rebondir sur ce que dit BHS dans son 2ème post :
Point 2 : je pense qu'on ne pourra jamais forcer des petits projets qui n'ont qu'un seul développeur (souvent à mi-temps) à distribuer des applis pour tous les OS.
Point 1 et 3 : difficile d'obliger à mettre dans le domaine public toutes les applis. Je suis sûr que bcp d'universités/labo de recherche doivent avoir des restrictions quant aux publications du travail de leurs employés
Point 4 : d'accord avec toi. Voir plus haut

Re-edit : grilled par ZeuZ  :lol:
Faut dire qu'un gros éclair est tombé à 100 metres de chez moi et que j'ai perdu ma connexion internet pdt 5 minutes  [:al@on:2]

Navigation

[0] Index des messages

[#] Page suivante