Comme il a été précisé dans la partie précédente, nous allons partir du principe que l'ordinateur est parfaitement stable, que le choix du client FAH est en adéquation aux spécificités de la machine, qu'aucun anti-virus ne vient perturber le client, que la connexion à internet est bien activée et en bon état de fonctionnement, que les serveurs FAH acceptent bien les résultats et attribuent correctement les WU à traiter.

Les bugs peuvent être quelque peu différents et aussi plus ou moins fréquents d'un client à l'autre. Je ne vais pas détailler client par client mais, à travers quelques exemples, fournir un minimum d'explication et donner la solution habituelle pour se sortir d'un mauvais pas.

1 - EARLY_UNIT_END (arrêt prématuré des calculs) dès le commencement de la simulation

[19:55:32] Assembly optimizations on if available.
[19:55:32] Entering M.D.
[19:55:38] Working on p3863_fkbprelative_ligand
[19:55:38] Completed 0 out of 1500000 steps  (0%)
[19:55:38] Extra SSE2 boost OK
[19:56:09] mdrun returned -1
[19:56:09] Going to send back what have done.
[19:56:09] logfile size: 29716
[19:56:09] - Writing 30254 bytes of core data to disk...
[19:56:09] Done: 29742 -> 3834 (compressed to 12.8 percent)
[19:56:09]   ... Done.
[19:56:09]
[19:56:09] Folding@home Core Shutdown: EARLY_UNIT_END

Il s'agit en général d'une unité comportant une erreur.

Normalement, le client, dans les dernières versions 6, doit être à même de poursuivre sans intervention extérieure, c'est-à-dire, après éventuellement quelques essais infructueux, informer le serveur qui a attribué l'unité par un "Attempting to send results", puis télécharger une nouvelle unité, mais il se peut que la procédure automatique ne s'enclenche pas.

Pour résoudre le problème, on ouvre le fichier folding concerné et on supprime les deux fichiers "work" et "queue", puis on relance le client en le reconfigurant avec un n° ID Machine différent.

2 - En pleine simulation, le calcul s'interrompt avec la mention EARLY_UNIT_END ou autres...

[18:02:36] Folding@home Core Shutdown: EARLY_UNIT_END

Comme pour précédemment, le client aurait dû poursuivre. Il y a lieu d'utiliser la même procédure. L'unité en cours est perdue mais il n'y a pas d'autre solution pour faire redémarrer le client dans de bonne condition.

3 - Le calcul s'est arrêté en plein cours de la simulation et semble figé

[21:28:09] Completed 90000 out of 250000 steps  (36%)
[21:33:14] Completed 92500 out of 250000 steps  (37%)
[21:38:18] Completed 95000 out of 250000 steps  (38%)
[02:37:16] - Autosending finished units... [July 11 02:37:16 UTC]
[02:37:16] Trying to send all finished work units
[02:37:16] + No unsent completed units remaining.
[02:37:16] - Autosend completed

Normalement, après un certain délai de non activité, le client constate une erreur et termine par une EARLY_UNIT_END (arrêt prématuré des calculs) ou tout autre mention. Si vous vous en apercevez avant cette fin fatale, ou si le couperet n'est pas tombé, vous avez une chance de ne pas perdre la WU en cours, en arrêtant le client proprement et en le relançant, tout simplement.

4 - Le calcul s'interrompt successivement sur une erreur pratiquement au même pourcentage

[18:54:39] Completed 30000 out of 500000 steps  (6%)
[19:25:38] Writing local files
[19:25:38] Completed 35000 out of 500000 steps  (7%)
[19:45:27]
[19:45:27] Folding@home Core Shutdown: UNKNOWN_ERROR
[19:45:31] CoreStatus = 77 (119)
[19:45:31] Client-core communications error: ERROR 0x77
[19:45:31] This is a sign of more serious problems, shutting down.
[22:21:48] - Autosending finished units... [May 27 22:21:48 UTC]
..........
[06:55:22] Completed 30000 out of 500000 steps  (6%)
[07:26:20] Writing local files
[07:26:20] Completed 35000 out of 500000 steps  (7%)
[07:46:08]
[07:46:08] Folding@home Core Shutdown: UNKNOWN_ERROR
[07:46:10] CoreStatus = 77 (119)
[07:46:10] Client-core communications error: ERROR 0x77
[07:46:10] This is a sign of more serious problems, shutting down.
[10:24:40] - Autosending finished units... [May 28 10:24:40 UTC]

Il s'agit d'une unité comportant une erreur ou bien la simulation n'a pas trouvé le chemin pour poursuivre les calculs et de ce fait les calculs se sont arrêtés. Normalement encore, le client doit gérer ce genre de situation. Après trois (chiffre variable) tentatives infructueuses, le client informe Stanford pour que cette unité soit retirée et télécharge une autre unité. Mais si pour une raison quelconque, cette procédure automatique ne fonctionne pas, vous pouvez fermer le client, ouvrir le fichier folding en question et supprimer les fichiers "work" et "queue", puis relancer le client en le reconfigurant avec un n° ID Machine différent. A la relance du client, une autre unité sera téléchargée.

