Le Forum de l'Alliance Francophone

Nouvelles:

Auteur Sujet: [Discussions permamentes] Le système des crédits BOINC/PROJETS  (Lu 90996 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
: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).



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #1 le: 09 March 2008 à 13:12
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

  • Invité
Réponse #2 le: 09 March 2008 à 13:26
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?



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #3 le: 09 March 2008 à 13:38
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.



Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #4 le: 09 March 2008 à 13:46
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]

Je prends les compliments comme des reproches d'hypocrites (Palinka)


XTC_ZeuZ

  • Invité
Réponse #5 le: 09 March 2008 à 13:50
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 :/



Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #6 le: 09 March 2008 à 14:02
Bon, j'ai réfléchi.

Ce que je voulais dire c'est : David Anderson prend une config lambda la plus commune qui soit (disons un p4 3 GHz sous WinXP 32bit). Cette machine fera tourner tous les projets et servira d'étalon. Pour elle, 1 minute de calcul = 1 crédit. Si ton PC (ou Mac) va plus vite qu'elle, tu auras plus de crédit et inversement (simple règle de trois)

C'est simple, non ?

Je prends les compliments comme des reproches d'hypocrites (Palinka)


XTC_ZeuZ

  • Invité
Réponse #7 le: 09 March 2008 à 14:07
Comme ça c'est plus simple oui et limite très interessant, après ça donnera peut être un peu trop de crédit, un p4 à 3ghz c'est pas très rapide par rapport à ce qu'on a maintenant, j'aurai un P4 qui fait 60pts/h par core je saute au plafond :D mais y'a de l'idée



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #8 le: 09 March 2008 à 14:08
Citation de: xipehuz
Bon, j'ai réfléchi.

Ce que je voulais dire c'est : David Anderson prend une config lambda la plus commune qui soit (disons un p4 3 GHz). Cette machine fera tourner tous les projets et servira d'étalon. Pour elle, 1 minute de calcul = 1 crédit. Si ton PC (ou Mac) va plus vite qu'elle, tu auras plus de crédit et inversement (simple règle de trois)

C'est simple, non ?


Oui et non :/

Les projets réalisent des types de calculs très différents.
Sur un P4, les extensions 64 bits ne sont pas présentes alors que certains projets s'en servent. A l'époque déjà, le fait d'avoir l'HyperThreading était soit un avantage, soit un handicap selon les projets.
Certains projets utilisent intensivement le cache L2 (voire L3) des processeurs alors que d'autres pas du tout. Certains projets utilisent intensivement voire exclusivement l'unité de calculs flottants alors que d'autres n'utilisent que des entiers.
Un AMD X2 sera plus à son aise sur un projet déterminé qu'un C2D alors que ce sera l'inverse sur un autre projet. Toujours pour une question de type de calcul employés par le projet.

Le résultat serait le suivant : certaines machines feraient X10 ou plus en crédit / heure que la machine étalon sur certains projets.



Hors ligne Jim PROFIT

  • Boinc'eur Respectable
  • ****
  • Messages: 896
  •   
Réponse #9 le: 09 March 2008 à 14:22
Bon la discussion va être houleuse!!

Tout d'abord ce n'est pas ce que j'ai compris http://boinc.berkeley.edu/trac/wiki/CreditProposal

Mais clairement il faut trouver un étalon, et chaque machine se basera sur cet étalon.

Je pense que c'est le plus simple, mais comme indiqué dans le lien, cela va être compliqué de prendre en compte toutes les spécificités.

 :hello:

Edit BHS : correction de la syntaxe du lien ;)



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #10 le: 09 March 2008 à 15:17
Je ne connaissais pas ce lien :??:

Faudrait que quelqu'un s'attaque à la traduction pour la coller ici :sweat:



Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #11 le: 09 March 2008 à 15:30
Effectivement, tout cela est beaucoup plus compliqué que je ne le pensais.  :sweat:

Mais j'aurais du m'en douter.

Je reste persuadé que le système de crédit doit être le plus simple possible.

