Team RC5-72 MacBidouille

[Mfx]

Désolé pour le multipost ...
Message d'erreur "too many connections ..." lors de la rédaction du post, plus probablement fausses manip

Si un modérateur pouvait passer faire le ménage, ce serait sympa

[nektarfl]

Nektarfl, Je viens de regarder ta page distributed.
Comment as tu donc fait pour afficher les pourcentages de calculs par rapport aux machines ? C'est une option distributed.net ou un calcul de ta part ?
[right][snapback]1022486[/snapback][/right]

Ce sont des stats tenues par mes soins.
En effet, je prends bien garde de n'envoyer qu'une seule machine par jour :le G3 va continuer à baisser régulièrement il m'a été volé l'an dernier, mais a calculé quand même, le Next calcule en solo depuis mars dernier des blocks au hasard alors quand je pourrais le rebrancher, j'aurais quand même presque 100 blocks de plus , le PC est à mon boulot et décharge une fois toutes les 8 semaines environ (mes envois de près de 6 à 8000 blocks d'un coup) quand aux 2 mac (G4 et G5) je tente de les décharger une fois par semaine, même si je prends 60 jours de blocks d'avance car je sais que je vais avoir un trou de connexion pendant près d'un mois.

Les 2 emac occasionnels n'envoient quant-à eux que de temps en temps.

Edit : Pour le détail, ça donne ceci avant l'envoi d'aujourd'hui :

G5 : 9 045 blocks
G4 : 129 657 blocks
G3 : 2 699 blocks
PC : 25 722 blocks
NeXT : 72 blocks

Soit une moyenne actuelle de 310 blocks par jour.



Ce message a été modifié par nektarfl - 11 Feb 2005, 19:00.

[popboy]

Attends, c'est quoi cette histoire ?
Le mec qui t'as volé le G3 n'a même pas pris la peine de formatter le disque dur et il envoie des blocks régulièrement ? Si c'est bien le cas il n'y aurait pas moyen de le tracer ?

[nektarfl]

Non, c'est ce qui a été envoyé avant le vol !!!!
Je n'ai pas eu d'envoi depuis, tu penses bien que j'aurais réagi!!!!

En plus, équipé de mot de passe pour chaque compte, il était impensable qu'il s'en serve comme ça, mais effectivement, juste allumé et branché à internet, il aurait pu envoyer des blocks puisqu'il se lançait au départ.

[Macafond]

heu! j'ai l'impression que d'être passé en X.3.8, cela m'a nettement diminué mon pouvoir de calcul, je suis à 21.83 Mkeys/s environ.
alors que l'ordi est tranquille dans son coin et que "rien" ne tourne de spécial.
suis pas content.. où est le problème svp ?

ah! et au sujet de ce paneau "économie énergie", faut il mieux le mettre en quelle position ??
car là je viens de le mettre en "auto" et le ventilo s'est mis en route et à descendu la température à 46° alors que le reste du temps ils sont à 64° je crois, sans déclenchement des ventilos !?? ce pour l'utilisation du début de ce post.

je remarque que lorsque l'on ouvre "moniteur activité" on voit "dnetc" à 40% puis il passe ensuite rapidement à un % nettement plus élevé, alors qu'avant on remarquait de suite l'occupation importante du processeur par "dnetc" et ce pour une même utilisation de l'ordi bien sur!

Ce message a été modifié par Macafond - 15 Feb 2005, 10:11.

[patpan]

heu! j'ai l'impression que d'être passé en X.3.8, cela m'a nettement diminué mon pouvoir de calcul, je suis à 21.83 Mkeys/s environ.
[right][snapback]1026506[/snapback][/right]

Bonjour Macafond,

je répond à ton post pour te donner mes chiffres brut avec le statut nocturne idle, sauf dnetc , bien sûr!

[email protected] = 30,95 Mkeys/s

[email protected] = 29,74 Mkeys/s

QS@1,333 = 28,08 Mkeys/s

[email protected] = 26,45 Mkeys/s

Comme je tourne sous 10.3.8 depuis la sortie de l'assemblage 7U7, ( actuellement 7U16 ) avec ces quatre G4, j'ai un recul suffisant pour dire qu'il n'y a pas eu de dégradation des performances.

