Team RC5-72 MacBidouille

[Gintonic]

Hello,
Merci pour ta réponse...
J'aime beaucoup ta dernière solution
Je vois aussi qu'il faut que j'apprenne à mieux savoir utiliser la fonction rechercher...
Dans tous les cas, je vais étudier tout ça...
@+

[Mathiasr]

Il n'est pas possible de n'utiliser qu'un certain pourcentage de la puissance processeur, du moins pas pour l'instant (et pas dans un avenir proche non plus). Si la température pose un problème, plusieurs solutions sont disponibles :
- Faire tourner dnetc avec autre chose (seti, folding@home, etc).
- Utiliser un autre cruncher que celui choisi par défaut.
- Configurer le client pour qu'il se mette en pause à une certaine température, lorsque c'est possible. Voir la doc ou ici pour les détails.
- Ne plus utiliser dnetc.

Il doit être possible d'utiliser les fonctions -pause et -unpause de manière répétée et alternée.

Ça devrait permettre de faire une minute de calcul suivie d'une minute de pause, par exemple.
Bon si le ventilo se déclenche très rapidement c'est pas génial.

Par exemple après avoir lancé le client, on peut lancer ce shellscript qui attend 20 secondes, met le client en pause, attend 20 secondes, fait sortir le client de la pause et recommence indéfiniment.

#!/bin/sh
while true
do
sleep 20
./dnetc -pause
sleep 20
./dnetc -unpause
done

Avec une bonne redirection des affichages et moyen simple pour arrêter le tout ça peut éventuellement faire l'affaire.

[kakace]

Il doit être possible d'utiliser les fonctions -pause et -unpause de manière répétée et alternée.

Ça devrait permettre de faire une minute de calcul suivie d'une minute de pause, par exemple.
Bon si le ventilo se déclenche très rapidement c'est pas génial.

Par exemple après avoir lancé le client, on peut lancer ce shellscript qui attend 20 secondes, met le client en pause, attend 20 secondes, fait sortir le client de la pause et recommence indéfiniment.

C'est possible, mais je laisse ça aux bidouilleurs. La seule façon officielle et "propre" de faire ça serait de faire tourner le client en mode "real time", auquel cas on peut définir un ratio de temps partagé. Seulement faire tourner un soft qui se veut invisible au même niveau de priorité qu'un soft multimédia (qui lui a des contraintes de temps à respecter) n'est pas une bonne idée.
Le code source du client est déjà un sacré foutoir, et je freine des 4 fers pour ne pas chercher à ajouter des gadgets qui n'ont, finallement, pas grand chose à faire là surtout s'ils obligent à re-écrire une bonne partie du code, avec à la clé le risque de planter les versions des autres plateformes. Je suis prêt à faire beaucoup d'efforts, mais pas à ce prix.

J'en profite pour indiquer que le core G5 est pratiquement abandonné. Si je sais ce qu'il faut faire pour atteindre les performances optimales, je ne sais pas comment le faire facilement et rapidement, et je n'ai ni le temps, ni la patience d'écrire plusieurs versions jusqu'à l'obtention du résultat espéré. Si quelqu'un veut s'en donner la peine, je suis prêt à aider. J'ai d'ailleurs provoqué la mise à jour des sources publiques pour "faciliter" un tel projet. Ceci dit, ce n'est pas à la portée de tout le monde et de solides connaissances en assembleur sont un minimum.

