Le Forum de l'Alliance Francophone

Nouvelles:

Auteur Sujet: Lobying anti DistRTgen  (Lu 59404 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne [AF>Libristes>Jip] otax

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5635
  •   
    • Le Libre  : Linux , Boinc et les autres  ;-)
    • E-mail
Réponse #50 le: 04 June 2012 à 23:03
Intéressant Clp.  :jap:

On attend la suite de tes cogitations  :)


Hors ligne [AF>Libristes>Jip] Elgrande71

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 5110
  •   
    • [AF>Libristes] - La Mini-Team Libristes de L'Alliance Francophone sur BOINC
    • E-mail
Réponse #51 le: 04 June 2012 à 23:13
Oui, tiens nous au courant clp.  :hello:

Debian - Distribution GNU/Linux de référence
Parabola GNU/Linux - Distribution GNU/Linux Libre
MX Linux
Emmabuntüs

Jabber elgrande71@chapril.org


Hors ligne al@ON

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 11703
  •   
    • MySpace al@ON
Réponse #52 le: 04 June 2012 à 23:19
Willy connaît-il l'ÉquiRAC?

En ce moment je me tiens une p*tain de forme dans ce classement... :winner2:


Hors ligne ousermaatre

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 12229
  •   
    • E-mail

Hors ligne [AF>Libristes>Jip] otax

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5635
  •   
    • Le Libre  : Linux , Boinc et les autres  ;-)
    • E-mail
Réponse #54 le: 04 June 2012 à 23:29
Willy connaît-il l'ÉquiRAC?

En ce moment je me tiens une p*tain de forme dans ce classement... :winner2:

Je ne pense pas.
Mais l'Equirac a été créé pour apporter la diversification au sein de l'AF.
C'est une base a étudier, mais le système fait trop yoyo pour que les gens puissent s'y retrouver rapidement au niveau évolution dans les classements.
L'intérêt reste qu'il lisse les points des projets et ça peut resservir sous cet angle.


Hors ligne Matt11

  • Boinc'eur Respectable
  • ****
  • Messages: 686
  •   
Réponse #55 le: 05 June 2012 à 00:52
Le problème de l'equirac c'est que ça force l'uniformisation.
Un projet peut avoir peu d'utilisateurs parce qu'il est mal géré, parce qu'il n'est pas très intéressant d'un point de vue scientifique ... et l'equirac "inciterait" à cruncher dessus, ce qui est un peu bizarre  :siflotte:

Les sites de stats pourraient aussi essayer de créer une "banque centrale de crédits" indépendante des projets et décideraient du "taux de change" entre les projets (en fonction des caractéristiques projets, temps de calcul sur machine test, intérêt scientifique, ...) pour avoir une certaine unité. Ainsi les projets qui surcréditent verraient leur taux diminuer (inflation).

C'est l'idée du CPCS mais tout l'enjeu est de savoir qui pourrait participer au négociations (admin des sites de stats, admin projets, représentant des teams, David Anderson ?) et sur quels critères seraient calculer ses taux de change.


Ubuntu Mate 18.04  Intel core i7 6700K 4x4.0GHz 16Gb Nvidia Geforce GTX 1070


Hors ligne ousermaatre

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 12229
  •   
    • E-mail
Réponse #56 le: 05 June 2012 à 00:59
ben forcément toujours en ma faveur, hé là, comme une banque....  :D



Sans raconter de blagues, Otax, tu as certainement pensé à link304, en parlant d'idées nouvelles pour les stats, faudrait peut-être qu'on le contacte ?

« Modifié: 05 June 2012 à 01:11 par ousermaatre »



Hors ligne [AF>Libristes>Jip] otax

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5635
  •   
    • Le Libre  : Linux , Boinc et les autres  ;-)
    • E-mail
Réponse #57 le: 05 June 2012 à 07:18
> Matt11
L'idée du CPCS comme équivalent (change) de crédit est assez bonne.
Ce qui est difficile est de trouver le bon change, bien accepté par tous et que tous les sites de stats aient le même.
Le problème est que vu sa complexité, il risque d'être "mouvant" ....