Tant pis si certaines machines/OS sont meilleurs sur certains projets que d'autres. L'essentiel, c'est que l'étalon représente la config majoritaire et que les projets se basent sur la durée d'une UT sur cet étalon pour fixer le nombre de crédits pour ce type d'UT et ensuite extrapoler les crédits en fonction de la durée de calcul sur les autres machines. Je serais surpris que la différence de perf soit si grande que ça.


Je prends les compliments comme des reproches d'hypocrites (Palinka)


Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #12 le: 09 March 2008 à 16:44
Thrr avait proposé de ce basé sur le nombre d'opérations faites au total lors du calcul d'une UT (100k opérations faites = 1 point).

Ou alors j'ai pensé que les projets pourraient intégrés un micro-benchmark dans chaque UT ?
Ou sur la première UT ressue.

BOINC, les grandes énigmes de la science résolues en 2 temps 3 calculs
I reject your reality and substitue my own


Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #13 le: 09 March 2008 à 17:10
Tout système qui se baserait sur un benchmark utilisateur serait voué à la triche : ce serait un retour en arrière par rapport au système de crédit fixe / wu

Pour le nombre d'opération à effectuer, ça pourrait le faire : sauf que je ne suis pas certain que tous les projets sachent estimer ça correctement (notamment ceux dont les durées de calcul varient énormément), et que cela ne pourrait pas s'appliquer à Depspid par exemple (puisqu'il n'y a pratiquement aucun calcul)



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #14 le: 09 March 2008 à 17:14
Citer
Tout système qui se baserait sur un benchmark utilisateur serait voué à la triche : ce serait un retour en arrière par rapport au système de crédit fixe / wu
Ha oui :/.

Pour depspid, le système en vigueur est bien puisqu'il est basé sur le nombre de Mb uploadé et downloadé par l'appli :spamafote:.

BOINC, les grandes énigmes de la science résolues en 2 temps 3 calculs
I reject your reality and substitue my own


Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #15 le: 09 March 2008 à 17:33
Certes, mais comment tu le compares à un projet qui effectue des calculs ?
Il faut déterminer si ce type de projet qui peut parfaitement tourner en parallèle d'un autre projet doit fournir autant de crédits (donc, ça doublerait le rac normalisé d'une machine)



Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #16 le: 09 March 2008 à 17:56
Une autre possibilté pour satsifaire tout le monde et éviter de monter une usine à gaz, c'est d'obliger les projets à accorder les crédits dans une fourchette de valeur de manière à ce que les projets le plus et le moins créditeurs ne soit pas séparés de plus de 25 %

De cette manière, les projets sont libres de définir les crédits comme ils le souhaitent en fonction des contraintes de leurs UT, mais ils limiteraient automatiquement le "granted credit".

Bien sûr, cela oblige quand même à avoir un étalon pour chaque CPU/OS, mais ce serait peut être plus simple à gérer pour tout le monde.

Exemple : si Leiden donne du 20 crédits/heure sous un P4 Win XT étalon, ABC ne pourrait pas donner plus que 24 c/h, par exemple.
et si Leiden donne du 25 c/h/core sous Linux 64, alors Primegrid ne pourra pas donner plus de 30 c/h/c sous cette même plateforme, même si son appli est optimisée. C'est un peu injuste pour les applis optimisées pour certains OS ou CPU, mais cela limiterait les dérives.

Je prends les compliments comme des reproches d'hypocrites (Palinka)


XTC_ZeuZ

  • Invité
Réponse #17 le: 09 March 2008 à 18:01
Marchera jamais, comme tu le dis toi même c'est totalement injuste

Les projets mathématiques en 64bits voit leur temps de calcul divisé par deux, aussi bien sous win que sous linux, par contre les projets médicaux n'ont aucun gain ou très léger, sur un projet comme ABC, primegrid, simap tu sous créditerais le travail effectué, sous ABC tu ferais 2 fois plus de taff pour le même crédit que leiden

Je vois pas pourquoi il faudrai défavoriser une appli qui tournent plus que bien en 64bits par rapport à une autre où le gain est négligeable  :??:



