Team RC5-72 MacBidouille

[patpan]

Bonsoir à toutes et à tous,

Loin de mon "home", et en fait loin de tout, je suis ce soir de retour de vacance(s), et franco j'ai balancé sur DN les blocks calculés en mon absence.

20758 blocks en plus, cela n'est pas négligeable

Un pat heureux de vous retrouver

Amicalement

[popboy]

Salut à toi grand Pat et tes nombreux blocs, je note que tu dis toutes et tous...
peu de présence féminine ici mais j'ai observé qu'il y avait une fille qui participe
très régulièrement, à moins qu'un macbidouilleur fatécieux...

[patpan]

Salut à toi grand Pat et tes nombreux blocs, je note que tu dis toutes et tous...
peu de présence féminine ici mais j'ai observé  qu'il y avait une fille qui participe
très régulièrement, à moins qu'un macbidouilleur fatécieux...
[right][snapback]1311093[/snapback][/right]

Bonsoir,

Quand bien même seraient-elles peu nombreuses (chacune est unique ), c'est par pure politesse, ami Genevois !

Les blocks sont de plus en plus difficile à calculer, qq G4 ayant rendu l'âme en mon absence .

je vais essayer d' remédier au plus vite.

amicalement

Pat

[popboy]

Tu es brave, nous flirtons avec la 3ème place (classement quotidien)
tes machines suffirons-t-elles pour l'assurer chaque jour ?

Pas sur, néamoins nous tennons bien le classement, ce n'est pas si mal.

Si les iPod pouvaient calculer des blocs

Ce message a été modifié par popboy - 8 Sep 2005, 15:53.

[Snoopy]

Depuis quelques jours j'utilise donc dnetc en tache de fond (par ./dnetc -install). Ca marche super mais aussi je vide et rempli mes buffers à la mimine (pour envoyer des blocs tous les jours)!...
Aujourd'hui j'avais 584 blocs dans le buff-out et cela demande plus de trois minutes à transférer et recharger le buff-in:

./dnetc -update

distributed.net client for Mac OS X Copyright 1997-2005, distributed.net
RC5-72 PowerPC assembly by Malcolm Howell and Didier Levet
Enhancements for 604e CPUs by Roberto Ragusa
RC7-72 Altivec and OGR assembly by Didier Levet
Please visit http://www.distributed.net/ for up-to-date contest information.


dnetc v2.9010-495-CTR-05051512 for Mac OS X (Darwin 8.2.0).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/
Using email address (distributed.net ID) 'xxxxxxxxx@yyyy'

[Sep 08 20:09:46 UTC] Connected to euro.v29.distributed.net:2064...           
[Sep 08 20:09:46 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Sep 08 20:09:46 UTC] Retrieved project state data from server. (cached)
[Sep 08 20:11:18 UTC] RC5-72: Retrieved stats unit 584 of 584 (100.00%)       
[Sep 08 20:12:50 UTC] RC5-72: Sent 584 packets (584.00 stats units) to server.
[Sep 08 20:12:50 UTC] Connection closed.

Est-ce normal, car ça semble assez lent (connection ADSL) ?
J'ai aussi essayé de retrouver comment faire l'opération automatiquement à une heure donnée grace à Crontab, mais sans succès. Quelqu'un connaît-il la solution?

Ce message a été modifié par Snoopy - 8 Sep 2005, 21:28.

[patpan]

Depuis quelques jours j'utilise donc dnetc en tache de fond (par ./dnetc -install). Ca marche super mais aussi je vide et rempli mes buffers à la mimine (pour envoyer des blocs tous les jours)!...
Aujourd'hui j'avais 584 blocs dans le buff-out et cela demande plus de trois minutes à transférer et recharger le buff-in:

./dnetc -update

dnetc v2.9010-495-CTR-05051512 for Mac OS X (Darwin 8.2.0).
[Sep 08 20:09:46 UTC] Connected to euro.v29.distributed.net:2064...           
[Sep 08 20:09:46 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Sep 08 20:09:46 UTC] Retrieved project state data from server. (cached)
[Sep 08 20:11:18 UTC] RC5-72: Retrieved stats unit 584 of 584 (100.00%)       
[Sep 08 20:12:50 UTC] RC5-72: Sent 584 packets (584.00 stats units) to server.
[Sep 08 20:12:50 UTC] Connection closed.

Est-ce normal, car ça semble assez lent (connection ADSL) ?
J'ai aussi essayé de retrouver comment faire l'opération automatiquement à une heure donnée grace à Crontab, mais sans succès. Quelqu'un connaît-il la solution?
[right][snapback]1312989[/snapback][/right]

Bonsoir Snoopy,

effectivement c'est apparament lent, mais ta vitesse de connexion est aléatoirement sans rapport avec tes performances de -flush ou de -fetch; c'est pourquoi je ne suis pas partisan de procéder ainsi;