Maintenant pour ce qui est de sa mise en place, ce doit être à mon sens uniquement un accord en sites de stats.
Pourquoi ?
1) Berkeley n'en a rien à faire de nos bidouilles de points
2) Les premiers sites de stats n'ont jamais rien demandé à personne pour s'établir, ils n'ont donc pas besoin du soutien des Teams (Au contraire, ça dessert leur impartialité).
3) Oui c'est un accord entre site de stats qui doit être fait en amont du changement, sinon, il n'aura aucun avenir.


> Ouser
Oui, j'ai parlé de lui au début, mais actuellement il est bien occupé je pense. (Mon 3ème Post : Un Gage : Relis tout !!!!  :D )
Je peux tjs lui poser la question en MP, mais je trouve que c'est prématuré si on arrive à une autre solution plus simple.

Pour trouver la bonne solution, il faut faire une matrice en croisant les 3ou 4  idées et les critères importants (compréhensibilité, simplicité, ...) . On pondère cela et ça permet de choisir avec un large consensus.


Hors ligne [AF>Libristes] Pascal

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2413
  •   
    • Forum de la M-T Libristes de L'AF
    • E-mail
Réponse #58 le: 05 June 2012 à 07:29
 :hello: Ma petite contribution à cette grande réflexion sur les crédits octroyés par les admins de projets BOINC.

Tout d'abord, je ne suis pas favorable à un crédit de points uniforme en fonction du temps passé aux calculs ; il y a une trop grande diversité de machines participantes qui pénaliserait les machines rapides et avantagerait les machines anciennes ou plus lentes.

À mon sens ne devraient pas rentrer dans les statistiques les applications nci car elles ne consomment que très peu de ressources et ne méritent pas un crédit de points qui bien souvent sont plus symboliques mais plutôt un classement à part avec une durée de participation sur le projet en jours, mois, années ... ce qui serait plus significatif sur l'engagement du participant.

Pour les projets classiques CPU et GPU, il n'est pas aisé de savoir quel travail à réellement été effectué lors d'une unité de calcul, donc on ne peut pas tenir compte des différences de sollicitation d'une application à l'autre. Par exemple, une application GPU va solliciter le GPU à 80% tandis qu'une autre ne le sollicitera qu'à 30%.

