Team RC5-72 MacBidouille

[Melaurë Curufin]

Aujourd'hui équart (X86/linux)-(ppc/rhapsody)=34 853 288…

Sympa que ça diminue, mais par contre je suis circonspect par le TeamComputerra. 154 membres et 224000 blocs en un jour avec 73 participants ?

En plus quand on voit l'historique des premiers de la journée, c'est très très louche. Ils n'envoyaient pas forcément grand chose et du jour au lendemain 40 ou 50000 blocs.

C'est fou ...

Cluster de G5 ou triche (impact très négatif dans ce cas) ?

[Tchou]

Aujourd'hui équart (X86/linux)-(ppc/rhapsody)=34 853 288…

Sympa que ça diminue, mais par contre je suis circonspect par le TeamComputerra. 154 membres et 224000 blocs en un jour avec 73 participants ?

En plus quand on voit l'historique des premiers de la journée, c'est très très louche. Ils n'envoyaient pas forcément grand chose et du jour au lendemain 40 ou 50000 blocs.

C'est fou ...

Cluster de G5 ou triche (impact très négatif dans ce cas) ?

Un pti coup de main du cluster de G5 peut être ;-)

[kakace]

Cluster de G5 ou triche (impact très négatif dans ce cas) ?

Il faut voir ce que cela va donner dans les jours qui viennent. Certain participants s'adonnent au "mega-flush" (ils ne postent rien pendant plusieurs jours, et envoient un gros nombre de blocs d'un seul coup). D'autres ont l'air suspect (probablement des tricheurs), et d'autres enfin sont des sub-teams (et affichent donc un keyrate assez fluctuant, ce qui semble normal). Bref, rien de vraiment flagrant pour le moment.

A ce propos, je ne sais toujours pas où en sont les contre-mesures chez distributed.net. Il va falloir que je jette une pierre dans la mare, on dirait...

[Melaurë Curufin]

Cluster de G5 ou triche (impact très négatif dans ce cas) ?

Il faut voir ce que cela va donner dans les jours qui viennent. Certain participants s'adonnent au "mega-flush" (ils ne postent rien pendant plusieurs jours, et envoient un gros nombre de blocs d'un seul coup). D'autres ont l'air suspect (probablement des tricheurs), et d'autres enfin sont des sub-teams (et affichent donc un keyrate assez fluctuant, ce qui semble normal). Bref, rien de vraiment flagrant pour le moment.

A ce propos, je ne sais toujours pas où en sont les contre-mesures chez distributed.net. Il va falloir que je jette une pierre dans la mare, on dirait...

Dans le cas que je donnais (computera) ce ne sont pas des gens qui ont stockés des blocs pendant longtemps. Il ont posté quelques dizaines ou centaines de blocs le jour précédent puis plus de 55000 chacun le jour suivant ...

Idem pour le team MooFarm aujourd'hui avec pas loin de 400000 blocs. RTCW zobarpol qui poste entre 50 et 100 blocs tous les jours jusqu'à hier a poste 70000 blocs aujourd'hui. RTCWUndergod qui a en moyenne 400 blocs par jour en poste 28995 le 31 après en avoir posté 516 le 30.

Bref ça sent le moisi tout ça et je sens venir de loin la grande claque des tricheurs qui va mettre le projet en l'air. Pourquoi ? Parce que dès qu'on saura qu'il y a eu des triches massives, tout le monde ira donner son temps machine ailleurs ...

[Suil]

moi pendant 2 semaines je n'ai pas calculé, vacances ..... et j'en avais vraiment besoin, mais je vais mettre les bouchées doubles à la rentrée

Meilleurs voeux à toutes et à tous

[kakace]

A ce propos, je ne sais toujours pas où en sont les contre-mesures chez distributed.net. Il va falloir que je jette une pierre dans la mare, on dirait... 

Dans le cas que je donnais (computera) ce ne sont pas des gens qui ont stockés des blocs pendant longtemps. Il ont posté quelques dizaines ou centaines de blocs le jour précédent puis plus de 55000 chacun le jour suivant ...
Idem pour le team MooFarm aujourd'hui avec pas loin de 400000 blocs.
Bref ça sent le moisi tout ça et je sens venir de loin la grande claque des tricheurs qui va mettre le projet en l'air. Pourquoi ? Parce que dès qu'on saura qu'il y a eu des triches massives, tout le monde ira donner son temps machine ailleurs ...