je préfère, si on a une connection online permanente, un -update toutes le 2 ou 4 heures - ( cela se fait automatiqement, et se définit dans ./dnetc -config ) -.

./dnetc update ou pas, les réglages ont déja été de nombreuses fois expliqués de long en large par kakace ou bien nektarfl ;
je sais, il faut avoir le courage de lire ou relire les nombreuses pages de ce topic.

il faut bien avoir en tête que le -fetch n'est pas simple: le serveur vérifie ta propre vitesse de connexion, ( pour savoir le nombre de blocks à t'alouer ) les blocks qui ont déja été distribués et calculés sur les 90 derniers jours avec retour -flush, (c'est en fait encore beaucoup plus complqué que cela).

l'heure et le jour sont des facteurs à ne pas négliger, car il y a là des variations très importantes.

Bien, j'espère ne pas avoir été trop confus .

Si tu trouves mes réponses trop simplistes, d'autres vont se faire un plaisir de t'en conter plus!

amicalement

Pat

[kakace]

Est-ce normal, car ça semble assez lent (connection ADSL) ?
[right][snapback]1312989[/snapback][/right]

C'est lent pour tout le monde. Ca vient du fait que le client envoie les paquets un par un et attend un accusé de réception du serveur entre chaque paquet (pareil dans l'autre sens). Diminuer le nombre de paquets envoyés/reçus ne fait que répartir ce délai sur une plus longue période.

[Snoopy]

C'est lent pour tout le monde. Ca vient du fait que le client envoie les paquets un par un et attend un accusé de réception du serveur entre chaque paquet (pareil dans l'autre sens). Diminuer le nombre de paquets envoyés/reçus ne fait que répartir ce délai sur une plus longue période.
[right][snapback]1314284[/snapback][/right]

Merci pour ces informations.
Mais au fait, tu n'as jamais parlé du projet RC7-72:

RC7-72 Altivec and OGR assembly by Didier Levet

[patpan]

Est-ce normal, car ça semble assez lent (connection ADSL) ?
[right][snapback]1312989[/snapback][/right]

C'est lent pour tout le monde. Ca vient du fait que le client envoie les paquets un par un et attend un accusé de réception du serveur entre chaque paquet (pareil dans l'autre sens). Diminuer le nombre de paquets envoyés/reçus ne fait que répartir ce délai sur une plus longue période.
[right][snapback]1314284[/snapback][/right]

bonsoir kakace ,
il n'est guère possible de réfuter tes propos.

Cependant tu sais très bien qu'en fonction des heures de -update , il y a des variations très importantes.
Le facteur de la variable peut être supèrieur à dix!
( et en fait, bien plus, je ne fais en aucun cas allusion aux déconexions intempestives et aléatoires ).
pourquoi un -fetch est-il si lent à certains moments ?

bien à toi

Pat

[Snoopy]

Cependant tu sais très bien qu'en fonction des heures  de -update , il y a des variations très importantes.
Le facteur de la variable peut être supèrieur à dix!
( et en fait, bien plus, je ne fais en aucun cas allusion aux déconexions intempestives et aléatoires ).
pourquoi un -fetch est-il si lent à certains  moments ?

bien à toi 

Pat
[right][snapback]1314957[/snapback][/right]

J'ai du hier soir effectivement m'y reprendre à trois fois pour updater 574 blocs: déconnexions suite à des erreurs en lisant des blocs, qui sont bien pris un peu plus tard!...

[kakace]

Cependant tu sais très bien qu'en fonction des heures  de -update , il y a des variations très importantes.
Le facteur de la variable peut être supèrieur à dix!
( et en fait, bien plus, je ne fais en aucun cas allusion aux déconexions intempestives et aléatoires ).
pourquoi un -fetch est-il si lent à certains  moments ?

Puisque la communication entre le client et le proxy est bidirectionnelle, toute surcharge du réseau ou du proxy (serveur) augmente la durée des négociations entre chaque paquet envoyé/reçu.

Ceci dit, j'ai du mal à comprendre en quoi cela représente une gêne. Les paquets qui ne sont pas retournés à temps pour le jour J seront crédités au jour J+1, si bien que le résultat final est le même. Si la connexion à Internet n'est pas active en permanence, il est possible de configurer le client pour faire un -update automatique à chaque connexion (lurk mode). Au bout du compte, les updates manuelles ne sont pas nécessaires.

Pour ceux qui estiment que le client perd trop de temps à communiquer avec le proxy (quelques secondes par jour), la solution la plus efficace reste le Personal Proxy. Cela exige une connexion permanente, l'installation et la configuration n'est pas des plus simples, mais cela permet d'isoler le client du réseau. Les updates sont alors tres rapides (plusieurs centaines de paquets par seconde), le "proxyper" se chargeant des communications avec le serveur en tâche de fond.
A mon avis le jeu n'en vaut pas la chandelle. En revanche, le proxyper reste la solution de choix lorsque le client tourne sur plusieurs machines reliées à un réseau local (centralisation).

