Team RC5-72 MacBidouille

[popboy]

Je m'attendais à une stagnation pour les temps prochains, en fait nous sommes à la limite de la regression. Malgré l'arrivé bienvenue de G5 dans l'équipe nos suivants devraient nous dépasser
dans six mois, autant dire demain. Si vous avez quelques minutes à "donner" à l'équipe n'hésitez pas, en fait si tout le meonde nous donnait un jour par mois ce serait énorme.

Ce message a été modifié par popboy - 4 Sep 2004, 18:44.

[patpan]

Je m'attendais à une stagnation pour les temps prochains, en fait nous sommes à la limite de la regression. Malgré l'arrivé bienvenue de G5 dans l'équipe nos suivants devraient nous dépasser
dans six mois, autant dire demain. Si vous avez quelques minutes à "donner" à l'équipe nhésitez pas, en fait sit tout le meonde nous donnait un jour par mois ce serait énorme.
[right][snapback]834192[/snapback][/right]

Et bien, je ne suis pas trop inquiet pour l'instant.
Les G5 ne sont guère plus performants que les anciens G4 à partir de 1,25Ghz:

PowerPC 970 G5
1800
13,147,178.00


PowerPC 970 G5
2000
15,057,412.00

==============

PowerPC 744x/745x G4
1200
12,570,285.00

----------------------------

PowerPC 744x/745x G4
1250
13,123,240.83


PowerPC 744x/745x G4
1333
13,928,854.67


PowerPC 744x/745x G4
1400
14,769,045.00


PowerPC 744x/745x G4
1416
15,045,897.00

PowerPC 744x/745x G4
1500
15,903,753.50

Ces données, extraites de la base de données de Distributed.net sont là pour nous donner une amorce d'explication.

Personellement en attendant mon beau G5, en passant mon G4 de 800 à 1200Mhz, j'ai augmenté ma moyenne de blocs quotidiens de 304, à 470!

[Tibam]

Hello!

je viens de déballer mon Bi 2.5 (ça existe!) de retour de l'Expo, et je lance mon tout vieux client DnetX, téléchargé sur Macbidouille l'année passée.

Il utilisait un core de 604e, donc j'ai téléchargé la version la plus récente depuis la page de la team Macbidouille. Résultat, dans le terminal (est-ce possible d'"upgrader" l'ancien client?), il dit bien

CODE

Automatic processor type detection found
                     a PowerPC 970FX (G5) processor.

mais ensuite il prend un core KKS 7450, donc de G4, est-ce normal?, si oui tout baigne, sinon ben quoi que faire?

il fait un packet en 2 minutes avec ce Core, ce qui n'est pas si mal

Par contre il ne calculera pas la nuit, vu le bruit que ça produit...

Merci de votre aide!

[kakace]

mais ensuite il prend un core KKS 7450, donc de G4, est-ce normal?

C'est normal. Il n'y a pas de core spécifique aux G5 (pour le moment)

[Tibam]

Oki!

Alors [32.96 Mkeys/s] à votre service!

[patpan]

Oki! 

Alors [32.96 Mkeys/s] à votre service! 
[right][snapback]835004[/snapback][/right]

par processeur, ou bien pour les deux?

je pense qu'il est important de le préciser!

Merci de ta réponse

[nektarfl]

Oki! 

Alors [32.96 Mkeys/s] à votre service! 
[right][snapback]835004[/snapback][/right]

par processeur, ou bien pour les deux?

je pense qu'il est important de le préciser!

Merci de ta réponse
[right][snapback]837287[/snapback][/right]

Faut pas rever, c'est pour les deux!!

C'est quand même pas si mal! (c'est 3x plus vite que ce que je fais avec le mien!)

[patpan]

Oki! 

Alors [32.96 Mkeys/s] à votre service! 
[right][snapback]835004[/snapback][/right]

par processeur, ou bien pour les deux?

je pense qu'il est important de le préciser!

Merci de ta réponse
[right][snapback]837287[/snapback][/right]

Faut pas rever, c'est pour les deux!!

C'est quand même pas si mal! (c'est 3x plus vite que ce que je fais avec le mien!)
[right][snapback]840447[/snapback][/right]

Bien sur, mais nous sommes loin des possibilités réelles d'un bi 2,5GHz!
Il faut attendre une optimisation du core pour le G5.

Merci

[Rol@ndB]

un bi2,5 devrait cruncher 50Mkeys/s avec un core aussi optimiser que les core G4.

un peu faiblard ces G5 quand meme

[SuperCed]

Il en faut pas oublier que le G5 n'est pas aussi bon que le G4e pour tout ce qui est Altivec.
Mais bon, la fréquence devrait quand même permettre de moonter un peu.