Après avoir développé tout ce qui était nécessaire à la partie OGR-P2 (du keymaster jusqu'aux clients) pour sauver les meubles, je travaille maintenant sur OGR-26, ce qui devrait me prendre plusieurs mois en recherche et développement (nouveaux cores, optimisations, calculs, etc). Je le fais pour le fun (le principe d'un OGR est extrêmement simple, mais en trouver est tellement compliqué qu'il devient interressant de chercher à améliorer les méthodes existantes), mais aussi pour fournir à distributed.net un projet pour prendre la relève d'OGR-P2.

En attendant, et par la force des choses, j'ai aussi la charge de maintenir le client et le proxy personnel pour Mac OS X. Et comme je n'ai qu'une tête, deux mains, un boulot et une vie de famille...

[Rol@ndB]

Depuis que j'ai ma Freebox le client ne se connecte plus automatiquement aux serveur,
je pense que cela vient du fait que je suis en DHCP.

et je n'ai pas trouver les bons reglages dans les menus de config

[nektarfl]

Pour ma part, aujourd'hui, j'ai une connexion ADSL, alors j'en ai profité pour envoyer mes 5681 blocks calculés, j'en profite également pour prendre de la réserve de blocks à calculer (10 ou 12 000)

Pour roland, je ne pense pas que le fait d'être en DHCP bloque le passage puisque souvent, derrière un modem routeur, on se met en DHCP pour ne pas avoir à faire des réglages. C'est la voie la plus simple pour se connecter sur un réseau. Le problème doit venir d'ailleurs!

[r2d2]

Hello!
Et moi je cherche comment faire pour récupérer beaucoup de blocs à calculer

[popboy]

Nektarfl dans sa grande sagesse en à déjà parlé :

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.

[nektarfl]

popboy a raison, pour ma part, je renomme les fichiers buf1.r72, buf2.r72 etc et donc quand j'en prend 10 ou plus, ça fonctionne correctement avec la fonction -import ensuite.
Un petit détail (qui a quand même son importance) il ne faut pas charger plus de blocks que ne pourrait en calculer l'ordinateur en 90 jours (puisque les blocks non calculés au bout de 90jours sont remis en calcul.
Je vais reposter des blocks aujourd'hui (moins que la semaine dernière mais le temps de non expédition est moins long cette fois-ci.) et prendre 10 000 blocks d'avance.

Une petite astuce consiste à changer le nom du fichier de réception en cours de chargement (notament vers la fin) et bizarrement, le serveur envoie plus de 1000 blocks d'un coup puisque le fichier buffer se retrouve brutalement vide, il le recharge à fond!

[Gintonic]

Purée,
vous avez vu cette équipe????
Elle carbure fort-fort...

[popboy]

C'est clair qu'ils ont fait une production qui correspond à une semaine de mac bidouille,
tiendrons-t-il longtemps à cette vitesse, l'été sera chaud.

A part ça, après la pommierisation de l'équipe avons nous eu des participants d'autres horizons que mac bidouille ?

[kakace]

Est-ce que quelqu'un pourrait me fournir les benchmarks d'un G5 bi-pro en OGR-P2 avec le dernier client (2.9008.491c - ./dnetc -bench OGR-P2) ?
Merci

[Gintonic]

Hello,
voici les résultats sur un "vieux" bi-1,8 de février:

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


dnetc v2.9008-491-CTR-04052815 for Mac OS X (Darwin 7.4.0).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/

[Jun 17 12:05:48 UTC] Automatic processor type detection found
                      a PowerPC 970 (G5) processor.
[Jun 17 12:05:48 UTC] OGR-P2: using core #0 (GARSP 5.14 Scalar).
[Jun 17 12:06:07 UTC] OGR-P2: Benchmark for core #0 (GARSP 5.14 Scalar)       
                      0.00:00:16.21 [17,609,168 nodes/sec]
[Jun 17 12:06:07 UTC] OGR-P2: using core #1 (GARSP 5.14 Vector).
[Jun 17 12:06:26 UTC] OGR-P2: Benchmark for core #1 (GARSP 5.14 Vector)       
                      0.00:00:16.64 [10,758,371 nodes/sec]

Je sais pas ça change quelque chose, mais je n'étais pas en root et il y avait 2 ou trois programmes qui tournais (mais qui ne faisaient rien de particulier...)

J'espère avoir pu t'aider...

@+

[kakace]

[Jun 17 12:06:07 UTC] OGR-P2: Benchmark for core #0 (GARSP 5.14 Scalar)       
                      0.00:00:16.21 [17,609,168 nodes/sec]
[Jun 17 12:06:07 UTC] OGR-P2: using core #1 (GARSP 5.14 Vector).
[Jun 17 12:06:26 UTC] OGR-P2: Benchmark for core #1 (GARSP 5.14 Vector)       
                      0.00:00:16.64 [10,758,371 nodes/sec]

Effectivement...
Le core GARSP 5.14 Scalar est 7% plus rapide qu'avant sur un G4, mais rien ne change sur un G5. Quant au core Vector, je n'en parle même pas... On en revient donc au même problème qu'avec le RC5 : le G5 paye le prix de ses pipelines plus longs, et ça se remarque dès que le code est optimisé (un optimisation spécifique au G5 n'étant pas possible compte-tenu des nombreuses dépendances entre instructions).
Passons...

