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.
|