Folding : le topic

[Bull45]

Tu occupes touts tes core ? C'est zarbi

[OlivierZ]

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

[Bull45]

Vérifie quand même que tu as ces ligne dans tes fichers de config des VM (.wmx)

 

priority.grabbed = "idle"

priority.ungrabbed = "idle"

évidement il faut relancer pour apliquer, moi je suspend la VM quand je quite le player pour redémarer sec là ou il s'est interompu dans VM Player / préférences/ Suspend the virtual machine, ça évite de devoir toujours taper les commandes dans le terminal.

 

Edit: Pas la suspention de linux je clique sur le pause du serveur VM Ware ou je clique sur la croix du player

Modifié le 29 août 2009 par Bull45

[Cobra]

C'est vraiment bizarre ce qui arrive à Olivier.

 

En attendant de réfléchir à une solution, je mets ce lien à tout hasard : http://process-manager.forumpro.fr/forum.htm

[Bull45]

Salut à tous

 

Oui c'est étrange, chez moi Bill's n'a jamais planté

 

Edit: Je sais que linux tire plus sur le Vcore, mais ça n'a en principe pas d'impact sur le GPU

Modifié le 29 août 2009 par Bull45

[OlivierZ]

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.

Modifié le 29 août 2009 par OlivierZ

[Cobra]

Je viens de m'apercevoir que la différence entre toi et moi c'est le type de client GPU installé. Tu as systray et j'ai console. Il y a peut-être un réglage incompatible kekpart ?

 

Tu ne voudrais pas passer en console, pour voir ?

[OlivierZ]

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

[Cobra]

Il vaut toujours mieux laisser le client terminer et envoyer la wu en cours.

[R_34]

On peut également mettre le client console en pause si on le coupe puis le relance.