La pierre angulaire du projet Folding@home est le calcul distribué, ce qui sous-entend une communication clients-serveurs la plus efficace possible. Malheureusement, comme en toute chose, le zéro défaut n'existe pas.

Nous allons partir du principe que votre connexion internet est bien activée, que votre FAI n'est pas en maintenance et que vous payez vos factures régulièrement, qu'aucun firewall ne bloque la connexion et que votre client est bien configuré comme précisé dans les tutos d'installation des clients FAH. Dans tous les cas, ayez toujours le paramètre -verbosity 9 dans votre configuration. Ce paramètre permet d'afficher le maximum d'informations disponibles dans le FAHlog et ainsi vous aider à mieux comprendre ce qui se passe.

...et que votre bureau ne ressemble pas à ça


Si votre client a l'habitude de bien retourner ses résultats, récupérer de nouvelles unités à traiter mais qu'il lui arrive tout à coup de ne plus pouvoir communiquer avec les serveurs de Stanford, il n'y a jamais lieu de s'affoler. Le serveur concerné par votre client peut être encombré ou indisponible momentanément ou tout simplement en panne. Mais ça dure rarement longtemps. Si vous vous dites que ça va faire baisser votre production... de science, dites-vous bien que tout le monde est en définitive dans la même galère le même bateau.

Le premier réflexe doit être de questionner le serveur concerné en recopiant son url dans l'adresse de votre navigateur Web. Cette url se trouve dans le FAHlog. S'il s'agit d'une tentative d'upload qui n'aboutit pas, l'url du serveur à l'origine de la WU ou du "Collection Server" est affichée dans les dernières lignes. S'il s'agit d'une tentative de download d'une WU, regardez dans le FAHlog là où votre client a l'habitude de renvoyer ses résultats ! Si la réponse renvoyée par le navigateur est "OK", il n'y a rien d'autre à faire que patienter, le temps que l'encombrement se résorbe ou que Stanford corrige un petit soucis. Si votre navigateur n'obtient pas de réponse, le serveur a sans doute un plus grave problème. Et il n'y a rien d'autre à faire que patienter également Mais vous pouvez, dans tous les cas, consulter l'état des serveurs FAH. Pour une bonne compréhension de ce grand tableau lisez ces explications !

Selon les clients, le temps d'attente entre deux tentatives d'upload ou de download augmente de plus en plus au fur et à mesure des échecs.. Au bout d'une dizaine d'essais, près de deux heures se sont éventuellement déjà écoulées et vous commencez à vous impatienter. Vous pouvez alors arrêter votre client et le relancer. Cette procédure vous apporte deux avantages. D'une part, le délai d'attente entre deux tentatives de communication redémarre au début, c'est-à-dire de quelques minutes à plusieurs dizaines de minutes, et d'autre part vous aurez peut-être la chance de réussir à capturer une nouvelle WU et commencer illico le processus de traitement. Sans compter que vous pouvez avoir en prime la chance de passer au travers de l'embouteillage et réussir à renvoyer votre WU en souffrance. Le soucis, c'est que si rien de tout ça ne fonctionne, vous participez à l'aggravation de l'encombrement avec les tentatives de communications plus rapprochées inutiles.

Lorsqu'il s'agit du problème particulier de download avec redirection vers le serveur 0.0.0.0, il s'agit d'une sorte de voie de garage transitoire car le serveur d'attribution de WU correspondant à la configuration de votre client est en rupture de stock. Il y a lieu d'attendre qu'il soit à nouveau approvisionné. Vous pouvez également avoir la mention "No appropriate work server was available" comme ci-après :

[19:24:58] + Attempting to get work packet
[19:24:58] - Will indicate memory of 2047 MB
[19:24:58] - Connecting to assignment server
[19:24:58] Connecting to http://assign.stanford.edu:8080/
[19:25:01] Posted data.
[19:25:01] Initial: 0000; + No appropriate work server was available; will try again in a bit.
[19:25:01] + Couldn't get work instructions.
[19:25:01] - Attempt #11  to get work failed, and no other work to do.

Cela signifie qu'aucun serveur correspondant à la configuration de votre client n'est disponible.  Il s'agit également de patienter.

Mais si vous êtes pressé, vous pouvez essayer de modifier la configuration du client afin qu'il soit éventuellement orienté vers un autre serveur. Modifiez la configuration de l'option : small/normal/big. Vous pouvez aussi modifier la réponse au paramètre -advmethods (yes/no). Mais attention, contrairement à ce qui est communément admis, il n'y a pas lieu de régresser dans le paramétrage du client, c'est-à-dire par exemple abandonner l'Advmethods ou quitter le "big" pour "small/normal". Il vaut mieux draguer le plus large possible, avec "big" et l'Advmethods, car qui peut le plus peut le moins. c'est-à-dire que si on a mis "Big" et Advmethods, on obtient les "Big" et les unités expérimentales, s'il y en a, sinon on est orienté vers les unités standards.

Un upload apparemment réussi pourrait vous inquiéter car vous n'avez pas été remercié :