Cette situation ennerve beaucoup de monde, surtout les top-teams. J'ai discuté de ça avec quelques membres de distributed (peu nombreux en début d'après midi, décalage horaire oblige), et tous partagent ce point de vue. Je n'ai malheureusement pas pu avoir plus d'informations à ce sujet.
Quoiqu'il en soit, je suis absolument déterminé à faire bouger les choses dans le bon sens, quitte, une fois de plus, à devoir tout faire moi-même

Ceci dit, les stats ne permettent pas vraiment de savoir ce qui se passe. Il suffit qu'un proxy soit en rade pour que subitement, lorsqu'il est relancé, un nombre impressionnant de blocs soit attribué à quelques participants (ce qui est normal, vu que le proxy sert de cache entre les utilisateurs et le serveur central). Certains participants peuvent aussi jouer au "mega-flush" avec certaines de leurs machines, volontairement ou non.
Si les stats sèment le doute (principalement parce qu'on sait qu'un client pourri existe), rien ne permet de conclure quoi que ce soit pour le moment.

[Melaurë Curufin]

Kakace pour les cas que je relève, j'ai examiné les posts sur plusieurs mois. C'est pour cela que j'en tire ce genre de conclusion. Bien sur on peut supposer que chacun a mis la main sur un cluster et l'a activé le même jour, mais c'est quand même très peu probable.

Enfin tout ce que j'espère c'est une garantie de la part des gens qui ont lancé le projet qu'il n'y a pas de triche. Quand on voit le nombre monstrueux de blocs restant, il ne faut pas faiblir. Il va falloir que les procs évoluent très vite sinon ça va être comme les cathédrales. On la commence mais on ne voit pas la fin de son vivant ...

[g4hd]

Black Pearl : cluster de 100 x G5 bi2gHz ???

[kakace]

Black Pearl : cluster de 100 x G5 bi2gHz ???

Le premier (et même le second) sont plus que suspects :-/
Quant au troisième, il peut s'agir de quelqu'un ayant installé le client sur plusieurs machines ces jours-ci (augmentation graduelle du keyrate).

[gillesC]

Effectivement, le premier semble incroyable, le second avec un nom pareil (!) à peut être installé subrepticement le client sur un certain nombre de machines à leurs insu.
Le troisième est probablement d'après son intitulé un labo de génétique qui profite des congés de fin d'année des chercheurs pour faire mouliner les bécanes à 100%, à voir après la rentrée...

Si cela se généralise, il va falloir faire du ménage pour conserver l'intérêt du projet.

[Aurel]

le 2e il en poste 10 et le lendemain il en poste 3800 fois plus et 7200 fois plus le surlendemain, c bizarre

[3x7]

Salut les chauffeurs de CPU !
Un exemple de chez nous :
Je fais calculer ma bécane chez moi (le bi-1,25, dans les 530 blocks par jour)
Petit détail : je n'ai pas encore internet (si si c'est possible !)
Donc de temps en temps, je récupère le fichier "buff-out.r72" avec son copain "buff-in.r72"
et je les emmène au taf.
je les envoie depuis mon G4 bi-867 du boulot qui calcule aussi de son côté.
Il a aussi six ou sept jumeaux qui bouffent des blocks chaque fois que possible, c'est à dire en dehors des heures de travail.

[Melaurë Curufin]

Ca faisait un petit moment que je n'avais rien posté avec mon TI. Voilà qui est fait ...

[nektarfl]

Ca faisait un petit moment que je n'avais rien posté avec mon TI. Voilà qui est fait ...

Tu penses ! je t'avais rattrapé, j'étais assez content, et voilà que tu t'échappes à nouveau!! C'est pas grave, je serais de nouveau devant toi lundi prochain!

Ma moyenne quotidienne s'approche de plus en plus des 200 packets par jours (195 pour être exact!)

3x7: sous quel pseudo postes-tu dans le team macbidouille? j'avoue ne pas t'avoir trouvé (et pas beaucoup cherché non plus!)

[Melaurë Curufin]

Ca faisait un petit moment que je n'avais rien posté avec mon TI. Voilà qui est fait ...

Tu penses ! je t'avais rattrapé, j'étais assez content, et voilà que tu t'échappes à nouveau!! C'est pas grave, je serais de nouveau devant toi lundi prochain!

