Le Forum de l'Alliance Francophone

Nouvelles:

Auteur Sujet: [Discussions permamentes] Le système des crédits BOINC/PROJETS  (Lu 91003 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
Réponse #25 le: 09 March 2008 à 19:10
@ Heyoka : le système que tu proposes comporte un inconvénient.
Il n'y a aucun intérêt pour les projets à développer le support du 64 bits (par exemple, ou de Linux).

Le principe de la base d'étalons est également problématique : le temps que les 50 (voire plus, voire moins) réalisent tous au moins 1 unité sur tous les projets, cela va prendre plusieurs mois.

Il vaudrait mieux amha reprendre quelques configurations qui servent d'étalon (et aux fréquences de base pour ne pas avoir l'effet oc).
En se basant par exemple sur ça :
http://fr.boincstats.com/stats/host_cpu_stats.php?pr=bo&teamid=&st=0&or=2

Et ça :
http://fr.boincstats.com/stats/host_os_stats.php?pr=bo&teamid=&st=0&or=2

Sauf que là, on a tout l'historique depuis la création de Boinc. Il suffirait par exemple d'avoir ces stats sur le dernier trimestre 2007 (où on peut supposer que les P4 3GHz ne seront plus les CPU les plus nombreux).

Comme je disais, du moment qu'un projet fait l'effort de fournir une appli 64 bits, un support Linux etc..., il y gagne forcément car plus d'utilisateurs pourront mettre leur machine dessus. Qu'ensuite certains projets bénéficient davantage du 64 bits que d'autres, c'est bonus pour le projet (qui progresse plus) et pour l'utilisateur. Idem que si l'utilisateur a une machine plus puissante (ou oc) que celles de référence.

@ Jim PROFIT : tout système de mesure qui se fera côté utilisateur (typiquement le benchmark) sera tôt ou tard détourné. Crypté ou pas. Sans oublier que Boinc publie ses sources. Donc celles du mode de bench le seront. Donc, falsifiables.



Hors ligne Black Hole Sun

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


Parce que les utilisateurs n'utiliseront pas le même hôte pour le calcul.
Exemple flagrant avec ABC :
User 1 : MacPPC
User 2 : P4 3GHz Win32
User 3 : C2D 3Ghz, OC, Linux 64

Sans même parler de triche, le delta entre la valeur la plus faible et la plus élevée est un tel abîme que cela ne voudra plus rien dire :(



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #27 le: 09 March 2008 à 19:35
Il y a un blem' avec l'étalonnage :/.
Comment BOINC va t-il savoir que ma machine est OC, et donc quelle produit plus que l'étalon qui a le même CPU mais non OC ?
Car il me dit personnellement que mon petit C2D tourne à 2,4Ghz alors qu'il est OC @3Ghz.

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 #28 le: 09 March 2008 à 19:48
Citation de: rom_185
Il y a un blem' avec l'étalonnage :/.
Comment BOINC va t-il savoir que ma machine est OC, et donc quelle produit plus que l'étalon qui a le même CPU mais non OC ?
Car il me dit personnellement que mon petit C2D tourne à 2,4Ghz alors qu'il est OC @3Ghz.


Non, ce n'est pas un problème ;)

Dans le modèle auquel j'ai pensé, c'est l'équipe de Boinc qui soit détient elle-même les machines (vu le faible nombre), soit elle les choisit parmi des utilisateurs qu'elle connait et à qui elle peut faire confiance pour ne pas overclocker les machines.

De ce fait, les étalons sont des machines de référence.

Si toi tu overclockes ta machine, c'est du bonus pour toi (et donc également pour le projet puisque ça calculera plus vite). De la même manière que si tu as plus de ram, de la ram plus rapide (latence) etc..., c'est une optimisation que tu apportes à TA machine pour qu'elle soit plus performante. Cela revient au même que d'avoir investi dans une machine dont les composants sont plus performants que celle(s) de référence (et fatalement plus chers).



Hors ligne Origin

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 4036
  •   
Réponse #29 le: 09 March 2008 à 19:52
A mon sens c'est essayer de trouver la quadrature du cercle : la seule manière vraiment objective faire un ratio cross projet est d'avoir un seul et même algorithme de benchmark compilé de la même façon sur tous les procos et une fois pour toute ... autant dire que c'est impossible.

Alors, dans la pratique, c'est à BOINC d'établir une règle commune de calcule des perfs intrinsèques d'un processeur. Par exemple en envoyant, quel que soit le projet, une WU particulière qui met "un certain temps sur le processeur" et donc établit un calcul unique et commun à toutes les plateformes.

A partir de cette WU de référence, on pondère et on affecte les cobblestones en conséquence par rapport aux perfs intrinsèques de la machine et plus par rapport aux algos des projets.



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #30 le: 09 March 2008 à 19:53
@BHS : Ok je ne l'avais pas vu comme ça :jap:.

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 #31 le: 09 March 2008 à 19:58
Citation de: Origin
A mon sens c'est essayer de trouver la quadrature du cercle : la seule manière vraiment objective faire un ratio cross projet est d'avoir un seul et même algorithme de benchmark compilé de la même façon sur tous les procos et une fois pour toute ... autant dire que c'est impossible.

Alors, dans la pratique, c'est à BOINC d'établir une règle commune de calcule des perfs intrinsèques d'un processeur. Par exemple en envoyant, quel que soit le projet, une WU particulière qui met "un certain temps sur le processeur" et donc établit un calcul unique et commun à toutes les plateformes.

A partir de cette WU de référence, on pondère et on affecte les cobblestones en conséquence par rapport aux perfs intrinsèques de la machine et plus par rapport aux algos des projets.


Pas mal l'idée :jap:
J'y vois 2 problèmes :
1. Risque de triche possible puisque le test se déroule côté utilisateur.
2. L'évaluation de la machine se fait sur une wu "test". OK. Le projet calibre ses crédits sur elle. Sauf que le projet en question peut être très fortement impacté par disons encore le 64 bits. Cela aura pour conséquence que la machine aura un niveau de crédit équivalent en 32 et 64 bits. Or en 64 bits, elle dépotera beaucoup plus (car les calculs s'y prêtent). Au final, c'est l'utilisateur qui est très largement perdant.