[Mathiasr]

Le core GARSP 5.14 Scalar est 7% plus rapide qu'avant sur un G4, mais rien ne change sur un G5. Quant au core Vector, je n'en parle même pas... On en revient donc au même problème qu'avec le RC5 : le G5 paye le prix de ses pipelines plus longs, et ça se remarque dès que le code est optimisé (un optimisation spécifique au G5 n'étant pas possible compte-tenu des nombreuses dépendances entre instructions).
Passons...

Question peut-être stupide, mais as-tu essayé d'aligner le début des boucles et points de branchement sur des adresses multiples de 32 ?
http://developer.apple.com/technotes/tn/tn....html#aligncode
Ça risque de faire grossir le code pour un gain minime, mais ça peut toujours être bon à prendre.

[Mathiasr]

Le client 491c qui est passé en final ne reconnait pas le PowerPC 750FX :

dnetc v2.9008-491-CTR-04052815 for Mac OS X (Darwin 7.4.0).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/

[Jun 20 19:27:57 UTC] Automatic processor type detection did not
recognize the processor (id: 28672)

[kakace]

Le client 491c qui est passé en final ne reconnait pas le PowerPC 750FX :

Bug #3675, qui est fixé depuis quelques jours. Il va falloir attendre la version 492, avec laquelle je compte bien éliminer certains vieux bugs et améliorer certaines choses. En exclusivité, j'en suis là :

2.9008-492
imp: ppc: Faster GARSP Vector core
imp: all: Added an option to rotate log files at local time or UTC time (#2613)
fix: all: Made week number ISO 8601 compliant (#3336)
imp: all: Display which cruncher load/save/complete work (#2954)
imp: all: Log more error messages (#3611)
imp: macosx: Made the buffer threshold limits hw-dependant (#3626)
fix: ppc: Select core #5 on PPC 601 (#3685)
fix: macosx: Now recognize PPC 750FX (#3675)
fix: macosx: No longer read the TAU on G4/G5.

... et ce n'est pas fini...

[Mathiasr]

Il y a également le fait que l'on puisse lancer le client avec -bench RC5, OGR, CSC ou encore DES et qu'il ne signale pas qu'il ne dispose plus des cores correspondants.

[Mathiasr]

Et en prime, le nom du fichier qui sert à arrêter le client (exitdnet.now par defaut) comment le supprime t-on dans les dernières versions ?!

Avant :
distributed.net client configuration: General Client Options
--------------------------------------------------------------------------
1) Your email address (distributed.net ID) ==> [email protected]
2) Complete this many packets, then exit ==> 0 (no limit)
3) Run for this long, then exit ==> 0:00 (no limit)
4) Pause flagfile Path/Name ==>
5) Exit flagfile Path/Name ==>
6) Enable restart on .ini file change? ==> no
7) "Pause if running" ==>
8) Pause if processor temperature thresholds are exceeded? ==> no
9) Pause if running on battery power? ==> yes
10) Run detached/disable all screen output? (quiet mode) ==> no
11) Crunch-o-meter (progress indicator) style ==> 0

Sur 491c :
distributed.net client configuration: General Client Options
--------------------------------------------------------------------------
1) Your email address (distributed.net ID) ==> [email protected]
2) Complete this many packets, then exit ==> 0 (no limit)
3) Run for this long, then exit ==> 0:00 (no limit)
4) Pause flagfile Path/Name ==>
5) Exit flagfile Path/Name ==> exitdnet.now
6) Enable restart on .ini file change ? ==> no
7) "Pause if running" ==>
8) Pause if processor temperature thresholds are exceeded ? ==> no
9) Pause if running on battery power ? ==> yes
10) Run detached/disable all screen output ? (quiet mode) ==> no
11) Crunch-o-meter (progress indicator) style ==> 0

Comparer le 5)

[caraboud]

Allez, encore une question PC ! :
Je fais travailler dnetc sur mon PC au boulot. Le client avait repéré deux processeurs, alors qu'il n'y en avait qu'un. C'était l'hyperthreading. J'ai donc décoché cette option dans dnetc config, et il ne travaille désormais que sur un seul block à la fois. Mais je viens de m'apercevoir qu'en faisant ctrll alt supp, dans la fenêtre processus, dnetc n'utilise que 47-50% du processeur.
Il y a toujours 50% du processeur inactif quand dnetc est seul à fonctionner !
Y a t'il une possibilité d'en utiliser 100% ?