[popboy]

Quand au début de cette page, je parlais de l'arrivée bienvenue des G5 comme renfort pour l'équipe, ce n'était pas à l'optimisation du core (sur laquelle Kacace travaille), mais surtout en termes de gains par rapport aux machines qu'ils remplacent, passer d'un G3 à un bi G5 par exemple. Mais de toutes façons la différence entre nos prédécesseurs et nous est telle que nous devrions plus que doubler nos scores pour progresser, donc le but est plutôt de nous maintenir actuellement.

[popboy]

Bon, je crois que nous sommes en phase de "restabilisation",
encore un petit effort et nous sommes tranquilles.

[Mfx]

Bonjour à tous,

Y a t'il moyen de définir le nombre de blocs à charger ?
La variable fetch-workunit-threshold n'a pas l'air d'être encore prise en compte dans les dernières versions ...

Sinon, le G5 2x2.5 marche pas mal !

dnetc v2.9009-494-CTR-04081423 for Mac OS X (Darwin 7.5.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) '[email protected]'

[Sep 30 19:29:36 UTC] Automatic processor type detection found
a PowerPC 970FX (G5) processor.
[Sep 30 19:29:36 UTC] OGR-P2: using core #0 (KOGE 2.0 Scalar).
[Sep 30 19:29:55 UTC] OGR-P2: Benchmark for core #0 (KOGE 2.0 Scalar)
0.00:00:16.17 [29,161,117 nodes/sec]
[Sep 30 19:29:55 UTC] OGR-P2: using core #1 (KOGE 2.0 Hybrid).
[Sep 30 19:30:14 UTC] OGR-P2: Benchmark for core #1 (KOGE 2.0 Hybrid)
0.00:00:16.18 [41,977,049 nodes/sec]

Et c'est bien sûr à multiplier par 2 ...
Sans affolement des ventilos. Mais les CPU passent quand même à 80 °C

Ce message a été modifié par Mfx - 13 Oct 2004, 17:02.

