Team RC5-72 MacBidouille

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

[SuperCed]

C'est quoi le core OGR Altivec? C'est quoi la différence avec l'ancien?

[nektarfl]

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



Plus de 4 fois plus puissant quand même !

Je suis surpris de tes "performances", je suppose que ton ordinateur ne tourne pas 24h/24 parce qu'avec mon G4 800 (avant le vol de ce dernier), je faisais 151 blocks par jour (de 22h théorique) avec un bonus de temps en temps alors qu'avec le G3 500 qui était à coté, j'avais pour la même période 31 blocks par jour.

Aujourd'hui avec le G4 1.25Ghz, j'arrive jusqu'à 256 blocks par jour (au maximum)

[ctrl_alt_suppr]

Je suis surpris de tes "performances", je suppose que ton ordinateur ne tourne pas 24h/24 parce qu'avec mon G4 800 (avant le vol de ce dernier), je faisais 151 blocks par jour (de 22h théorique) avec un bonus de temps en temps alors qu'avec le G3 500 qui était à coté, j'avais pour la même période 31 blocks par jour.

Aujourd'hui avec le G4 1.25Ghz, j'arrive jusqu'à 256 blocks par jour (au maximum)

Disons que j'exploite beaucoup mon processeur à côté de RC5, donc forcement ça le bride un peut.

Si ça peut te rassurer, j'ai fait 112 blocs hier (j'ai rien compilé, gcc est resté au repos).

Par contre, peponne s'est déchiré, hier, plus de 15 000 blocs à lui tout seul ! J'aimerai bien savoir combien de machines il a lancé dessus...

[caraboud]

Par contre, peponne s'est déchiré, hier, plus de 15 000 blocs à lui tout seul ! J'aimerai bien savoir combien de machines il a lancé dessus...

C'est son G5 2x2 qui a du bosser dur pendant presque 1 mois !

[nektarfl]

pour ma part (afin de relancer aussi un peu le sujet qui a l'air de s'épuiser avant les vacances) j'ai envoyé quelques menus calculs :

CODE

[Jul 17 17:43:03 UTC] Connected to euro.v29.distributed.net:2064...            
[Jul 17 17:43:03 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Jul 17 17:43:03 UTC] Retrieved project state data from server. (cached)
[Jul 17 17:48:50 UTC] RC5-72: Sent 2032 packets (2032.00 stats units) to se ...
[Jul 17 17:48:50 UTC] Connection closed.

Et j'ai pris de quoi être tranquille à peu près 3 à 4 semaines :

CODE

[Jul 17 17:43:40 UTC] Connected to euro.v29.distributed.net:2064...            
[Jul 17 17:43:40 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Jul 17 17:43:40 UTC] Retrieved project state data from server. (cached)
[Jul 17 17:52:32 UTC] RC5-72: Retrieved stats unit 2992 of 2992 (100.00%)      
[Jul 17 17:52:32 UTC] Connection closed.

CODE

[Jul 17 17:45:19 UTC] Connected to euro.v29.distributed.net:2064...            
[Jul 17 17:45:19 UTC] The keyserver says: "AIEEEEEEEEEEEEEEEEE! [bob]"
[Jul 17 17:45:19 UTC] Retrieved project state data from server. (cached)
[Jul 17 17:54:14 UTC] RC5-72: Retrieved stats unit 2989 of 2989 (100.00%)      
[Jul 17 17:54:14 UTC] Connection closed.

Je ne vais pas arreter de calculer pendant les vacances, par contre, je ne vais pas forcément être régulier dans mes expéditions de blocks.

Il faut continuer à envoyer des blocks... (mon ancien PC ayant rendu l'âme, il a été remplacé par un autre plus récent. => 110 blocks par jour contre 9,5 avec l'ancien!!)
Pendant mon mois d'août, je vais essayer de vider les blocks calculés au hasard par mon NeXT depuis 6 mois!

[jpaa]

Le serveur pour envoyer les blocks est HS !

Connected to euro.v29.distributed.net:2064...
Net::write: error 61: Connection refused
Connection closed.
Network update is currently not available.
Buffer update failed.

[kakace]

Le serveur pour envoyer les blocks est HS ! 

Connected to euro.v29.distributed.net:2064...           
Net::write: error 61: Connection refused
Connection closed.
Network update is currently not available.
Buffer update failed.

Il est possible d'utiliser un autre proxy en dépannage. Par exemple, "./dnetc -fetch -a us.v29.distributed.net" devrait permettre de récupérer de nouveaux blocs. On peut utiliser "-update" à la place de "-fetch" de façon à aussi retourner les blocs calculés.

[g4hd]

c'était inaccessible... c'est reparti.
Concernant l'utilisation de Dnetcx,
que j'aime bien parce que je ne suis pas acharné au terminal,
et surtout, j'ai un accès instantané pour le lancer ou l'arrêter à ma convenance (quand le bruit de ventilo m'énerve),
je le mets régulièrement à jour en y insérant la dernière version de dnetc (comme l'explique Dr No 7) :
Dnetcx--> afficher le contenu du paquet /Contents/Resources/dnetc/(glisser ici la dernière version)dnetc.

Pour info, j'ai regardé avec Moniteur d'activité :
1- quand Dnetcx a une fenêtre ouverte à l'écran, il consomme de 0,4% à 0,9% de mon CPU.
pendant ce temps-là, dnetc comble l'activité à 100% : je vois souvent de 75% à 92%.
le proc' n'est pas souvent vraiment exploité.
2- quand la fenêtre Dnetcx est close, il apparait toujours dans Moniteur d'activité avec 0%.

Ainsi, tout en ne perdant que très très peu (je ferme la fenêtre Dnetcx et dnetc travaille en tâche de fond), je garde un accès à dnetc comme une autre appli.

Pour télécharger cette version, sur ma homepage •mac / rubrique Bidouilles Mac

[jpaa]

D'ailleurs par rapport a l'utilisation de DnetcX, c'est normal qu'il n'affiche pas de barre de progression ( la présentation 2) ?

[pimus]

Question de néophyte avant d'installer RC75 sur mon PC :
Peut-on, comme avec le Terminal sur Mac, couper/relancer/updater avec le client dnetc-75 Windows XP? En plus clair, y a-t-il des pièges? Je ne voudrais pas mettre "en péril" cet animal que je n'ai pas encore domestiqué et que mes kikis -les traîtres- utilisent quotidiennement pour jouer mais à des jeux encore absents sur Mac...