Sommaire SETI@home
Depuis chez vous, partez à la
Recherche d'une Intelligence
Extraterrestre
.

Page de référence : Anglais (English)

Changements dans la version 3.03 de SETI@home.

La version 3.03 corrige des problèmes mineurs présents dans la version 3.0, notamment sous Windows, et étend encore le domaine de recherche par rapport aux améliorations opérationnelles de la version 3.0 et des version 2.x précédentes. Merci à vous tous pour votre patience, cette révision a pris plus de temps que prévu.

Pour télécharger la version 3.03, cliquez ici.

*Windows.

  • Correction d'un bogue mineur empêchant souvent l'affichage du graphique FFT.

*Toutes plates-formes.

  • Extension des domaines de recherche scientifique. Nous effectuons maintenant une recherche approfondie en analysant des vitesses de dérives Doppler allant jusqu'à +20 Hz/seconde. Le coût de cette recherche additionnelle est que le client prendra maintenant plus de temps pour traiter une unité de travail.

    Pourquoi faisons nous ceci ? Nous avons toujours voulu équilibrer les retours scientifiques avec les ressources mises à disposition du projet, la part la plus importante étant bien sûr notre communauté très large et active de participants. La croissance de cette communauté a été telle que cela nous a permis d'étendre les recherches dans la version 3.0. Nous avions en effet tenté auparavant de contrebalancer les retours scientifiques avec la rapidité de traitement des unités de travail, aussi nous avions concentré la recherche approfondie uniquement dans le domaine jusqu'à +10Hz/s. Mais nous avions sacrifié une part de la recherche scientifique au bénéfice de la vitesse des clients.

    Une autre ressource importante au projet est notre propre connexion vers Internet. U.C. Berkeley a été particulièrement généreux avec nous, en nous permettant d'utiliser le FAI du campus, en considérant que SETI@home consomme à lui seul 30 % de la capacité pour la totalité du trafic Internet du campus de Berkeley ! C'est une ressource particulièrement onéreuse (18 000 $USD par mois). C'est monté jusqu'à un point où le campus a du limiter notre usage de la bande passante. Nous sommes maintenant limité à 30 Mbits/seconde en débit sortant (la quasi-totalité de notre trafic est sortant). Cela a provoqué en retour des échecs de connexion et plus généralement une réponse plus lente du serveur à toutes vos demandes d'accès. Nous devons donc absolument maîtriser notre consommation de bande passante.

    Heureusement, il n'est pas nécessaire de le faire de façon artificielle, en autorisant certains à se connecter et pas d'autres : toutes les contributions sont volontaires et bienvenues, et il n'est pas question de casser cette volonté affichée. Aussi la seule bonne réponse est d'étendre le domaine des recherches. Ainsi, oui vous verrez vos clients ralentir, mais la réponse du serveur devrait être bien meilleure, du fait du moins grand nombre de connexions simultanées. Ce qui est le plus important, c'est que vous effectuerez plus de calculs scientifiques, et qu'en fin de compte le projet peut continuer à croître en capacité de traitement.
  • Correction d'un bogue mineur où les temps des triplets étaient mal reportés dans le fichier d'état intermédiaire (utilisé par certains outils tiers de contrôle de performance du client). Cependant les temps retournés dans le fichier de résultat étaient bien corrects et cela n'affectait pas les résultats scientifiques.
  • Ajout d'un mécanisme permettant au serveur d'indiquer que le client est désormais obsolète, le client gardant en mémoire cet état de fait constaté. Cette mémorisation évite ensuite de recontacter en permanence le serveur.
  • Changement de l'alias de domaine du serveur hôte. A la fois l'ancien et le nouveau nom seront disponibles durant un certain temp. Par la suite, nous désactiveront l'ancien nom et le serveur de données ne pourra plus être atteint par les anciens clients non mis à jour. La raison en est que certaines versions vraiment anciennes du client (1.x) et certains programmes de bufférisation tiers (par ailleurs très utiles !), n'ont pas la logique leur permettant de reconnaître ce qui ce passe, et ces clients continueront en permanence à réessayer des connexions. En essayant en permanence de contacter notre serveur, ils consomment inutilement de la précieuse bande passante sur notre liaison réseau.

    Quand nous désactiverons l'ancien nom de serveur (shserver.ssl.berkeley.edu), ces clients seront dans l'incapacité d'atteindre le serveur (du moins pas de façon automatique), et les utilisateurs verront un message d'erreur système, leur permettant alors de constater qu'une nouvelle version règlera ce problème.

Retour à la page d'aide.

 
Page mise à jour le lundi 26 mars (2001-03-26 17:24:12 +0100).
Site Web convenant à tout public : Étiquette ICRA (RSACi), Classification SafeSurf et Weburbia Safe For Kids
.
Traduction en Français : Philippe Verdy - Copyright ©1999-2001 SETI@home (U.C. Berkeley).