[patpan]

Puisque la communication entre le client et le proxy est bidirectionnelle, toute surcharge du réseau ou du proxy (serveur) augmente la durée des négociations entre chaque paquet envoyé/reçu.

Ceci dit, j'ai du mal à comprendre en quoi cela représente une gêne. Les paquets qui ne sont pas retournés à temps pour le jour J seront crédités au jour J+1, si bien que le résultat final est le même. Si la connexion à Internet n'est pas active en permanence, il est possible de configurer le client pour faire un -update automatique à chaque connexion (lurk mode). Au bout du compte, les updates manuelles ne sont pas nécessaires.

kakace bonjour,

Merci pour cette réponse qui éclaire un peu plus nos lumières !

Cela paraît être assez clair.

Ce qui est coton, hum..., c'est la configuration de proxyper,
absolument inaccessible à mon niveau ( et je ne dois pas être le seul! )

encore merci pour tes lumières

Pat

[altai]

Enfin arrivé dans le top 100 dans la statistique de la team.

[popboy]

Hé, 100 ème place de l'équipe en 3 mois pas mal, faut dire que tu n'es pas sous équipé non plus.

Bonne continuation et à bientôt

[Snoopy]

Enfin arrivé dans le top 100 dans la statistique de la team. 
[right][snapback]1321495[/snapback][/right]

Bravo!
Tu fais combien de blocs par jour en moyenne avec ton bi 2,3GHz ?
Pour mon bi 2,5 GHz, sur les 9 derniers jours cela fait 596,6 blocs/jour, soit un keyrate de 29.66 Mkeys/s.
C'est pas énorme par rapport au MDD bi 1GHz que j'avais avant (keyrate de 19.7 Mkeys/s) Il faut que quelqu'un optimise le core pour les G5, car il y a de plus en plus de G5 qui tournent actuellement et ça aiderai à la progression de la team MB.

Ce message a été modifié par Snoopy - 14 Sep 2005, 20:23.

[popboy]

C'est sur, mais Kacace Levet il code pour AMD maintenant
Il n'a pas apprécié le dénigrement de l'altivec.

[altai]

Enfin arrivé dans le top 100 dans la statistique de la team. 
[right][snapback]1321495[/snapback][/right]

Bravo!
Tu fais combien de blocs par jour en moyenne avec ton bi 2,3GHz ?
Pour mon bi 2,5 GHz, sur les 9 derniers jours cela fait 596,6 blocs/jour, soit un keyrate de 29.66 Mkeys/s.
C'est pas énorme par rapport au MDD bi 1GHz que j'avais avant (keyrate de 19.7 Mkeys/s) Il faut que quelqu'un optimise le core pour les G5, car il y a de plus en plus de G5 qui tournent actuellement et ça aiderai à la progression de la team MB.
[right][snapback]1321768[/snapback][/right]

Je fais en moyenne d'environ 612 blocs/jours. Mais pendant les vacances la moyenne jour était de 694 blocs/jour.

Mais ma moyenne sera à la baisse pour cause de travaux chez moi. J'ai éteins mon mac hier soir et je pourrai le relancer pas avant la fin de weekend.

Merci pour les compliments !

[Snoopy]

Je fais en moyenne d'environ 612 blocs/jours. Mais pendant les vacances la moyenne jour était de 694 blocs/jour.

Mais ma moyenne sera à la baisse pour cause de travaux chez moi. J'ai éteins mon mac hier soir et je pourrai le relancer pas avant la fin de weekend.

Merci pour les compliments !
[right][snapback]1322278[/snapback][/right]

Là je ne comprend pas cette différence, car logiquement avec un bi 2.5 GHz, je devrai faire environ 8% de plus que toi, nos config étant très semblables, et au contraire je calcule de 2.5% à 16% de blocs en moins , soit une différence de 10% à 24%
Sous quel système est ton G5, moi c'est Tiger 10.4.2 ?
Tu utilises quel client dnetc ?

Je n'utilise mon Mac que le soir environ 2 / 3 heures et le reste, comme je coupe le 2405FPW et que ma tablette Wacom est branchée dessus, le driver correspondant ne prend apparement plus de ressources processeur.
Il faut que j'essaie de déconnecter Airport, on ne sais jamais!...

Ce message a été modifié par Snoopy - 15 Sep 2005, 14:43.

[altai]

Je fais en moyenne d'environ 612 blocs/jours. Mais pendant les vacances la moyenne jour était de 694 blocs/jour.

