SETI@home : les rapports techniques (août 2000)

Une interruption du serveur est prévue mercredi 30 août 2000, à partir de 13:00 UTC (15:00 CEDT, 06:00 PDT). Bien que la principale raison de cette interruption ne soit pas liée à SETI@home (Le Laboratoire de Sciences Spatiales met à niveau la configuration de l'alimentation électrique de secours sur toute l'ossature du réseau), nous utiliserons ce temps pour la mise à niveau de nos matériels et logiciels.

Lundi 21 août 2000.

Nous devons faire un arrêt d'une demi-heure aujourd'hui pour mesurer les performances de la base de données et combler notre retard dans le traitement des résultats, car nous sommes tombé sous un seuil significatif durant le week-end en ce qui concerne l'insertion des résultats dans la base de données.

Bonne nouvelle, toutes les statistiques importantes ont été rétablies : graphiques d'évolution des totaux et variations de performances, cumuls généraux corrigés. Une estimation moyenne a été faite sur toute la première quinzaine d'août où ces statistiques manquaient. Il ne manque plus que les nouvelles statistiques détaillées des utilisateurs relatives aux 10 dernières unités calculées.

Mercredi 16 août 2000.

Plus d'infos sur les récentes interruptions : nous avons stoppé le serveur rapidement ce matin pour nettoyer rapidement une table dans la base de données qui semblait affecter les performances du serveur de données et envoyait probablement de faux messages d'erreur au sujet de "résultats en double" à nos utilisateurs.

Et demain matin vers 07:30 PDT (14:30 UTC, 16:30 CEDT), il y aura une mise à jour d'un routeur sur le réseau du campus. On nous a informé que cette interruption ne devrait pas excéder trente minutes.

Mardi 15 août 2000.

Il y a eu deux coupures successives inattendues d'électricité ce matin vers 10:00 PDT (17:00 UTC, 19:00 CEDT). Nous avons temporairement basculé vers une alimentation de secours, mais il pourrait y avoir une autre coupure plus tard dans la journée ou demain quand nous nous rebrancherons sur l'alimentation électrique normal. Nous posterons plus de détails dès que nous en saurons plus.

Samedi 12 août 2000.

Voici la traduction d'une mini FAQ composée à partir de discussions par Eric Korpela et d'autres membres du projet SETI@home à Berkeley, sur un newsgroup américain:

INDEX

01. Que sont les impulsions et triplets détectés par SETI@home bêta 2.70 et bêta 2.71 et qui figurent dans la nouvelle version définitive 3.0 ?

02. Quels sont les impulsions/triplets intéressants ?

03. Pourquoi le nouveau client met-il plus de temps à achever une unité de travail ?

04. Pourquoi certaines unités de travail prennent-elles plus de temps à calculer ?

05. Pourquoi les recherches d'impulsions sont elles plus nombreuses avec une vitesse nulle de dérive en fréquence ?

06. N'y a-t-il pas quelque chose d'étrange avec la puissance rapportée pour les impulsions dans le fichier de résultats "outfile.sah" par rapport au fichier d'état "state.sah" ?

07. La première moitié du graphique d'impulsion est-elle identique à la seconde ?

CONTENU

01. Que sont les impulsions et triplets détectés par SETI@home bêta 2.70 et bêta 2.71 et qui figurent dans la nouvelle version définitive 3.0 ?

Dans les contextes de SETI@home, il y a des pics qui sont répétés de nombreuses fois. Un triplet signifie qu'il y a trois pics de puissance qui sont situés à égale distance. La détection des triplets prends très peu de temps, mais elle ne peut détecter que des signaux puissants.

L'algorithme de recherche des impulsions peut trouver des impulsions bien plus faibles, plus nombreuses elles sont, mieux cet algorithme pourra les trouver. Cependant la recherche des impulsions prends beaucoup de temps.

02. Quels sont les impulsions/triplets intéressants ?