Hors ligne Corran Horn

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1109
  •   
Réponse #18 le: 09 March 2008 à 18:25
Je pense que c'est une très mauvaise idée que je lis là.

Si les projets n'arrivent pas à se mettre d'accord sur le nombre de crédit à donner je ne vois pas comment il va s'y prendre.

1/ Changer les stats des utilisateurs via les sites de stats. Ca ne changera pas grand chose car il y aura d'autres sites de stats qui ouvriront pour satisfaire l'envie des utilisateurs.
2/ Que les utilisateurs qui sont content de faire plein de points doivent rester dans la course. Un utilisateur qui faisait x point avec son parc machine et qui ne ferait plus que x/2 arrêtera peut être de calculer. Au final c'est l'avancée de des projets qui va en souffrir.

Par contre je suis pour une espèce de validation du code en interne. Inutile de divulguer le code source par contre ça devrait être à "BOINC" de labeliser les projets qui fonctionnent sur leur plate forme.

J'aimerai bien aussi que sur tous les projets les wus soient calculées par au moins deux utilisateurs.



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #19 le: 09 March 2008 à 18:30
Le problème est bien là : en fonction des calculs (si encore il y en a cf depspid), les projets tirent avantage d'une plateforme matérielle et/ou logicielle. Ce qui fausse complètement les calculs.

Une manière de simplifier le problème serait de le faire par rapport au projet lui-même. Nous sommes d'accord qu'une WU est un bout du problème à résoudre (ou d'une série sur Einstein / LHC, ou d'une bande sur Seti ...) quel que soit l'hôte qui la calcule.

Il y aurait alors un étalonnage simple à faire : considérons les plateformes matérielles.
On prend 1 AMD double core, l'entrée de gamme.
On prend 1 Intel C2D, l'entrée de gamme.
On prend 1 Mac Intel et 1 Mac PPC, toujours l'entrée de gamme des familles de procos.

Cela représente un investissement de 4 machines par projet (ou que les projets trouvent 4 étalons communs à tous les projets, ou encore que ce soit l'équipe de Boinc qui s'en occupe).

Sauf pour Mac (qui tourne OS X, sinon ce sont des MacIntel Windows et donc des "PC Windows"), on installe XP32 et Linux 32 en dual boot.
Et on balance les calculs sur tous les projets. On peut alors déterminer le temps mis par chaque plateforme et OS pour les wus des différents projets.
On calcule alors la moyenne de temps mis par chaque plateforme pour la wu de chaque projet et on lui attribue un crédit / heure de 100.

Et cette valeur devient la valeur de référence pour les projets.

Ensuite, que le projet bénéficie du 64 bits, tant mieux pour lui (et pour les users). Que l'user investisse davantage que la plateforme de base (C2Q, V8, Phenom, ou tout simplement en achetant un processeur qui ne soit pas l'entrée de gamme), alors le gain en crédit est pour l'user et le gain en progression du projet est pour le projet.

De cette manière, les projets sont incités à optimiser leurs applis et à en proposer pour davantage de plateformes. Et les users ne sont pas pénalisés en crunchant sur un projet. Au pire, ils ne gagnent pas le "bonus" de crédit que les efforts de développement des projets et le surinvestissement des users peut créer.

Cette solution aurait le mérite d'être faire play pour tous les projets et pour les utilisateurs également.

En ce qui concerne les projets qui ne dépendent pas d'une durée de traitement (style depspid avec la BP ou un projet à venir qui utiliserait nos DD pour stocker), il suffit de définir une base qui serve d'étalon (style connexion adsl 512k)



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #20 le: 09 March 2008 à 18:34
Citation de: Corran Horn
Je pense que c'est une très mauvaise idée que je lis là.

Si les projets n'arrivent pas à se mettre d'accord sur le nombre de crédit à donner je ne vois pas comment il va s'y prendre.