[Mathiasr]

Y a t'il une possibilité d'en utiliser 100% ?

Désactiver l'HT au niveau du BIOS.

[Guest_macmagna_*]

Mais je viens de m'apercevoir qu'en faisant ctrll alt supp, dans la fenêtre processus, dnetc n'utilise que 47-50% du processeur.
Il y a toujours 50% du processeur inactif quand dnetc est seul à fonctionner !

Même si rien d'autre ne tourne, c'est peut être Window$ qui utilise le reste, ocaou

[gastonlag]

Salut

j'ai un G5 DP 1.8GHz qui ne fait (encore) rien l'essentiel du temps (au moins un proc de dispo en tout cas...). Je suis volontaire pour le faire participer au jeu RC5. Mon truc c'est que je trouve la configuration ligne de commande très très (très) dissuasive . Il y a quelques mois j'avais récupéré dnetcx qui avait l'avantage immense qu'il n'y avait rien à configurer et juste à cliquer sur start ce qui est de l'ordre de difficulté auquel je peux m'attaquer

Est-ce qu'il y a une version recente de DnetcX avec le dernier client disponible quelque part (une recherche dans les forums ne m'a rien donné de récent et j'ai la flemme de me farcir les 61 pages de ce topic )

[nektarfl]

On va te donner un coup de main: c'est pas si compliqué que ça.
Conventions :
(return) signifie qu'il faut appuyer sur la touche return.
(espace) signifie qu'il faut appuyer sur la barre d'espace.
Les caractères gras sont à saisir au clavier

Mode d'emploi pour la mise en route la première fois :

1) Ouvrir l'application Terminal (dans /Applications/Utilitaires)
2) Taper : cd(espace)
3) Ouvrir une page du finder et sélectionner le répertoire où se trouve dnetc
4) Glisser le répertoire dnetc dans la page du terminal
5) Revenir dans le Terminal et taper : (return)
6) Taper : ./dnetc -config(return)

CODE

distributed.net client configuration:
--------------------------------------------------------------------------
1) General Client Options
2) Buffer and Buffer Update Options
3) Performance related options
4) Logging Options

9) Discard settings and exit
0) Save settings and exit


Choice -->

7) Taper : 1(return) ->pour configurer le client

CODE

distributed.net client configuration: General Client Options
--------------------------------------------------------------------------
1) Your email address (distributed.net ID) ==> mon_mail@mon_fournisseur.com
2) Complete this many packets, then exit ==> 0 (no limit)
3) Run for this long, then exit ==> 0:00 (no limit)
4) Pause flagfile Path/Name ==>
5) Exit flagfile Path/Name ==> exitrc5.now
6) Enable restart on .ini file change? ==> no
7) "Pause if running" ==>
8) Pause if processor temperature thresholds are exceeded? ==> no
9) Pause if running on battery power? ==> yes
10) Run detached/disable all screen output? (quiet mode) ==> no
11) Crunch-o-meter (progress indicator) style ==> -1 (auto-sense)

0) Return to main menu

Choice -->

8) Taper : 1(return) ->pour donner votre email
9) Entrez votre email (return)
10) Taper : 0(return) -> pour revenir au menu précédent
11) Taper : 2(return) -> pour définir le nombre de blocks à charger

CODE

distributed.net client configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------
1) Buffer in memory only? (no disk I/O) ==> no
2) In-Buffer Filename Prefix ==> buff-in
3) Out-Buffer Filename Prefix ==> buff-out
4) Checkpoint Filename ==>
5) Disable buffer updates from/to a keyserver ==> no
6) Keyserver<->client connectivity options
7) Disable buffer updates from/to remote buffers ==> no
8) Remote buffer directory ==>
9) Load-work precedence ==> OGR=0,RC5-72
10) Additional buffer-level checking ==> 0 (none)
11) Buffer-level check interval ==> 0:00 (on buffer change)
12) Fetch work threshold ==> OGR=0,RC5-72=1000
13) Fetch time threshold (in hours) ==> RC5-72=0

0) Return to main menu

Choice -->