Mais ma moyenne sera à la baisse pour cause de travaux chez moi. J'ai éteins mon mac hier soir et je pourrai le relancer pas avant la fin de weekend.

Merci pour les compliments !
[right][snapback]1322278[/snapback][/right]

Là je ne comprend pas cette différence, car logiquement avec un bi 2.5 GHz, je devrai faire environ 8% de plus que toi, nos config étant très semblables, et au contraire je calcule de 2.5% à 16% de blocs en moins , soit une différence de 10% à 24%
Sous quel système est ton G5, moi c'est Tiger 10.4.2 ?
Tu utilises quel client dnetc ?

Je n'utilise mon Mac que le soir environ 2 / 3 heures et le reste, comme je coupe le 2405FPW et que ma tablette Wacom est branchée dessus, le driver correspondant ne prend apparement plus de ressources processeur.
Il faut que j'essaie de déconnecter Airport, on ne sais jamais!...
[right][snapback]1322886[/snapback][/right]

Je suis aussi sur Tiger 10.4.2

Es-tu en performance processeur maximale ? Si ce n'est pas le cas tu trouveras cette option sous /préférence système /Economiseur d'énergie /Options

[Snoopy]

Es-tu en performance processeur maximale ? Si ce n'est pas le cas tu trouveras cette option sous /préférence système /Economiseur d'énergie /Options
[right][snapback]1323145[/snapback][/right]

J'étais en "Automatique"
Donc si c'est la raison j'en suis un ..., de ne pas avoir pensé à ce paramètre depuis le temps que je cherche!...
Résultat demain soir

[altai]

Es-tu en performance processeur maximale ? Si ce n'est pas le cas tu trouveras cette option sous /préférence système /Economiseur d'énergie /Options
[right][snapback]1323145[/snapback][/right]

J'étais en "Automatique"
Donc si c'est la raison j'en suis un ..., de ne pas avoir pensé à ce paramètre depuis le temps que je cherche!...
Résultat demain soir
[right][snapback]1323220[/snapback][/right]

Quand j'étais en automatique la capacité de calcul de mon bi 2.3 était de 542 blocs/jour. Donc pour toi tu devrais normalement en calculer plus de 700 blocs/jour.

As-tu la version de client dnetc v2.9010.495 ?

[Snoopy]

As-tu la version de client dnetc v2.9010.495 ?
[right][snapback]1323253[/snapback][/right]

Oui comme tu peux le lire sur mon post du 8 septembre.
J'attends avec impatience les résultats du passage en "Performance Maximale"

[Snoopy]

735 blocs sur ces dernières 24h
Cela représente un keyrate de 36,54 Mkey/s.
Confirmation qu'il est primordiale, pour les G5, de mettre la "performance du processeur" sur "maximale"

Ce message a été modifié par Snoopy - 16 Sep 2005, 21:42.

[popboy]

Sacré score de l'équipe "aujourd'hui" ceux qui on ralenti leur production
pour cause de chaleur éprouvante peuvent relancer la machine

[altai]

Imaginer que chaque membre (41'300) de ce forum calcul 50 blocks/jours cela fait un total de 2'065'000/jour

[popboy]

Comme nous ne sommes qu'une nonantaine (plus ou moins) à contribuer,
la progression potentielle est énorme, mais en fait une dizaine de membres réguliers nous
feraient déjà vraiment avancer, pas rêver.

Ce message a été modifié par popboy - 23 Sep 2005, 07:14.

[altai]

Comme nous ne sommes qu'une nonantaine (plus ou moins) à contribuer,
la progression potentielle est énorme, mais en fait une dizaine de membres réguliers nous
ferais déjà vraiment avancer, pas rêver.
[right][snapback]1332272[/snapback][/right]

En effet une dizaine de membres réguliers nous ferais déjà du bien.

Mais pour attirer les personnes auprès de la team il faudrait peut-être faire le point de la situation actuelle.

Expliquer pourquoi nous avons besoin de membres supplémentaire.

N'oublions pas que ce post fait 83 pages....

[popboy]

Enccore de bons scores ces derniers jours, avec le fraîchissement de ces derniers jours faites chauffer vos mac pour l'équipe. Quelques nouveaux membres et ce sera la félicité du calcul partagé

[nektarfl]

Je dois avouer qu'il y avait un certain temps que j'avais rien posté comme block, mais que mes ordinateurs n'ont pas arreté de travailler, alors effectivement, ces derniers temps, j'ai pas mal de blocks d'envoyé pour l'équipe, et je vais certainement en avoir encore plein d'autre dans pas longtemps (mon PC du boulot non connecté à internet)

[popboy]

Ah! je viens de passer devant Patrick Blazy qui à longtemps été notre "héraut".

Etonnant comme la production de blocs tient le coup avec aussi peu de participants.