J'ai a peine fait 1000 blocs en un mois, tu me dépasseras sans problème

[3x7]

3x7: sous quel pseudo postes-tu dans le team macbidouille? j'avoue ne pas t'avoir trouvé (et pas beaucoup cherché non plus!)

Je n'ai jamais dissocié mes calculs de l'équipe MacBidouille.
Comme ca l'équipe est en 26eme position.

J'ai laissé la config dnetc d'origine.

Mais si tu veux, je peux interrompre mes calculs pendant 24h pour que tu puisses voir l'incidence...

je vais essayer d'améliorer le truc avec xgrid.

[nektarfl]

C'est certainement la raison pour laquelle il y a autant de blocks sur le mail de l'équipe!

c'est grace à des personnes comme toi que l'équipe avance. Pour ma part, je fait modestement avec mon matériel!!

C'est pas la peine de t'arreter pour me montrer l'incidence de tes blocks sur l'équipe, ça m'explique simplement pourquoi tu n'apparais pas directement. Quel altruisme!

[Celeri]

J'ai une réponse qui pourrait expliquer une partie de ceux qui ont des chiffres normaux tous les jours sauf un jour par-ci par-là où ils en ont une grosse quantité d'un seul coup : perso, à la boite où je travaille, je fais calculer plusieurs serveurs, mais aucun d'entre eux n'a accès au net. Donc je les laisse travailler plusieurs semaines, voire plusieurs mois, après je centralise et j'envoie tout. Et comme c'est des serveurs assez costauds, ça peut aller chercher dans les 20,000 blocks en quelques mois !
Je ne pense pas qu'il y ait vraiment de triche (ou en tout cas pas beaucoup) puisque ça n'apporte rien d'être dans le top-100 et que de toute façon la récompense ira forcément à quelqu'un qui aura effectivement calculé quelque chose...

[Tchou]

J'ai une réponse qui pourrait expliquer une partie de ceux qui ont des chiffres normaux tous les jours sauf un jour par-ci par-là où ils en ont une grosse quantité d'un seul coup : perso, à la boite où je travaille, je fais calculer plusieurs serveurs, mais aucun d'entre eux n'a accès au net. Donc je les laisse travailler plusieurs semaines, voire plusieurs mois, après je centralise et j'envoie tout. Et comme c'est des serveurs assez costauds, ça peut aller chercher dans les 20,000 blocks en quelques mois !
Je ne pense pas qu'il y ait vraiment de triche (ou en tout cas pas beaucoup) puisque ça n'apporte rien d'être dans le top-100 et que de toute façon la récompense ira forcément à quelqu'un qui aura effectivement calculé quelque chose...

plusieurs mois ça veut dire que tu bosses pour rien,
les blocs après 90 jours sont perdus et réassignés à d'autres donc il faut pas laisser travailler les serveurs plusieurs mois...

[popboy]

Deux mois, c'est plusieurs mois

mais c'est vrai qu'après 90 jours tes blocs peuvent être redistribué à d'autres.

[g4hd]

J'ai dû raté quelque chose...

Comment fait-on pour 'aspirer' 10 000 packets en buff-in (par exemple) puis les calculer tranquillement sans être connecté, puis envoyer 10 000 packets en buff-out.
Pour ma part, j'aspire 24 packets... ils sont calculés puis transférés en buff-out.
Et ainsi de suite.