12) Taper : 12(return) -> pour choisir le nombre de blocks à charger
ou 12bis) Taper : 13(return) -> pour choisir un nombre d'heure de travail
Pour les fonctions de cette page, vous pouvez recopier les valeurs ci-dessus
13) Appuyer sur (return) pour valider vos choix (dans mon choix, je charge 1000 blocks à la fois ce qui donne environ 4 jours de travail sur mon imac)
14) Taper : 0(return)
15) Taper : 0(return) -> pour sortir et sauver la configuration

Ca y est : la configuration est faite maintenant.

On peut décider que dnetc démarre aussitôt que l'ordinateur est allumé en tapant :
./dnetc -install(return)
Et ensuite décider de le démarrer tout de suite :
En aveugle : ./dnetc -quiet(return)
En voyant le résultat : ./dnetc(return)

J'espère avoir été simple et accessible, et si un point était flou, pas de problème, j'essaye d'y remédier.

[Dr No 7]

Pour répondre à gastonlag, oui tu peux utiliser le client dnetcx le plus simplement du monde. De plus, pour avoir le core à jour, il te suffit de télécharger le dernier sorti et d'aller le remplacer dans le paquet de l'application (clique droit sur l'application et "Afficher le contenu du paquet"). Que du bonheur.


Par contre j'avais une question justement concernant dnetcx: quelle différence entre l'utilisation de ce dernier et du client seul via le terminal? Un quelconque impact sur les performances (j'en doute quand même)? Ou juste pour le plaisir de le lancer à la dur et surtout la flexibilité que ça peut induire (lancement en tâche de fond comme tout bon daemon)?

Sinon, mon petit Ti fait de son mieux toute la journée J'ai juste le ventilateur qui fait un bruit étrange depuis deux jours.... pourvu qu'il ne rende pas l'âme !

Sinon pour les scores bravo à tout ceux qui participent au projet, le classement parle de lui même

P.S.: il ne manquerai plus que ce soit un membre qui trouve la clé finale

Ce message a été modifié par Dr No 7 - 30 Jun 2004, 11:20.

[nektarfl]

Tu poses la question des perf?
Très simple: l'interface graphique "mange" environ 10 à 20% du proc

Avec ce que j'ai mis plus haut, pas de "montage" on prépare 1 fois, et ça marche tout seul ensuite, sans y penser.
Même le programme terminal arrive à manger 1à2% de CPU!!

Et surtout, en faisant le -install, même pendant la page de login, dnetc est actif, il calcule et envoie/reçoit des blocks si nécessaire (avec une connexion ADSL et modem ethernet)

Ce message a été modifié par nektarfl - 26 Jun 2004, 15:01.

[ctrl_alt_suppr]

Salut à tous.

Bon, voilà, cette fois j'ai sauté le pas : j'ai mis mon modeste G4 800 à disposition du team Macbidouille/Le Pommier !

[Mathiasr]

Juste un petit mot, pour dire que suite à déménagement, je vais être privé d'ADSL pour une durée indéterminée. Vais (re)goûter aux joies du RTC.
Mais si j'ai un moment je colle une doc avec Cowboy qui permet d'avoir une interface pour piloter le client sans utiliser le terminal et sans consommer de cycles CPU, mais qui demande éventuellement un fichier de log.

[ctrl_alt_suppr]

C'est dingue ce qu'un G4 800 peut faire, par rapport à un G3 400 !



Plus de 4 fois plus puissant quand même !

[gastonlag]

OK j'ai pris mon (absence de) courage à deux mains et j'ai configuré dnetc. Bon ca crunche.
Reste plus qu'a me rattacher à la Macbidouille team ce que je devrais arriver à faire.
Je suis deçu ça n'a même pas l'air de faire chauffer la machine... Sur les autres machines surlesquelles j'avais essayé ca declenchait les ventilos assez rapidement...

Ce message a été modifié par gastonlag - 28 Jun 2004, 12:03.

[kakace]

Le client en version 2.9008.492 est disponible en pre-release depuis aujourd'hui. Il apporte des corrections de bugs, diverses améliorations, et un core OGR AltiVec beaucoup plus rapide, lequel est maintenant sélectionné par défaut sur G4. Je ne sais pas ce qu'il donne sur un G5, mais à priori il ne devrait pas casser des briques...