[Bac's]

Il marche pas mal !

Mais tu bosses pour le projet OGR, pas pour RC5-72 !

[g4hd]

Y a t'il moyen de définir le nombre de blocs à charger ?....

oui, ça fait partie des options qui sont enregistrées en dnetc.ini : exemple ci-dessous pour 1000 blocs.
Comme te le signale Bac's, tu ne fournis pas pour le team MacBidouille pour l'instant : tu dois déclarer dans ton choix pour RC5-72 et d'autres paramètres :
Exemple dans dnetc.ini, que tu peux éditer avec textedit :
[parameters]
id=tonnom@tonadresse

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

[rc5-72]
fetch-workunit-threshold=1000

[display]
progress-indicator=auto-sense

Autre chose : dans ton message précédent tu as copié-collé ton adresse mail : évite ceci sur un forum
Tu peux éditer ton post pour l'effacer.

[patpan]

Y a t'il moyen de définir le nombre de blocs à charger ?....

oui, ça fait partie des options qui sont enregistrées en dnetc.ini : exemple ci-dessous pour 1000 blocs.
Comme te le signale Bac's, tu ne fournis pas pour le team MacBidouille pour l'instant : tu dois déclarer dans ton choix pour RC5-72 et d'autres paramètres :
Exemple dans dnetc.ini, que tu peux éditer avec textedit :
[parameters]
id=tonnom@tonadresse

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

[rc5-72]
fetch-workunit-threshold=1000

[display]
progress-indicator=auto-sense

[right][snapback]867992[/snapback][/right]

Bonjour,

Je participe à RC5-72 pour Le Pommier MacBidouille

je ne suis pas certain de : fetch-workunit-threshold=1000 , pour 1000 stats units, car c'est à priori en heures que le calcul est fait; il varie en fonction des différentes vitesses de calcul des blocs précédemment expédiés!

Pour ce qui me concerne, si je veux charger à "bloc" mon buff -in.r72, une valeur maximale de 14 jours exprimée en heures de calcul ( 336 ) est retenue ( j'en prend quand même 8800 ) .

Voilà, c'est à se faire confirmer, mais je ne pense pas me tromper.

Dernière chose: il faut un éditeur pour modifier les paramètres ( Terminal, BBedit, SubEthaEdit.... )
et non TextEdit. Avec eux, c'est réalisé à la volée. - on voit cette activité dans Terminal, ouvert après le cd "espace" adéquat-


@ +

[g4hd]

... il faut un éditeur pour modifier les paramètres ( Terminal, BBedit, SubEthaEdit.... )
et non TextEdit. Avec eux, c'est réalisé à la volée. - on voit cette activité dans Terminal, ouvert après le cd "espace" adéquat-
[right][snapback]868078[/snapback][/right]

Bah, non.
avec "afficher le contenu du paquet", puis je sélectionne le fichier dnetc.ini et je le modifie/réenregistre avec Textedit.
No problem.

[patpan]

... il faut un éditeur pour modifier les paramètres ( Terminal, BBedit, SubEthaEdit.... )
et non TextEdit. Avec eux, c'est réalisé à la volée. - on voit cette activité dans Terminal, ouvert après le cd "espace" adéquat-
[right][snapback]868078[/snapback][/right]

Bah, non.
avec "afficher le contenu du paquet", puis je sélectionne le fichier dnetc.ini et je le modifie/réenregistre avec Textedit.
No problem.
[right][snapback]868154[/snapback][/right]

OK, chez moi cela ne fonctionne pas avec TextEdit!

[Bac's]

Il faut juste faire attention au format de fichier que tu utilises pour enregistrer tes travaux.

Utilise du texte seul et même ce bon vieux TextEdit fera l'affaire.

[Mathiasr]

Utilise du texte seul et même ce bon vieux TextEdit fera l'affaire.

Hum... vi dnetc.ini (bien plus vieux)
Si vous ne savez pas où se trouve le fichier de configuration dnetc.ini essayez:
locate dnetc.ini
Sinon si vous voulez modifier les paramètres plus proprement utilisez plutôt :
./dnetc -config

[nektarfl]

La semaine prochaine (samedi pour être précis), je vais libérer un nombre de blocks calculés par le PC depuis le 30 aout(~5200), plus ceux du emac depuis 15 jours (~1900) accompagnés de ceux calculés par mon imac A partir d'aujourd'hui (~1500). (Aujourd'hui, envoi de 1889 blocks)
A bientôt

Edit: remise à jour de la quantité de blocks du PC (aujourd'hui 11/10/04:4800)

Ce message a été modifié par nektarfl - 11 Oct 2004, 11:35.

[benjix1er]

Bonjour,

Je vient d'installée le client sur mon nouvelle iMac G5 or il n'arrive pas à récupérer les packets à calculés.

Le client me dit : "Network update is currently not available."

Bien sur ma connexion internet est fonctionnel

merci d'avance.

[Mfx]

De retour après quelques jours de vacances ... Plusieurs réponses :

Je calcule volontairement sur le projet OGR ... et bien sûr pour la team macbidouille
Nous sommes passés depuis peu à la 82ème place mondiale, en gagnant pas mal de places depuis le passage à la phase 2 du projet OGR.

Le fetch-workunit-threshold ne fonctionne apparemment pas sur le projet OGR. J'ai essayé de le mettre dans une section [OGR], puis dans une section [OGR-P2] du fichier .ini, mais je ne charge toujours que 46 paquets, je ne sais pas pourquoi ... Si kakace traine par ici un de ces jours, on aura peut-être le fin mot de l'histoire

Et merci pour la remarque sur l'email dans mon message, je n'avais pas bien relu avant de l'evoyer

[benja]

Merci les gars... grace à ce post, j'ai enfin compris comment s'inscrire dans une équipe... C'est donc avec plaisir que mon G4 se joint à vous... Hein mon joli ?...

Ce message a été modifié par benja - 13 Oct 2004, 17:24.

[kakace]

Le fetch-workunit-threshold ne fonctionne apparemment pas sur le projet OGR. J'ai essayé de le mettre dans une section [OGR], puis dans une section [OGR-P2] du fichier .ini, mais je ne charge toujours que 46 paquets, je ne sais pas pourquoi ... Si kakace traine par ici un de ces jours, on aura peut-être le fin mot de l'histoire

Heu... Moi j'ai :

CODE

[ogr_p2]
fetch-workunit-threshold=8

... et ça marche. Ceci dit, j'ai déjà dit plusieurs fois qu'il n'était pas conseillé de modifier le fichier dnetc.ini directement, afin d'éviter ce genre de problèmes (noms des sections, casse, etc)
Taper "dnetc -config" dans un Shell, puis examiner les menus d'un peu plus près n'est pas très compliqué, et c'est surtout beaucoup plus sûr.

[patpan]

Le fetch-workunit-threshold ne fonctionne apparemment pas sur le projet OGR. J'ai essayé de le mettre dans une section [OGR], puis dans une section [OGR-P2] du fichier .ini, mais je ne charge toujours que 46 paquets, je ne sais pas pourquoi ... Si kakace traine par ici un de ces jours, on aura peut-être le fin mot de l'histoire

Heu... Moi j'ai :

CODE

[ogr_p2]
fetch-workunit-threshold=8

... et ça marche. Ceci dit, j'ai déjà dit plusieurs fois qu'il n'était pas conseillé de modifier le fichier dnetc.ini directement, afin d'éviter ce genre de problèmes (noms des sections, casse, etc)
Taper "dnetc -config" dans un Shell, puis examiner les menus d'un peu plus près n'est pas très compliqué, et c'est surtout beaucoup plus sûr.
[right][snapback]881048[/snapback][/right]

Bonsoir,

Merci de confirmer ce que j'ai écrit dans mon post du 02/10, 14.22 dans ce forum:

"Dernière chose: il faut un éditeur pour modifier les paramètres ( Terminal, BBedit, SubEthaEdit..)"

Terminal permet d'accéder à tous les paramètres, et respecte ceux qui ne sont pas modifiés.

[Mfx]

... et ça marche. Ceci dit, j'ai déjà dit plusieurs fois qu'il n'était pas conseillé de modifier le fichier dnetc.ini directement, afin d'éviter ce genre de problèmes (noms des sections, casse, etc) 
Taper "dnetc -config" dans un Shell, puis examiner les menus d'un peu plus près n'est pas très compliqué, et c'est surtout beaucoup plus sûr.

J'ai essayé pour de vrai la méthode du "dnetc -config" ... mais je dois être obtus, car je n'ai jamais trouvé comment définir ce nombre de blocs
La modif 'manuelle' était bien sûr un pis-aller, je le reconnais.
Cela dit, j'ai testé [ogr_p2], et la connexon est alors refusée ...
Avec [ogr-p2], la connexion est acceptée, mais le serveur me répond que mes buffers sont full (j'ai 46 blocs en buffer in).
En attendant mieux, je vais continuer à faire des -fetch ou des -update de temps en temps

Merci quand même pour la réponse, et en route pour le top 50 ...

[kakace]

J'ai essayé pour de vrai la méthode du "dnetc -config" ... mais je dois être obtus, car je n'ai jamais trouvé comment définir ce nombre de blocs

Option " 2) Buffer and Buffer Update Options", puis "12) Fetch work threshold ==> RC5-72=20,OGR-P2=8"
NOTE: Se fier au texte des options plutôt qu'aux numéros : la numérotation peut changer suivant les réglages effectués (insertion d'options supplémentaires).

La modif 'manuelle' était bien sûr un pis-aller, je le reconnais.
Cela dit, j'ai testé [ogr_p2], et la connexon est alors refusée ...
Avec [ogr-p2], la connexion est acceptée, mais le serveur me répond que mes buffers sont full (j'ai 46 blocs en buffer in).
En attendant mieux, je vais continuer à faire des -fetch ou des -update de temps en temps

Le copier/coller n'ayant pas pu se tromper, il s'agit bien de la section "[ogr_p2]". Partant de là, le dysfonctionnement signalé est incompréhensible. Soit le fichier dnetc.ini est foireux, soit il y a des problèmes d'accès au réseau, des problèmes d'accès au buffer (partagé avec d'autres clients, problèmes de droits, etc), l'utilisation d'un proxy non compatible, une machine trop lente (puisque le nombre de paquets maximum est limité par la puissance théorique de la machine hôte), un client qui n'est pas "à jour", ou encore un bug (auquel cas, je manque d'infos).

A défaut d'ouvrir un bug-report en bonne et due forme, il est toujours possible de me mailer le maximum d'infos (notament les logs) -> kakace(at)distributed.net

[Mfx]

Option " 2) Buffer and Buffer Update Options", puis "12) Fetch work threshold ==> RC5-72=20,OGR-P2=8"
NOTE: Se fier au texte des options plutôt qu'aux numéros : la numérotation peut changer suivant les réglages effectués (insertion d'options supplémentaires).

Ok, ok, ça doit être ma faute ...
J'ai dû recopier le dnetc.ini d'une version précédente, par flemme, et l'option 2 ne m'affichait que 7 sous-options ... et donc pas la 12

un petit coup de "mv dnetc.ini dnetc.ini.old", et on repart sur de meilleures bases

Désolé de t'avoir fait perdre ton temps sur des bétises pareilles, au lieu de te laisser bosser sur le core G5

Amitiés.

[ctrl_alt_suppr]

OUIIIIN !

Mes paquets se perdent, ça fait une semaine que j'ai plus aucun paquet indiqué sur ma page de stat ! Mais quest-ce qui ce passe-t-y donc ? Mes réglages sont pourtant corrects (inchangés depuis au moins trois mois) et mon ordi taffe comme un fou 24H/24, je comprend pas !

Please… help !