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.

Avril 2001.

Lundi 30 avril 2001.
Hier, le moteur Informix servant notre base de données scientifique s'est bloqué, apparemment à cause d'une contention de ressource. Cela s'est à nouveau produit aujourd'hui. Nous en recherchons activement la cause. Nous avons profité de l'interruption pour mettre à niveau la machine de la base de données scientifique (un des Sun E450). Nous lui avons ajouté 2 processeurs supplémentaires, et encore 0,5 Go de mémoire centrale.
Mercredi 25 avril 2001.
Nous avons enrichi nos pages de liens avec des nouvelles descriptions de sites sur les *outils complémentaires SETI@home et les *ressources éducatives.
Lundi 23 avril 2001.
Comme beaucoup le savent, notre option "View last 10 workunits" (voir les 10 derniers résultats) sur la page de statistiques personnelles d'un utilisateur a été suspendue à cause d'une surcharge du serveur. Nous travaillons en ce moment pour rétablir cette fonctionnalité sur la base de données en ligne (grâce à la migration en cours de notre base d'analyse scientifique). Bientôt en ligne !
Jeudi 5 avril 2001.
Nous avons bien avancé dans la phase d'audit qualité des données résultant de l'analyse des 80 millions d'unités de travail distribuées jusqu'ici. Pour vérifier la qualité des données, chaque unité de travail est analysée par 2 ou 3 (parfois plus) clients et les résultats redondants sont comparés mutuellement entre eux. Nous choisissons un des résultats dans l'ensemble associé à chaque unité de travail, et l'insérons dans notre nouvelle base de données scientifique principale. Cette base principale ne contiendra donc qu'un résultat canonique et un seul pour chaque unité analysée. Les références à tous les participants qui ont contribué aux résultats de chaque unité de travail sont maintenus dans la base de données scientifique en ligne.
Nous appelons le programme qui choisit le résultat canonique le "vérificateur de redondances" ou "VR" ("redundancy checker" ou "RC" en Anglais). Le VR détermine le résultat canonique en se basant sur l'accord avec les autres résultats de la même unité de travail. Un accord est est trouvé quand les signaux contenus dans un résultat correspondent valeur par valeur avec ceux de signaux contenus dans un autre résultat du même ensemble. Nous n'insistons pas sur une égalité stricte, car les signaux qui s'accordent réellement peuvent varier légèrement à cause des arrondis de calculs et des effets du "dechirping" (suppression de l'effet d'accélération Doppler) qui est réalisé de façon différentielle par les clients. Nous sommes heureux de constater que seule une infime portion des résultats ne passe pas l'étape de vérification des redondances. Attendez une discussion détaillée de l'algorithme du VR et des statistiques dans un futur bulletin scientifique. Maintenant puisque cette page concerne les nouvelles des opérations, venons-en à une discussion sur notre nouveau serveur.
SETI@home avait à l'origine 2 bases de données sur des serveurs indépendants, pour distribuer les unités de travail aux processeurs finaux (les clients), recevoir leurs résultats et garder la trace des statistiques des utilisateurs. Nous avions pensé pouvoir conduire l'analyse scientifique directement sur la base de données qui collecte et stocke les résultats des unités de travail depuis les processeurs finaux. Au bout d'un moment on s'est aperçu qu'il n'était guère possible de conduire une analyse poussée en même temps que nous recevions effectivement les résultats. Une des fonctions avait un trop grand impact sur l'autre. Aussi nous avons établi qu'il nous fallait répliquer la base de données en ligne vers un serveur séparé, de sorte qu'on pourrait mener une analyse hors-ligne sans faire souffrir les temps de réponse du serveur.
La base de données en ligne est une configuration multiprocesseur à base de SUN 450 Enterprise, avec 2 Go de RAM ECC et près de 400 Go de disques RAIDs. Nous utilisons plusieurs contrôleurs SCSI dotés de 64 Mo de cache dans des configurations RAID 0+1. Nous utilisons le logiciel Informix Dynamic Server pour gérer nos bases de données à haute performance. Cette base de données en ligne accepte de recevoir plusieurs résultats redondants pour chaque unité de travail. Aussi, la taille de la base de données en ligne pourrait être réduite de 66 % à 75 % une fois les résultats canoniques sélectionnés.
La nouvelle base de données scientifique maître est maintenant en cours de chargement par le RC. Le nouveau serveur est une machine bien moins puissante, basée sur un Compaq 570r avec 2 processeurs et 1 Go de RAM ECC tournant sous Solaris avec Informix. Il dispose de 2 contrôleurs SCSI-2W et de 144 Go sur 16 disques. Nous pensons que la plus grande partie du processus de chargement de ce serveur prendra autour de 50 à 90 jours. Alorsnous pourrons reconduire un processus périodique pour le mettre à jour avec les nouveaux résultats parvenus dans la base de données en ligne.
Nous avons pu définir la base de donnée en utilisant la fonction de "fragmentation" des tables. Celle-ci permet à Informix de distribuer équitablement une table ligne par ligne suivant la valeur numérique de leur identifiant, et sur autant de disques que l'administrateur pense nécessaire (Informix définit des fonctions dites de "hachage" utilisables pour créer une clé pseudo-aléatoire pour cette fragmentation). Bien que nous n'atteindrons pas la capacité brute d'E/S des configurations RAID, il est possible d'optimiser la capacité en bande passante d'E/S suivant les caractéristiques de l'application et les besoins de tables spécifiques.

Actuellement la table des Signaux de crête (où nous stockons tous les signaux de crête rapportés) est la structure la plus large et la plus souvent sollicitée dans la base de données. Aussi un soin particulier a été donné pour s'assurer que cette table et ses index serait éclatée sur un nombre de disques exclusifs, et n'aurait aucun conflit d'E/S avec les autres tables. Nous avons eu quelques problèmes pour répartir les index exactement où nous le voulions, puisque Informix définit un positionnement fixe pour les index obligatoires et implicites. En fin de compte, nous nous sommes assurés que ces emplacements fixes auraient assez d'espace disque et des chemins d'accès minimisant les files d'attente d'E/S durant les activités sur de gros volumes. En pratique, la nouvelle base de donnée s'est avérée assez performante.


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 13:44:45 +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).