Pour les impulsions, le seuil a été fixé au score 1,0. Un score de 1,04 signifie que l'impulsion a deux fois moins de chance d'être causée par du bruit aléatoire.

Pour les triplets, le seuil a été fixé au score de 0,75.

03. Pourquoi le nouveau client met-il plus de temps à achever une unité de travail ?

Parce que plus de calcul scientifique est réalisé. Le client recherche maintenant dans un domaine plus étendu de vitesses de dérive Doppler en fréquences, de -50 Hz/s à +50 Hz/s. Le client recherche également des signaux pulsatifs.

04. Pourquoi certaines unités de travail prennent-elles plus de temps à calculer ?

Le radio-observatoire d'Arecibo peut poursuivre des étoiles jusqu'à un certain degré, même s'il s'agit d'un grand trou creusé dans le sol. Si le télescope se déplace plus lentement, vous obtenez plus de données d'une portion plus petite du ciel, ou simplement plus de temps sur la même cible. Cela permet à l'algorithme de recherche d'impulsions d'utiliser un plus grand tronçon de données de l'unité de travail dans le même temps, ce qui le rend plus sensible aux impulsions possibles reçues.

05. Pourquoi les recherches d'impulsions sont elles plus nombreuses avec une vitesse nulle de dérive en fréquence ?

Des impulsions plus courtes ont une largeur de bande plus étendue, et sont donc moins affectées par un décalage Doppler. C'est pourquoi il est inutile de chercher des impulsions avec par exemple une FFT longue de 128 points et une dérive de 2,3 Hz/s.

06. N'y a-t-Il pas quelque chose d'étrange avec la puissance rapportée pour les impulsions dans le fichier de résultats outfile.sah par rapport au fichier d'état state.sah ?

En effet, la puissance est mesurée différemment, et voici un message posté par Eric Korpela, membre du projet SETI@home qui l'explique :

Il s'agit d'un choix de conception. La valeur interne de la puissance de l'impulsion est la puissance moyenne mesurée depuis le point zéro. La valeur rapportée est la puissance de crête mesurée depuis la puissance moyenne. Puisque ces deux valeurs sont normalisées par rapport à la puissance moyenne, la puissance rapportée devrait toujours être 1,0000 moins la valeur dans le fichier d'état. Désolé pour cette source possible de confusion.

07. La première moitié du graphique d'impulsion est-elle identique à la seconde ?

Oui en effet, c'est à cause de la façon dont l'algorithme de recherche travaille. Puisque le nombre d'impulsions peut dépasser 2000, il est impossible de dessiner le graphique de la durée entière des impulsions (on le fait déjà avec le graphique gaussien), aussi on affiche deux fois le résultat de l'algorithme de superposition pour lui donner un aspect périodique.

Voici la description faite par Eric Korpela, de SETI@home au sujet de cet algorithme :

L'algorithme de recherche ressemble à ceci (dans ses généralités, mais pas dans tous ses détails) : l'algorithme est appelé algorithme de repli. Supposons que nous avons un flux de données de 66 points qui ressemble à ceci :

001100010010010011010001000100001111010110000110011101010011111100

L'algorithme de repli commence par rechercher des choses qui ont une période de N/3, soit ici 22 échantillons, en additionnant les points par groupe de 22 :

0011000100100100110100
0100010000111101011000
0110011101010011111100
----------------------
0221021201221212232200

Maintenant nous recherchons dans ce flux replié un évènement au dessus du seuil fixé. S'il y a un signal fort avec une période de 22 échantillons, les pics de ces signaux devraient s'aligner et nous devrions voir un pic dans le signal replié. Puis nous prenons le tableau replié et le plions de nouveau par moitié pour chercher une période de 11 échantillons :

02210212012
21212232200
-----------
23422444212

Puis nous recherchons des pics au dessus du seuil. Et nous répétons encore l'opération pour obtenir une période (moyenne) de 5,5 échantillons (cela devient complexe avec des périodes non entières, et je ne vais vraiment pas essayer de m'étendre pour donner une bonne explication de cette partie) :