5 - Le client a fini ses calculs mais bloque au moment d'envoyer les résultats

[05:53:33] - Couldn't send HTTP request to server
[05:53:33] + Could not connect to Work Server (results)
[05:53:33]     (171.64.65.56:80)
[05:53:33] - Error: Could not transmit unit 02 (completed August 12) to work server.
[05:53:33] - 2 failed uploads of this unit.
[05:53:33] + Attempting to send results [August 12 05:53:33 UTC]
[05:53:33] - Reading file work/wuresults_02.dat from core
[05:53:33]   (Read 48691482 bytes from disk)
[05:53:33] Connecting to http://171.67.108.25:8080/
[09:52:31] ***** Got an Activate signal (2)
[09:52:31] Killing all core threads

Dans cet exemple précis, le serveur était en panne mais le client aurait dû relancer périodiquement et non calé. Un arrêt et une relance manuels ont été nécessaires. Pendant que les résultats en attente sont envoyés, une autre unité est automatiquement téléchargée.

6 - Le client a fini ses calculs, envoyé ses résultats mais ne continue plus la suite de la procédure

On arrête le client, on le relance et la procédure de téléchargement d'une unité démarre.

7 - Le client ne veut plus envoyer les résultats, les garde dans la file d'attente et poursuit cependant le téléchargement et le calcul d'autres unités

[08:02:30] + Attempting to send results [July 23 08:02:30 UTC]
[08:02:30] - Reading file work/wuresults_00.dat from core
[08:02:30]   (Read 48672823 bytes from disk)
[08:02:30] Connecting to http://171.67.108.24:8080/
[08:32:23] - Autosending finished units... [July 23 08:32:23 UTC]
[08:32:23] Trying to send all finished work units
[08:32:23] - Already sending work
[08:32:23] - Already sending work
[08:32:23] + Sent 0 of 2 completed units to the server

On arrête le client et on relance. Si la procédure d'envoi ne démarre pas, arrêtez à nouveau le client et forcez l'envoi manuel avec le paramètre -send all (voir les paramètres).

8 - Le client affiche un "pausing 24 hours"

[03:08:01] mdrun_gpu returned
[03:08:01] NANs detected on GPU
[03:08:01]
[03:08:01] Folding@home Core Shutdown: UNSTABLE_MACHINE
[03:08:04] CoreStatus = 7A (122)
[03:08:04] Sending work to server
[03:08:04] Project: 5771 (Run 1, Clone 112, Gen 955)
[03:08:04] - Read packet limit of 540015616... Set to 524286976.
[03:08:04] - Error: Could not get length of results file work/wuresults_08.dat
[03:08:04] - Error: Could not read unit 08 file. Removing from queue.
[03:08:04] EUE limit exceeded. Pausing 24 hours.
[06:42:26] ***** Got a SIGTERM signal (2)
[06:42:26] Killing all core threads

Le programme prévoit qu'après un certain nombre d'incidents (EUE, UM...) successifs, le client se met délibérément en pause, cela afin de ne pas puiser inutilement dans le stock de WU disponibles sur les serveurs, et de permettre au donateur de vérifier la stabilité de son matériel, ce qui nécessite une intervention manuelle. Avant de suivre la procédure décrite en (1), il y a lieu de bien vérifier qu'il ne s'agit pas avant tout d'un problème matériel (ram, processeur, carte graphique). De toute façon, si ce "pausing" se reproduit, pour différentes WU, il ne pourra alors s'agir que d'une défaillance matérielle qu'il y a lieu de régler.

Dans l'exemple cité, le client GPU s'est mis en pause après trois erreurs successives au lancement du calcul de la même WU. Après vérification auprès de Stanford, il s'est avéré qu'il s'agissait d'une "broken WU", une WU "foireuse" quoi.


Cette liste n'est pas exhaustive, on peut être confronté à bien d'autres types de bugs. Mais en définitive, nous avons deux armes imparables :

- le paramètre -send all pour forcer un envoi récalcitrant.
- la suppression des fichiers "work" et "queue" avec changement de n° ID Machine pour une erreur de calcul quelle qu'elle soit.

Nous pouvons aussi imaginer que le Fahcore est corrompu ou qu'il y a lieu de forcer son update. Dans ce cas, il y a lieu de supprimer le fichier et de relancer le client. Si une unité est en cours de traitement, il est préférable d'attendre la fin des calculs et l'envoi des résultats, afin d'éviter la perte éventuelle de l'unité.

On peut aussi envisager de désinstaller le client (si un installateur a été nécessaire) ou supprimer carrément le dossier du client (là où un installateur n'a pas été utilisé).

Et si, malgré cela, les "bugs" persistent, voyez plutôt du côté des "faux bugs" potentiels de la page précédente !

Et vous pouvez faire part de votre problème sur le forum support (Anglais) ou tout simplement sur votre propre forum ou celui de l'Alliance Francophone.


Les "faux bugs" de la page précédente