Une autre difficulté est de faire la part des points obtenus en applications CPU et ceux obtenus en applications GPU pour les projets comportant ces deux types d'applications. J'ai une pensée particulière au projet GPUGrid qui se dit exclusivement GPU mais qui monopolise (chez moi en tous cas) un core en permanence et pénalise donc les projets CPU en augmentant par là même leur durée d'exécution d'un tiers (j'ai 4 cores).

Ma proposition serait dans un premier temps si la majorité des admins de sites de statistiques sont d'accord de ne plus additionner les données brutes venant des projets mais de les affecter d'un coefficient du genre de tableau déjà cité http://boincstats.com/fr/stats/-1/cpcs

Dans un deuxième temps, pour affiner les coeffs, serait de prendre une machine de référence par plate-forme et de les faire calculer durant quelques jours sur un projet qui servira de référence aux autres projets, par exemple SETI@home, et d'appliquer le coeff 1 à une application CPU et à une application GPU par plate-forme.
Ensuite, ces mêmes machines calculeront également quelques jours sur chaque application de chaque projet afin de déterminer le coefficient pour qu'à durée de travail égal il y ait le même nombre de points qu'avec l'application de référence.
Ainsi, une heure passée en GPU sur seti@home Enhanced 6.08(cuda) aurait le même nombre de points qu'une heure passée sur distrrtgen 3.48(cuda23) et qu'une heure passée en CPU sur seti@home 5.28 donnerait le même nombre de points qu'une heure passée sur distrrtgen 3.48 ; tout ça pour une même machine évidemment!
Ensuite il faut ramener le compte de points par unité de travail et ainsi attribuer ce compte de point à chaque unité calculée par les participants. Les machines rapides feront plus d'unités dans un laps de temps donné qu'une machine ancienne ou plus lente et tout le monde y trouvera son compte sur les projets de son choix.

C'est peut-être un peu compliqué à mettre en place, surtout la phase de calcul des coefficients qui pourra prendre plusieurs mois mais en commençant par les projets qui s'éloignent le plus de la moyenne en sur-créditant ou en sous-créditant on pourrait avoir un équilibre assez rapidement.
Le plus dur est je pense de convaincre les admins de stats de modifier leurs calculs ! :hyperbon:


PC ; GNU/Linux ubuntu-mate 20.04 LTS (focal) - AMD FX8350 x8 - 32Go DDR3 - GTX 1060 et GTX 1080 Ti
Raspberry Pi : RaspBian (dérivé de Debian Wheezy) - ARMv6 - carte flash SD 8Go


Hors ligne Sébastien

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 2455
  •   
Réponse #59 le: 05 June 2012 à 07:32
J'ai une autre suggestion de classement en se servant de la production journalière médiane.

Le principe est de collecter pour chaque projet la production de chaque host lors des dernières 24 heures et de déterminer la médiane de ces productions.
Cette médiane servirait alors d'étalon. Pour un projet donné, un utilisateur ou une team qui créditerait X fois plus que la médiane lors des dernières 24 heures recevrait X fois 1000 crédits équivalents.
On obtiendrait ainsi chaque jour et pour chaque projet des crédits équivalents. Il suffirait alors de les additionner et de faire un classement glissant sur un an.

Je sais pas si mes propos sont très clairs. Je devrais être en mesure de poster une démo d'ici quelques jours.



Hors ligne kasur

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 3128
  •   
    • E-mail
Réponse #60 le: 05 June 2012 à 07:45

Dans un deuxième temps, pour affiner les coeffs, serait de prendre une machine de référence par plate-forme


 :kookoo:
Ce serait un must je trouve, si le cycle est moins long. Peut etre qu'avec des VM dessus ça permettrai d'etre plus équitable sur la ressource allouée et que ça permettrai de faire plusieurs test en meme temps.

edit @seb: c'est plutot clair les points serait distribué suivant la position dans la prod du projet, non? ça enlèverait la limite de participants. Il y a toujours l'effet pervers du projets alpha qui calcule peu, mal et inutile et dont un cruncheurs prendrait la moitié des unités, non?

bon journée à tous
« Modifié: 05 June 2012 à 07:50 par kasur »


et 194 SETI@home classic workunits (4 764 hours) :p


Hors ligne Sébastien

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 2455
  •   
Réponse #61 le: 05 June 2012 à 07:48
@Pascal: Au niveau des exports des stats, on ne peut pas différencier les points obtenus par des WU CPU ou GPU.



Hors ligne [AF>Libristes] Pascal

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2413
  •   
    • Forum de la M-T Libristes de L'AF
    • E-mail
Réponse #62 le: 05 June 2012 à 08:06
@Pascal: Au niveau des exports des stats, on ne peut pas différencier les points obtenus par des WU CPU ou GPU.
C'est bien ce que je pensais. Pour ces projets là il sera très difficile de faire quelque chose de cohérent sauf s'il y a le même coefficient  pour les applications CPU et pour celles GPU.


PC ; GNU/Linux ubuntu-mate 20.04 LTS (focal) - AMD FX8350 x8 - 32Go DDR3 - GTX 1060 et GTX 1080 Ti
Raspberry Pi : RaspBian (dérivé de Debian Wheezy) - ARMv6 - carte flash SD 8Go


Hors ligne [AF>Libristes>Jip] otax

  • Animateur fanatique
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 5635
  •   
    • Le Libre  : Linux , Boinc et les autres  ;-)
    • E-mail
Réponse #63 le: 05 June 2012 à 08:07
> Kasur,

Non, je ne pense pas que c'est ça.

Plutôt ça :

3 cruncheurs : chacun fait par jour sur 1 projet donné :
C1= 100
C2=10
C3=1

Médiane = 10   (valeur située au milieu)

donc
C1 aura 10 fois 1000 = 10 000
C2 aura 1 fois 1000 = 1 000
C3 0.1 fois 1000 = 100

Et CELA QUEL QUE SOIT LE RAC REEL, donc indépendant du projet.


Hors ligne [AF>Libristes] Pascal

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 2413
  •   
    • Forum de la M-T Libristes de L'AF
    • E-mail
Réponse #64 le: 05 June 2012 à 08:17
Je n'avais pas compris ça comme ça.
C'est pas mal en effet !


PC ; GNU/Linux ubuntu-mate 20.04 LTS (focal) - AMD FX8350 x8 - 32Go DDR3 - GTX 1060 et GTX 1080 Ti
Raspberry Pi : RaspBian (dérivé de Debian Wheezy) - ARMv6 - carte flash SD 8Go


