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

[JeromeC]

C'est vrai que l'idée de Spica est pas mal.

Appelle David !

[b3rl1go]

Il suffit de faire des badges pour me récupérer

Justement, les projets non "badgeurs" ont-ils été démarchés pour leur proposer d'en intégrer?

[Spica]

certains oui, Einstein par exemple... C'est notre camarade Nico qui avait lancé l'idée: certains membres du forum ont trouvé cela une bonne idée, d'autres ont cassé l'idée...

[JeromeC]

Certainement plus facile à faire sur un projet jeune sans culture trop marquée ni base utilisateur trop installée... (cf. "la résistance au changement")

[JeromeC]

Je ressuscite ce vieux topic car je suis abonné à la mailing liste "boinc_projects" où des admins de projets parlent de divers sujets, et y'a une discussion très intéressante que je vous traduits
(légers ajustements à la merveilleuse traduction Deepl) :

yoyo : (l'admin du projet yoyo)

Bonjour,

dans certains projets avec des mt-apps et où les unités de travail ont des temps d'exécution imprévisibles très différents, les tricheurs ont trouvé des moyens de
tricher avec le creditNew pour obtenir beaucoup plus de crédits que les autres utilisateurs.
Ils exécutent par exemple une unité de travail qui était censée fonctionner sur 8 cœurs sur un seul cœur.
Pour autant que je sache, la base de creditNew est le temps d'exécution et ils ont beaucoup plus de temps d'exécution, donc ils obtiennent beaucoup plus de crédits que les autres.
Après 1 ou 2 unités de travail, ils créent un nouvel hôte et recommencent encore et encore.

Serait-il préférable de baser le creditNew sur le temps processeur plutôt que sur le temps d'exécution ?

yoyo

Richard Haselgrove : (je sais plus sur quel projet il bosse j'ai déjà vu son nom souvent par le passé)

N'oubliez pas que de nombreux projets fournissent également des travaux pour les GPU. Le temps CPU d'une tâche GPU peut représenter entre 0 et 100 % du temps d'exécution, selon la nature de la tâche, le langage de programmation choisi et les compétences du programmeur.

Le changement que vous proposez peut avoir des implications ailleurs, et doit être mûrement réfléchi.

Charles Elliott : (lui aussi son nom me parle... can't remember)

Baser le crédit sur le temps d'horloge murale ou le temps CPU n'a pas beaucoup de sens.  Prenons l'exemple suivant :

J'ai les GPU suivants dans mon système

- Une AMD Radeon RX 580 (circa 2019) qui complète deux unités de travail (WU) d'Einstein@Home (E@H) en 16 minutes, soit 8 minutes par WU.
- Une NVidia Tesla K80 (datant de 2014) réalise deux unités de travail en 56 minutes, soit 28 minutes par unité.

La technologie a progressé entre 2014 et 2019 permettant d'accomplir plus de 3 fois le travail dans le même temps (wallclock, CPU ou GPU).

E@H accorde un crédit par unité de travail correctement réalisée. De son point de vue, c'est logique. Il ne se soucie pas et ne peut pas se soucier de la quantité ou de la durée d'immobilisation du système de l'utilisateur.  Les utilisateurs se font concurrence en achetant la technologie la plus récente.  Tout le monde paie pour les résultats, pas pour le temps consommé.  Le rendement du travail est sa productivité marginale.  Dans une aciérie, les ouvriers du haut fourneau sont moins bien payés que ceux du convertisseur basique à oxygène (CBO), moins bien payés que ceux du laminoir, moins bien payés que ceux du laminoir de finition.  Pourtant, tous travaillent 8 heures par jour.  C'est la valeur de leur production qui change.  La fonte brute provenant d'un haut fourneau vaut moins qu'une brame d'acier provenant d'un convertisseur à oxygène, moins qu'un rouleau d'acier semi-fini provenant d'un laminoir, moins qu'un acier galvanisé coupé à la largeur exacte requise par la machine à estamper du client.  De même, le coût d'une erreur d'un travailleur augmente à mesure que le temps de traitement du produit s'allonge.  Par conséquent, plus le produit a de valeur, plus les travailleurs sont payés pour concentrer leur attention et encourager la réduction des erreurs.

Charles Elliott

yoyo répond :

Tous vos arguments sont valables pour baser les crédits sur une complexité connue.
Mais ce n'est pas possible dans mon cas, puisque l'algorithme utilisé est un algorithme de factorisation d'essai.
Cela signifie qu'il peut se terminer en une minute seulement ou s'exécuter en plusieurs heures. Le temps d'exécution n'est pas prévisible et dépend de nombreuses graines choisies au hasard pendant l'exécution de l'unité de travail.

Même en le calculant sur un deuxième ordinateur, le temps d'exécution est totalement différent.

yoyo

Et Dieu a répondu :

Il existe plusieurs options pour l'attribution des crédits ; voir
https://boinc.berkeley.edu/trac/wiki/CreditOptions

-David

[JeromeC]

La discussion continue

Eric Korpela (encore l'admin d'un projet je me souviens plus lequel, ou alors un des dev de boinc historique ? can't remember)

C'est étonnant de voir à quel point toute cette histoire de crédit est encore confuse.

Baser le crédit sur le temps CPU ne signifie pas que deux machines différentes obtiennent le même crédit par seconde CPU.

Le système de crédit BOINC original était basé sur le temps CPU multiplié par les scores de référence.  Credit_new a changé cela pour être le temps écoulé multiplié par un nouveau facteur multiplié par les scores de référence, ce qui cause le problème potentiel avec les applications multithread mentionnées en premier.

Pour autant que je sache, SETI@home est le seul projet qui a réellement compté les PO (dans le système de crédit original, credit_new l'a détruit).  Presque tous les projets surévaluent leur traitement (surtout sur les GPU).  SETI@home est, à ma connaissance, le seul projet qui ait jamais évalué les OPs des GPUs et des CPUs de manière égale en ne séparant pas les applications GPU et CPU.  Certains projets qui utilisent des applications multithreads n'accordent même pas la même valeur aux OP multithreads et aux OP à CPU unique, car certains utilisent (par exemple) 8 threads, mais ne gardent que 5 CPU occupés, tout en réclamant 8 fois le crédit.  De même, la "tricherie" de la part des volontaires mentionnée dans le premier message.

J'avais sérieusement envisagé de faire une modification de credit_new pour les applications multithreads qui aurait été un retour de facto au temps CPU, en ajoutant un champ n_cpus à la structure host_app_version.  Le n_cpus aurait été calculé comme le ratio médian courant du temps cpu par rapport au temps d'exécution, et aurait été utilisé dans le calcul du crédit et les demandes de travail.

Mais personne n'était intéressé. 

Les crédits des projets croisés n'ont aucune signification, et les nouveaux projets gonflent les crédits en offrant plusieurs fois les crédits d'un projet qui a démarré il y a des années.  (Universe@home offre 25x le crédit de rosetta ou de climateprediction).   Il aurait été bien d'offrir un marché de crédits stable, ce qui aurait pu être fait en faisant dépendre la part des ressources du RAC plutôt que d'une fraction des ressources locales.  Des parts égales de ressources égaliseraient le RAC d'un projet, donc si un projet accorde 25 fois plus de crédit, il se retrouvera avec 1/25ème de la puissance de traitement qu'il obtiendrait s'il offrait un crédit égal.   Mais là encore, personne n'était intéressé car ils avaient déjà gonflé leurs propres crédits.

Nicolas Alvarez (encore un nom qui me parle... je crois que je deviens vraiment vieux en fait )

Vous devriez le rendre déterministe, inclure la ou les graines dans les paramètres de l'unité de travail afin que l'exécution de la même unité de travail deux fois donne le même résultat (et le même temps d'exécution). Reprendre une unité de travail suspendue pourrait être difficile cependant (il faudrait sauvegarder l'état du RNG dans le point de contrôle)...

C'est étonnant de voir à quel point toute cette histoire de crédit est encore confuse.//

Si je me souviens bien, lorsque SETI@Home est passé au comptage des PO, il a aussi accidentellement donné deux fois plus de crédits qu'avant (et que d'autres projets), et lorsque cela a été remarqué, la définition du crédit a été modifiée pour correspondre à celle de l'OP.

https://boinc.berkeley.edu/w/?title=Computation_credit&diff=prev&oldid=2818

J'avais sérieusement envisagé de faire une modification de credit_new

Comme je l'ai déjà dit il y a des années, étant donné un CPU et un GPU spécifiques, et
étant donné deux projets où :
L'application GPU de Foo@home est 3 fois plus rapide que son application CPU.
L'application GPU de Bar@home est 6 fois plus rapide que son application CPU.

Il est *fondamentalement* impossible de créer un système de crédits où
#1 : les crédits par jour sur le CPU sont les mêmes pour les deux projets.
#2 : les crédits par jour sur le GPU sont les mêmes pour les deux projets.
#3 : dans chaque projet, la même WU devrait donner les mêmes crédits, peu importe le processeur utilisé

Et nous avons passé des années à discuter de la manière de modifier le système et de mesurer les choses différemment pour rendre le point 1 plus précis tout en ignorant le point 2. Cela a plusieurs conséquences. Si deux projets ont une bonne "parité de crédit parité de crédit" en termes de #1, alors moins l'application CPU d'un projet est optimisé (et donc plus elle est longue et plus elle donne de crédits par UW), plus il donnera de crédits aux utilisateurs de GPU en raison du point 3.

Que se passe-t-il si, un jour, un projet trouve un moyen de rendre l'application CPU plus rapide, sans modifier l'application GPU de quelque manière que ce soit ? S'ils gardent les mêmes crédits par UW, alors les utilisateurs du CPU obtiennent plus de crédits par heure qu'avant (et que les autres projets). (et que les autres projets). S'ils gardent les mêmes crédits par heure CPU (moins par UW), alors les utilisateurs de GPU obtiennent moins de crédits par heure qu'avant, et peut-être préféreront-ils maintenant aller sur un autre projet. En donnant donner des crédits différents au CPU et au GPU pour le même résultat (en ignorant le n°3) est un non-sens, et facile à tricher : un tricheur pourrait exécuter l'application sur le GPU et et prétendre qu'elle était sur le CPU.


Les crédits inter-projets n'ont en effet aucun sens. Peut-être que la meilleure chose qui puisse être faite pour améliorer le système de crédit est de faire en sorte que les sites de statistiques les sites web de statistiques cessent d'afficher un "total" additionnant plusieurs projets. Ils sont dans des unités différentes, vous ne pouvez pas simplement les additionner. Ou se débarrasser du le DICP et alors ils n'ont pas le choix

La proposition de "partage des ressources lié au RAC" est également intéressante...

Richard Haselgrove (ok, ok, j'arrête d'essayer...)

Il n'y a qu'un seul endroit où les crédits comptent vraiment : c'est lorsqu'ils sont reconvertis en flops pour rendre compte de notre taux de progression au reste de la communauté scientifique. En l'absence d'une procédure de comptage des flops comme celle de SETI, ce chiffre est particulièrement suspect.

Je soupçonne qu'une grande partie des flops rapportés sur https://boinc.berkeley.edu/chart_list.php sont en réalité des iops.

[greatoliver]

En effet BHS c'est assez compliqué

@xipehuz: ton système ne convient pas du tout, pourquoi c'est simple, tu dis 1min de calcul = 1 crédit, en gros je calcule 1h avec un seul core de mon C2D à 3.2ghz, et 1h avec un P2 à 266mhz, les deux pc auront donc 60pts chacun .... c'est ridicule, un core d'un C2D à 3.2ghz fait 15 - 20 fois plus de calcul qu'une P2 à 266mhz

A ce moment là ça privilégie uniquement les très vieux pc et ceux qui investissent dans des C2D, C2Q bha ils se feront bien entuber

Je suis tout à fait d'accord, c'est un peu de la politique dans le fond, soit on n'incite pas les gens à exploiter et à utiliser tout ce qu'il y a de plus performant (dernières technologies), soit on reste dans un système "communiste" où tout le monde à la même récompense quelque soit le travail effectué, dans ce dernier contexte, cela ne motive pas à faire plus et cela ne sert pas le projet. La compétition reste ce qu'il y a de plus performant (capitalisme). Il est vrai cependant qu'il faut inciter plus de monde à utiliser le calcul distribué, y compris ceux qui ont des PC moins récents.

Il faudrait donc soit un système hybride qui tienne compte de plusieurs facteurs, soit continuer avec plusieurs statistiques comme sur WCG où c'est plutôt bien fait, il y a le classement au temps, aux nb d'unités renvoyées et au nombre de points avec la puissance. Cela permet à chacun de trouver sa justice.

Si je comprends bien, c'est le système de points qui pose problème. Je ne suis pas un expert et j'aurais du mal à me prononcer techniquement. Le débat est ouvert et intéressant.

[Oncle Bob]

Pour le temps passé il y a déjà WUProp, projet NCI de Seb qui stat sur le temps passé sur chaque appli (que ça soit avec une merde en ARM ou le dernier CPU surpuissant sorti).

[JeromeC]

Mmmmmmm ça c'est quand il y arrive