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 ?
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 / wuHa oui :/.
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.
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.
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.
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.
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.
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.
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 ;)
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.
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].
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.
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.
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.
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:
Si tu ne prends que win32 ça encourage les projets qui ont des versions win32 pourraves et de très bonnes applications win64, mac ou linux
Si tu ne prends que win32 ça encourage les projets qui ont des versions win32 pourraves et de très bonnes applications win64, mac ou linux
Le problème en ne favorisant que le temps machine, c'est qu'on va pousser les gens à ressortir de derrière les fagaux les vieux PC qui ne sont actuellement pas utilisés. Or faire tourner un PC juste pour boinc est contraire à la charte écologique de Berkeley. En conséquence, je vois mal comment on peut entériner un tel système de crédit.
Le problème en ne favorisant que le temps machine, c'est qu'on va pousser les gens à ressortir de derrière les fagaux les vieux PC qui ne sont actuellement pas utilisés. Or faire tourner un PC juste pour boinc est contraire à la charte écologique de Berkeley
Dans la mesure ou un tel engagement se fait sur cette base, j'ai toujours eu du mal a comprendre les batailles autour des problemes de credits dans l'ensemble des forums que j'ai parcourus. Pourquoi attendre un quelconque retour 'valorisant' des projets a qui vous avez decide de donner du temps CPU ? A mon avis, le seul interet des stats/credits et autres systemes de classement est de permettre, avec un cote fun pour certains dont je suis, de materialiser/quantifier son propre engagement et de valoriser son ego. C'est aussi la seule methode gratuite pour les projets de nous dire merci (et au passage, continuez comme ca vous allez niquer votre voisin :))
En deux ans, j'ai fait 3 000 000 de points. Aujourd'hui, avec les quelques machines que j'ai chez moi et en "choisissant" bien les projets, je peux tourner à 1 000 000 de points par moi. Où est passé tout mon travail de mes début ? :(
:jap:
Système de crédit par "contrôles surprise" :Mwai bah pas grand chose a ajouter a ce que tu a mit dans le post n°1...
De manière aléatoire mais régulière, chaque projet envoie une wu de bench non identifiable et imprévisible. Cette wu permet d'étalonner la puissance de l'hôte.
Le bench peut aussi être intégré directement dans l'UT.
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).
Credit system by "random checking"
Randomly but on a regular basis, each project will send a benchmark work unit posing as a regular work unit (same size, same name, same computing time). This WU will collect data in order to benchmark its host computer. An alternative could be to insert some benchmarking code inside a regular work unit.
Pros : Although we're talking about a benchmark on the user's side, cheating (as in under-clocking while processing the benchmark WU) will be virtually non existent as the benchmark WU will not be detectable, being identical to the regular ones.
Cons : Each project must implement a benchmark WU system and insert them in their feeders on a regular but random basis
Special cases : For projects with very long WUs (à la CPDN), to be indetectable, the benchmark code will have to be inserted inside a regular WU, as it would be quite impractical and inneficient to run a 60 days benchmark
- 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:
Je ne vois pas trop l'intérêt de ces challenges, mais c'est un sentiment personnel.
L'argent n'est pas - à mon avis - la raison qui pousse des équipes à s'affronter. L'argent est venu après et a changé beaucoup de choses, mais ce n'est pas la motivation de base.
Je ne critique en rien ceux qui aiment bien ce genre de "confrontation" sur Boinc, je dis juste que pour moi ça n'offre aucun intérêt. Boinc me semble être une idée intéressante pour le bien commun, j'ai envie de calculer en espérant que ça servira à quelque chose, je pense que c'est utile, et point.
A la rigueur, les "compétitions amicales" pourraient peut-être m'intéresser à deux conditions :
- que l'on puisse influer au niveau de l'équipe à tel ou tel moment et sur tel ou tel projet (honnêtement je me vois mal envoyer un mail à mon équipe pour leur dire que du 1er au 5 avril tout le monde doit passer sur Seti ou autre...). Actuellement je vois l'équipe comme un bloc sur lequel je n'ai pas spécialement d'emprise... je ne sais pas si je suis très clair ^^
- si les participants étaient de "force" égale. Tu cites le sport, mais en général dans le sport les participants partent plus ou moins avec les même chances (je sais bien qu'en réalité c'est différent, mais disons que les participants sont "gloablement égaux"). Je ne vois pas l'intérêt - pour mon équipe par exemple - de rejoindre un challenge dans lequel 50 équipes ayant des centaines voire des milliers de membres vont à chaque fois nous reléguer dans le fond du classement.
En gros, je ne vois pas trop l'intérêt des challenges sur Boinc dans la mesure où la "puissance" générale de l'équipe n'est pas modifiable et que des équipes ayant un rapport de force de 1 à 100.000 sont dans le même bain. C'est un peu comme si Haïti voulait déclarer la guerre au reste du monde ^^
Ca pourrait en revanche être plus "amusant" si les divers challenges se faisaient dans des "poules" avec des équipes à peu près équivalentes en terme de puissance de calcul, mais je ne sais pas si c'est réalisable.
Cela étant je comprends parfaitement le côté "fun" de la chose et je ne reproche rien à ceux qui sont à fond dans Boinc, bien au contraire ... mieux vaut y être à fond que pas du tout ^^
Je ne vois pas l'intérêt - pour mon équipe par exemple - de rejoindre un challenge dans lequel 50 équipes ayant des centaines voire des milliers de membres vont à chaque fois nous reléguer dans le fond du classement.
En gros, je ne vois pas trop l'intérêt des challenges sur Boinc dans la mesure où la "puissance" générale de l'équipe n'est pas modifiable et que des équipes ayant un rapport de force de 1 à 100.000 sont dans le même bain. C'est un peu comme si Haïti voulait déclarer la guerre au reste du monde ^^
XTC_ZeuZ > merci pour la proposition mais j'ai déjà eu pas mal d'éclaircissements à ce sujet et je n'ai pas trop envie d'abandonner tous les efforts faits avec mon équipe, sans compter que je pense qu'une bonne partie des membres actuels ne suivraient pas pour des raisons X ou Y. Mais le jour où on trouve un moyen de rattacher une équipe-fille à une équipe-mère sans rien changer, je vous rejoindrai avec plaisir (encore une fonctionnalité à inventer ça ^^).
Mais il faut le code source des appli', c'est pas gagné pour les avoir :/....
Et si un projet refuse toujours de faire noter son code, on lui met une note sanction directe.Pas faux....
Justement, c'est là qu'intervient le comité pour les projets qui ne veulent pas libérer leur code source.
Pour ces projets, le code source reste dans le secret mais pas la note sur le degré d'optimisation du code.
De toute façon, on sait très bien qu'il y a des gens comme askof qui est déjà arrivé à mettre la main sur le code source d'ABC alors que celui-ci n'était pas en théorie consultable
Et si un projet refuse toujours de faire noter son code, on lui met une note sanction directe.
Akos n'a jamais eu les codes des applis. Il les décompilait, les modifiait en assembleur et les réassemblait. Et s'il a disparu du circuit, c'est probablement que cette technique est interdite par la plupart des éditeurs de compilateurs ;)
Hi David,
As promised, the Alliance Francophone members discussed on the cross-project credit comparison. Discussions led to the following :
Credit system by "random checking"
Randomly but on a regular basis, each project will send a benchmark work unit posing as a regular work unit (same size, same name, same computing time). This WU will collect data in order to benchmark the host. An alternative could be to insert some benchmarking code inside a regular work unit (like for very long CPDN wus).
Pros : Although we're talking about a benchmark on the user's side, cheating (as in under-clocking while processing the benchmark WU) will be virtually non existent as the benchmark WU will not be detectable, being identical to the regular ones.
Cons : Each project must implement a benchmark WU system and insert them in their feeders on a regular but random basis
Special cases : For projects with very long WUs (CPDN-like), to be indetectable, the benchmark code will have to be inserted inside a regular WU, as it would be quite impractical and ineficient to run a 60 days benchmark.
Another approach could be the following :
Each host on each project has to be compared to a reference host.
* Every project needs to have an official win32 application that could be used as a reference
* One hardware configuration is chosen (e.g. C2D at X.XX GHz with a DDR II at 800 MHz)
* A time step for this configuration (e.g. 1 hour) with the win32 application should brought xx points (the same number for every projects).
* This is the basis of the credit system : a WU on a defined project should grant xx points, according to the previous calibration.
* This credit/WU ratio is the same for every project, without any consideration of CPU architectures, 64 bits utilisation or OS used. If a 64 bit optimized application is available and very efficient, it benefits to those who have such configuration. It is project's developpers interest to make efficient applications available for different OSes and architectures.
* Regularly, the standard application OS and the standard hardware configuration should be revisited in order to be relevant with the median composition of computers on BOINC.
In other words, the one who have a computer near the standard hardware configuration that runs a win 32 OS should have the same RAC on every project.
Win32 OS has been chosen as a reference as it is the most common host configuration. The reference project could be Seti@Home as it is a Berkeley's developpment as Boinc is. Otherwise, it could simply be a reference machine held by Boinc dev team who could determine which projet they want as a reference.
The discussion topic can be found here :
http://forum.boinc.fr/boinc/LAllianceFrancophone/Stats/systeme-credits-boinc-sujet_302_1.htm
It is french-speaking, but you can come by and post directly in english if you want more information. Our members will translate your posts and answer in French and English.
Cheers
BHS
Franchement je suis pas du tout d'accords avec la proposition qu'on va faire.
Qu'en est t-il si un projet met en place une application extrêmement mal codée en 32 bits, pour avantager les applications 64 bits, mac et linux qui eux seront normalement codées
Qu'en est t-il des projets qui font n'importe quoi comme TSP, ils distribuent à tout le monde une application extrêmement mal codée. Ensuite certains s'échangent entre eux une application normalement codée, sans la mettre en place sur le projet pour tout le monde.
Regardez les points réalisés par Seti.USA sur TSP ces derniers jours avec ces optimisations privées :
http://fr.boincstats.com/charts/chart_fr_tsp_object_new_teams_17.gif
En plus prendre en compte les architectures 32 bits uniquement, c'est avantager les projets mathématiques qui eux sont beaucoup plus efficaces sur 64 bits. Le passage du 32 bits au 64 bits, ne permet pas de calculer beaucoup plus vite en astronomie, physique, climatologie et biologie
Le benchmark ne règle pas du tout ces problèmes.
astronomie : milky et cosmo beaucoup plus rapide en 64
Climatologie : CPDN 2x plus rapide en 64
Biologie : Lattice : 1,5x plus rapide en 64
Il y en a surement d'autres ;)
le "a la CPDN" je suis pas sûr qu'il comprenne :p
Sinon ça serait bien de bien séparer les 2 approches différentes. Là ça fait un peu confus.
1. Le projet qui code son appli Win32 avec ses pieds perd ENORMEMENT de puissance puisque le parc d'ordinateurs Boinc est constitué à 70% de cet OS. C'est tellement gros que ce n'est pas envisageable sérieusement ;)
Par ailleurs, tu critiques TSP, et ce n'est pas la première fois : que le projet sorte une appli et que d'autres l'optimisent, ça fait des années que ça existe. Où est donc le problème ?
Il existe déjà des projets qui n'ont pas d'application Windows, WEP-M+2 Project par exempleTu vas pas me dire que la puissance de calcul attribué à WEP-M+2 est phénoménale non plus. Ils ont fait le choix de ne pas avoir d'appli win 32 ça se retrouve en terme de puissance de calcul pour le projet.
Et si un projet arrive à attirer une grosse partie des ordi sous Linux 64 bits, il ne perdrait pas de la puissance mais en gagnerait énormément.
rien que 1% d'un petaflops, ça fait 10 teraflops. Soit une puissance de calcul que beaucoup de projets aimeraient rassembler.
Tu as regardé les stats de ce projet.Certes, mais je ne vois pas le rapport avec le nombre de points. Si on va par là, on peut aussi dire que c'est de la responsabilité des sites de stats qui continuent de prendre en compte ces points là. On peut même aller discuter de boycotter ce projet pour ce problème, mais je vois pas le rapport avec le système de crédit... pensez qu'on trouvera un système inviolable est illusoire. Au moins ça a le mérite de se voir ce genre de pratique.
Des unités qui rapportent 16 points après 14 secondes de calcul sur un quad.
Soit 1000 points par heure pour un seul quad.
C'est pas une optimisation c'est juste une application correctement codée qui vient palier les défauts de l'application qui est distribuée.
Donc une fois que le responsable de projet a remarqué ça, il aurait dû stopper momentanément son projet pour revoir l'application qui est distribuée à tout le monde. Il doit quand même avoir moyen de l'améliorer. Et ne pas rester avec une optimisation qui calcule 20 fois plus vite que l'application envoyée à tout le monde.
Sinon c'est extrêmement facile on lance un projet peu optimisé, on code une optimisation et on obtient un projet qui donne 30.000 points par jour et par ordi
Bon, et pour être constructif, tu proposes quoi de réalisable ?
Parce que j'ai beau chercher ...
Tu vas pas me dire que la puissance de calcul attribué à WEP-M+2 est phénoménale non plus. Ils ont fait le choix de ne pas avoir d'appli win 32 ça se retrouve en terme de puissance de calcul pour le projet.
Il est aussi à noter que l'utilisation des applis optimisées SETI qui pouvaient faire gagner jusqu'à plus de 60% de perf n'a jamais été autant décrier non plus...
De plus l'application optimisée TSP est une appli win 32 non ? si oui on peut la prendre comme référence.
Beaucoup de monde risque d'avoir quelque chose à redire sur les propos d'Extra Ball qui sortent un peu du cadre de ce topic dont le but est de donner une réponse à David Anderson. Mais derrière son discourt, il y a une idée pas forcement mauvaise dont il faut discuter. D'ailleurs, plus j'y pense, plus je trouve qu'elle a un grand intérêt.
1 minute de calcul = 1 point quelque soit la plateforme
Si je regarde les début de boinc, j'avais une centaine de machines et je passais des heures à les porter à bout de bras pour que ça tourne. Aujourd'hui, avec mes quelques machines perso, je fais bien plus de points qu'à l'époque. C'est presque comme si je n'avais jamais travaillé sur un gros parc. En deux ans, j'ai fait 3 000 000 de points. Aujourd'hui, avec les quelques machines que j'ai chez moi et en "choisissant" bien les projets, je peux tourner à 1 000 000 de points par moi. Où est passé tout mon travail de mes début ? :(
L'idée d'Extra Ball permet de tenir compte de l'avancée technologique, sans pour autant dévaloriser les points acquis par le passé:
- A64, P4A (1 coeur): 1440 de rac
- A64X2, P4E, P4D, C2D (2 coeurs): 2880 de rac
- C2Q, Phenom (4 coeurs): 5760 de rac
- PS3 (on prend les 6 coeurs SPE): 8640 de rac
- V8 (8 coeurs): 11520 de rac
Plus on laissera de taches en parallèle, plus ça rapportera. Reste à trouver le moyen d'empécher de lancer 100 tâches boinc sur une seule machine si celle-ci à moins de 100 coeurs ;)
:jap:
C'est peut-être qu'un détail, mais un P4D est 2.5 fois moins puissant qu'un C2D sur un projet comme Rosetta (je ne sais pas si c'est du aux optimisations par rapport au C2D)
Finalement, pourquoi ne pas donner les points par rapport à la puissance de calcul à la virgule flottante par rapport au processeur, comme ça, tous les projets seraient égaux, et un C2D aurait vraiment ces points tout comme un P4D.
Et comment ça se fait que ce n'est plus le cas ?
A cause des optimisations ?
A cause de la triche. Ce système est une vraie passoire :(
C'est justement l'idée de ma proposition.
On sait très bien que la plupart des projets ont besoin d'aide dans la programmation, mais beaucoup ne veulent pas rendre leur code source libre pour de multiples raisons
Donc le compromis, c'est de créer un comité externe chargé d'examiner les codes. Le code ne serait pas communiqué au delà de ce cercle de bénévoles programmeurs.
Ensuite ce comité donne une note qui sera rendue publique, et des conseils à l'intention du responsable du projet pour améliorer le code. Voir pour les projets avec peu de moyens, proposer un nouveau code optimisé.
Parce que de voir tout d'un coup sur des projets comme Sztaki, TSP, Riesel qu'on a calculé des mois voir des années pratiquement dans le vide, ça fout un peu les boules.
TSP a eu le bon réflexe de rendre son code source libre, ce qui est une excellente initiative.
Mais si ça se trouve, il y a d'autres projets qui ont des codes très mal optimisés et on le saura jamais parce qu'ils n'ont pas l'intention de rendre leur code source librement consultable.
On a quand même le droit à la transparence, de savoir si les calculs que l'on fait sur tel ou tel projet sont efficaces ou pas.
Je doute de la faisabilité :(
Les équipes des projets ne sont certainement pas prêtes à ce que d'autres examinent leur code source, en particulier pour les projets qui travaillent dans le même domaine, sur les mêmes molécules ...
Par ailleurs, au cours de mes échanges avec David Anderson, il m'a explicitement dit qu'il ne peut en aucun cas forcer les projets à publier leur code source. Même de façon confidentielle.
1. Berkeley n'a pas ce pouvoir sur les projets.
2. Berkeley ne peut en aucun cas obliger les projets à communiquer leurs sources, ne serait-ce qu'en comité restreint.
3. Berkeley n'a pas les ressources (humaines notamment) pour s'atteler à cela.
4. Plusieurs projets utilisent des approches différentes pour un même thème d'étude. D'une certaine manière, ils sont en concurrence (ou compétition, au choix). Jamais ils ne partageront leurs sources avant l'obtention de résultats (et même après publication, c'est pas évident qu'ils les publient).
C'est pour ça que le comité serait composé de bénévoles externes à Berkeley, et qu'il faut mettre en place un système qui récompense les gens dans ce comité qui vont programmer des optimisations (comme l'a proposé jump ici : http://forum.boinc.fr/boinc/LAllianceFrancophone/Stats/systeme-credits-boinc-sujet_302_3.htm#t38557 )
Les programmeurs qui font des optimisations existent déjà, mais là le but est d'officialiser la chose en ayant des bénévoles labellisés par Berkeley auprès desquels une bonne partie des projets auraient plus confiance pour confier leur code
Atténue fortement la possibilité de tricherie vu que BOINC scanne régulièrement les capacités du PC
moi j'ai commencé à une toutes les 32 heures !
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.
Hallo.
Ja, ich lese mit :)
Ok, ich werde mir was zum Benchmarken überlegen. Ist ein neues thema für mich, klingt aber sehr interessant.
Super, danke!
Einstiegspunkt für Dein Engagement: Such Dir eine Workunit mit ca. 30 Minuten Dauer, die bereits gelöst wurde. Spiel die 200mal unter dem Namen test_xxx (mit xxx=0,...,199 ins System ein. Einen Tag später analysier die Benchmark-Werte. (Achtung, db_purge läßt Dir dazu nicht lange Zeit, dann sind die Werte wieder weg). Die wichtige Fragestellung ist, ob die erhaltenen Werte tatsächlich die Systemgeschwindigkeit repräsentieren. Also wird der gleiche Rechner immer etwa gleich bewertet? Sind die Werte gleicher CPU's unterschiedlicher Rechner immer ähnlich? Und ganz wichtig: Wenn CPU 1 doppelt so schnell ist wie CPU 2, dann sollte die Workunit auch wirklich doppelt so schnell auf CPU 1 gelöst worden sein.
Wenn der Score, den die Rechner erreichen, erst mal fair ist, dann kannst Du einen Umrechnungs-Faktor auf die zu grantenden Credits überlegen. Und zwar so, daß wir mit Mainstream-Projekten wie Seti gleichziehen.
Danke! / lg
Bernhard
Ah, c'était ça que je n'avais pas compris, comment les projets découpaient les tâches (WU donc).
Donc ce n'est pas possible d'avoir des tâches d'une durée fixée.
Pourtant Milkyway (par exemple) m'envoi toujours les mêmes tâches (même durée), donc théoriquement ça devrait être possible pour ce projet non ?
Ca dépend des projets. Par exemple, pour Nqueens il faut pour un certain damier appliquer récursivement un algorithme pour trouver les solutions et l'algorithme se termine lorsqu'il les a trouvé toutes. Comme on ne connait pas à l'avance le nombre de solutions, on ne peut pas donner une mesure précise même si on peut (dans ce cas) plus ou moins l'estimer.
Par contre pour Seti, où ils doivent analyser des signaux produits sur un intervalle de temps prévis. Ils savent plus précisément estimer le nombre de fois que l'analyse devrait être appliquée et connaître le durée du WU.
Je pense que tous les projets, à part yoyo, devraient pouvoir s'inspirer de cette méthode. En plus les sources de seti sont disponibles et il est très facile de voir comment elle a été implémentée :)Thrr avait déjà fait cette proposition mais certains ont répondus que les projets ne pouvaient pas connaitre le nombres d'oppération éffectué ou alors il serait falsifiable...
CiterJe pense que tous les projets, à part yoyo, devraient pouvoir s'inspirer de cette méthode. En plus les sources de seti sont disponibles et il est très facile de voir comment elle a été implémentée :)Thrr avait déjà fait cette proposition mais certains ont répondus que les projets ne pouvaient pas connaitre le nombres d'oppération éffectué ou alors il serait falsifiable...
C'est complètement faux. Implémenter un ou plusieurs compteurs, comme dans seti, pour savoir combien de fois le programme est passé à tel ou tel endroit, c'est faisable dans n'importe quelle appli, même pour les mauvais développeurs ;)Je ne sais pas si c'est réellement possible pour toutes les applications fonctionnant en mode wrapper (yoyo, H@H, ...)
Bon je suis d'accords pour qu'on soumette le message qui avait été écrit il y a 2 mois :
http://forum.boinc.fr/boinc/LAllianceFrancophone/Stats/systeme-credits-boinc-sujet_302_3.htm#t38496
Par contre, je pense vraiment qu'il faudra en parallèle tout faire pour inciter au maximum les projets à rendre leur code source librement consultable, en rendant plus attractif (en terme de points attribués) les projets qui le font.
Bonjour David,
Comme promis, les membres de l'Alliance Francophone ont discuté de la comparaison de crédit inter-projets. Les discussions ont mené à cela :
A l'origine, il y avait SetiClassic.
Des wus d'angles différents, des crédits accordés selon le nombre de wus renvoyées => simple.
Certains pratiquaient le "tri" des wus pour ne garder que les 3.3x, trichaient en renvoyant plusieurs fois les mêmes résultats. Mais c'était simple.
Aujourd'hui, il y a plusieurs projets, plusieurs types de calculs, plusieurs OS, plusieurs architectures matérielles, mais il reste 1 point commun à TOUS les projets : le temps.
D'où :
Definition de 2 machines de référence. Un AMD double coeur milieu de gamme et un intel double coeur milieu de gamme aux fréquences de base. Sous XP 32 bits et Linux 32 bits en double boot (parce que les plus répandus), une connexion internet 512 ou 1024ko, un GPU milieu de gamme (un ATI dans l'une, un NV dans l'autre par exemple).
Ces deux machines sont opérées à Berkeley et tournent TOUS les projets qu'elles peuvent exécuter.
Et la base sera x credit / heure / thread. La valeur x devant être l'étalon pour TOUS les projets pour leur application.
Ensuite, c'est très simple.
- Si un utilisateur overclocke sa machine ou dispose d'une configuration plus puissante que la référence => il crédite plus.
- Si le projet fait l'effort de coder en 64 bits parce que ses calculs en tirent bénéfice => tant mieux pour lui et pour les utilisateurs qui sont en 64 bits aussi.
- Si le projet permet de tirer partie du GPU => tant mieux et pour le projet, et pour l'utilisateur.
- Si l'utilisateur a une connexion ADSL 100 Mbits, tant mieux.
L'idée de base, c'est de définir un étalon, à la fois pour les projets et pour les utilisateurs.
- Si les utilisateurs font l'effort d'investir dans un matériel meilleur que celui de référence, ils sont rémunérés en crédits.
- Si un projet fait l'effort de proposer des applications pour des plateformes logicielles plus performantes, fait l'effort de solliciter le GPU etc, alors le projet est rémunéré par une plus grande puissance de calcul et l'utilisateur par des crédits au-delà de la référence.
Le cas des projets non mesurables :
Certains projets ne tournent QUE sur PS3 ou ne disposent pas d'applications XP/Linux 32. Certaines machines sont trop différentes de celles de référence (serveurs sous AIX, Mac...).
Dans ce cas, on reprend le principe de base : x credit / heure / thread.
Pourquoi thread et pas core ?
Si un projet peut tourner en parallèle sur le CPU + le GPU (donc 1 client par core du CPU + 1 client par core sur le GPU), il faut le prendre en compte. Donc, x credit / heure / thread.
L'idée de cette proposition est de rester le plus simple possible et d'éviter toute triche. Côté utilisateurs, les machines de références à Berkeley empêche toute triche. Côté projets en revanche, c'est plus compliqué car ils peuvent décider de passer outre l'étalon credit / heure / thread défini par Berkeley pour leur application. Pour ceux-là, c'est à Berkeley de résoudre le problème. Peut être en bloquant les projets qui ne respectent pas la valeur étalon.
Il existe un moyen : la version de Boinc est liée à la version côté serveur (donc côté projet). Il suffit que la version de Boinc soit mise à jour et requière une version minimum côté serveur. Or cette version serveur ne serait accordée aux projets que s'ils respectent la valeur étalon.
Cordialement,
blabla
On avait proposé d'autres variantesC'est vrai c'est à Berkeley de faire son choix parmit nos idées :o.
You might want to post it to boinc_projects or boinc_dev.
But in any case: we're not likely to make any credit-related changes for several months; too many other things to do right now.
Il existe déjà, mais il a fait... du vent parce que Anderson en a rien à cirer
EDIT : http://forum.boinc.fr/boinc/LAllia [...] _302_1.htm
Je me demande si l'outils d'IVAN ne serai pas plus efficace pour y calculer...
Un petit tableau que chacun peut remplir sur les projets sur lesquels il crunche : (c'est un fichier excel)Comme ce n'est pas réellement un fichier partagé, ma petite contribution sur un "vieux" AMD 5200 en copie d'écran
http://imp.free.fr/horde/util/go.php?url=http%3A%2F%2Fdl.free.fr%2FpugTcWCu3&Horde=fdb5eff190e25ea78b8348832cee2d12 (http://imp.free.fr/horde/util/go.php?url=http%3A%2F%2Fdl.free.fr%2FpugTcWCu3&Horde=fdb5eff190e25ea78b8348832cee2d12)
une petite fusion de topics ?
Nouveau concept de système de credit :
FLOPS maximum et performance
BOINC estime la performance maximale en FLOPS que peut fournir chaque processeur.
Pour les CPUs, il s'agit du score de benchmark en Whetstone.
Pour les GPUs, il faut utiliser une formule fournie par le fabriquant.
Pour autant, d'autres facteurs peuvent affecter les performances d'une application.
Par example, les applications ont besoin d'accéder à la mémoire vive, et la vitesse de cette mémoire n'est pas factorisée dans le score Whetstone de l'ordinateur.
C'est pourquoi un calcul donné peut prendre autant de temps sur un système de 1 GFLOPS que sur un autre de 10 GFLOPS.
La performance d'une application tournant sur un ordinateur donné est représentée par le ratio des FLOPS fournies par rapport aux FLOPS maximum du système.
Les GPUs ont ainsi habituellement une performance en FLOPS beaucoup plus élevée (50-100X) que les CPUs.
Cependant, la performance de leurs applications est généralement plus basse (très grossièrement, 10% pour les GPUs, 50% pour les CPUs).
Objectifs du système de credits
Quelques un des buts à atteindre dans la conception d'un nouveau système de credit:
Neutralité du matériel: des calculs similaires devraient obtenir des credits similaires quelque soient les processeurs ou GPU sur lesquels ils tournent.
Neutralité du Projet: different projets devraient accorder à peu près le même nombre de credits par jour pour un même processeur.
Il est facile de démontrer que ces deux objectifs ne peuvent être satisfaits simultanément.
Le premier système de crédit
Dans la première version du système de crédit de BOINC, les "crédits demandés" étaient définis par la formule
C1 = H.whetstone * J.temps_cpu
Il y avait alors plusieurs manières de prendre la moyenne ou le minimum des crédits demandés d'un calcul répliqué sur un autre hôte, et de l'utiliser comme "crédit accordé".
On appelle ce système "Peak-FLOPS-based" parce qu'il est basé sur la performance maximale (de pointe) d'un CPU.
Le problème avec ce système est que la performance d'une application donnée peut varier énormément d'un ordinateur à l'autre.
Dans l'exemple précédent, l'ordinateur de 10 GFLOPS demanderait dix fois plus de crédits et son possesseur serait furax de ne se voir attribuer qu'un dixième de ceux-ci.
Pour couronner le tout, les crédits accordés à un hôte donné pour une série de calculs identiques pourraient aussi varier énormément en fonction de l'ordinateur avec lequel celui-ci se trouverait apparié par le système de réplication des tâches.
Tout cela nous est apparu très arbitraire et injuste pour les utilisateurs.
Le second système de crédit
Nous avons donc changé de philosophie pour que les crédits soient proportionnels au nombre de FLOPs effectivement utilisés par l'application.
Nous avons ajouté des appels à des API spécifiques permettant aux applications de déclarer leurs FLOPs.
Nous avons appelé cette approche "Actual-FLOPs-based".
Comme l'application de SETI@home autorise le décompte des FLOPs, ce projet a adopté ce système en y ajoutant un facteur d'échelle de façon à ce que le crédit moyen par UT soit identique à celui du premier système de crédit.
Malheureusement, tous les projets n'étaient pas en mesure de compter leurs FLOPs.
SETI@home a donc publié son crédit moyen par CPU seconde et les autres projets ont continué à utiliser des crédits basés sur le benchmark, mais multipliés par un facteur d'échelle leur permettant de coller à la moyenne de SETI@home.
Ce système présentait cependant plusieurs problèmes:
Il ne prenait pas en compte les GPUs.
Les projets incapables de compter leurs FLOPs continuaient à avoir des problèmes liès à la neutralité du matériel.
Il n'empêchait pas la triche lorsqu'une réplication unique était utilisée.
Et la suite ...:jap:
Pour les autres paragraphes, je continuerai demain :kookoo:
Allez, pour faire plaisir à al@ON...
Buts du nouveau (3ème) système de crédit
Complètement automatique : Les projets n'auront pas besoin de changer leur code ni leur réglages, entre autre.
Neutralité matérielle.
Neutralité aménagée par Projet: différent projets devraient accorder à peu près le même nombre de crédits par jour pour un même processeur, ramenés à la moyenne des autres ordinateurs faisant tourner ce projet.
Les projets avec des applis GPU devraient accorder leurs crédits en proportion de la performance de leurs applications
(ce qui signifie que les projets ayant des applis plus performantes devraient créditer davantage, en moyenne, ce qui n'est pas un problème).
La comptabilisation des FLOP Maxi ou "Peak FLOP Count" (PFC)
Ce système s'inspire de l'approche basée sur la performance maximale (de pointe) d'un CPU, dite "Peak-FLOPS-based" mais s'attaque au problème d'une manière diférente.
Lorsqu'un calcul est envoyé à un hôte, l'ordonnanceur en définie l'utilisation(J,D) par l'hôte, soit J utilisation des ressources de calcul D: c'est à dire le nombre de CPUs et de GPUs à affecter à ce calcul (peut être une fraction).
Si le calcul se termine dans un temps T, on défini la fonction peak_flop_count(J), or PFC(J) comme
PFC(J) = T * (somme des processeurs D (usage(J, D) * peak_flop_rate(D))
Notes:
On utilise le temps écoulé plutôt que le temps processeur réel (temps CPU, par ex.).
Si un calcul utilise ces ressources de manière non optimale (par ex. une UT CPU qui génère beaucoup d'accès disque), le PFC() ne va pas en rendre compte.
Ce n'est pas grave.
Le point important est que BOINC aura réservé le processeur pour ce calcul, que celui-ci ait été utilisé de manière optimale ou non.
usage(J,D) peut ne pas être très précis; par ex. un calcul GPU peut monopoliser plus ou moins le CPU par rapport à ce que l'ordonnanceur avait estimé.
Au final, on pourrait même se tourner vers un système où le client détermine lui-même de manière dynamique l'utilisation du CPU.
Pour l'instant, on se contentera de l'estimation faite par l'ordonnanceur.
Les crédits accordés pour un calcul donné J sont proportionnels à (J), mais sont normalisés de la manière suivante:
Harmonisation inter-versions
Si une application donnée a plusieurs versions (par ex. une version pour CPU et une pour GPU) les crédits octroyés par UT sont ajustés de manière à ce que leur moyenne soit la même pour chaque version.
L'ajustement est toujours vers le bas: on conserve la moyenne PFCmean(V) de PFC() pour chaque version V d'une appli, et on trouve le minimum X. Les UT d'une version V sont alors redimensionnées par le facteur :
S(V) = (X/PFCmean(V))
Le résultat pour un calcul donné J est nommé "Version-Normalized Peak FLOP Count", or VNPFC(J):
VNPFC(J) = PFC(J) * (X/PFCmean(V))
Notes:
Ceci permet de prendre en compte la situation habituelle où l'appli GPU est beaucoup moins performante que l'appli CPU (c'est à dire que le ratio des FLOPs courants par rapport aux FLOPs maxi de l'appli est bien moindre).
D'une certaine manière, ce mécanisme fait pencher le système vers la philosophie des "Actual FLOPs", puisque les crédits sont distribués sur la base de l'appli la plus performante.
Mais ce n'est pas pour autant exactement "Actual FLOPs", puisque la performance de l'appli la plus performante n'est pas forcément de 100%.
Il y a deux sources de variations dans PFC(V): les variations de performance de l'hôte, et les possibles variations dans la taille des UTs.
Si nous savons faire une bonne estimation de la taille de l'UT (par ex., workunit.rsc_fpops_est) on peut l'utiliser pour harmoniser et réduire la variance, et faire en sorte que PFCmean(V) converge plus rapidement.
Une estimation a posteriori de la taille d'une UT peut également être possible (par ex., un nombre d'itérations relayé par l'appli) mais utiliser cette notion à quelque niveau que ce soit introduirait un risque de triche, il parait donc préférable de s'en abstenir.
Harmonisation inter-projets
Si une application possède à la fois une version CPU et une version GPU, alors le mécanisme d'harmonisation inter-version utilise la version CPU comme un "contrôle de validité" pour limiter le montant des crédits distribués aux calculs GPU.
Par contre, si un projet n'a qu'une appli GPU, il n'y aura pas d'appli CPU pour servir de contrôle de validité.
Dans ce cas, si on octroi les crédits seulement sur la base de la vitesse de pointe du GPU, le projet donnera beaucoup plus de crédits par heure GPU que les autres projets, violant ainsi le principe de "neutralité aménagée par projet".
Une solution à ce problème, pour les projets avec seulement une appli GPU serait, pour chaque version V, d'utiliser S(V) comme le facteur d'échelle moyen de ce type de GPU pour tous les projets qui ont à la fois une appli CPU et une appli GPU.
Ce facteur s'obtiendrait en interrogeant un serveur BOINC central.
Les calculs de l'appli V seront donc redimensionnés par S(V) comme ci-dessus.
Notes:
Les projets devront exécuter périodiquement un script pour mettre à jour les facteurs de mise à l'échelle.
Plutôt que le type de GPU, on utilisera probablement les "plan class" (j'ai pas compris...), puisque, par ex.,, la performance moyenne des applis sous CUDA 2.3 peut être assez différente de celles sous CUDA 2.1
Au départ, nous collecterons les facteurs de mise à l'échelle depuis les grands projets qui ont à la fois des applis GPU et des applis CPU (par ex. SETI@home).
Plus tard, nous utiliserons une moyenne (pondéré par le travail total effectué) sur de multiples projets (voir ci-dessous).
Harmonisation par hôte
Si l'on considère que, pour une appli donnée, les UT envoyées à tous les hôtes le sont de manière uniforme (sans discriminer entre type d'hôte), alors, pour cette appli, chaque hôte devrait avoir un même crédit moyen accordé par UT.
Pour s'en assurer, pour chaque application A, on conserve la moyenne VNPFCmean(A), et pour chaque hôte H, on conserve VNPFCmean(H, A).
Le nombre de FLOPS réclamé pour un calcul donné J est alors:
F = VNPFC(J) * (VNPFCmean(A)/VNPFCmean(H, A))
et les crédits réclamés (en Cobblestones) sont:
C = F*100/86400e9
Il y a cependant des cas où les UT ne sont pas envoyées de manière uniforme aux hôtes:
- attribution des UT par leur taille (les UT les plus courtes sont envoyées aux hôtes les plus lents) ou
- le système de GPUGrid.net qui envoie certaines UT (probablement les plus longues) vers les GPUs ayant le plus de processeurs.
Dans ces cas là, le crédit moyen par UT doit différer d'un hôte à l'autre, en fonction du type d'UT qui leur est envoyé.
Cela peut être réalisé en divisant chaque échantillon du calcul VNPFCmean par WU.rsc_fpops_est (en fait, il n'y a aucune raison de ne pas toujours faire ainsi).
Notes:
Le mécanisme d'harmonisation par hôte diminue le nombre de crédits réclamés par les hôtes qui sont moins performants que la moyenne, et augmente celui des hôtes qui le sont plus.
La moyenne VNPFCmean est calculée par rapport aux UT, pas aux hôtes.
Le calcul des moyennes
Il nous faut calculer les moyennes avec beaucoup d'attention car :
Les quantités dont on fait la moyenne peuvent changer progressivement avec le temps (par ex. la taille moyenne des UT peut changer, la performance des applis peut changer au fur et à mesure que de nouvelles versions sont déployées) et il nous faut tenir compte de tout ça.
Un échantillon donné peut être complètement hors des clous et on ne peut pas laisser ce mauvais calcul pourrir la moyenne.
Les moyennes devraient être pondérées par la taille des UT.
En plus, on pourrait également conserver la variance des quantités, bien que le système actuel n'en fasse pas usage.
Le code qui permet tout cela est ici.
Facteurs inter-projets de mise à l'échelle
Nous aurons un script qui publiera les données comptables des projets (voir l'implémentation)
Le site web de BOINC les collectera depuis quelques uns des gros projets et publiera les moyennes.
Réplication et triche
L'harmonisation par hôte élimine presque toute incitation à la triche qui consiste à réclamer des crédits excessifs (c'est à dire en falsifiant les scores de benchmark ou de temps écoulé).
En effet, une requête de crédit excessive ferait augmenter VNPFC*(H,A), ce qui aurait pour conséquence de rabaisser le nombre de crédits demandés en proportion.
Cela signifie qu'il n'est pas nécessaire de mettre en place un système de prévention de la triche dans les cas de réplication unique : crédits accordés = crédits demandés.
Pour les UT qui sont répliquées, les crédits accordés devraient être alignés sur le minimum des résultats validés (on utilisera le minimum plutôt que la moyenne afin de supprimer l'incitation au picorage, voir plus loin).
Malgré ce, il existe encore quelques possibilités de triche.
Des triches isolées (comme réclamer 1e304) peuvent être évitées en limitant VNPFC(J) à un certain multiple (disons, 10) de VNPFCmean(A).
Le picorage : imaginons une application ayant deux types d'UT, qui tournent pendant 1 seconde pour l'une et 1 heure pour l'autre.
Les clients peuvent deviner laquelle est laquelle, par ex. en faisant tourner une UT pendant 2 seconds et en vérifiant si elle s'est terminée.
Imaginons qu'un client rejette les UT d'une heure (par ex. en rapportant un crash ou en ne les rapportant jamais, ces UT).
Le VNPFCmean(H, A) de ce client va rapidement diminuer et bientôt il obtiendra des milliers de fois plus de crédits par calcul effectué que les autres hôtes!
Contremesures: à chaque fois qu'une UT finit en erreur, dépasse sa date de retour ou ne peut êre validée, remettre le taux d'erreur de l'hôte à sa valeur initiale par défaut et mettre à jour son VNPFCmean(H, A) à VNPFCmean(A) pour toutes les applis A. Cela mettra cet hôte dans un état où plusieurs dizaine de ses calculs suivants seront répliquées.
quel boulot merciMassacreur de Pseudo. :oxipheusxipehuz
Merci, al, de défendre mon intégritéPar contre je ne défends pas la veuve et l'orphelin. :D
oui mais si on calcul par exemple 10 uts est qu'elles partent en erreur.... on l'a dans le c..
enfin, on est participant pour aider la science, les points sont secondaires, théoriquement.
:)
En effet, le total de credits d'un compte ne veut plus rien dire.Je réfléchis à un classement qui tiendrait compte de la comparaison projet par projet.
La seule comparaison se fait projet par projet.
Je suis 21eme de l'AF selon les stats SetiBZH avec un joli total quand meme et 2eme sur GPUGrid (Merci mes 2 GPUs).
Mais je suis tres loin sur des projets comme QMC (295eme ! :o)
Bref, quand on se compare aux autres maintenant, il faut le faire projet par projet :sun:
Bon va falloir que je :hyperbon: un peu sur QMC :D
Cruncher | Projet X | Projet Y | Projet Z |
Nouf-Nouf | 2 000 | 100 000 | 0 |
Nif-Nif | 0 | 200 000 | 1 500 |
Naf-Naf | 1 000 | 0 | 500 |
Projet | Nb utilisateurs | Prod | Points distribués (Nb utilisateurs X 1000) |
X | 500 | 500 000 | 500 000 |
Y | 100 | 5 000 000 | 100 000 |
Z | 1 000 | 500 000 | 1 000 000 |
Projet | Prod réelle | Participation au projet | Points obtenus |
X | 2 000 | 0.4% | 2 000 |
Y | 100 000 | 2% | 2 000 |
Z | 0 | 0% | 0 |
Total | 102 000 | 4 000 |
Projet | Prod réelle | Participation au projet | Points obtenus |
X | 0 | 0% | 0 |
Y | 200 000 | 4% | 4 000 |
Z | 1 500 | 0.3% | 3 000 |
Total | 201 500 | 7 000 |
Projet | Prod réelle | Participation au projet | Points obtenus |
X | 1 000 | 0.2% | 1 000 |
Y | 0 | 0% | 0 |
Z | 500 | 0.1% | 1 000 |
Total | 1 500 | 2 000 |
bravo Seb,Ma proposition ne marche que pour les crédtis futurs. Les crédits antérieurs à la mise en place du classement ne pourraient pas être pris en compte puisqu'il est impossible de connaître dans quelles conditions ont été obtenus ces crédits. C'est la raison pour laquelle j'ai proposé un classement glissant sur un an.
Je me disais que tu n'allais pas en rester a ce que tu as fait pour le RAID. Vu que j'avais fait des propositions et que je reflechis toujours a ce sujet. Je vais etudier ta proposition en detail. Pour les 2 premiers points, je crois que je suis parfaitement d'accord avec toi. Pour le troisieme point : pourquoi 365 jours glissants? Ca veut dire un classement annuel...pourquoi pas 'éternel' ou cumulé.
Ma proposition ne marche que pour les crédtis futurs. Les crédits antérieurs à la mise en place du classement ne pourraient pas être pris en compte puisqu'il est impossible de connaître dans quelles conditions ont été obtenus ces crédits. C'est la raison pour laquelle j'ai proposé un classement glissant sur un an.Je vois 2 solutions.
Pour faire un classement perpétuel, il faudrait recalculer les crédits actuels avec comme base sur chaque projet le nombre total d'utilisateur et la somme des crédits. C'est faisable mais je ne sais pas si ça serait juste.
Pour l'instant, je n'ai rien mis en place. Je pense mette en place une page de démo ce week-end.
:pt1cable: :pt1cable: :pt1cable: :pt1cable: :pt1cable:Surtout ne pas les déranger :adonf: ... ça pourrait être dangereux dans leur état :warf:
Ouf ça décoiffe ! Bravo Sébastien et merci au WE pluvieux :lol:Qu'est-ce qu'il avait ce WE? :siflotte: :siflotte:, un excellent temps pour la pêche...ou les champignons
Sinon une question plus technique. Il arrive parfois qu'un utilisateur n'a pas le même CPID sur tous les projets mais qu'un jour en crunchant avec le même pc sur tous les projets qu'ils se regroupe sur le même CPID. On a alors des choses bizarre qui se produise dans le classement. Par exemple cet utilisateur (http://boincstats.com/fr/stats/-1/user/detail/425083/charts)dont le "Crédit/jour " est énorme (500 millions) alors qu'en réalité il n'a pas gagné plus de 5 millions aujourd'hui.Le classement ne devrait pas être faussé par le changement de CPID. Lors des MAJ des stats, je prends l'userid sur chaque projet
Cela peut-il être évité ? Car sinon le classement se trouverait complètement faussé :/
J'ai pas vu de classement entre équipes (mais peut-etre que j'ai mal cherché).. MAis bon,, y a pas le feu! Juste pour voir si ca va jaser ou pas quand quelqu'un ira vendre cette proposition à d'autres teams...Pour le moment, il n'y a pas de classement team.
WUProp@Home ne serait il pas un peu favorisé :sun:Les projets NCI sont effectivement avantagés.
Je vois un effet pervers à cette réglementation, c'est le départ de l'AF de tout(e)s celles et ceux qui calculent pour les crédit et rien d'autre!!!je ne comprend pas trop cette partie
Je n'ose pas imaginer que ce soit le but recherché...
Ce serait dommage de perdre de gros comptes/cruncheurs pour nos "combats" dans les classements juste pour essayer de "réguler" les crédits!!
je ne comprend pas trop cette partie@RLDF: justement non, c'était l'idée de remplacer TOUS les sites de stats par une nouvelle formule, sinon, ca sert à RIEN! d’où des discussions à mener avec les autres équipes qui ont des sites reconnus Boincstats, free-DC ? equipes: SG par exemple...
qu'est ce qui empêche quelqu'un qui calcule pour les crédits de rester à l'AF ?
il existe des stats comme boincstats qui resteront sur la base des points des projets boinc
@ Sebastien11, Désolé, je l'avais pris pour moi... :/
@RLDF: justement non, c'était l'idée de remplacer TOUS les sites de stats par une nouvelle formule, sinon, ca sert à RIEN! d’où des discussions à mener avec les autres équipes qui ont des sites reconnus Boincstats, free-DC ? equipes: SG par exemple...marchera jamais, mais bon courage les gars :siflotte:
marchera jamais, mais bon courage les gars :siflotte:pas si sur que cela. D'apres quelques posts sur ce forum il y a un certain temps, j'avais compris que Boincstats et SG cherchaient d'autres manières de calculer. On verra bien...
Bonjour,Peut-être que toute les réponses a ces questions sont le fofo qu'il faut prendre le temps de lire et découvrir. :ange:
suis un petit nouveau au sein de l'AF.
Quelqu'un pourrait-il m'expliquer ou me dire où trouver des infos au sujet de :
UOTD : qui désigne les lauréats et sur quel(s) critère(s) ?
EQUIRAC : Y'at'il des badges, points ou autre récompense ? Reçoit-on des points supplémentaires ?
Merci Beaucoup
Philippe
Je crois que je vais laisser tomber ce système.
BoincStats a déja proposé un système similaire (RAC sur 30 jours au lieu de la prod journalière) et ça n'a pas pris :/
Je réfléchis plutôt à un classement similaire au FB pour les utilisateurs. La distribution des points serait évidemment plus large et fonction du nombre de membre actifs sur le projets.
Je ne crois pas possible de remplacer le classement actuel. Il faudrait d'abord que l'ensemble des sites de stats décident d'arrêter d'additionner les stats des projets. Je l'ai déjà dit, on n'additionne pas les carottes et les navets.
Je l'ai déjà dit, on n'additionne pas les carottes et les navets.
Alors, le système de comparaison utilisé compare un même hôte sur 2 projets.
Pour ceux qui s’interrogent sur l'écart de point entre CPU et GPU voici une bonne explication de Slicker l'administrateur de Collatz à "Dingo" membre de l'équipe Australienne!
Tout d'abord voici la question de "Dingo" de l'équipe Australienne:
Je pense qu'il est étrange qu'un GPU peut obtenir 6707.12101530731 points à l'heure pour l'unité http://boinc.thesonntags.com/collatz/workunit.php?wuid=13778756 tandis que la version "Raspberry" obtiens 10.75486936930966 crédits par heure pour l'unité http://boinc.thesonntags.com/collatz/workunit.php?wuid=13688037
Je sais que le traitement de "Raspberry" prend plus de temps, mais les deux unités sont cruncher à la fin?
Voici le message original:
"Message 20348 - Posted: 27 Mar 2015, 1:55:15 UTC - in response to Message 20342.
I think that it is strange that a GPU can get 6707.120101530731 credits per hour for this job, http://boinc.thesonntags.com/collatz/workunit.php?wuid=13778756But the Raspberry gets 10.75486936930966 credits per hour for this job http://boinc.thesonntags.com/collatz/workunit.php?wuid=13688037
I know the Raspberry takes a long time to procvess the work but in the end they both end up with a result ? "
Voici la réponse de l'Admin Slicker:
Dans ce cas, le GPU qui a cruncher l'unité Mini Collatz en 49,265,227,273,268 étapes tandis que "Raspberry" a complété l'unité Micro en 3,730,627,081,902 étapes. En somme, le GPU a cruncher 13 fois plus de travail que le "Raspberry". Pour ce travail le GPU a reçu 719 points, techniquement le "Raspberry" devrait recevoir que 55 point (soit 1/13 de 719). Cependant, il en a reçu 65 points, donc il en a plus qu'il devrait en recevoir.
Le "Raspberry" a seulement cruncher 1/13 du travail et ce en 56 fois plus de temps pour le faire. Le "Raspberry" ne peut pas s'approcher au même niveau de production par heure qu'un GPU et ce d'aucune façon!
Voici la réponse originale:
"Message 20349 - Posted: 27 Mar 2015, 18:25:24 UTC - in response to Message 20348.
In this case, the GPU which completed a MINI WU calculated 49,265,227,273,268 steps whereas the Raspberry which completed a MICRO WU only did 3,730,627,081,902. In other words, the GPU did 13 times the work of the Raspberry. Since the GPU received 719 credits, technically the Raspberry should have only received 55 credits which is 1/13 of 719. But, it received 65 credits, so it really got more than it should have.
The Raspberry only did 1/13th the work and it took 56 times longer to do it. There's no way it is going to get anywhere close to the same credit per hour as the GPU."
En tout cas, GoofyxGrid me donne 10 crédit par WU depuis le début.:+1:
C'est invariable...
Pour moi le seul système équitable serait le temps, durée par UT = crédit fixe pour tout projet.Bon, personne n'a répondu après plus de 4 heures, même pas un point pour la présence, vous êtes recalés... :D :D
Mais il n'est plus représentatif des Gflops calculés, ce que prétend faire Boinc depuis le début, le rendant par nature inégalitaire.
Mais l'égalitarisme est-il équitable ?
(sujet de philo, vos avez 4 heures)
Il faut faire RESET. En passant de SETI@Home à BOINC, il y a eu RESET mais souvenir des crédits de SETIClassic. On peu imaginer que reset et souvenir de BOINC 1.0 au moment de passer au BOINC 2.0
Blague à part, dans ce genre de changement, souhaitable, il y a un passif à gérer, garder les scores en état (des nouveaux vont râler), dévaluer ou raz des scores (des anciens vont râler), et j'en passe... Il y a une compétition en jeu pour certains...
Problème épineux comme partout :coffeetime:
Il n'y a pas d'instance "dirigeante" pour Boinc hormis le code, ça demanderai une concertation générale des projets et je doute qu'ils aient la disponibilité et voient un intérêt pour leur projet; pas impossible mais hautement improbable. Beaucoup de négociations à prévoir, mais entre qui et qui? décision à l'unanimité? majorité? ... pas mal de prises de têtes en vue :)Il faut faire RESET. En passant de SETI@Home à BOINC, il y a eu RESET mais souvenir des crédits de SETIClassic. On peu imaginer que reset et souvenir de BOINC 1.0 au moment de passer au BOINC 2.0
Blague à part, dans ce genre de changement, souhaitable, il y a un passif à gérer, garder les scores en état (des nouveaux vont râler), dévaluer ou raz des scores (des anciens vont râler), et j'en passe... Il y a une compétition en jeu pour certains...
Problème épineux comme partout :coffeetime:
Je suis un 'vieux', j'ai plus d'1 myard de crédits. Le nouveau système me défavoriserait, je le sais et je devrais repartir à 0. Pas grave, il y a des gens qui repartent à zéro dans leur vie pour des raisons bien pires que des crédits BOINC... Et les mégacruncheurs d'aujourd'hui resteront les mégacruncheurs avec le nouveau système mais ils ne pourront plus faire QUE du Collatz pour se retrouver en haut du podium...
...Les vieux ronchonnent :) j'avoue que je ressens l'effet que peuvent produire les écarts de points d'un projet à l'autre pour un petit nouveau qui fait sa BA sur WCG et Rosetta et autres projets bio non gpu, et qui a l'impression de rester sur place parce qu'il ne peut pas mettre sa gpu en calcul (beaucoup de cartes graphiques correctes pour un jeu ne conviennent pas au calcul, question rendement), sachant que le public visé par Boinc initialement n'est pas censé faire du calcul dédié.
mais y'a un réel mouvement pour ce BOINC 2.0 ou se sont les "vieux" ( ;) ) de l'AF qui ronchonnent dans leur coin (enfin on fait mieux que ronchonner vu que l'on débat sur des propositions que l'on apporte :jap: ) ?
Pourquoi pas des "points" suivant l'ancienneté tout simplement.il faudrait dans ce cas comptabiliser l'ancienneté sur le processus boinc lancé dans le système, calculant ou pas
Que tu ai 1 ou 50 PCs, c'est la même chose...
il n'empêche que compter chaque boinc revient à donner des points en fonction de la taille du parc
la question de base alors devient : faut-il compter chaque machine ou chaque CPID utilisateur qui apparait dans les stats ?
là encore, l'utilisateur peut très bien tricher en ayant plusieurs CPID et donc plus de points au global
Hé bien je pensais pas obtenir autant de réactions, on voit bien que ça interpelle....
1er point : je crois que justement c'est le cas. Les projets appliquent justement LA règle rappelée quelque part dans les pages de ce sujet.
Du coup, si je devais résumer mes préconisations :
- Définir un taux fixe de points/FLOPs
- Séparer les compteurs CPU/GPU/ASIC
D’après moi, le meilleur compromis actuel se trouve au niveau de World Community Grid. Pas au niveau des crédits certes, mais au niveau de l’attribution des badges.Ouais pas tout a fait convaincu.
FightAIDS@Home - Phase 2 230.829 94 0:062:00:30:41
J'ai mis un I7 et un x6 pendant 4 jours ( pas plus ) pour me voir attribuer ce badge (https://secure.worldcommunitygrid.org/images/pb/fahb_1.jpg) et le projet m'attribue 62 jours de calcul.CiterFightAIDS@Home - Phase 2 230.829 94 0:062:00:30:41
Je trouve cela bien généreux.
moi j'aimerais surtout que l'on arrive à trouver une solution pour répartir un peu mieux la puissance de calcule pour que tout le monde en profite un peu... et pas que les futur projets aient besoin de sur-enchérire-créditer pour récupérer des cruncher !C'est bien pour ça que WUprop a été créé, il me semble. Ainsi que le Formula Boinc. (ou l'inverse? cocoricooo)
:jap:
car rien que sur Yoyo, les 3 projets tu as bien 20% de différence entre les sous-projets (sur mon PhenomII c'est 5K à plus de 8K de RAC en fonction du projet) !C'est parce que sur des sous-projets plus difficiles (de mémoire Muon et evolution - à cause de la rareté, respectivement de l'absence de points de sauvegarde), il y a un bonus. C'est expliqué qq part sur le forum de yoyo (chui pas chez moi, donc pas de lien direct car pas de barre d'outils de l'AF :siflotte: )
Les deux dernières pages me rappellent les débats qu'il y a eu du temps de BHS lors de l'apparition des projets GPU :origin:
Il y a belle lurette que je ne regarde plus les crédits
Augure link=topic=953.msg430552#msg430552 date=]
moi j'aimerais surtout que l'on arrive à trouver une solution pour répartir un peu mieux la puissance de calcule pour que tout le monde en profite un peu... et pas que les futur projets aient besoin de sur-enchérire-créditer pour récupérer des cruncher !
:jap:
Il suffit de faire des badges pour me récupérer :D :D
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
Il existe plusieurs options pour l'attribution des crédits ; voir
https://boinc.berkeley.edu/trac/wiki/CreditOptions
-David
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)...CiterC'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=2818CiterJ'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.
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 :/