Hors ligne JeromeC

  • CàA
  • Boinc'eur devant l'éternel
  • *****
  • Messages: 31106
  •   
Réponse #65 le: 05 June 2012 à 12:13
Très intéressante l'idée de Seb, avec l'avantage de la simplicité, pas des tonnes d'analyses sur machine de référence à faire, faisable avec les données dispo actuellement.

Mais ça continue de mélanger les points CPU et GPU, c'est une bonne chose au final ?

A quoi bon prendre la vie au sérieux, puisque de toute façon nous n’en sortirons pas vivants ? (Alphonse Allais)



Hors ligne Spica

  • Méchant modo
  • Boinc'eur devant l'éternel
  • ******
  • Messages: 5146
  •   
Réponse #66 le: 05 June 2012 à 16:46
J'ai creusé un peu mon idée d'hier soir. Merci pour les encouragements. En fait, j'ai l'impression qu'on est plusieurs à avoir la même idée en gros à savoir utiliser les idées d'equirac et conserver un système proche de ce qui existe et plutôt simple pour être efficace et qui évite le grand n'importe quoi.


Dans le tableau ci-dessous, j'ai regroupe quelques infos sur différents projets qui me semblent représentatifs. A gauche, les noms de projets ensuite leur 'date de naissance', leur age en années depuis leur creation (l'idée est que les anciens qui ont survecu sont populaires et donc attirent les cruncheurs). Ensuite, il y a une colonne si c'est GPU ou CPU : les projets mixtes seront traites comme GPU only, il n'y a pas le choix. Ensuite, il y a 3 colonnes tirées du site BOINCstats, le nombre moyen de crunchers actifs sur ce projet, le nombre de hosts actifs pour ce projet (donc combien de machines tournent sur ce projet) et enfin le nombre moyen de credits que ce projet delivre par jour. Pour cette colonne, l'unité est le million de crédits, pour les deux autres , en milliers.
Premiere chose qui frappe, on voit bien une distortion forte entre les projets qui creditent enomement avec peu de 'hosts' qui contiennent peut-etre des armadas de GPUs (ou CPUs). AInsi GPUGRID et surtout DIstrtgen creditent a mort avec tres peu de machines 'utilisées' comparés à Einstein.

Les colonnes suivantes: mon idée presentée hier est de dire que chaque projet attribuera X credits par jour pour le classement combine. La question est X doit-il etre le meme pour tous les projets GPU d'une part et tous les projets CPU d'autre part ou bien X est gouverné par autre chose tel que la popularité du dit projet.  Pour moi un X identique pour tous les projets est non viable et pénalise lourdement les projets populaires...

En definissant 2 parametres que je note GPU et CPU, j'essaie de m'approcher de ce qui est credite actuellement par les projets tout en essayant de limiter les distortions :
Les colonnes vertes et bleues correspondent à dire tous les projets ont le meme nombre de credits modules par leur age: pour un GPU 10Myons de credit/jour mais comme la technologie s'ameliore de jour en jour, cela veut dire que chacun gagne de moins en moins avec le temps. Une maniere de corriger cela est 'betement' de dire que SETI qui est populaire et qui est le plus vieux distribuera 10Myions*13 ans=130Myons par jour ce qui n'est pas tres loin de ce qu'il distribue au total chaque jour en 2013, il distribuera 140Myons/jour (pour l'interclassement entre projets toujours!). On remarque que pour les projets GPU, les projets 'epingles' pour surcreditation se trouvent diminués, les osu-crediteurs comme seti inchange pour Eisntein reevalué.
No comment pour Distrtgen!! Pour les projets CPU, la difference entre la colonne bleu et la colonne verte est si on met un rapport 100 entre CPU et GPU ou bien 10 seulement ce qui veut dire qu'un projet CPU donnera 100kcredits ou bien 1M. Il faut voir qu'il y a plus de CPUs dans la nature que de GPUs et donc le facteur 100 en puissance est compensé par l'effet de nombre.
En prenant donc un rapport 10, c'est a dire tout projet CPU correspond à se partager 1M de crdits par jour, les chiffres sont proches de ce qui est distribue a l'heure actuelle, les grands gagnants sont donc Leiden et Ibercivis, pas une surprise qui on le sait souscredite mechamment mais Rosetta et WCG sont les grands perdants...Euh! ca c'est pas possible, donc utiliser l'age (du capitaine  :siflotte:) n'est pas un bon critere...
-) Autre possibilité: SI un projet attire beaucoup de monde, c'est qu'il intéresse du monde et et il a su être attractif en ce qui concerne son projet scientifique. Donc au lieu d'utiliser l'age du projet, utilisons le nombre d'users actifs (en milliers) sur le projet qui est une certaine mesure de sa popularité et donc de l’intérêt scientifique qu'y trouve les cruncheurs, c'est la colonne sur fond orange. Pour les projets GPU, je prend donc credits du projet=1000* nombre de users actifs pour avoir un chiffre correct pour SETI, si Einstein, c'est pas trop mal, c'est le désastre pour GPUGRID et dans une moindre mesure, Collatz et Milky et PRimegrid et berezina pour Distrtgen. Mais ca non plus, c'est pas une surprise, on sait que Seti et Einstein sous credite a mort par rapport a tous ces projets (cf topic de Nabz avec la comparaison entre les projets GPU), donc on peut monter le coefficient si on veut pour 2M/projet, cela remettra en selle Eisntein et Seti a des niveaux plus accceptables. Pour le CPU, il faut 0,5Myions/jour*nombre d'actifs pour obtenir des chiffres acceptables. Si pour Rosetta, tout va bien, pour WCG, c'est toujours pas ca!