Avant et après chaque Màj, un coup d' Onyx complet, et chaque mois un tour de Drive 10.
C'est long, astreignant, mais les performances sont au rendez-vous.

Essaye donc au minimun de faire du nettoyage système, et je pense que cela permettra de valoriser au mieux le sacré travail de notre ami kakace .

Bien à toi

Pat

[Macafond]

heu! j'ai l'impression que d'être passé en X.3.8, cela m'a nettement diminué mon pouvoir de calcul, je suis à 21.83 Mkeys/s environ.
[right][snapback]1026506[/snapback][/right]

Bonjour Macafond,

je répond à ton post pour te donner mes chiffres brut avec le statut nocturne idle, sauf dnetc , bien sûr!
[email protected] = 30,95 Mkeys/s
[email protected] = 29,74 Mkeys/s
QS@1,333 = 28,08 Mkeys/s
[email protected] = 26,45 Mkeys/s

super et qu'est qu'il fait mon G5, lui avec des processeurs plus puissants et une architecture plus récente !! la meilleure pointe depuis qu'il calcule à été de 26,42 Mkeys/s, même pas ton [email protected].. as tu une config ou commande spéciale pour optimiser les ressources du processeur ?? là je ne comprends pas ce résultat un peu miteux à mon goût !

Comme je tourne sous 10.3.8 depuis la sortie de l'assemblage 7U7, ( actuellement 7U16 ) avec ces quatre G4, j'ai un recul suffisant pour dire qu'il n'y a pas eu de dégradation des performances. 

bon ben.. échange super G5 contre G4, avis à la population !

Avant et après chaque Màj, un coup d' Onyx complet, et chaque mois un tour de  Drive 10.
C'est  long, astreignant, mais les performances sont au rendez-vous.

Essaye donc au minimun de faire du nettoyage système, et je pense que cela permettra de valoriser au mieux le sacré travail de notre ami kakace   .

Bien à toi

Pat

merci
après avoir passé "toolX" et un utilitaire disque, au 16/02 la pointe est à [26.08 Mkeys/s].. c'est mieux.. mais rien à voir avec tes perfs
et merci apple de vendre des machines moins véloces que des anciennes
c'est en rapport avec l'article: "Une erreur de conception des G5" je pense..

Ce message a été modifié par Macafond - 16 Feb 2005, 09:22.

[kakace]

c'est en rapport avec l'article: "Une erreur de conception des G5" je pense..
[right][snapback]1027003[/snapback][/right]

Pas du tout. C'est en rapport direct avec l'architecture différente du G5. Pour pouvoir monter en fréquence, les ingénieurs ont modifié les pipelines et cette modification s'avère coûteuse dans certains cas, dont le RC5. Avec les mêmes modifications, un G4 pourrait aussi tourner à 2 GHz sans problème, seulement ce n'est pas la politique de Motorola (ils préfèrent une latence faible à une fréquence élevée).
En fin de compte, ce n'est qu'une histoire de compromis : soit on augmente la fréquence en augmentant la latence, soit on garde une latence faible et la fréquence monte au grè des progrès technologiques. Les deux méthodes ont leurs avantages, et leurs inconvénients.

D'où la nécessité d'avoir des cores RC5 spécifiques pour le G5...

[Macafond]

Bonjour, je constate que l'effectif de participants est important dans le team, mais le hic, c'est que l'on pourrai en enlever la moitié, et cela reflèterait mieux les membres vraiments en activité.
on ne peut pas faire un peu de ménage dedans ??
NB: je ne blâme pas les membres en standby depuis 2003/2004, puisque moi-même ne sachant le temps que j'y consacrerais
- c'était juste une reflection par apport à certains teams, ou ils sont moins nombreux, mais leurs envois de blocks sont importants.

- sinon j'avais fait un post sur le calcul partagé: intérêts, bonne cause ou fun, rémunéré..) mais cela n'a pas l'air du tout d'intéressé quelqu'un bon bref !

[popboy]

C'est comme ça, et ça ne date pas d'hier, certains avaient contacté les participants assoupis.
Mais c'est sûrement un sacré boulot, avec un résultat... pas forcément à la hauteur.
Donc le mieux c'est de poster un peu sur ce fil histoire que les nouveaux du forum découvrent dnetc.
La question que je me pose c''est si nous ne devrions pas faire un mode d'emploi pour ce fameux DNETC, je ne sais pas pour vous, mais quand j'ai du l'installer, le configurer et comprendre les fonctions, ça à été dur, le frein de la participation serait là ?