1/ Changer les stats des utilisateurs via les sites de stats. Ca ne changera pas grand chose car il y aura d'autres sites de stats qui ouvriront pour satisfaire l'envie des utilisateurs.
2/ Que les utilisateurs qui sont content de faire plein de points doivent rester dans la course. Un utilisateur qui faisait x point avec son parc machine et qui ne ferait plus que x/2 arrêtera peut être de calculer. Au final c'est l'avancée de des projets qui va en souffrir.

Par contre je suis pour une espèce de validation du code en interne. Inutile de divulguer le code source par contre ça devrait être à "BOINC" de labeliser les projets qui fonctionnent sur leur plate forme.

J'aimerai bien aussi que sur tous les projets les wus soient calculées par au moins deux utilisateurs.


En dernier recours, je suppose que David Anderson a un ultime moyen de pression sur les projets (plus efficace que celui des sites de stats).
La version 6 de Boinc est en préparation. Elle nécessitera probablement une mise à jour côté projets. Donc, si le projet est conforme, il a la mise à jour serveur, s'il ne l'est pas, il ne l'aura pas tant que son système de crédit n'est pas normalisé.

En clair, dès que plusieurs projets seront passés en version 6, il suffira que ces projets la rende obligatoire. Total, une majorité d'utilisateurs passeront en version 6 de Boinc et ne pourront donc plus cruncher sur les projets n'ayant pas la v6 serveur.

Il ne s'agit là que de suppositions. Mais avouez que ça pourrait faire un magnifique levier pour imposer une décision...



Hors ligne Jim PROFIT

  • Boinc'eur Respectable
  • ****
  • Messages: 896
  •   
Réponse #21 le: 09 March 2008 à 18:46
Et bien justement dans le lien, cela parle de benchmarks!
Citer

