OlivierZ

Salut DK, J'espère que tu vas bien Les dernières pages sont très axées machines virtuelles ("VM") linux sous windows, et problèmes de wu défectueuses envoyées par stanford (surtout liées aux fameuses machines virtuelles), et un peu Windows 7. Donc c'est normal que cela ne soit pas très clair si tu n'as pas regardé de près ces sujets, constitué ton glossaire (ça jargonne bien !), fais tes révisions, etc. Tes interventions piquantes nous manquent !

Je me demande si bill2 process manager est vraiment utile sous win7 (je n'ai pas envie de désactiver complètement l'uac). Le scheduler de win7 est censé être la dernière merveille du monde, n'est-il pas ? Je teste depuis 1/2h et ça tourne bien sans bill2. De plus, dans win 7, si je règle l'affinité des fahcore sur toutes les cpu, je peux enfin positionner une priorité temps réel sur les fahcore, alors que bill2 ne me le permet pas 9 fois sur 10 (strange, isn't it ?). Bull, as-tu fait des essais de ton côté ?

Tu as raison mais dans le passé j'ai déjà fait des erreurs en oubliant justement le advconfig, ou en recréant une vm, ou une smp win, à zéro et oubliant le big. Bref, des trucs qui ne se produisent pas tous les jours mais qui m'agaçaient. Mais je ne voue pas de haine féroce au configonly

Je dénonce cette vile accusation ! Par "erreur", je visais un simple problème de paramétrage comme oublier de sélectionner "big", ou le flag smp. Des bêtises, donc. Pour l'éditer, j'utilise ultraedit et je ne convertis pas le fichier en txt-ms dos. Jusque là, pas de problème.

Salut à tous, La révolte gronde ! Pour ma part, je ne me plains pas encore trop : 1 défectueuse hier (et une l'autre jour quand j'avais posté sur le sujet). Hier c'était sur une VMplayer et on ne voit rien ! J'ai failli faire comme cobra et revenir à VMServer. Mais trop flemmard, j'ai juste viré tous les fichiers de la VM en question et recommencé. Et comme l'autre fois, j'ai récupéré une wu fonctionnelle. Mais je pense que je m'agacerais pour le moins si je récupérais 5 fois de suite une wu défectueuse ! Et je m'aperçois en lisant les posts que je n'ai pas eu une approche développement durable en laissant traîner un déchet de wu dans la nature, pas glop ... Pour info, quand je recrée une wu sous vmserver, je ne refais pas le configonly : je récupère un client.cfg que j'édite directement : je trouve ça plus rapide et avec moins de risque d'erreur.

En testant sur le quad, cela vient en fait de la priorité : si priorité = temps réel, alors conso cpu apparente = 0 (sauf début/fin wu) sinon conso variable (1 à 5% hors changement de wu). Edit : pas vraiment confirmé sous win7 (cpu monte à plus de 40%, et reste élevée même en priorité haute)... Bonne nuit !

Ajouté les lignes. Je verrai demain les résultats. Pour fahmon, effectivement, il se calme après 3%. Je ne touche pas ce soir à l'uac ; on verra plus tard si la priorité normale pose un problème. Merci des infos. Reste la conso cpu des fahcore en mode console (1 à 2% au lieu de 0% en mode systray/win XP, sauf en fin/début de wu). Lié à win7/64 vs xp ou à console vs systray ?

Pour NOD32, il y a effectivement incompatibilité avec les v3.x : il faut désactiver nod32. En v4.x, il paraît qu'il n'y a plus de problème. Suite de mon test Win7/64 + VMPlayer : J'ai chargé les clients gpu (en mode console ce coup-ci). Je n'ai pas de dummy plug => connecté l'écran du 2ème PC. Au passage, ça m'a fait planter le pc2... Comme je suis flemmard, j'ai récupéré les work et queue des mes clients systray. Pour un gpu ok, pour l'autre Unstable_machine. 50% de réussite, pas trop mal J'ai chargé une 2ème VM. OK avec baisse perf VM-1 (3000 au lieu de 3700 sur wu à 1920 points). Puis chargement d'une 3ème VM (je n'ai plus que 300 Meg de Ram dispo... joueur !) Les perfs se dégradent sur la VM-1 et la VM2 (les 2 à 2500). Je verrai demain au bout de plusieurs heures. Les affinités ne sont pas gérées (tous les cores). Les fahcore gpu console consomment de la cpu sous win7, ce qui n'est pas le cas en version systray sous win xp. Je ferai peut-être un test en mode systray un autre jour. Bill2 et le process manager de Win7 n'arrivent pas à positionner la priorité des fahcore_xx des gpu à temps réel. Du coup de les ai mises à Normale (sinon Win7 et Bill2 la mette à Haute avec une très légère dégradation des temps de réponse du système pour l'utilisateur). (sur le quad sous win xp, bill2 ne tient pas le temps réel et je dois régulièrement forcer la priorité manuellement). FahMon délire sur une des VM. La suppression du client dans fahmon et recréation ne résoud généralement pas le problème (l'a fait une fois, mais est reparti en rideau au relancement de la VM).

(je viens de perdre ma réponse ; recommence) J'avais choisi nofred pour son côté quasi pré-paramétré (rapidité du test) et la possibilité de cloner les VM (si je dois aller jusqu'à 4 VM, plutôt sympa). Mais c'est vrai qu'on ne voit rien... Pour info, la VM nofred, sans autre client folding ni gpu ni cpu, fait 3700 ppd selon fahmon. Pas mal du tout (en smp win entre 1800 et 2400 pour 2 clients). Pour les VM Linux, je me demande si le réglage mémoire de la VM n'est pas une des causes (en plus des wu défectueuses). Sur un tuto pour les vm nofred, j'ai lu qu'il fallait régler la mémoire à 1024 voire 1152 au lieu de 640 : http://forum.xcpus.com/xtreme-folding-home...e-your-ppd.html D'ailleurs, l'install nofred est maitenant paramétrée par défaut à 1024 au lieu de 640.

Bull, je teste VMPlayer sous windows7/64 avec le core i7 (une seule instance pour le moment vu la faible quantité de RAM du PC). Pour la VM, j'utilise la distro de Notfred. Cela a l'air de marcher car j'ai une occupation cpu 25%. Fahmon débloque à mort : soit es données sont farfelues (mélanges entre les colonnes) soit il marque le process "Hung" alors que le log montre bien l'avancement. Comme tu es sous vmplayer, as-tu eu ce problème et quelle solution ?

Na sdarovje, salud, le chaim DK

Bonjour à tous Bill2 tient. Par flemme, je reste en systray gpu pour le moment. Problème smp linux : 7 heures minimum de perdues sur une VM avec un log bizarre. Extraits : [03:02:36] Sending work to server (...) [03:02:42] + Could not connect to Work Server (results) [03:02:42] - 2 failed uploads of this unit. [03:02:42] Connecting to http://171.67.108.25:8080/ [08:38:55] - Autosending finished units... [August 30 08:38:55 UTC] ; 5 heures sans action/message ?!!! [08:38:55] Trying to send all finished work units [08:38:55] - Already sending work [08:38:55] + Sent 0 of 1 completed units to the server [08:38:55] - Autosend completed [10:14:13] ***** Got an Activate signal (2) ; 2 heures sans action/message ?!!! Je stoppe par Control C [10:14:13] Killing all core threads (je relance, récupère work assignement, réussit à envoyer le résultat, plie normalement). Ces périodes de plusieurs heures sans aucune action ou message sont-elles "courantes" ? Faut-il effectivement stopper/relancer ou y a-t-il une meilleure façon ?

Merci Par précaution, j'ai aussi changé machineid dans client.cfg.

@R_34 : nickel jusqu'à ce qu'une des VM reçoive une WU monocore (ça ne m'est jamais arrivé avec le smp windows). Là, j'ai tout coupé dans Linux pour redémarrer VMServer et les VM. Cela n'a pas plu (ou coïncidence ?) au driver nvidia qui a fait un bsod. Reboot. Je relance tout. Au bout de 5 minutes un des fahcore était tombé à basse priorité... On va voir, mais je suis moins optimiste que tout à l'heure. J'attends encore un peu mais je pense finir par passer au client console pour les gpu. J'ai le driver nvidia 185.85. Les drivers plus récents (j'ai perdu le fil) marchent-ils bien/mieux pour le pliage ? @Bull : merci. Je pense que j'essaierai pour mes tests VM sur l'i7, ce qui sera plus long que le test sur le quad : test VM seule pour diff de perf ; test vista64 par rapport à XP pour mes autres programmes ; achat ram (si je suis motivé !) ; install vista64 et réinstall de mes programmes ; install vmware server ou player, etc. Un peu lourd tout ça...

J'ai supprimé les règles bill2 "temps réel" que j'avais positionnées pour les folding@home (enp lus des règles pour les fahcore_xx). Si la stabilité se confirme, j'étais le seul à avoir le problème car je suis en systray et j'avais ajouté ces règles (bad, bad idea !). Bull, quelle différence pour le pliage entre les deux versions ?

P'tit point de situation : bill2 tient toujours et je suis encore en client systray pour les gpu. Je garde les doigts croisés

En effet. Je vais essayer (mais probablement en fin de journée). Question mineure : je perdrai les travaux en cours ou pourrai-je récupérer le queue.dat et le répertoire work ? J'ai identifié une 2ème différence mais je pense qu'elle n'est pas significative : j'avais aussi mis une règle temps réel sur le process folding@home des gpu. Je viens de la supprimer au cas où. Je vais m'absenter quelques heures et verrai à mon retour si le problème s'est reproduit. Alors je passera en client console. (j'aimais bien le systray car il permet de mettre le traitement en pause).

Bonjour à tous, Merci pour l'aide. Je vais aller voir le forum de bill2. Eh bien ce matin, un des fahcore était retombé à Basse priorité. C'est ulcérant. Pour résumer le pb : 1) Contexte * windows xp pro sp3 * 2 VM * 2 clients gpu systray (gtx260) * bill2 paramétré comme suit : Règles process : fahcore_xx (11, 13, 14) priorité temps réel. Pas de réglage des affinités. Par défaut je pense que bill2 équilibre sur tous les cores car les 4 cpu sont cochés en grisé. Les fahcore sont désignés par le nom uniquement, sans chemin complet. Pas de règle pour les VM (j'ai testé avec une règle Basse priorité, sans différence pour mon pb). Options (globales) Bill2 : * vérification et application des règles toutes les 10 minutes. * exception sur la priorité automatique (baisse auto niveau de priorité si occupation cpu >50% pendant >10 secondes) : les fahcore_xx (pas de chemin complet). Rem : fahcore désigne ici uniquement les process gpu (les process smp étant dans les VM, bill2 ne les voit pas directement). 2) Problème Bill2 ne maintient pas la priorité temps réel sur un ou les 2 fahcore : passage en Basse priorité. Et pas de remontée en priorité temps réel. Contexte de survenance du problème : j'ai l'impression que cela se produit quand il y a un pic de conso cpu (mais bien inférieur au seuil de 90%) sur un fahcore. J'ai vu le cas se produire 2 ou 3 fois avec des conso cpu de 10 à 20% sur le fahcore en question (observé sur le 11 et le 14). En revanche, si pas de pic, la priorité reste bien à temps réel, même en cas de changement de wu : bulle message indiquant que la règle bill2 de priorité temps réel est bien appliquée. --edit : je pense qu'il y a en fait toujours pic de conso cpu à la finalisation et au redémarrage de traitement de wu. Ce qui voudrait dire que la survenance du probleme est aussi liée à un autre facteur, non identifié. J'ai en ce moment un fahcore_11 qui tire sur la cpu (entre 4 et 20% de conso cpu (fin de traitement wu). Pour l'instant bill2 tient et a même généré la bulle d'application de la règle. Donc le problème ne survient pas sytématiquement en pic de conso cpu d'un fahcore. Argh, bill2 vient de passer le fahcore en question en basse priorité... Je force manuellement la priorité temps réel.

Oui, tous les cores cpu sont occupés (pas de réglage d'affinité dans bill2 ; en grisé, les 4 cpu sont cochés sur tous les process fahcore des gpu et sur les VM). Je n'ai pas d'idée là. Je vais laisser passer la nuit et espérer que le problème ne se reproduise pas...

Non pas d'éco d'energie. Là ça tient depuis quelques temps. C'est vraiment bizarre. J'espère que le problème disparaîtra (ou que je trouverai une solution) car sinon je devrai revenir au smp win : la baisse de perf gpu est supérieure au gain linux smp Merci de ton aide.

Mais j'ai déjà créé les règles ! ça marche bien au démarrage mais pas dans la durée... Si j'arrête Bill2 et le relance, ça marche de nouveau, mais ne tient pas. Le problème se produit quand il y a un pic de conso cpu par les cores gpu. Bill2 force à priorité basse sans tenir compte des règles et ne les réapplique pas ensuite. En revanche si pas de pic cpu, marche bien y compris au changement de wu (bulle message indiquant que la règle priorité temps réel est appliquée). Le paramétrage d'exceptions pour les fahcore à la priorité auto de bill2 ne résoud pas le problème.

Après les aliens, je reviens bassement sur les priorités des cores (c'est sûr, ça fait moins dark vador en jupette égyptienne, n'est-il pas ? ). Bill2 n'arrive pas à maintenir la priorité temps réel sur les cores gpu. Retombe à "basse" au bout de quelques heures. Je n'ai pas réglé les affinités dans bill2, mais je ne vois pas de lien avec les priorités (me trompé-je ?). Même lors des changements de cores (fahcore11 -> fahcore 14 par exemple), le nouveau core retombe à priorité basse... :P Tous les cores ont pourtant une règle à priorité temps réel, sans lien chemin complet. Si quelqu'un a une idée de solution, je suis preneur. Edit : je teste le paramétrage d'une exception pour les fahcore_xx à la priorité automatique dans les options de bill2 (bouton Options, Priorité automatique, Liste des exceptions). On va voir si ça marche (mais bizarre que ni Cobra ni Bull n'aient eu le même problème que moi). Edit2: Argh, ne marche pas. L'un des deux cores vient de tomber à priorité basse...

C'est le premier point que je n'avais pas compris : que smpaffinity était "esclave" de bill2. Merci pour les explications

yep mais bill2 ne va-t-il pas modifier le réglage fait par smpaffinity ?

De retour, les 2 fahcore_11 étaient en priorité basse avec pourtant chacun une règle "temps réel". Grrr... J'ai fait comme le conseille Bull pour les priorités j'ai décoché le chemin complet. J'ai coupé Bill2 et l'ai redémarré. Les core se sont bien mis à temps réel (pour combien de temps ?). Pour les affinités, je n'ai pas les mêmes valeurs par défaut que bull : en grisé, les 4 cores sont cochés (sur tous les programmes : fahcore, vmware, etc.). Bizarre qu'on n'ait pas tous la même chose. Et c'est sur le quad, pas le core i7. Je laisse la définition d'affinité désactivée pour le moment. Edit : Bull, je vois dans ta copie d'écran que tu as à la fois Bill2 et fahsmpaffinitychanger : ils ne sont pas redondants ? Pas de conflit ?