Hors ligne Origin

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 4036
  •   
Réponse #32 le: 09 March 2008 à 20:04
Ben, le 32 ou 64 bit est un composant intrinsèque de "la machine" je dirais ... certains O.S. ont des impacts différents sur les performances rendues par des processeurs identiques aussi, suivant que l'O.S. en question est interventionniste (comme Windows) ou laxiste (comme Linux). C'est pas une critique hein ;), d'autant que ça peut se tuner pas mal ;)

Le plus dur (notamment vis à vis du contexte dont tu parles : 32 vs 64) sera de produire et calculer cette WU pour que ce soit le plus "générique" possible. On peut éventuellement avoir plusieurs couples (algo de calcul et donnée de la WU) mais toujours cross-projet, c'est le plus important.

La triche, ok, mais de toutes façons, est-ce qu'on peut vraiment l'éviter ?

Et comme j'ai déjà dit, il faudra de toutes façons faire des concessions à mon avis. Avant, avec Seti@Home, c'était les tricheurs coté utilisateur qu'il fallait pister. Maintenant, c'est les utilisateurs ET les projets indépendants ... dur dur



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #33 le: 09 March 2008 à 20:10
OK, donc on oublierait le 32 ou 64 bits, on se focalise uniquement sur l'OS et la machine (comme le sont les hôtes sur nos comptes projets d'ailleurs).

Ce qui signifie donc qu'un hôte sous Linux 32 et le même sous Linux 64 créditeraient pareil... sachant que le 2ème produit très nettement plus que le 1er :/ Pas fair play ce truc

Pour la triche, le système de crédit fixe par unité résoud le problème. Revenir à un système de bench côté user, c'est rouvrir la triche à grande échelle :/



Hors ligne Origin

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 4036
  •   
Réponse #34 le: 09 March 2008 à 20:16
ben non, pas du tout ? sur ta plateforme 64, ta WU de référence se compilerais plus vite, si l'algo qui va avec connait les extensions 64 ;)

Par contre, je vois pas bien comment tu peux allouer un crédit fixe par unité si tu n'évalue pas la vitesse à laquelle cette unité est calculée ? Ou alors j'ai loupé un truc ;)




Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #35 le: 09 March 2008 à 20:33
Citation de: Origin
ben non, pas du tout ? sur ta plateforme 64, ta WU de référence se compilerais plus vite, si l'algo qui va avec connait les extensions 64 ;)

Par contre, je vois pas bien comment tu peux allouer un crédit fixe par unité si tu n'évalue pas la vitesse à laquelle cette unité est calculée ? Ou alors j'ai loupé un truc ;)


OK, c'est plus clair. Reste le problème du fait que le test se fait côté utilisateur et que cela induit un fort risque de triche :/
De plus, pour tricher, il y aurait une manière très simple : sous-clocker la machine le temps du test (qui logiquement se ferait au moment où l'hôte s'attache à un projet), et ensuite la remettre @ freq de base (voire oc).

Pour allouer le crédit fixe à une wu, les machines de référence permettent de déterminer une base de temps nécessaire au calcul. A cette base de temps, par simple règle de 3, on attribue un crédit / heure.

Charge au projet ensuite de déterminer la durée de calcul de ses wus sur la base des calculs à réaliser et de fixer le nombre de points de la wu toujours par une règle de 3 (ou par un système de palier pour les projets ayant des wus beaucoup trop disparates en durée).