Proposal

    * Computers are described by a set of parameters (FP and int benchmarks, #CPUs, cache sizes, memory bandwidth, available RAM, available disk, presence of particular GPUs, network bandwidth, available fraction, connected fraction, maybe others).
    * Each project P publishes a "credit function" C(H) specifying, for a host H with given parameters, how much credit per day would be granted if H is attached exclusively to P.
    * Normalization rule: for each project, the average of C(H) over all hosts participating in BOINC must be about 100.
    * Accounting rule: the credit granted by a project P cannot exceed the sum over hosts H of

      RS(H, P)*C(H)

      where RS(H, P) is the fractional resource share of H's attachment to P.

The normalization and accounting rules would be evaluated by cross-project statistics sites.


La propoistion (traduite rapidement)

Les PC sont décrits par différents paramètres (FP et benchmarks!!, type de CPU, taille du cache, bande passante mémoire, RAM disponible, disque disponible, la présence d'une carte graphique particulière, ets...)
Chaque projet P publie une "fonction crédit " C(H), je pense crédit par heure, pour un hote H donné avec ses paramètres, combien de crédit par jour serait dobbé si H est attaché au projet P.
Règle de normalisation : pour chaque projet, la moyenne des crédits par heure C(H) pour tous les hotes participant un BOINC devra être à peu près 100.
Règle de comptage : le crédit accordé par un projet P ne peut excéder plus que la somme des hôtes H

RS(H, P)*C(H)
Ou RS(H, P) est la part des ressources de l'hote H au projet P

La normalisation et les règles de comptage serait évalué par les sites de stats multi projet.

Bon je vous l'accorde, mais c'est un peu fait en tapant ceci, donc merci de ne pas tenir compte des erreurs  :pt1cable:

Mais sinon, ce document était aussi une base pour une discussion qui devait avoir lieu, donc cela a peut-être changé.

 :hello:



Hors ligne Heyoka

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 4064
  •   
Réponse #22 le: 09 March 2008 à 18:48
Voila ce que je pense qu'il faudrait faire.
1. Crédit fixe sur tous les projets
2. Ensuite sur chaque projet, on fait tourner une cinquantaine d'étalons représentant à peu près toutes les combinaisons de config les plus courantes, et exclusivement dédié au calcul. Pour cela on suit les statistiques de personnes de confiance qui feront tourner tous les projets l'un après l'autre, et les résultats seront traités automatiquement.
Il faudra prendre comme étalon des ordinateurs mélangeant toutes les plateformes avec les différents processeurs
Windows 64, Linux 64, Windows 32, Linux 32, Mac OS
associés à chaque fois avec différents types d'architectures Intel et AMD

On regarde combien de points/heure ou par jour ramène chaque config étalon

On fait la moyenne des 50 configurations étalons, et on obtient le nombre de points moyen attribués par le projet.
Si il ressort qu'un projet crédite 30% de plus qu'un autre on corrige de 30% les points attribués par le projet dans les sites de stats. Ou on demande à l'administrateur du projet de baisser de 30% les points attribués
L'important est de prendre un étalon par config et de ne pas prendre la moyenne de l'ensemble des ordinateurs tournant sur le projet
Parce que si on fait la moyenne de l'ensemble des ordinateurs sur un projet, ça désavantagerait les projets qui ont des applications 64 bits performantes et qui attirent un plus gros % de configurations 64 bits.

Par exemple, en simplifiant au maximum le problème :

Si sur un projet X il y a :
10 config 64 bits à 100 points/heures
5 config 32 bits à 50 points/heures

La moyenne pour la totalité des ordinateurs : [(10x100)+(50x5)] / 15 => 83 points/heures
La moyenne en prenant 1 étalon 64 bits et un étalon 32 bits : (100+50)/2 => 75 points/heure

Et si un projet Y
5 configs 64 bits à 90 points/heures
10 configs 32 bits à 60 points/heures

La moyenne pour la totalité des ordinateurs : [(5x90)+(60x10)] / 15 => 70 points/heures
La moyenne en prenant 1 étalon 64 bits et un étalon 32 bits : (90+60)/2 => 75 points/heure

On voit bien ici que le projet X attribue plus de points au total, non pas parce qu'il triche avec le système de crédit, mais c'est juste parce qu'il offre une application 64 bits beaucoup plus performante par rapport au 32 bits. Il attire les applications 64 bits, qui ont une meilleure efficacité sur son projet que sur l'autre.
Donc au final, avec les étalons, on garde l'efficience du système qui encourage chaque personne à aller sur le projet pour lequel son ordinateur est le plus performant.
Ici les 64 bits iront sur le projet X, et les 32 bits sur Y


Hors ligne Jim PROFIT

  • Boinc'eur Respectable
  • ****
  • Messages: 896
  •   
Réponse #23 le: 09 March 2008 à 18:54
Citation de: Black Hole Sun
Le problème est bien là : en fonction des calculs (si encore il y en a cf depspid), les projets tirent avantage d'une plateforme matérielle et/ou logicielle. Ce qui fausse complètement les calculs.


Et non, justement ils veulent prendre en compte tous les paramètres en fonction ce que le projet fait!
Que le projet utilise le GPU, le disque, le cache L2, la bande passante, et je ne sais quoi d'autre.

Et c'est là que tout se complique!

Pour ce qui est du benchmark, je ne comprend pas en quoi cela va apporter de la triche.
Il suffit de trouver un moyen pour que ceux qui trichent se voient purement et simplement amputés des crédits!

Avec une machine étalon, on part avec un score de 100 pour un P4 1,5 Ghz, 100 pour 1 Go de RAM, 100 pour 50 Go de DD, etc....
Et donc chaque machine avec des composant supérieurs se vera gratifié de X% par rapport à cette base.

Il doit bien exister un boyen de bloquer la triche, en ne publiant pas le code source juste de la partie benchmark de BOINC.
En cryptant le résultat de ce bench aussi.

 :hello:



Hors ligne Corran Horn

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1109
  •   
Réponse #24 le: 09 March 2008 à 19:03
Je ne vois pas comment on peut tricher en utilisant le système de x users calculant la même wu. Soit il y a une majorité de tricheur et oui les wus seront comptabilisées avec un crédit plus haut soit c'est une minotité et faire calculer la wu par trois users permet de limiter la triche.