[Mfx]

La question que je me pose c''est si nous ne devrions pas faire un mode d'emploi pour ce fameux  DNETC, je ne sais pas pour vous, mais quand j'ai du l'installer, le configurer et comprendre les fonctions, ça à été dur, le frein de la participation serait là ?

Ben non, justement ... Le problème (enfin, le truc, quoi, ce n'est pas vraiment un problème ), ce sont les quelques dizaines de contributeurs qui n'ont contribué ... qu'une seule fois ou à peu près. C'est vrai que ça me chiffonne un peu aussi ... Mais ils se sont inscrits à l'équipe, et ont envoyé des résultats, donc ils ont réussi à installer dnetc, à le configurer correctement, et à le faire tourner au moins une fois.

Pour en revenir à ce qui me gène (un peu) : si on prend l'exemple du groupe OGR 25, l'équipe compte 180 membres, et a calculé à ce jour 17,532,570 GNodes.
Là dessus, le 100ème en a calculé 1895, pour une seule contribution (le 9/10/2004). Contribution 'par erreur' de quelqu'un qui voulait travailler sur le projet RC5 ?
Et la somme des contributions du 101ème au 182ème et dernier représente 55 656 Gnodes ...

C'est vrai qu'on pourrait songer à mettre à jour la liste, car dans les stats, afficher que l'équipe travaille avec 180 membres, c'est un peu faussé
Mais je ne voudrai pas non plus vexer les participants occasionnels ...

Kakace, le pro de distributed, sais-tu comment ça se passe dans d'autres teams ?


D'ailleurs, j'ai un bug à soumettre ... à je ne sais pas qui. La page de résumé indique
This team has had 181 participants contribute blocks. Of those, 180 are still on this team, and 11 submitted work today.
Or, le détail des contributions en affiche 182 ... Alors, combien sommes nous : 180, 181 ou 182 ?

Amicalement

[kakace]

J'imagine qu'un nombre conséquent de contributeurs ont installé un "front-end" comme Dnetcx ou Cow-boy pour tester (facilement) au moment où le projet avait le vent en poupe. S'en suivit une perte de motivation, un désinterêt, ou une attirance vers d'autres projets comme seti@home ou folding@home. Quoiqu'il en soit, leur participation, aussi minime soit elle, contribue au total général de l'équipe jusqu'à la fin du projet. Par respect pour ce travail, on ne peut pas les "effacer" des statistiques, juste pour faire joli...
D'autres contributeurs participent quasi exclusivement à un projet spécifique (RC5-72), et contribuent occasionnellement à OGR selon l'humeur des serveurs et les réglages des clients.

Il n'y a là rien de spécifique à la team MacBidouille. Toutes les équipes sont touchées à des degrés divers, en fonction de la motivation suscitée par l'objectif de ces équipes. Celles construites autour d'interêts communs, d'une nationalité, ou d'une communauté sont moins sensibles aux défections, bien que l'interêt essentiel réside dans la course au classement général.

D'ailleurs, j'ai un bug à soumettre ... à je ne sais pas qui. La page de résumé indique
          This team has had 181 participants contribute blocks. Of those, 180 are still on this team, and 11 submitted work today.
Or, le détail des contributions en affiche 182 ... Alors, combien sommes nous : 180, 181 ou 182 ? 

Imaginons que [email protected] a participé pendant un temps avant de changer d'identifiant pour devenir [email protected]. Les deux identifiants (avant et après le changement) sont affichés dans les statistiques, mais ils identifient un même participant. On peut alors avoir 182 identifiants répertoriés, mais seulement 181 participants

[Mfx]

Imaginons que [email protected] a participé pendant un temps avant de changer d'identifiant pour devenir [email protected]. Les deux identifiants (avant et après le changement) sont affichés dans les statistiques, mais ils identifient un même participant. On peut alors avoir 182 identifiants répertoriés, mais seulement 181 participants

Bon sang, mais c'est bien sûr ... (les nostalgiques apprécieront )

Je passerai sur le foo-bar caractéristique du développeur ...

Quant au "ménage" dans la liste, c'est vrai que ça laisserait un goût un peu amer ... et c'est un peu pour ça que je n'avais jamais abordé la question. Le message de Macafond a été le déclencheur. D'où aussi ma remarque sur les participants occasionnels. Et c'est sans doute pour ça aussi que la page des stats mentionne le nombre total de participants, ceux qui sont encore actifs, et ceux qui ont contribué la veille !

c'était juste une reflection par apport à certains teams, ou ils sont moins nombreux, mais leurs envois de blocks sont importants.

Que dire de l'équipe Distributed Static, qui vient de nous enrhumer en passant en trombe devant nous il y a peu de temps, et qui fait régulièrement 200 à 250 000 Gnodes par jour avec ... 2 participants ? Bon, je sens bien la participation collective, là Mais quand même, chapeau ...

[kakace]

Que dire de l'équipe Distributed Static, qui vient de nous enrhumer en passant en trombe devant nous il y a peu de temps, et qui fait régulièrement 200 à 250 000 Gnodes par jour avec ... 2 participants ?  Bon, je sens bien la participation collective, là    Mais quand même, chapeau ...
[right][snapback]1030770[/snapback][/right]

Je m'en suis ému le jour où on s'est fait doubler. La réponse fût sans appel : quelqu'un venait de joindre cette team, en apportant avec lui un nombre considérable de GNodes (autour de 20000000 si ma mémoire est bonne). L'augmentation brutale des performances de l'un des deux participants en novembre m'avait aussi parue suspecte, mais rien au niveau des logs ne laisse entrevoir une quelconque tricherie, du moins pour le moment (lorsque ses stubs seront vérifiés par une autre machine, on y verra plus clair).
En tout cas, il est hautement improbable qu'il s'amuse à flusher continuellement les mêmes stubs. J'ai mis au point une protection anti-clonage pour OGR-P2 afin d'éviter de telles pratiques et, même si aucune solution n'est 100% fiable, je suis assez confiant sur ses performances.

Tant que j'y suis, mon générateur de cores RC5 prend forme petit à petit. Pour le moment, il me sort un core G3 tout ce qu'il y a de plus banal. Il me reste à mettre au point l'automatisation des optimisations (à partir du code banal), et à dériver cette base pour les cores AltiVec.
Ce n'est pas gagné, mais c'est en bonne voie...

[Macafond]

Tant que j'y suis, mon générateur de cores RC5 prend forme petit à petit. Pour le moment, il me sort un core G3 tout ce qu'il y a de plus banal. Il me reste à mettre au point l'automatisation des optimisations (à partir du code banal), et à dériver cette base pour les cores AltiVec.
Ce n'est pas gagné, mais c'est en bonne voie...

j'ai rien compris ! mais suis de tout coeur mentalement avec toi
maaaaaaaais.. cela veut dire que beau petit G5 bi 1,8 va décoller.. ?????? parce que si je crois "patpan" avec son [email protected] = 26,45 Mkeys/s, il me fout les boules. moi ma vitesse est maintenant à 26,08 Mkeys/s au mieux.

oueh! c'est la faute à "kakace' ça!

Ce message a été modifié par Macafond - 18 Feb 2005, 20:53.

[patpan]

maaaaaaaais.. cela veut dire que beau petit G5 bi 1,8 va décoller.. ?????? parce que si je  crois "patpan" avec son [email protected] = 26,45 Mkeys/s, il me fout les boules. moi ma vitesse est maintenant à  26,08 Mkeys/s au mieux.

oueh! c'est la faute à "kakace' ça!   
[right][snapback]1031091[/snapback][/right]

salut,

ben ce sacré "patpan " peut te dire ce soir, qu'il confirme 26,48Mkes/s
et que c'est pour lui une perf de très bon augure, car réalisée sous Darwin 8.bla_bla!

Donc Tiger s'avère très prometteur!

@ + les costauds.......

[Mfx]

L'augmentation brutale des performances de l'un des deux participants en novembre m'avait aussi parue suspecte, mais rien au niveau des logs ne laisse entrevoir une quelconque tricherie, du moins pour le moment (lorsque ses stubs seront vérifiés par une autre machine, on y verra plus clair).
En tout cas, il est hautement improbable qu'il s'amuse à flusher continuellement les mêmes stubs. J'ai mis au point une protection anti-clonage pour OGR-P2 afin d'éviter de telles pratiques et, même si aucune solution n'est 100% fiable, je suis assez confiant sur ses performances

Je n'envisageais pas la chose en termes de tricherie ... mais l'envoi sous le même id des résultats d'un certain nombre de machines (et même un nombre certain, pour arriver à de tels résultats ).
C'est d'ailleurs ce que je fais moi-même, en cumulant sous mon nom les résultats du G5 et d'un serveur que je fais bosser à ses moments perdus ... sans avoir l'impression de tricher pour autant.
L'iBook n'est pas assez souvent en route pour que sa contribution en vaille la peine

[Mathiasr]

Tant que j'y suis, mon générateur de cores RC5 prend forme petit à petit. Pour le moment, il me sort un core G3 tout ce qu'il y a de plus banal. Il me reste à mettre au point l'automatisation des optimisations (à partir du code banal), et à dériver cette base pour les cores AltiVec.

Bonne chance pour le Cell

[xavtek]

mon bahut vient de s'équiper de 28 powermacG5 bipro 2Ghz, ils ne tournent pas tout le temps (pas la nuit en tous cas et ils restent allumés.
comment "vendre" a mon administration l'intéret de participer au RC5-72 ?
est-ce que ca peut aider significativement?
merci.

[nektarfl]

Oui, l'ajout de ces machines sera significative...

Je suppose que dans ce genre de cas, il faudrait installer au départ l'application (./dnetc -install)

Pour le vendre, il faut avoir le soutien d'un prof d'informatique un peu matheux et surtout un peu compétiteur (il y a bien une compétition sous-jacente la-dessous non?). et lui expliquer que même si tous les ordinateurs ne sont allumés en moyenne que 1h par jour, cela va générer quelques 700 à 800 blocks par jour (vision basse), ce qui veut dire que l'établissement scolaire apparaîtrai déjà dans le top 100 en un peu mois de 2 mois et au top 50 en mois de 4 mois, (pour te donner une idée, je suis 30ème avec 3 machines 24h/24 (1 mac G4-1,25 ; 1 mac G4-1,8 et 1PC-1,8) et 2 machines de temps en temps (1 emac 1,0 et 1 emac 1,25) avec la possibilité de se faire connaître de la communauté Mac en mettant un lien de la page perso vers le site de l'établissement.

Celà ne ralenti pas le travail du mac. (c'est installé sur toutes mes machines, et c'est totalement transparent) même lorsque warcraft III est lancé.

Par contre, n'essaye pas de l'installer sans autorisation.

[nektarfl]

Un petit mot pour signaler l'arrêt des pages de stat au moment où j'écris. J'espère que les quelques 4350 blocks du G5 que je suis en train d'envoyer passeront correctement (je ne vois pas pourquoi ça passerait pas, mais ...)

le message:

Stats are unavailable


Sorry, but stats are down at the moment.


For more information, check the .plans. Particularly, look at decibel's .plan and nugget's .plan


Check back later

[Mfx]

En fait, les stats sont disponibles ..
C'est un problème de DNS ou autre, je ne sais pas trop, mais on peut y accéder par

http://63.149.157.132/team/tmsummary.php?p...d=25&team=29128

alors qu'avec l'adresse habituelle, rien à faire.

Bizarre, bizarre, vous avez dit bizarre ...




Bon, aujourd'hui 2 mars, ça remarche normalement ...

Ce message a été modifié par Mfx - 2 Mar 2005, 10:26.

[patpan]

Bonsoir,

Mes G4 et moi sont heureux de vous faire part que pour la première fois nous venons de passer le cap des 1000 blocs/jour - en moyenne quotidienne -

à suivre.........

pour du meilleur encore pour notre Team.

Alors de grands merci à vous tous qui m'avez tant aidé

Toujours est-il que cela ce déroule sous Darwin 7.8.0, 7.9.0, et 8.0.0

no comments more are possible at this time! désolé......

Ce message a été modifié par patpan - 3 Mar 2005, 02:16.

[nektarfl]

Et voilà que ça recommence !!!!!
J'envoie hier 1754 blocks, et ce matin seulement 1731 retenus (aucun calcul au hasard cette fois-ci et une prise de moins de 90 jours pour les blocks)

CODE

dnetc v2.9007-486-CTR-03110414 for Mac OS X (Darwin 7.8.0).
Using email address (distributed.net ID) 'nektarfl'

[Mar 18 15:56:16 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Mar 18 15:56:16 UTC] Retrieved project state data from server. (cached)
[Mar 18 16:01:27 UTC] RC5-72: Sent 1754 packets (1754.00 stats units) to server.

pour kakace, si tu veux, je peux envoyer les logs correspondant pour cette semaine.

[patpan]

Et voilà que ça recommence !!!!!
J'envoie hier 1754 blocks, et ce matin seulement 1731 retenus (aucun calcul au hasard cette fois-ci et une prise de moins de 90 jours pour les blocks)
[code]dnetc v2.9007-486-CTR-03110414 for Mac OS X (Darwin 7.8.0).
Using email address (distributed.net ID) 'nektarfl'

[right][snapback]1067704[/snapback][/right]

Bonjour nektarfl,

attends demain, afin de savoir s'il est certain que tes packets manquants ne te sont pas tout simplement attribués avec retard. Cela m'arrive à moi aussi, et le lendemain je constate que leur crédit a été normallement effectué.
Il faut garder espoir

@ +

Patrick

[nektarfl]

Oui OK, mais demain, j'envoie les blocks calculés par le G5, j'espère que ça fera pas pareil!!!
Perso, j'estime que si j'avais été limite en temps pour envoyer mes blocks, ça aurait pu se justifier, mais là, avant 16h !!!!! Et surtout, ça m'est jamais arrivé de voir mes blocks disparus revenir, même le lendemain!

[patpan]

Oui OK, ..... Et surtout, ça m'est jamais arrivé de voir mes blocks disparus revenir, même le lendemain!
[right][snapback]1067935[/snapback][/right]

je te confirme absolument que cela m'arrive de temps à autre,
et j'esssaie pourtant de ne pas être mesquin dans mes envois, ce soir j'aurai dépassé les 1100 blocks en moyenne jour depuis mes débuts à vos cotés dans cette aventure!

[nektarfl]

Bon, pour une fois, les 23 blocks manquants sont bien là!!!! je retire tout ce que j'ai pu dire.

Par contre, mon G5 n'a presque pas calculé cette semaine, effectivement, j'ai fait une mise à jour du système la semaine dernière, et je le trouvais extrèmement silencieux..... et pour cause, il disait être à 100% de travail, mais il était réglé à automatique dans les performances du processeur, résultat, à peine 6Mkey/s sur une semaine . Je l'ai mis sur maximale, et le ventilo s'est aussitôt mis en route (mais sans violance) et les perf sont remontées à plus de 13Mkey/s. Je l'avais trouvé un peu mou sur W3 cette semaine, je comprends maintenant pourquoi.

[patpan]

Bon, pour une fois, les 23 blocks manquants sont bien là!!!! je retire tout ce que j'ai pu dire.

[right][snapback]1068797[/snapback][/right]

Salut,

et bien, tu vois qu'il ne faut pas désespérer !
ce qui me surprend en revanche, c'est que cela se soit produit avec des flush réalisés avant 16h.
L'ami kakace doit bien avoir une petite explication.

pour le reste du message, il suffit de faire un peu attention!

@ +
Patrick

[kakace]

L'heure à laquelle sont envoyés les paquets n'a guère d'importance. Les proxies sont réglés pour ré-expédier les paquets vers le serveur à partir d'un certain niveau. Par exemple, un proxy peut très bien attendre d'avoir 1000 paquets avant d'initier une connexion.
Comme cette fonction est asynchrone, un flush vers le serveur (keymaster) peut intervenir pendant que le proxy accepte de nouveaux paquets depuis un client. Du coup, un flush de 1754 blocs peut très bien être ré-expédié partiellement vers le keymaster, le reliquat étant mit de côté pour une future connexion.
Si on ajoute à ça les problèmes de liaison entre proxies et keymaster, et la charge de travail des machines considérées, le délai entre le flush initial et la prise en compte dans les stats peut s'allonger jusqu'à plusieurs heures.

J'en profite pour signaler que le proxy situé en Hollande (utrecht) connaît des soucis. En principe, le nécessaire a été fait pour rediriger les clients vers d'autres proxies. Plus d'infos ici.

Ce message a été modifié par kakace - 20 Mar 2005, 14:15.