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

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

 Retour au sommaire de SETI@home.


 Informations sur SETI et SETI@home :

  Calendrier des opérations.

 État du serveur.

  Rapports techniques :

1999
  mai
juin
juil.
aoû.
sep.
oct.
nov.
déc.
2000
jan.
fév.
mar.
avr.
mai
juin
juil.
aoû.
sep.
oct.
nov.
déc.
2001
jan.
fév.
mar.
avr.
mai
juin
juil.
aoû.
sep.
oct.
nov.
déc.

 Aidez-nous.

 Utilisez SETI@home.

 Statistiques et résultats.

Les rapports techniques sur SETI@home.

Juin 1999.

Mercredi 30 juin 1999.
Le recycleur de déchets, le serveur, et les tranchoirs ont atteint un point d'équilibre. Les unités de travail sont générées aussi vite qu'elles sont effacées, et elles sont à peu près aussi vite effacées que les nouveaux résultats nous parviennent.
Les nouvelles version 1.05 des clients Windows et Mac sont disponibles.
Mardi 29 juin 1999.
La troisième machine rapide pour le tranchoir est désormais en ligne. Nous avons arrêté l'ancienne plus lente, et transféré la bande sur laquelle elle opérait vers cette nouvelle machine.
Lundi 28 juin 1999.
Nous avons ajouté un mécanisme qui permet au membre fondateur du groupe d'éditer les informations du groupe, telles que le nom, la description, le lien URL éventuel, et le type de groupe. Pour éditer un groupe, allez sur la page des groupes et cliquez sur "Edit this group" (éditer ce groupe).
Nous avons maintenant 750 000 unités de travail sur disque. Les tranchoirs tournent au rythme de 140 000 unités de travail par jour, un peu plus lentement qu'à notre première estimation. Une troisième machine rapide pour la production des tranches de données devrait être en ligne cette semaine. Nous approchons du seuil d'espace disque libre où le collecteur de déchets s'activera et commencera à effacer les unités de travail pour lesquelles des résultats ont été reçus, ou qui ont été envoyées à plusieurs utilisateurs.
Le serveur SETI@home a été déplacé sur une nouvelle machine, plus rapide. Les 360 Go de stockage des unités de travail, qui étaient auparavant répartis entre deux machines, sont maintenant consolidées sur cette machine là. Le serveur a été coupé durant deux heures aujourd'hui alors que nous effectuions ces changements.
Dimanche 27 juin 1999.
Nous avons modifié le serveur SETI@home pour qu'il utilise un ensemble fixe de processus pour les utilisateurs, chacun avec une connexion de base de données persistante. Cela devrait rendre notre serveur quelque peu plus efficace, parce que cela élimine les fourches de processus et la création des connexions de bases de données. Cela élimine également le besoin d'un processus séparé pour gérer les mises à jour des comptes utilisateurs.
Samedi 26 juin 1999.
Les tranchoirs rapides ont terminé les bandes 09ja99aa et 02mar99aa, et démarré les bandes 10ja99aa et 01mr99ab (à ne pas confondre avec 01mr99aa.) Le tranchoir le plus lent s'attache toujours à traiter le 01mr99aa.
Jeudi 24 juin 1999.
A la suite d'un bogue du serveur (maintenant résolu) les crédits des dernières 24 heures ont été perdus.
Nous avons modifié les pages statistiques de façon à ce que les balises HTML dans le nom d'un utilisateur ne soient plus interprétés comme du HTML, mais affichés tels quels. Également, la balise "mailto:" a été ajoutée à l'adresse E-mail de l'utilisateur affichée dans les statistiques.
Mercredi 23 juin 1999.
Deux nouvelles machines rapides s'occupe du découpage des données. La vitesse effective devrait monter à 180 000 unités de travail par jour.
Le serveur SETI@home a été modifié pour détecter quand un utilisateur nous envoie de façon répétée les mêmes résultats.
Mardi 22 juin 1999.
Nous revérifions maintenant les résultats intéressants en analysant les unités de travail nous-mêmes. Nous l'avons fait pour l'unité de travail contenant le plus haut score Gaussien, et n'avons pas eu les mêmes résultats, aussi nous avons ôté ces résultats de notre base de données.
Le nouveau matériel de Sun (3 stations de travail Ultra-10 et 6 lecteurs DLT) est arrivé. Nous configurons les machines.
Lundi 21 juin 1999.
Nous ajoutons les mécanismes pour les responsables de groupes leur permettant d'éditer les informations de leur groupe et de le fusionner avec un autre groupe.
Dimanche 20 juin 1999.
Le nouveau schéma modifié de comptabilisation est en place et semble fonctionner ; les crédits apparaissant dans l'écran de veille sont maintenant synchronisés avec ceux du serveur.
Le transfert des unités de travail découpées de WS4 à WS3 (via NFS) provoquait des erreurs NFS de dépassement de délais et consommait trop de processus sur WS3. Le tranchoir est temporairement désactivé jusqu'à demain.
Jeudi 17 juin 1999.
Nous avons modifié la façon dont les décomptes sont faits de façon à ce que les champs d'information utilisateur de l'écran de veille (User Info) soient mis à jour immédiatement après qu'un résultat est envoyé (c'était la demande n°1 de nos utilisateurs). Quand un résultat est reçu, l'enregistrement de l'utilisateur est mis à jour immédiatement (pas par le processus qui gère la requête, mais par un processus dédié utilisant un schéma de mémoire partagée similaire à celui utilisé pour envoyer les unités de travail). Le programme de décompte hors-ligne (qui a maintenant pratiquement refait tout son retard) gère toujours les autres crédits (groupes, pays, domaines, ...).
Mercredi 16 Juin 1999.
En raison des nombreuses demandes, nous avons réinitialisé les crédits des groupes (temps de calcul et nombre de résultats) à la somme des crédits de tous ceux appartenant au groupe.
Mardi 15 juin 1999.
Les décomptes des groupes ne fonctionnent pas correctement. Les crédits ont été cumulés quand les participants se sont joints au départ, mais pas pour leur travail réalisé depuis. C'est maintenant résolu, mais nous ne pouvons pas restaurer les crédits manquants.
Nous avons décidé d'arrêter de faire le décompte des "unités de travail envoyées" pour tout ce qui n'est pas des utilisateurs individuels. Cette information sera très vite supprimée des pages de statistiques.
La "pompe" à unités de travail est maintenant de nouveau pleinement opérationnelle. Les utilisateurs verront enfin des données enregistrées à une grande variété de dates sur ces quelques derniers mois.
Lundi 14 juin 1999.
A la suite du problème "d'i-nodes", nous avons effectué quelques changements à l'architecture du serveur. L'idée est de faire le tri des priorités :
  1. Les opérations critiques : les faire immédiatement ;
  2. Les choses nécessaires mais non critiques dans le temps : les mettre en file d'attente ; accroître l'efficacité en fusionnant les mises à jour de la base de données ;
  3. Tout le reste : appliquer toutes les ressources restantes, mais ne pas les mettre en file d'attente.