HS : David Anderson vient de me répondre. On dispose 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.



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #36 le: 09 March 2008 à 21:24
Citer
De plus, pour tricher, il y aurait une manière très simple : sous-clocker la machine le temps du test (qui logiquement se ferait au moment où l'hôte s'attache à un projet), et ensuite la remettre @ freq de base (voire oc).
D'ou mon idée de mettre un micro-bench dans chaque UT, ou dans ce cas pour ne pas perdre trop de temps CPU avec les benchs, mettre des "contrôles surprises" (un bench dans des UT une fois de temps à autre) dans les UTs, comme ça impossible de savoir quelles UTs ont le bench et donc impossible de sous-clocker le CPU avant.

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 #37 le: 09 March 2008 à 21:58
effectivement, c'est une possibilité. Ça implique une gestion au niveau des projets qui doivent injecter les wus tests dans leurs séries et faire en sorte qu'elles soient attribuées aux hôtes. C'est là le côté compliqué dans le sens où on veut 1 wu test par semaine ou par mois par hôte alors que les wus sont distribuées sous le principe du FIFO (1ère entrée, 1ère distribuée) et donc non attribuée à un hôte en particulier (c'est le 1er qui demande qui est servi). C'est peut être réalisable.

Idée à garder dans un coin :jap:



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #38 le: 09 March 2008 à 21:59
On avance :bounce:



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #39 le: 09 March 2008 à 23:07
Si mon système de crédit marche, on pourra appeler ça le Rom1lestone ?
[spoiler] [:marc]  [:douglas riper] [/spoiler]

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


Hors ligne Origin

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 4036
  •   
Réponse #40 le: 10 March 2008 à 00:06
Oué, avec l'idée de Rom de carément intégrer tous les "X" WU une WU de bench, ca parait pas trop compliqué et difficile à anticiper donc a contourner ;)




Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #41 le: 10 March 2008 à 00:09
Ouais, je vais la noter dans le 1er post :jap:



Hors ligne Black Hole Sun

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 5197
  •   
    • RC Classics & Moderns
Réponse #42 le: 10 March 2008 à 00:19
Rom_185 : merci de me dire si le descriptif de ton idée est correct.

J'ai ajouté un inconvénient (et sa solution) car j'y ai pensé en l'écrivant : les projets à wus très longues (CPDN) devront intégrer la wu test (le bench) en cours de calcul à l'intérieur de la wu elle-même.

Autre chose : les projets devront mettre en place un système qui fournit automatiquement mais aléatoirement une wu test parmi les 10 premières que reçoit un nouvel hôte. Sinon, impossible de le calibrer. Et tant que cette wu test n'est pas retournée au serveur, toutes les wus "normales" devront rester en pending.



Hors ligne rom_185

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5215
  •   
    • le portail de l'alliance
Réponse #43 le: 10 March 2008 à 00:48
Ces ça :jap:.
Citer
les projets à wus très longues (CPDN) devront intégrer la wu test (le bench) en cours de calcul à l'intérieur de la wu elle-même.
C'est ce que j'avais pensé au début faire avec toutes les UTs de tous les projet, mais si le calcul de l'UT dure 2min et le bench met 1min à ce faire c'est nul  [:douglas riper:2].

Citer
Autre chose : les projets devront mettre en place un système qui fournit automatiquement mais aléatoirement une wu test parmi les 10 premières que reçoit un nouvel hôte. Sinon, impossible de le calibrer. Et tant que cette wu test n'est pas retournée au serveur, toutes les wus "normales" devront rester en pending.

J'étais plus sur l'idée de l'intégrer au coeur même d'une WU normal et de le faire régulièrement.
Car si l'utilisateur change de CPU, ce sera toujours l'ancien bench qui servira à l'étalonnage.
Mais si c'est trop compliquer pour les projets, s'pas grave :jap:.

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


Hors ligne ThierryH

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 3316
  •   
    • Keep4eveR
Réponse #44 le: 10 March 2008 à 14:11
Je viens juste de m'apercevoir de l'existantce de ce topic. Je n'ai pas le temps de lire tout ce qu'il s'est dit pour le moment mais voici ce que je propose:

- Tous les projets doivent avoir une application win32 officielle qui sert de référence.
- On prend une machine de référence (par example C2D à x.x GHz et mémoire DDR II à 800 MHz).
- Une heure de calcul sur cette machine avec l'appli win32 doit rapporter xx points (fixe pour tous les projets).
- On se sert de cette base de calcul pour définir un nombre de points pour une wu (à moyenner selon les durées éventuellement variables des wu).
- Ce nombre de points par wu est le même pour toutes les autres plateformes (hardware et OS) sur lesquelles est portée l'appli.