234224
444212
------
678436

Et de nouveau avec une période de 2,75 :

6  8  7
4  6  3
--------
10 14 10

Puis nous revenons aux données d'origine et nous recherchons sur une période légèrement réduite, dans ce cas, 21+2/3 ~= 21,6667. Nous faisons ceci en recalant simplement le point final de 1 échantillon. Voici les données originales à nouveau :

001100010010010011010001000100001111010110000110011101010011111100

Et voici les échantillons que nous ajoutons ensembles, notez que la troisième ligne a été décalée d'une position :

0011000100100100110100
0100010000111101011000
0011001110101001111110
----------------------
0122011210312202232210

Maintenant nous replions par moitié sur une période de (21+2/3)/2, soit environ 10,83333 :

01220112103
12202232210
-----------
13422344313

Et ainsi de suite...

Pour un tableau de données de longueur N, nous recherchons des périodes de :
N / (3 * 2^{^n}) à N / (4 * 2^{^n}), par pas périodiques de 1 / (3 * 2^{^n}),
        avec n = 0 à log₂(N / 3) - 1 ;
N / (4 * 2^{^n}) à N / (5 * 2^{^n}), par pas périodiques de 1 / (4 * 2^{^n}),
        avec n = 0 à log₂(N / 4) - 1 ;
N / (5 * 2^{^n}) à N / (6 * 2^{^n}), par par périodiques de 1 / (5 * 2^{^n}),
        avec n = 0 à log₂(N / 5) - 1.

En principe, vous pourriez continuer ainsi avec N / (6 * 2^{^n}) et toute la suite, mais vous avez déjà dépassé le point où les résultats diminuent fortement, puisque la plupart des périodes à laquelle vous chercheriez seraient déjà couvertes. Vous gagnez seulement en sensibilité pour des durées d'impulsions très inférieures à la fréquence d'échantillonnage, et puisque SETI@home a été conçu pour être insensible aux signaux de large bande, nous ne détecterions de toute façon pas pas des signaux d'une durée aussi courte.

Mercredi 9 août 2000.

L'interruption d'aujourd'hui à 13:00 UTC (15:00 CEDT, 6:00 PDT) a finalement duré un peu moins de 2 heures et demi. Il n'y a pas eu de coupure totale du réseau puisque le serveur web de Berkeley est resté accessible. Néanmoins le serveur de données a été suspendu et a repris son activité normale.

Nous avons donc connu une interruption du réseau dans notre laboratoire ce matin qui s'est passée calmement, durant laquelle nous avons mis à jour quelques tables dans la base de données. Malheureusement, les répercussions de cette modification n'ont pas été apparentes jusqu'à tard dans l'après-midi. Durant ce temps, aucun nouveau compte utilisateur n'a pu être créé. Le serveur avait encore besoin de quelques modifications (ce qui incluait un court arrêt et une recompilation), mais maintenant nous sommes revenus à la normale.

Bonne nouvelle pour les nouveaux inscrits : désormais ils peuvent de nouveau obtenir leur mot de passe SETI@home et avec ce mot de passe s'inscrire enfin dans un groupe ou modifier leur inscription. Bien entendu, cela concerne aussi ceux qui ont perdu leur mot de passe personnel et souhaite en obtenir une nouvelle copie.

Pour que le serveur soit totalement opérationnel, il ne reste plus qu'à remettre ne service l'actualisation des graphiques d'activité et de performance globale, et corriger les erreurs de dépassement de capacité (valeurs NaN) qui se produisent dans l'écran des statistiques globales, notamment dans le temps de calcul total cumulé (en années).

Mardi 8 août 2000.

La courte interruption du réseau de cet après-midi s'est passée sans incident, et le serveur est reparti normalement. L'interruption de demain mercredi est maintenue à 13:00 UTC (15:00 CEDT, 6:00 PDT) et devrait durer 2 heures.

Les statistiques sur le serveur ont également été rétablies depuis 22:00 UTC (24:00 CEDT, 15:00 PDT). Tous les classements des groupes et pays ont été remis à jour sur le serveur.