Voici un résumé des fonctions de nos serveurs et comment nous les gérons :
  • Génération des unités de travail : WS4 est dédié a cette tâche, et peut générer quelques 15 000 nouvelles UT (unités de travail) par jour. Le stockage des UTs sur disques consiste en deux groupes de 8x18 Go, chacun sur WS3 et WS4.
  • Diffusion des unités de travail : le processus principal du serveur SETI@home maintient une liste en mémoire partagée des UTs à envoyer. Cette liste est alimentée par une requête de base de données qui favorise les UTs qui n'ont jamais été envoyées, ou qui ont été envoyées mais sans aucun résultat reçu. Les processus fils (qui sont branchés pour traiter les requêtes utilisateur) obtiennent des UTs depuis cette liste. Cela évite de créer une connexion de base de données depuis chaque processus fils.
  • Recyclage des déchets : ce démon efface les unités de travail du disque, libérant de la place pour de nouvelles UTs. La politique courante : d'abord, effacer les UTs pour lesquelles un résultat a été reçu, puis les UTs qui ont été envoyées trois fois, puis les UTs qui ont été envoyées deux fois, enfin les UTs qui ont été envoyées une seule fois.
  • Gestion des résultats : le serveur SETI@home stocke chaque résultat dans un fichier et ajoute une ligne dans un fichier de comptabilité (cela évite d'utiliser la base de données.) Le "démon science" traite le fichier résultat, utilisant toute la capacité supplémentaire de la base de données pour insérer les signaux de crêtes et gaussiens. Il évite d'insérer des résultats en double.
  • Décompte des crédits : le processus "démon comptable" sur WS2 lit les fichiers de décompte générés pas le serveur SETI@home, et met à jour les champs de crédits des utilisateurs, des équipes, domaines, pays, etc... Il maintient un cache mémoire des entités crédités, combinant des milliers de mises à jour de la base de données en une seule. Actuellement le démon comptable a environ 2 jours de retard.
  • Pages statistiques : ces pages sont régénérées tous les jours (domaines) ou toutes les 6 heures (autres entités) par une tâche "cron."
  • Inscription et identification : elles sont traitées immédiatement par le serveur SETI@home et requièrent une connexion à la base de données.
  • Gestion des formulaires Web (inclut les requêtes de compte utilisateur, l'édition des information utilisateur, les création/recherche/jonctions aux groupes) : Ce traitement est effectué par un programme CGI qui est exécuté depuis le serveur Web.
Samedi 12 juin 1999.
Les fichiers de résultats se sont accumulés et nous sommes tombés à cours "d'i-nodes" sur notre système de fichiers, en dépit de la place disque disponible. Cela a eu pour effet de faire tomber le serveur.
Vendredi 11 juin 1999.
Nous ajoutons un mécanisme pour permettre aux utilisateurs d'éditer leur compte (Adresse de courriel, nom, etc...) par une interface du site Web.
Mercredi 9 juin 1999.
Nous avons une quatrième station de travail Sun, WS4. Nous avons déplacé le lecteur DLT sur WS4 et pouvons exécuter le Tranchoir de nouveau. Nous projetons de modifier le serveur SETI@home pour utiliser la base de données de façon plus efficace, en lui requérant environ un millier d'unités de travail à renvoyer.
Lundi 7 juin 1999.
Nous avons formulé un plan pour utiliser le nouveau matériel Sun quand il arrivera plus tard durant ce mois. Pour simplifier :
  • Nous couperons notre base de données en deux parties : science et gestion des comptes. La base de données scientifique résidera sur le 450, et la Phase 2 des Traitements y seront réalisés.
  • Les lecteurs DLT seront attachés à WS5, WS6, WS7 et WS8. Le Tranchoir sera exécuté sur chacune de ces machines.
Cette nouvelle architecture permettra, nous l'espérons, d'atteindre les objectifs suivants:
  • Le Tranchoir pourra enfin suivre les données entrantes.
  • Nous aurons assez de capacité en performance de bases de données pour enregistrer tous les résultats scientifiques durant les deux années du projet.
  • Nous disposerons de suffisamment de capacité de processeur et de base de données pour réaliser la Phase 2 des Traitements.
Vendredi 4 juin 1999.
Nous avons appris que le serveur SETI@home a diffusé de façon répétée les mêmes 115 unités de travail pendant les derniers jours. Cela a été résolu immédiatement, et avons diffusé une notice sur le site Web. Nous revoilà donc pour diffuser nos 31 415 unités de travail existantes. Le problème était dû à un bogue subtile du système d'exploitation, mais nous étions fort déçus de ne pas l'avoir repéré plus tôt.
Mardi 1er juin 1999.
Sun Microsystems a fait une donation substantielle de nouveau matériel : 4 stations de travail, 4 lecteurs DLT, une grosse quantité de stockage disque, et un serveur quadri-processeur 450 Enterprise Server. La livraison de ces stations de travail et des unités de bande est prévue pour la mi-juin, et le 450 est reporté vers la fin juin.

Des questions ?  Écrivez-nous !

Retour en haut de cette page.

 Retour au sommaire de SETI@home.

 
Page mise à jour le dimanche 15 juillet (2001-07-15 16:48:10 +0200).
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).