[16:41:04] - Error: Could not transmit unit 09 (completed July 11) to work server.
[16:41:04] - 7 failed uploads of this unit.
[16:41:04] - Read packet limit of 540015616... Set to 524286976.
[16:41:04] + Attempting to send results [July 11 16:41:04 UTC]
[16:41:04] - Reading file work/wuresults_09.dat from core
[16:41:04]   (Read 99775 bytes from disk)
[16:41:04] Connecting to http://171.67.108.25:8080/
[16:41:07] Posted data.
[16:41:07] Initial: 0000; - Uploaded at ~32 kB/s
[16:41:07] - Averaged speed for that direction ~28 kB/s
[16:41:07] - Server does not have record of this unit. Will try again later.
[16:41:07]   Could not transmit unit 09 to Collection server; keeping in queue.
[16:41:07] + Sent 0 of 1 completed units to the server

Le débit de 32 kB/s signifie en effet que la WU est bien partie et pourtant Stanford annonce que le serveur n'a pas enregistré l'unité qui reste donc dans la file d'attente sur votre ordinateur. Cela vient du fait que le serveur à l'origine de l'attibution de la WU n'a pas eu le temps, avant de cesser de fonctionner, d'informer le "Collection Server" de l'attribution de cette WU à votre client. Dans ce cas, le "Collection Server" l'ignorera et vous devrez patienter jusquà ce que le serveur de données soit à nouveau opérationnel.

Nous avons déjà vu que le processus automatisé de téléchargements et de renvois des résultats arrive très bien à se sortir de quelques péripéties. Mais des bugs peuvent survenir et il ne reste plus que la procédure manuelle que vous pouvez utilisez avec plus ou moins de succès, selon l'état du serveur (s'il est inaccessible, cette procédure n'aura aucun résultat). Pour un client "console" Windows, dans la cible du raccourci, inscrivez la mention -send all et relancez le client. Pour un client "console" Linux, c'est en ligne de commande. S'il peut communiquer avec les serveurs de Stanford, le client renverra les WU en attente.

Une particularité ? Plutôt un bug...

[17:52:43] Trying to send all finished work units
[17:52:43] - Already sending work
[17:52:43] - Already sending work
[17:52:43] - Already sending work
[17:52:43] + Sent 0 of 3 completed units to the server
[17:52:43] + Closed connections
..........

J'ai vu ce genre de cas, à plusieurs reprises, avec un client SMP Linux et, dans notre exemple, il s'agissait de trois WU bien différentes qui avaient été téléchargées tout à fait normalement pour traitement mais les résultats ne pouvaient pas être retournés au serveur. L'arrêt et la relance du client n'apporta pas la solution. Au bout de trois jours et trois WU dans la file d'attente, il devenait urgent de commencer à s'inquiéter, à cause de la deadline. La mention du paramètre -send all régla le problème illico :

[04:12:09] Attempting to return result(s) to server...
[04:12:09] Trying to send all finished work units

[04:12:09] Project: 2677 (Run 34, Clone 18, Gen 17)

[04:12:09] + Attempting to send results [June 27 04:12:09 UTC]
[04:12:09] - Reading file work/wuresults_04.dat from core
[04:12:11]   (Read 52722909 bytes from disk)
[04:12:11] Connecting to http://171.64.65.56:8080/
[04:24:48] Posted data.
[04:24:48] Initial: 0000; - Uploaded at ~66 kB/s
[04:25:01] - Averaged speed for that direction ~62 kB/s
[04:25:01] + Results successfully sent
[04:25:01] Thank you for your contribution to Folding@Home.
[04:25:01] + Number of Units Completed: 54

[04:25:06] Project: 2669 (Run 7, Clone 48, Gen 156)

[04:25:06] + Attempting to send results [June 27 04:25:06 UTC]
[04:25:06] - Reading file work/wuresults_05.dat from core
[04:25:07]   (Read 25887619 bytes from disk)
[04:25:07] Connecting to http://171.64.65.56:8080/
[04:34:04] - Couldn't send HTTP request to server
[04:34:04] + Could not connect to Work Server (results)
[04:34:04]     (171.64.65.56:8080)
[04:34:04] + Retrying using alternative port
[04:34:04] Connecting to http://171.64.65.56:80/
[04:40:08] Posted data.
[04:40:09] Initial: 0000; + Results successfully sent
[04:40:13] Thank you for your contribution to Folding@Home.
[04:40:13] + Number of Units Completed: 55

[04:40:15] Project: 2677 (Run 13, Clone 21, Gen 18)

[04:40:15] + Attempting to send results [June 27 04:40:15 UTC]
[04:40:15] - Reading file work/wuresults_06.dat from core
[04:40:15]   (Read 48615101 bytes from disk)
[04:40:15] Connecting to http://171.64.65.56:8080/
[04:51:34] Posted data.
[04:51:34] Initial: 0000; - Uploaded at ~69 kB/s
[04:51:43] - Averaged speed for that direction ~63 kB/s
[04:51:43] + Results successfully sent
[04:51:43] Thank you for your contribution to Folding@Home.
[04:51:43] + Number of Units Completed: 56

[04:51:47] + Sent 3 of 3 completed units to the server


En définitive, sauf bugs, tout arrive à point à qui sait attendre