-) Enfin, au lieu de considerer les users, on considere plutot les hosts, on obtient les 2 colonnes de droite sur fond jaune avec des coeffs différents pour le GPU. On voit bien qu'avec un projet CPU =0,3* nombre de hosts actifs*1000, on arrive à retrouver à peu près ce qui est credite par les projets actuellement, certains sont favorisés comme Leiden bien sur et WCG est encore un peu penalisé. En ce qui concenre les GPU, si on dit 0,5*nombre de hosts*1000 ou 3*nombre de hosts*1000, on a le meme probleme qu'au dessus a savoir favoriser ou non SETI et Einstein qui, comme on le sait sous-credite...Afin d'eviter l'inflation des credits, je prefere (perso) le 500k*nombre de hosts

MA PROPOSITION :
1) tous les projets definissent leurs credits comme il veulent et font leurs classements internes a leur souhait
2) pour l'interclassement entre participants/equipes/pays....les credits obtenus pour chaque participant sont:
-) pour un projet CPU: en 1 jour, un cruncher fait x% des credits de ce projet obtenus ce jour-la, il obtient x * 300* nombre de hosts actifs sur le projet au jour donné

(exemple: un cruncher fait 1 000 credits sur un projet CPU qui a donné 400 000 crédits dans la journée avec 3000 hosts actifs ce jour-la, la contribution du cruncher à l'interclassement est donc 1000/400000*300*3000= 2250 credits, ca fait peut-etre beaucoup mais c'est ce qui se passerait avec Leiden en gros. Si par contre, on a 40M de credits et 30000 hosts, il ne recupererait que 225 credits! cela favorise les projets a peu de CPUs...)

-) pour un projet GPU: en 1 jour, un cruncher fait y% des credits de ce projet obtenus ce jour-là, il obtient y*500*nombre de hosts actifs sur le projet au jour donné
(exemple: un cruncher fait 1 000 000 credits sur un projet GPU qui distribue 50Myions de credits ce jour-là avec 5000 hosts actifs, sa contribution pour l'interclassement est de 1Myon/50Myions*500*5000=50000 credits only ca semble peu par rapport a Collatz, Milky actuels ... mais c'est enorme pour Einstein et Seti!!!!L'effet sera immediat, moins de gens sur ces projets, peut-être en partie a tort mais cela correspond a resoudre un probleme vieux de quelques années et qui a fait couler beaucoup d'encre)

Quelques problemes a regler:
1° les 'intermittents du spectacle' genre LHC@Home ou Simap, on garde le système actuel et les points obtenus pour ces projets tels quels d'où mon idée au-dessus d'essayer de se rapprocher des crédits actuels!

2° Les projets nci: on ne change rien non plus a leurs credits actuels

3° Le projet fou : supposons qu'un personne decide de monter un projet a lui tout seul et refuse que quiconque ne s'y attache, il obtient alors 100% de la prime ... Tout comme pour le Formula BOINC, il faudra un nombre minimal de hosts connectés pour participer a cet interclassement BOINC: 1000 hosts? SI le nombre redescend en dessous de 1000, on le vire du classement???(je sais pas repondre pour le moment)

