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 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
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
.
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.
A vos claviers
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).