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