4° Avec le temps les CPUs sont plus puissants et les GPUs aussi donc mes coeffs 300 et 500 doivent evoluer avec le temps (d'ou mon idée d'introduire l'age du projet). J'avoue ne pas avoir trouvé de solutions miracles mais peut-etre qu'il faut remplacer 300 par age*50 et 500 par age*80??? (et avoir age toujours au moins egal à 1)

5° Pour les projets mixtes CPU/GPU, cela favorise-t-il le crunch en CPU ou en GPU pour ces projets, le GPU a mon avis...

J'attends vos commentaires, critiques... En esperant avoir fait avancer le schimili...schmili...schiiimmiillliii... :kookoo:


22717 SETI@home classic workunits; Redécouverte pulsar J1916+12 (le 07Nov2009) Einstein@Home.


Hors ligne Matt11

  • Boinc'eur Respectable
  • ****
  • Messages: 686
  •   
Réponse #67 le: 05 June 2012 à 18:25
Beau travail et belle reflexion !
En fait tu propose de comparer les projets par rapport à leur moyenne de crédit distribué par ordinateur.
Il serait aussi intéressant de voir ce qui se passe si on prend la médiane comme l'a proposé sebastien.

C'est vrai qu'au final ça reviendrait sûrement au même résultat qu'un ordinateur de référence mais c'est beaucoup plus facile à mettre en place.


Ubuntu Mate 18.04  Intel core i7 6700K 4x4.0GHz 16Gb Nvidia Geforce GTX 1070


Hors ligne Spica

  • Méchant modo
  • Boinc'eur devant l'éternel
  • ******
  • Messages: 5146
  •   
Réponse #68 le: 05 June 2012 à 18:44
Merci, oui en gros, la difficulté est de tenir compte que le parc de CPUs et GPUs augmente avec le temps, que les projets tres populaires doivent etre maintenus a un bon niveau de 'rendement' de crédits... et taxer sévèrement les surcréditeurs.  Peut-etre que la methode Seb est plus simple, je crois que lui vise plutot sur les participants et pas les ordianteurs. La mienne est un tout petit peu compliquée. Je peux faire des tests sur les membres de l'AF mais si ca ne plait pas du tout... pas la peine d'en faire plus.

22717 SETI@home classic workunits; Redécouverte pulsar J1916+12 (le 07Nov2009) Einstein@Home.


Hors ligne Sébastien

  • Gentil admin
  • Boinc'eur devant l'éternel
  • *******
  • Messages: 2455
  •   
Réponse #69 le: 05 June 2012 à 18:55
@clp: nos méthodes sont semblables. Je ne vois que deux différences:
  • Tu utilises la moyenne alors que j'utilise la médiane
  • Dans ta méthode, les projets CPU et GPU n'ont pas le même coefficient alors que de mon côté le coefficient est identique quelque soit le projet.
Dans quelques jours, je vais mettre en place une page de démo de ma méthode. Par la même occasion, si tu le souhaites, je peux aussi créer une page de démo de ta méthode.



Hors ligne Spica

  • Méchant modo
  • Boinc'eur devant l'éternel
  • ******
  • Messages: 5146
  •   
Réponse #70 le: 05 June 2012 à 19:09
@clp: nos méthodes sont semblables. Je ne vois que deux différences:
  • Tu utilises la moyenne alors que j'utilise la médiane
  • Dans ta méthode, les projets CPU et GPU n'ont pas le même coefficient alors que de mon côté le coefficient est identique quelque soit le projet.
Dans quelques jours, je vais mettre en place une page de démo de ma méthode. Par la même occasion, si tu le souhaites, je peux aussi créer une page de démo de ta méthode.
Seb, deja, c'est bien que nos methodes soient semblables ... mais c'est grace a 'ton' equirac et ses resultats deja testes depusi un certain temps. Si les membres de l'AF sont de notre avis, on a fait un grand pas et si on convainc SG et Boinc stats, ce sera encore mieux...

Si toi tu as un unique coeff, ca simplifie toujours.... En gros, j'etais presque arrivé à des coeffs proches mais je ne comprends pas pourquoi alors que la puissance GPU est beaucoup plus grande que celle CPU... mais peut-etre que l'effet de nombre des CPUs compense...

Ce serait sympa (si tu peux ) de voir ce que donne ma methode : peut-etre qu'on (les membres de l'AF) verra des avantages ou inconvenients a l'une (ou l'autre) mais il y a des chances que les resultats soient tres proches auquel cas, le plus simple sera le mieux. Merci d'avance  :jap:

Ca permettra de reviser la différence entre la mediane et la moyenne...  :siflotte:  :lol:

22717 SETI@home classic workunits; Redécouverte pulsar J1916+12 (le 07Nov2009) Einstein@Home.


Hors ligne kasur

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 3128
  •   
    • E-mail
Réponse #71 le: 05 June 2012 à 19:12
De ma premiere impression je prefere quand meme les systeme CPCS de boinc stat ou la machine étalon.

Avec ce systeme il y a toujours l'effet pervers qui arrive avec peu de cruncheurs et un top cruncheur au dessus du lot. Et l'effet que si beaucoup de grosse config sont sur le projet, les mêmes GFlops donné à la science peuvent valoir beaucoup moins que sur un projet qui compte beaucoup d'ordi lambda.

Et toujours mon idée de projet "police des points" avec des crédits absurde (intermédiaire éphémère de projets serieux)  qui annulerai l'attirance pour les projets qui paye trop :)


et 194 SETI@home classic workunits (4 764 hours) :p


Hors ligne Spica

  • Méchant modo
  • Boinc'eur devant l'éternel
  • ******
  • Messages: 5146
  •   
Réponse #72 le: 05 June 2012 à 19:23
Kasur, la methode CPCS m'a toujours donne des resultats moyens. Regardes, si tu prends la premiere colonne ABC@home et la ligne Distrtgen il y a un coeff 1,0017 je reve.....  :priz2tet:  :priz2tet:!
Perso, j'ai parfois pas du tout obtenu les resultats de ce tableau... Je crois que ce tableau n'est valable que pour les CPUs et ne tient pas compte des GPUs, la ou il y a le plus de problemes!!! Et puis ce tableau, j’arrive pas a le lire deja : qui crédite avec le coeff indiqué? celui sur la ligne par rapport a la colonne ou l'inverse??? Meme en cherchant la reponse quelques heures, je ne suis pas d'accord avec lui souvent...

22717 SETI@home classic workunits; Redécouverte pulsar J1916+12 (le 07Nov2009) Einstein@Home.


Hors ligne kasur

  • Boinc'eur devant l'éternel
  • *****
  • Messages: 3128
  •   
    • E-mail
Réponse #73 le: 05 June 2012 à 19:28
je suis bien sur d accord que comme tel c'est inexploitable, d'ailleurs comme tel distrigen n'est pas le meilleur.


et 194 SETI@home classic workunits (4 764 hours) :p


Hors ligne [AF>Libristes>Jip]Augure

  • Méchant modo
  • Boinc'eur devant l'éternel
  • ******
  • Messages: 4703
  •   
Réponse #74 le: 05 June 2012 à 19:59
Non, mais je ne pense pas que ce soit la bonne façon de prendre le problème.
Si on s'attaque (même gentiment) au projet lui-même, et qu'on arrivait (ô miracle) à lui faire entendre raison, on n'aurait coupé une tête de l'hydre, et d'autres projets iniques naitraient dans un temps assez court, et il faudrait recommencer le boulot sans fin.

donc si tu veux couper toutes les autres têtes, ce qui effectivement être plus efficace, je veux bien vous proposer une idée assez original !!!

suffit que quelques grosses écuries ne crunch plus que sur DistRTgen exclusivement !!!  :jap:

oui, c'est original, pour dénoncer le faite que le projet joue sur une fibre crunching pour recruter outre mesure... je vous propose de jouer le jeu à fond et ne plus que cruncher sur les projets les plus créditeur !!!

et surtout de le communiquer (et bien-sur pas tout seul)

quel sera l'effet ?
ben un mouvement chez tous les autres projets qui vont voir leur activité chuter !!!
et eux pourrons faire bouger Berkeley, eux seul le pourront car comme dit Otax... à par une fuite "hors BOINC genre Folding" les crunchers migreront de projet en projet mais resteront dans le microcos BOINCiens !  :jap:

>>