[Bac's]

dnetc -update -bin 10000

par exemple !

Ce message a été modifié par Bacs - 10 Jan 2004, 17:54.

[popboy]

./dnetc -config

2 (Buffer and Buffer Update Options)

12 (Fetch work threshold)

OGR=0,RC5-72=xx (-> étant les blocks que tu charges)

voilà ce que je fait, il faut noter qu'il y a des aides à la configuration ce qui est bien agréable
si l'on est pas fanatique du terminal, merci Kacace et ses frères d'armes

[g4hd]

Merci pour ces réponses.
Vous allez pouvoir me conseiller : j'utilise une version de DnetcX qui permet de configurer un fichier d'initialisation dans lequel j'ai ceci :

[misc]
project-priority=OGR=0,RC5-72

[parameters]
id=xxxxxx@xxxxxx                                  (mon adresse mail)

[display]
progress-indicator=auto-sense

[triggers]
pause-on-high-cpu-temp=yes
cpu-temperature-thresholds=328K:334K    (ça, c'est pour surveiller la tempétarure! )

Que dois-je ajouter dans ce fichier .ini qui permette de charger 10000 packets (par exemple) ?

[Tchou]

./dnetc -config

2 (Buffer and Buffer Update Options)

12 (Fetch work threshold)

OGR=0,RC5-72=xx (-> étant les blocks que tu charges)

voilà ce que je fait, il faut noter qu'il y a des aides à la configuration ce qui est bien agréable
si l'on est pas fanatique du terminal, merci Kacace et ses frères d'armes

Sauf que xx est limité à 1000 si tu mets 10000 ça en prendra 1000...

[popboy]

Bon voilà que l'on me force a ouvrir
des fichiers .ini maintenant.

[rc5-72]
fetch-time-threshold=3
fetch-workunit-threshold=XXXX (<- c'est ici que tu met tes blocks, tu vois tchou je tiens
compte de tes remarques, je m'applique )

mais franchement tu t'en sortirais plus simplement
en faisant avec -config, avec l'aide en ligne je comprends parfois,
c'est dire

[g4hd]

[rc5-72]
fetch-time-threshold=3
fetch-workunit-threshold=XXXX

Merci, je teste ça pour envoyer encore plus de paquets.

[edit]
Bon, je suis revenu au dnetc.ini précédent.
L'édition du fichier dérangeait le fonctionnement du contrôle de température qui coupait et ne remettait plus en route.
Allez, ça marche correctement comme ça, par lots de 24 paquets.

Ce message a été modifié par G4HD - 11 Jan 2004, 16:52.

[kakace]

Quelques remarques en passant...
Ce n'est pas parce que le fichier .ini est lisible, éditable et modifiable qu'il faut y toucher n'importe comment. C'est même généralement une très mauvaise idée
Il existe un menu de configuration (certe en anglais, ce qui n'a rien d'insurmontable), lequel garanti que le fameux fichier .ini est en bonne "santé". A noter que certaines interfaces graphiques (il y en a plusieurs) permettent de changer ce réglage très simplement. Bref, si une erreur dans ce fichier n'est pas catastrophique pour un programme tel que dnetc, ce genre de pratique réserve des surprises à ceux qui s'y adonnent. Fin de la leçon de morale
Quoiqu'il en soit, le client refuse de charger plus de 999 blocks RC5, quels que soient les paramètres fournis. Si ce n'est pas suffisant, il existe la solution du "personal proxy" qui permet d'avoir jusqu'à 3 jours de réserves (niveau adapté en temps réel par rapport à la consommation). Ce personal proxy permet de résoudre bien des problèmes, notament dans les réseaux locaux (il se charge de communiquer avec le keyserver, et sert de keyserver local à tous les clients du réseau local). La dernière solution consiste à faire un -fetch, à mettre de côté le tampon buff-in.rc5, puis à faire un autre -fetch, etc, pour se constituer une collection de tampons pleins. C'est néanmoins déconseillé : risque d'envoyer des blocs après le délai imparti (variable), ou risque d'envoyer des blocs en double (là on se fait éjecter des stats très rapidement).

[Melaurë Curufin]

Aujourd'hui : 35 276 004 ça se réduit encore

En 4 jours (du 8 au 12) : 8 793 de mieux pour PPC/rhapsody

A se rythme, il nous faut a peu près 4012 jours pour que notre Os soit en 2ème position.

L'écart est maintenant de 34 705 793 ...

La plateforme MacOS X/PPC rattrape lentement mais surement Linux sur x86 !

C'est l'effet G5 et ca va continuer !!!

[nektarfl]

pour ma part, j'ai fait un petit test qui a été très concluant:

j'ai chargé mon compte en blocks (1000), j'ai renommé le fichier buff-in en autre chose (_buff-in).

j'ai ensuite rechargé 1000 blocks avec ./dnetc -fetch

puis j'ai tapé : ./dnetc -import _buff-in

pour qui veut réceptionner 10000 blocks recommence 10 fois!

et mon client voyait effectivement 2000 blocks en buffer in. 2000 blocks, ça correspond à un peu plus d'une semaine pour moi, alors il n'y a pas de problème de délai, mais il va m'arriver un moment où je n'aurais peut-être une connexion qu'une seule fois par semaine, et ça sera pour moi la meilleure méthode pour ne pas calculer des blocks au hasard qui risquent d'être déjà calculés.