Autrement dit, celui qui possède une machine proche de la machine de référence et qui l'a fait tourner sous win32, doit avoir le même rac quelque soit le projet.
Comme le configuration C2D/win32 est de loin la plus répendue parmis les volontaires, je pense qu'il s'agit d'une bonne base de travail pour uniformiser les stats.
 :jap:


Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #45 le: 10 March 2008 à 16:25
Citation de: Black Hole Sun
Autre chose : les projets devront mettre en place un système qui fournit automatiquement mais aléatoirement une wu test parmi les 10 premières que reçoit un nouvel hôte. Sinon, impossible de le calibrer. Et tant que cette wu test n'est pas retournée au serveur, toutes les wus "normales" devront rester en pending.


C'est une bonne idée, cette idée d'UTs étalons (benchmark), mais vu la complexité, il faudra surement recoder tout le système de gestion de crédit et ce n'est pas pret d'être mis en place (probablement pas avant la version 7 de Boinc si c'était accepté).

Peut-être faudrait-il s'attacher à trouver une solution plus rapide à mettre en oeuvre si on ne veut pas trainer ce problème de crédit pendant encore 1 an ou 2

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


Hors ligne Jim PROFIT

  • Boinc'eur Respectable
  • ****
  • Messages: 896
  •   
Réponse #46 le: 10 March 2008 à 17:51
Il doit être possible d'intégrer une fonction permettant de télécharger une WU de test, quelque soit le projet, toutes les X jours, bien évidemment avec une variable X qui changerait aléatoirement, de sorte que cela ne soit pas détectable par les tricheurs, car ne sachant pas quand elle va se  déclencher.

Et la WU de test sera spécifique à chaque projet, donc poura être testé, la bande passante mémoire, ou le GPU, etc...


 :hello:



Hors ligne ThierryH

  • Membre d'honneur
  • Boinc'eur devant l'éternel
  • *
  • Messages: 3316
  •   
    • Keep4eveR
Réponse #47 le: 10 March 2008 à 18:06
Je viens de prendre un moment pour tout lire. L'UT étalon n'est pas vraiment compliquée à gérer. Elle doit faire partie du package serveur et être directement gérée par boinc sans que le projet s'en occupe. En plus, on peut faire en sorte que le client la traite en priorité. Le temps que l'utilisateur réagisse, elle est déjà calculée et renvoyée.
Reste qu'on peut toujours recompiler le client boinc pour la truquer :(


Pour le reste je pense qu'il y a un pricipe de base à ne pas oublier: à nombre de wu égal, paye égale. Autrement dit, sur un même type de wu, avoir la même paye, quelque soit la plateforme et donc le temps mis pour le calcul.
C'est pour cela que je suis partisant d'une plateforme étalon. Les machines sous win32 sont de loin les plus répendues. L'OS de la plateforme de test doit donc être win32. Maintenant, pour le proc, il faut se baser sur la techonoligie la plus répendue en magasin, soit le C2D. Cette plateforme étalon devra évoluer à chaque montée de version majeur de boinc.
 :jap:


Hors ligne power600

  • Boinc'eur Respectable
  • ****
  • Messages: 548
  •   
Réponse #48 le: 10 March 2008 à 18:54
Bon, à moi.  :p

Mon idée à mwa, ce serait un truc style WU étalon mais qui soit faite et utilisée sous le seul contrôle de Berk le Laid  :D

Ce serait une WU à part, utilisant un client ne servant qu'à utiliser cette unique wu, le tout ne dépendant d'aucun projet et n'utilisant donc qu'un (ou des) algorythme(s) conçu(s) à berkeley.
La wu de référence mesurerait la vitesse de cacul de la lessiveuse et ce serait les serveurs de berkeley qui auraient la charge d'attribuer les points en fonction de la puissance de calcul déterminée par la wu de référence.
Par exemple si il est attribué un point par 25 MegaFlops accomplis, il y aurait alors un points de donné à l'ordi pour 25 MegaFlops accomplis quel que soit le temps qu'il y a passé, une fois que le résultat du calcul a été éventuellement validé par d'autres lessiveuses.
Cela serait en vigueur sur tous les projets utilisant BOINC quels qu'ils soient, quelle que soit al longueur de la wu. A charge alors pour les responsables de chaque projet d'optimiser ou non leur appli pour tirer le meilleur des machines inscrites au projet.
Bien sur il serait permis de donner les points gagnés par le participant même si la wu en cours n'est pas terminée dans le cas de wu qui prennent longtemps.
L'avantage serait alors que c'est le boulot réellement accompli qui est récompensé.



Hors ligne xipehuz

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 1672
  •   
    • Les Xipéhuz
Réponse #49 le: 11 March 2008 à 16:36
Oui mais y'a comme un problème.

Comme l'a dit BHS plus haut,

Citer
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.


Donc comment batir un UT de test qui puisse simuler tous ces cas de figure différents   :??:

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