Vendredi 4 août 2000.

les programmes CGI du serveur web sont rétablis depuis 21:30 UTC, 23:30 CEDT. Vous pouvez de nouveau procéder à un changement de compte, ou vous inscrire au projet, rafraîchir vos statistiques personnelles, consulter les statistiques des groupes par le module de recherche. Cependant les pages de compilation des statistiques de groupes et de cumuls par pays ou domaine ne sont pas encore à jour, de même que les graphiques d'activité, qui datent encore tous du 31 juillet à 13:00 UTC. Nous faisons en sorte de les rétablir le plus rapidement possible.

Il y aura 2 interruptions de service au début de la semaine prochaine. Ce seront des interruptions sur le réseau de U. C. Berkeley, qui ne sont pas liées à SETI@home, mais à des opérations de maintenance plus faciles à programmer en période estivale. Nous profiterons cependant de ces interruptions pour faire d'autres opérations de maintenance sur le système. La première aura lieu mardi 8 août à 13:30 UTC (15:30 CEDT, 6:30 PDT) et ne devrait pas durer plus de 30 minutes. La seconde aura lieu le lendemain mercredi 9 août à 13:00 UTC (15:00 CEDT, 6:00 PDT) et ne devrait pas durer plus de 2 heures.

Jeudi 3 août 2000.

Nos bases de données subissent actuellement une charge de travail extrêmement importante, dans le but de terminer les contrôles et réparations suite aux pannes survenues en juillet, et ne peuvent pas supporter le trafic supplémentaire requis par tous les programmes CGI du serveur. Dans des conditions normales, nous recevons pas moins de 5 à 10 requêtes de statistiques des utilisateurs par seconde, 24 heures sur 24. Si nous réactivions le programme statistiques maintenant, notre base de données scientifique ne serait plus capable de servir le serveur de données, et pourrait potentiellement perdre des résultats scientifiques.

Également, nous n'exécutons pas pour le moment les programmes qui habituellement mettent à jour les pages statistiques (par exemple les totaux par domaine, équipe ou par pays).

Nous comprenons que les statistiques sont un élément majeur de l'intérêt porté à SETI@home, et faisons actuellement tout notre possible pour rétablir au plus vite la base de données en bon ordre de marche.

Mardi 1^er août 2000.

Après un premier redémarrage infructueux aujourd'hui vers 07:30 PDT (14:30 UTC, 16:30 CEDT), la base de données a de nouveau été suspendue jusqu'à 15:00 PDT (22:00 UTC, Mercredi 2 aôut 00:00 CEDT).

Nous avons migré avec succès la base de données scientifiques vers les nouveaux disques. Cependant il nous a fallu pratiquement 31 heures pour effectuer cette migration, soit le double de ce qui était prévu : nous avons subi une limitation Informix préexistante, sur le nombre de "fragments d'extensions" que nous pouvons allouer à la table des signaux de crêtes. Nous avons donc créé une seconde table de signaux de crêtes de sorte que les résultats peuvent être acceptés, mais cela romps quelque peu notre code. Aussi, certains CGI's resteront inactifs jusqu'à ce que nous mettions au point un contournement, mais au moins le serveur de données devrait fonctionner. Veuillez noter qu'il pourrait y avoir des redémarrages inopinés du serveur durant les deux prochains jours.

Un autre problème presque indépendant du premier, est que le réseau dorsal du campus de Berkeley connaît des problèmes de connectivité avec Internet, ce qui peut faire croire que le serveur de données est arrêté.

Page mise à jour le dimanche 15 juillet (2001-07-15 15:56:55 +0200).
Site Web convenant à tout public :

Étiquette ICRA (RSACi),

Classification SafeSurf et

Weburbia Safe For Kids.
Traduction en Français :

SETI@home (U.C. Berkeley).

Les derniers rapports techniques sur SETI@home.

Les rapports techniques sur SETI@home.

Août 2000.