URL du projet | https://einsteinathome.org/ (https://einsteinathome.org/) |
Détails scientifiques (en Anglais) | Le projet (https://einsteinathome.org/fr/about) |
Unités Windows | OUI |
Unités LINUX | OUI |
Unités Mac | OUI |
Utilisation GPU | OUI |
Applications 64 bits | OUI (Linux) |
Applications optimisées | NON mais on peut faire plusieurs unités GPU à la fois |
Temps de calcul | projet WUPROP (http://wuprop.boinc-af.org/results/delai.py) temps de calcul en fonction du nombre d'unités calculées par GPU et du GPU (fichier pdf) (http://www.dskag.at/images/Research/EinsteinGPUperformancelist.pdf) |
Etat du serveur | https://einsteinathome.org/server_status.html (https://einsteinathome.org/server_status.html) |
Classement mondial des équipes | position de l'AF (http://einstein.phys.uwm.edu/top_teams.php?sort_by=total_credit) |
Classement interne de l'AF | Votre classement (https://statseb.boinc-af.org/classement_membres.py?projet=15) |
Badges pour le projet | NON mais de beaux certificats de découvertes (http://einstein.phys.uwm.edu/forum_thread.php?id=9643) si vous en faites une |
May 3, 2005
We have finished the first complete analysis of the LIGO S3 data set. Based on this, the data preparation and cleaning process have been modified to remove a number of instrumental artifacts that appeared in the post-processing stage, and a new data set has been prepared. This new data set uses the final S3 time-domain calibration and also includes a number of 'software simulated' fake source signals. After we have completed analysis of this final S3 data set (a few weeks) we will to move on to the new and more sensitive S4 data set.
il avance bien ce projet :)
July 28, 2005
A new feature has been added to the Einstein@Home scheduler to re-send Workunits that were lost when sent to your computer. Please report experiences with this feature to this message board thread.
A partir de ce moment la nébuleuse du crabe était née, appellé également Messier 1 (nom d'un célébre astronome français du 18ième siècle).
Ah oui ! :wahoo:
Là, je ne savais pas qu'il était de Badonviller.
On pourrait aussi envisager un petit mailling au cas où il n'y ait plus de travail pour quelques temps, histoire de réorienter nos membres vers d'autres projets (en mettant la priorité sur la physique).Très bonne idée :)
So as the computations are taking place we're actually always continuing to try and improve our algorithms. So that even with the huge computational power that we have with Einstein At Home we can actually do deeper searches which means really extending the reach of the search even further. And in fact I think it's interesting to comment after Brian's slide that pointed to a period when the instruments will be offline. I think we shouldn't worry about Einstein At Home running out of work. This in some respects will give us a chance to catch up with the data. It will be a nice sort of period of time when we can apply our most sensitive algorithm that we will have developed then to the full S5 run data.
Il reste moins d'une semaine de travail sur Einstein :(
J'ai voulu poser une question à ce propos sur le forum officiel mais je me suis fait jeter par manque de points (1 300 000 / 147ème mondial :D )
C'est vrai que je suis inactif depuis un moment sur ce projet. J'ai tendance à aider les petits qui débutent :jap:
Alors, si quelqu'un veut bien se dévouer pour aller poser la question de l'après S5R1 sur einstein :jap:
On pourrait aussi envisager un petit mailling au cas où il n'y ait plus de travail pour quelques temps, histoire de réorienter nos membres vers d'autres projets (en mettant la priorité sur la physique).
:jap:
on dirait quil reste plus de wu en reserve, cependant les dernieres qu'on ma refillé sont bizarres, ça doit etre dans les 24h de calcul, au lieu de 2h45 pour moi avant . une explication ?
Interessant, mais l'appli Linux64 n'apporte pas d'avantage de vitesse, alors je passe.
il faut supprimer tout ce qu'il y a dans le "dossier" Einstein, puis "déziper" la nouvelle version dans ce dossier et normalement ça roule. ;)
Reviens.... Personne n'est parfait (surtout pas moi :lol: )C'est ce que j'ai fais :spamafote:.
Donc: - 1 Quitter BOINC (pour de vrai...pas d' icône ni autre)
- 2 "Explorer" jusqu'à trouver le dossier: einstein.phys.uwm.edu
- 3 Supprimer les éléments du dossier (Tous! mais pas le dossier).
- 4 "Dezipper" le fichier téléchargé dans le dossier
- 5 Relancer Boinc
ET il faut installer cette application pour continuer à recevoir du travail ?Non.
ET il faut installer cette application pour continuer à recevoir du travail ?:non:
j'ai l'impression de ne plus en reçevoir depuis plusieurs jours ...
:non: tu dois calculer sur plusieurs projets.:p, s'pas clair sinon :ange:.
Si tu veux du travail pour Einstein [...]
J'ai édité. :jap: :pCiter:non: tu dois calculer sur plusieurs projets.:p, s'pas clair sinon :ange:.
Si tu veux du travail pour Einstein [...]
Jun 27, 2008[:al@on:3] bubletitan, j'ai cliqué sur ton lien mais...
You can play a game and learn something about gravitational waves at the new website http://www.blackholehunter.org. This project was developed as part of the Royal Society Summer Exhibition 2008.
Le site http://alexandria.astro.cf.ac.uk demande un nom d'utilisateur et un mot de passe. Le site indique : « Private »
Le projet Einstein nous encourage à participer à un jeu pour en apprendre davantage sur les ondes gravitationnelles:
Citation :
News items
Jun 27, 2008
You can play a game and learn something about gravitational waves at the new website http://www.blackholehunter.org. This project was developed as part of the Royal Society Summer Exhibition 2008.
Il y a trois niveaux de difficultés: débutant, moyen et confirmé.
:hello:[:al@on:3] modesti je ne suis pas vraiment de ton avis, tu sembles te réjouir des crédits que t'accorde Einstein mais en calculant ta moyenne ça donne du 11,2 crédits/h :pfff: ce qui me semble très faible pour ce projet alors que je crois me souvenir d'un projet rémunérateur.
Je viens de finir ma première UT S5R4a. Pour 5h annoncées elle a duré 19h49 - donc sensiblement la même durée que les S5R3. Et côté crédits, rien à redire ;) http://einstein.phys.uwm.edu/workunit.php?wuid=42717659
Measured floating point speed 1539.62 million ops/secje les trouve un peu faible, voilà qu'elles sont celles de mon 3400+ non O/C
Measured integer speed 2710.07 million ops/sec
Measured floating point speed 1952.72 million ops/secmais bon je me trompe peut-être [:jwhy]... il serait bien qu'un membre calculant sur ce projet avec un mono-core nous éclaire de ses observations :D, d'avance merci.
Measured integer speed 4529.88 million ops/sec
06.09.08 18:32:04||Benchmark results:
06.09.08 18:32:04|| Number of CPUs: 1
06.09.08 18:32:04|| 1991 floating point MIPS (Whetstone) per CPU
06.09.08 18:32:04|| 3596 integer MIPS (Dhrystone) per CPU
Quant aux performances de ma bécane, je n'y connais rien, de plus elles peuvent varier d'un jour à l'autre. Pour ce même PC j'ai déjà eu ~1900 / ~3000 comme résultat. AMHA ça dépend combien d'autres logiciels (et lesquels) tournent en même temps que Boinc. [:saispas]Ça est sûr 2x!!! :D
Voilà ce que je viens d'obtenir à l'instant:Bin là c'est beaucoup mieux.Citer06.09.08 18:32:04||Benchmark results:
06.09.08 18:32:04|| Number of CPUs: 1
06.09.08 18:32:04|| 1991 floating point MIPS (Whetstone) per CPU
06.09.08 18:32:04|| 3596 integer MIPS (Dhrystone) per CPU
2008-09-25: Einstein@Home
We have completed processing the S5R3 workunits. S5R3 was the first search
using the combined F-stat plus Hough method, which is currently the
most sensitive search technique that is known. This search used approximately one year of data
from LIGO's first science run (S5) at design sensitivity.
The S5R3 post-processing is being led by Dr. Maria Alessandra Papa,
one of the inventors of the search technique.
The Einstein@Home project has started a new search for binary radio pulsars in data from the Arecibo Observatory in Puerto Rico. This will run in parallel with the existing search for gravitational waves from rapidly-spinning neutron stars. Please see this press release (http://www.aei.mpg.de/pdf/pm_news/2009/PM09_EinsteinatHome_eng.pdf) for more information.
Tue Aug 11 23:26:28 UTC 2009
Einstein@Home is down as the result of yet another fileserver crash. We are
working on repairing the filesystem now but it will likely take a couple days
before the project is running again. Further news will be posted here.
Thank you for your patience.
Fri Aug 14 17:01:20 UTC 2009
The first attempt to fix the filesystem failed and the second attempt is
underway. We will have more news in about 36 hours.
August 18, 2009
Einstein@home suffered from another severe fileserver crash last week. We were able to bring the result upload up again with a temporary solution, and are now using the downtime for some improvements of the database setup that should finally speed up re-enabling the project. We expect to have the project up & running again in about two hours, i.e. at 16:30 UTC.
Hello, visiblement rien a été signalé-sauf erreur de ma part-, mais il semble que Einstein@home travaille très activement sur une application CUDA.Je l'avais signalé dans ce topic http://forum.boinc-af.org/index.php/topic,1588.msg196655/boardseen.html#new . Je vais réeffectuer quelques tests mais pour l'instant pas possible de calculer une seule unité sans problèmes. :/
Une application test pour windows etmacLInux est disponible MAIS ATTENTION il y a des retours de bugs et j'insiste, c'est une application test.
Cela semble en bonne voie car les dev semblent réactifs et ont sortie un correctif.
Comme c'est du CUDA, ne sont donc concernées que les Nvidia.
Task details
Task ID 140790921
Name p2030_53676_76975_0054_G58.59-01.64.N_6.dm_169_0
Workunit 59079566
Created 25 Sep 2009 5:23:07 UTC
Sent 25 Sep 2009 23:45:26 UTC
Received 26 Sep 2009 4:47:41 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 2093030
Report deadline 9 Oct 2009 23:45:26 UTC
CPU time 16027.27
stderr out
<core_client_version>6.10.4</core_client_version>
<![CDATA[
<stderr_txt>
[01:45:47][7079][INFO ] Starting data processing...
[01:45:47][7079][INFO ] Using CUDA device #0 "GeForce GTX 260" (979.78 GFLOPS)
[01:45:47][7079][INFO ] Checkpoint file unavailable: status.cpt (No such file or directory).
------> Starting from scratch...
j'ai testé l'appli einstein_gpu pour linux et elle fonctionne correctement aussi bien sur 64bit que sur 32 bit..: en moyenne +20% de gain par rapport au calcul sur cpu...Chic, encore une appli gpu ! Si tu veux, je peux la tester aussi sous linux. :bounce:
sinon pour les aventuriers sous linux et possedant un gpu nvidia un zip sera dispo sur le site boinclinux contenant des fichiers à mettre directement dans le dossier einstein,ceci vous permettra de cruncher a la fois sur le cpu et le gpu...j'ai réglé le ncpu à 0.25 le changer n'apporterais pas grand chose en gain....
Pour ceux qui veulent uniquement cruncher des wu einstein sur le gpu il vous suffit de modifer le app.info ;-) amusez vous bien
Depuis quelques temps, le Ligo s'est équipé d'un supercalculateur on dirait. Ils envoient du lourd, autant que le supercalculateur allemand qui avait rejoint Einstein at Work.
Du coup, c'est le projet qui va progresser à vitesse grand V, mais pour nous autres crunchers ca fait rager avec un grand R. :gno:
160 points pour 3h de calcul :miam:
(unités GPU qui utilisent 1CPU tout entier [/quote]
Un core tu veux dire.
non. Il existe une application Cuda, qui n'est pas déployée d'ailleurs dans les applications, il faut fouiller le forum du projet pour la trouver.
Néanmoins, pour autant que je m'en souvienne, elle nécessitait jusqu'à il y a quatre ou cinq mois un core entier.
Je ne sais si elle est encore d'actualité.
oui.
Dans le tableau en haut à droite, la ligne qui nous intéresse plus particulièrement, c'est "unsent" : ça indique le nombre d'UT disponibles pour nous à l'instant T.
Le tableau S5GC1 n'indique que les UT pour le "Global Correlation 1". Il faut savoir qu'il existe aussi une appli "Arecibo" (tableau ABP).
Je pensai que dans le tableau en haut à droite c'était la ligne in database et non unsent qui disait combien d'uts à calculés...
Il faut donc additionner les trois pour savoir combien d'uts à calculer ?
Tu le fais Popo?Heeeeyy pis quoi encore ?! Nan mais ho, j'dois me taper le programme de maths de maths spé pour le 30 août, j'ai pas le temps :lol:
Sur Einstein le Gpu load est de 10%Je ne fais que du CPU sur Einstein.
ça veut dire qu'il y a 90% du Gpu qui est en vacances... :cavachier:
Sur Einstein le Gpu load est de 10%
ça veut dire qu'il y a 90% du Gpu qui est en vacances... :cavachier:
Ne pensez-vous pas que la découverte du pulsar mériterait un mail pour les utilisateurs Einstein@home de L'AF ? Ca pourrait relancer certaines personnes de montrer qu'il y a des résultats ;)
Dear Einstein@Home volunteer,
I want to share some good news with you.
For more than a year, Einstein@Home has been using about
one-third of the available computer time to search for radio
pulsars in data from the Arecibo Observatory. I'm happy to report
that we found our first radio pulsar last month: PSR J2007+2722.
It is still not sure, but this appears to be a rare type of object
called a Disrupted Recycled Pulsar. The discovery was published
on-line by the journal Science, on Thursday August 12th.
Congratulations to our volunteers Chris and Helen Colvin (Ames, Iowa,
USA) and Daniel Gebhardt (Universitaet Mainz, Musikinformatik, German),
whose computers discovered the pulsar with the highest significance!
Further details of this first Einstein@Home discovery may be found
in the main news item posted on the Einstein@Home web site, at
http://einstein.phys.uwm.edu/ . You can also use Google News
and similar searches, with keywords like 'pulsar' or 'J2007+2722'
or 'Einstein@Home' to find recent news articles about the
discovery, in English, German, French, Spanish, Russian and other
languages.
So far, Einstein@Home has only analyzed about half of the Arecibo data
set. Due to improvements in the instrumentation, the more recent data
is better-quality than the older data, so I am sure there are other
interesting objects to be discovered!
If you have trouble getting Einstein@Home to run, you may search
our user forums for help (http://einstein.phys.uwm.edu/forum_index.php)
or post a message asking for assistance in the "Getting Started" forum
at http://einstein.phys.uwm.edu/forum_forum.php?id=5
Sincerely,
Bruce Allen
Director, Einstein@Home
C'est plus la peine ! Je viens de recevoir un mail d'Einstein directement pour annoncer la découverte :p
C'est plus la peine ! Je viens de recevoir un mail d'Einstein directement pour annoncer la découverte :pje ne l'ai pas reçue... mais je ne suis plus actif sur le projet... cela peu rester intéressant !
je ne l'ai pas reçue... mais je ne suis plus actif sur le projet... cela peu rester intéressant !
ou si vous voulez relancer ( je l'ai lancé 2fois sans succès ! :D ! l'idée d'un petit NewsAF trimestriel cela vous ferai déjà un article ! ;) )
En tous cas merci pour l'info ... J'espère que ça m'aidera à convaincre Madame de l'utilité du calcul partagé ... Elle ne voit que le pc qui surchauffe en permanence et le bruit des ventilos ...
Mets le à la cave ou au garage :desole:
en fait j'opterais plutôt pour le glou-glou dans le pc et le tout relié au chauffage central ... économies en hiver! mais va faire chaud en été ...alors ça, c'est top, passe moi le schéma, et fais en part aux projets qui veulent faire des économies d'énergie... le gouvernement pourrait aussi être intéressé. Dépose un brevet, la france va devenir la plus grande plateforme de calcul partagé devant tous les autres pays réunis.... :pt1cable:
Une chaudière gaz 7500 EUR pour 21kW
avec 7500 EUR on peut consommer 21kW dans des PC et le thermostat du salon gère le taux d'utilisaion CPU de boinc!
Use CPU
Enforced by version 6.10+ yes
Use NVIDIA GPU
Enforced by version 6.10+ no
31/08/2010 17:43:57 Einstein@Home Sending scheduler request: To fetch work.
31/08/2010 17:43:57 Einstein@Home Requesting new tasks for GPU
31/08/2010 17:44:00 Einstein@Home Scheduler request completed: got 0 new tasks
31/08/2010 17:44:00 Einstein@Home Message from server: No work sent
31/08/2010 17:44:00 Einstein@Home Message from server: Your computer has no NVIDIA GPU
Je crois que je vais continuer à le faire tourner sur mon vieux PC qui n'a pas de carte graphique, là au moins pas d'ambiguïté.
La vache ! 1 UT Arecibo calculée en moins de 2h sur mon i7 en CPU only :eek: http://einstein.phys.uwm.edu/workunit.php?wuid=81270096
J'en reviens pas ! Sur mon Athlon 64 3000+ elles mettaient ~9.5 h :o
Einstein@Home hors ligne
Ils peuvent leur donner leurs noms ? :D
...
:coffeetime:
Depuis le 22 décembre une nouvelle application cuda 3.2 pour Windows (projet : Binary Radio Pulsar Search) nommée 1.04 (BRP3cuda32) est là....
Personne ne l'avait vu ? Je vais la tester....
apparemment elle serait 75% GPU et 25 % CPU...
Edit : en faite elle prend 0.20 d'un CPU...
faut croire que non car ca paye pas :lol:
500 points apparemment....
Depuis le 22 décembre une nouvelle application cuda 3.2 pour Windows (projet : Binary Radio Pulsar Search) nommée 1.04 (BRP3cuda32) est là....
Personne ne l'avait vu ? Je vais la tester....
apparemment elle serait 75% GPU et 25 % CPU...
Edit : en faite elle prend 0.20 d'un CPU...et 30 % de charge GPU
pour 1h30 500 pts...
Avec 30% de charge, je peux en faire 3 en même temps ?
je préfère de loin les faire en CPU only ... http://einstein.phys.uwm.edu/results.php?hostid=3389507:kookoo: Modesti pourquoi tu dis cela ? En tout cas tant que Collatz est dans les choux, 1 WU Einstein GPU au forfait de 500 points c'est mieux que rien (http://einstein.phys.uwm.edu/results.php?userid=100075) et comparativement au temps passé le crédit CPU est faible / Ou est ce que j'interprète mal ?
ça vaut vraiment pas le coup en GPU
Parce que - autant que je sache - Einstein squatte non seulement le GPU, mais aussi un core, tout comme Seti. Et je n'ai ni le temps, ni la patience, ni les connaissances pour trifouiller des fichiers de config pour que ça change. Donc pour moi Einstein sera en CPU only. Epicétou :D
si j'ai bien suivi, je crois que Ryzen voulait dire qu'avec 0.20 CPU, une UT met 2h ;)
Parce que - autant que je sache - Einstein squatte non seulement le GPU, mais aussi un core, tout comme Seti. Et je n'ai ni le temps, ni la patience, ni les connaissances pour trifouiller des fichiers de config pour que ça change. Donc pour moi Einstein sera en CPU only. Epicétou :D
19/01/2011 16:13:25 Einstein@Home Message from server: Your computer has no NVIDIA GPU
Nous venons de publier un 32-bit Linux CUDA binaire. Il utilise le même code source que la version Windows, mais contient une solution de contournement d'un bogue dans le pilote de planification actuelle NVIDIA CUDA. Cette solution de contournement conduit au fait que l'application doit utiliser un processeur complet, au lieu de seulement ~ 20%. Alors que ce n'est clairement pas optimale, il est probablement mieux que de n'avoir aucune application Linux CUDA à tous (rappelez-vous: la vieille ABP2 CUDA également utilisé un noyau complet, mais ce soft est beaucoup plus efficace). Dès que NVIDIA a sorti son jour le pilote de la prochaine (environ 2-3 mois à partir de maintenant) nous allons revenir à la mise en œuvre régulière qui utilise comme moins d'un noyau CPU que possible.
En attendant, nous allons continuer à améliorer l'utilisation du GPU et de précision. Nous espérons être en mesure de publier une version Mac OS CUDA dans un avenir pas trop lointain. Nous avons également commencé à se pencher sur une mise en œuvre OpenCL qui permettra éventuellement l'utilisation des GPU ATI / AMD pour Einstein @ Home.
Nouvelle appli lunix pour le projetNouvelle appli linux ? :jap:
Depuis le 22 décembre une nouvelle application cuda 3.2 pour Windows (projet : Binary Radio Pulsar Search) nommée 1.04 (BRP3cuda32) est là....
Personne ne l'avait vu ? Je vais la tester....
Edit : en faite elle prend 0.20 d'un CPU...et 30 % de charge GPU
pour 1h30 500 pts...
Pour avoir plus de travail finir les ut en cours arreter boinc et suprimer le fichier app-info :ange: redemarrer boincah ah ah çà j'avais compris...
çà signifie vraiment quoi ce message :
24/01/2011 20:37:19 | Einstein@Home | To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart.
Pour avoir plus de travail finir les ut en cours arreter boinc et suprimer le fichier app-info :ange: redemarrer boinc
ah ah ah çà j'avais compris...
Pou resevwa plis Einstein @ Kay travay, fini aktyèl travay, sispann bwenk, retire app_info.xml ranpli, epi rekòmanse.
Impetro magis opus Einstein @ Home explete current opere prohibere BOINC transfer app_info.xml lima, sileo.
Bis 2015 wird die Empfindlichkeit der Gravitationswellenobservatorien GEO600 (http://www.geo600.org/), LIGO (http://www.ligo.caltech.edu/) und Virgo (https://wwwcascina.virgo.infn.it/) ver 10-facht. Damit können die Wissenschafftler 10-mal tiefer ins Weltall horchen und hoffen dann regelmäßig Gravitationswellen zu finden. Der Upgrade der Laserquellen und Spiegelaufhängung der Laserinterferometer hat gerade begonnen. Beim GEO600 nördlich von Hannover sind einige der Neuerungen bereits im Einsatz. Die Signale der Gravitationswellenobservatorien werden teilweise im verteilten Rechenprojekt Einstein@home (http://www.rechenkraft.net/wiki/index.php?title=Einstein%40home) analysiert. Einen umfangreichen Artikel über die Erweiterungen gibt es auf astronews (http://www.astronews.com/news/artikel/2011/02/1102-011.shtml).
- En 2015, la sensibilité des observatoires d'ondes gravitationnelles GEO600 (http://www.geo600.org/) , LIGO (http://www.ligo.caltech.edu/) et Virgo (?? (https://wwwcascina.virgo.infn.it/)VER attisé 10e Cela signifie que le 10-Wissenschafftler??) loin dans l'espace puis de les écouter à nouveau et de l'espoir de trouver régulièrement des ondes gravitationnelles. La mise à niveau des sources laser et interféromètre à laser, la suspension du miroir vient de commencer. Lorsque GEO600 nord de Hanovre, quelques-unes des innovations déjà en cours d'utilisation. Les signaux des ondes gravitationnelles sont en partie dans le projet de calcul distribué Einstein @ home (http://www.rechenkraft.net/wiki/index.php?title=Einstein%40home) analyse. article détaillé, d'une part, il est offert sur nouvelles astro (http://www.astronews.com/news/artikel/2011/02/1102-011.shtml).
Einstein@Home Discovers New Binary Radio Pulsar
A new preprint reports the second Einstein@Home discovery, of a radio pulsar orbiting a white dwarf star once every 9.4 hours. The pulsar, called J1952+2630, is spinning on its axis 48 times per second. It was discovered in data collected at Arecibo Observatory in 2005 by the PALFA Collaboration. The white-dwarf companion star is unusually massive, and weighs at least 95% as much as our sun. This means that J1952+2630 probably belongs to a rare class of intermediate-mass binary pulsars (five were previously known).
The "discovery plots" can be seen near the top of the Einstein@Home (re)detection page.
Congratulations to the two Einstein@Home participants whose computers found J1952+2630 with the highest significance: Dr. Vitaliy V. Shiryaev (Moscow, Russia) and Stacey Eastham (Darwen, UK)! And a big "thank you" to all Einstein@Home volunteers, whose continuing support makes these exciting discoveries possible.
Bruce Allen
Director, Einstein@Home
SPEG zu Besuch bei Onkel Albert (http://www.seti-germany.de/blog/lang/de/2011/05/speg-zu-besuch-bei-onkel-albert)
Nach dem erfolgreichen Pentathlon hat die SPEG ein neues Basisprojekt für die nächste Zeit ausgewählt. Es handelt sich um einen guten alten Bekannten: Einstein@Home.
Zu Jahresbeginn wurde SETI.Germany vom Czech National Team auf Platz 4 verdrängt. Der Rückstand wuchs zunächst ziemlich schnell an, aber inzwischen haben beide Teams seit etlichen Wochen fast identische Tagesdurchsätze. Ziel dieser Aktion ist daher, den Rückstand von derzeit 7 Millionen Cobblestones zu reduzieren und langfristig wieder den 3. Platz hinter den beiden großen Einstein@Home-Hausteams zu besetzen. (http://www.seti-germany.de/forum/images/smilies/sg/cool.gif)
Projekt-URL: http://einstein.phys.uwm.edu/ (http://einstein.phys.uwm.edu/)
SETI.Germany beitreten: http://einstein.phys.uwm.edu/team_join_form.php?id=49 (http://einstein.phys.uwm.edu/team_join_form.php?id=49)
Artikel im SG-Wiki: http://www.seti-germany.de/wiki/Einstein@Home (http://www.seti-germany.de/wiki/Einstein@Home)
Anwendungen sind für Windows, Linux und MacOS (Intel+PPC) vorhanden, eine SSE2-optimierte Anwendung wird automatisch an alle CPUs mit dieser Befehlssatzerweiterung geschickt. Auch CUDA-Versionen für diese 3 Betriebssysteme stehen zur Verfügung.
Wir laden alle Mitglieder von SETI.Germany ein, gemeinsam mit der SPEG unser Einstein@Home-Stammteam für eine Weile zu verstärken.
This is a deliberate policy decision on my part; let me explain why.
The search for gravitational waves is the fundamental reason for Einstein@Home, and I want to keep that at the core of our activities. The scientific impact of gravitational wave detections and observations is hard to overstate.
Detecting gravitational waves is hard -- it's not a walk in the park -- and I want to ensure that at least half of our computational resources go into that direction. I hope you understand!
Salut tout le monde !Je vois où se situe le problème Guepi.
Voilà, j'ai un soucis : toutes mes unités CUDA partent en erreur, parce que le logiciel n'arrive pas à localiser les librairies CUDA.
J'ai posté sur le forum Einstein : http://einstein.phys.uwm.edu/forum_thread.php?id=8974
:??:
Des idées ?
Des remarques ?
Euh ...Personnellement, j'avais copié les librairies 32 bits téléchargées avec l'application cliente Einstein dans le répertoire /usr/local/lib32 puis exécuté la commande ldconfig dans un terminal. Après, j'avais redémarré mon client Boinc.
juste les librairies ? ou le driver 32 bits ?
Pas d'incompatibilité avec le driver 64 bits ?
Pourquoi pas juste des liens symboliques vers les librairies existantes ?
Einstein@OSG fonctionne depuis seulement six mois, il est déjà le principal contributeur à Einstein@Home, avec 10% du montant des contributions.
http://www.opensciencegrid.org/Case_Study_-_Einstein_at_OSG
Si quelqu'un pouvait dire de quoi parle en résumé cette article car avec google pas évident de vraiment comprendre...
Cela par d'une grille de calcul....
Personnellement, j'avais copié les librairies 32 bits téléchargées avec l'application cliente Einstein dans le répertoire /usr/local/lib32 puis exécuté la commande ldconfig dans un terminal. Après, j'avais redémarré mon client Boinc.
Elles rapportent pas beaucoup les unités gamma : 250 pts pour 37 000 sec ....
http://einstein.phys.uwm.edu/workunit.php?wuid=102189321 (http://einstein.phys.uwm.edu/workunit.php?wuid=102189321)
Elles rapportent pas beaucoup les unités gamma : 250 pts pour 37 000 sec...Je crois que c'est le 'tarif Einstein' c'est à dire pas extravagant (surtout en GPU quand on compare a tous les autres projets GPU!)
http://einstein.phys.uwm.edu/workunit.php?wuid=102189321 (http://einstein.phys.uwm.edu/workunit.php?wuid=102189321)
J'ai quelques problèmes de validation des unités GPU, ca vous le fait aussi ?
5 Sep 2011 19:47:01 UTC 9 Sep 2011 8:27:29 UTC Terminé, en attente de validation 4,264.68 644.21 5.32 en attente Binary Radio Pulsar Search (Arecibo) v1.00 (BRP3cuda32nv270)
5 Sep 2011 19:47:01 UTC 9 Sep 2011 8:27:29 UTC Terminé, en attente de validation 4,553.57 644.30 5.32 en attente Binary Radio Pulsar Search (Arecibo) v1.00 (BRP3cuda32nv270)
Sous linux seulement, l'optimisation 64b, non !
Je me trompe peut-être !
:hello:
C'est normal Gilles !
C'est du 32 Bit englobé dans du 64Bits ! donc c'est du 32Bits ! Hildor a raison !
http://einstein.phys.uwm.edu/apps.php
Il commence à me souler à foirer environ 50% des WUs en GPU ... :priz2tet:bizarre...t'as quoi comme config, moi c'est nickel chrome. Attention, il ne faut pas bidouiller un cc-config.xml ou un app-info.xml, il aime pas....
tu veux pas mettre tes trads sur le portail ?il faudrait SVP corriger la petite faute de frappe: publication (et non publiquation) :jap:
:hyperbon: Einstein@home découvre un nouveau pulsar radio gâce aux données d'Arecibo :hyperbon:
Je suis très heureux d'annoncer que Einstein@Home a découvert un troisième pulsar-radio dans les données de l'Observatoire d'Arecibo.
Il s'agit de la première découverte de Einstein@Home gâce aux données d'Arecibo.
Elles ont été prises avec le nouveau spectromètre back-end « Simulation ».
Le pulsar est exceptionnel, il s'agit d'un pulsar de courte période (milliseconde) dans un système binaire.
Plus de détails sur le pulsar nouvellement découvert ici : http://einstein.phys.uwm.edu/radiopulsar/html/BRP4_discoveries/
Une publiquation officielle interviendra un peu plus tard.
Félicitations à vous, les bénévoles, nous vous remercions de votre participation au projet Einstein@Home !
Bruce Allen
Directeur, Einstein@Home, le 27 Oct 2011 21:21:25 UTC
bizarre...t'as quoi comme config, moi c'est nickel chrome. Attention, il ne faut pas bidouiller un cc-config.xml ou un app-info.xml, il aime pas....
Deux 9800 GTX+ ... pas d'OC ni de bidouilles installées ...Je vois pas... je crois qu'avec Milky et ces cartes il y avait un souci mais je ne sais pas si il y a un rapport. C'etait avec les 9800 quelque chose.
Elle sont pas double précision, donc pas Milky de toutes façons ...Exact, :desole: ca devait etre avec GPUGRID alors!
Oui, GPUGRID est pas très stable non plus et ne l'a jamais été :/avec les 9800 certes, mais avec les autres cartes successives que j'ai eu, j'ai jamais trop eu de problemes sauf pour la GTS200 (je ne me souviens plus du chiffre exact) aussi je crois. Avec les GTX actuelles, no souci :coffeetime:. Il vaut mieux avoir les derniers drivers quand meme.
:kookoo:On peut le féliciter :kookoo: :jap:
Je completerai qu'un des deux volontaires sur l'unité crunch pour l'AF!! C'est Georges01 (http://statsbzh.boinc-af.org/user.php?cpid=d66d8d70fdb813b4dceafac051372da5)
:05_16:
hello j ai 4 ordi et quand je demande du travail sur 1pc je reçois ce méssageIl manque un s à phy dans l'URL.
http://einstein.phy.uwm.edu//host_sched_logs/5140/5140371 ou l'id du pc auquel je demande du travail
2012-05-03 21:51:15.9764 [PID=17293] Request: [USER#xxxxx] [HOST#5140371] [IP xxx.xxx.xxx.119] client 6.12.34
2012-05-03 21:51:15.9847 [PID=17293] [send] effective_ncpus 5 max_jobs_on_host_cpu 999999 max_jobs_on_host 999999
2012-05-03 21:51:15.9848 [PID=17293] [send] effective_ngpus 3 max_jobs_on_host_gpu 999999
2012-05-03 21:51:15.9848 [PID=17293] [send] Not using matchmaker scheduling; Not using EDF sim
2012-05-03 21:51:15.9848 [PID=17293] [send] CPU: req 0.00 sec, 0.00 instances; est delay 0.00
2012-05-03 21:51:15.9848 [PID=17293] [send] CUDA: req 0.00 sec, 0.00 instances; est delay 0.00
2012-05-03 21:51:15.9848 [PID=17293] [send] work_req_seconds: 0.00 secs
2012-05-03 21:51:15.9848 [PID=17293] [send] available disk 3.95 GB, work_buf_min 0
2012-05-03 21:51:15.9848 [PID=17293] [send] active_frac 0.996363 on_frac 0.997210 DCF 0.887095
2012-05-03 21:51:15.9869 [PID=17293] Sending reply to [HOST#5140371]: 0 results, delay req 60.00
2012-05-03 21:51:15.9872 [PID=17293] Scheduler ran 0.017 seconds
Einstein@Home GPU Application for ATI/AMD Graphics Cards
After more than a year of work by Oliver Bock, Bernd Machenschalk, Heinz-Bernd Eggenstein and other developers, we are pleased to announce the release of the first Einstein@Home application for ATI/AMD Graphics Cards.
This OpenCL application, which searches Arecibo data for new radio pulsars, is about a factor of ten faster than the same search running on a typical CPU. The application is currently available for Windows and Linux computers with Radeon HD 5000 or better graphics cards. We hope to have a version for Macintosh (Apple OS X 10.8, Mountain Lion) sometime this summer, but there are still some problems that need to be fixed or worked around.
Volunteers who wish to run this application will need to install version 7.0.27 or later of the BOINC client. Please see this thread for more information, or if you want to ask questions.
Many thanks to the AMD/ATI team for their support in the OpenCL software development effort.
Bruce Allen
Director, Einstein@Home
Einstein@Home GPU Application for ATI/AMD Graphics Cards
Après plus d'une année de travail de Oliver Bock, Bernd Machenschalk, Heinz-Bernd Eggenstein et d'autres développeurs, nous sommes fiers d'annoncer la sortie de la première application GPU ATI pour Einstein@Home.
Cette application OpenCL, qui recherche dans les données Arecibo de nouveaux pulsars, est environ 10x plus rapide que la même recherche sur CPU. L'application est actuellement dispnible pour Windows et Linux avec une carte de génération Radeon HD 5000 ou supérieur. Nous espérons avoir une version pour Macintosh (Apple OS X 10.8, Mountain Lion) cette été, mais il existe encore des problèmes qui doivent être résolus.
Les personnes souhaitant utiliser cette application devront installer la version client BOINC 7.0.27 ou supérieur. Si vous avez des questions veuillez les poser dans ce fil de discussion.
Merci beaucoup à l'équipe AMD/ATI pour leur aide dans le développement de l'application OpenCL.
Bruce Allen
Directeur, Einstein@Home
Merci pour l'info, Cédric. Vais probablement tester après le Pentathlon. Ça pourrait me faciliter l'atteinte de mes objectifs perso :gniak::+1:
Radeon HD 5000 or better graphics cards
Il s'agit probablement d'un problème d'allocation CPU, je suppose que ses règlagles sont à 100% d'utilisation des CPU et comme BOINC gère assez mal le truc, ça traine en longueur. :/
Voila l'explication ...
Einsten ne fait pas tourner l'application en GPU avec ma CG HIS Radeon HD 6970 2Go, 900 MHz GPU et 1400 Mhz RAM, GPU = 0% !!!
Conclusion = Pas encore très au point Einsten en GPU pour les ATI !!!Sur ce type de projet, le CPU effectue encore une partie du calcul.
P.S.: Allez les gars de Einsten remettez la sauce et faite nous cette fois-ci un truc qui tienne vraiment la route et pas plein de BUG !!!
Sur HD 7950 Saphire dual X OC 950Mhz (d'usine) overclock à 1000Mhz ...
Sur HD 7950 Saphire dual X OC 950Mhz (d'usine) overclock à 1000Mhz et windo7 64Bits (après je fais un petit test sur Ubuntu :D )
C'est vrai l'HT peut y être pour quelque chose. Faudrait que je teste sur mon Q6600 et ensuite le E6600 pour voir s'il y a une montée en charge du CPU.
Message très constructif :cpopossib:
Voici le lien (http://einstein.phys.uwm.edu/license.php) pour télécharger le code source de l'application. Libre à toi de le l'optimiser pour les calculs GPU.
After several years of analysis and post-processing work, the results of the Einstein@Home search for gravitational waves in the full LIGO S5 data set are now publicly available. The paper can be found here http://arxiv.org/abs/1207.7176 (http://arxiv.org/abs/1207.7176).
The results are negative: no statistically-significant gravitational wave signals have been detected. However the search excluded signals with a greater level of sensitivity than previously achieved. For example, in the 0.5 Hz-wide band at 152.5 Hz, signals with intrinsic strain h0 greater than 7.6e-25 are excluded with 90% confidence.
Einstein@Home will continue to search for gravitational-wave signals. In the long term, we are optimistic. The LIGO and VIRGO and GEO detectors are all undergoing hardware upgrades to improve their sensitivity, and Einstein@Home will continue to develop and employ better and more sensitive data analysis methods.
Bruce Allen
Director, Einstein@Home
Comment ça c'est négatif et les pulsars découverts c'était quoi??l'objectif c'etait de detecter des ondes gravitationnelles, c'est la qu'ils n'en ont pas encore trouvés. PArc contre, ils ont bien trouvé des pulsars 'en plus'.
Over the coming weekend there will be interruptions of the network services at UWM which will affect Einstein@Home. We'll shut down the daemons at AEI (affecting validation of BRP and FGRP applications), but try to keep uploads, downloads and the scheduler running and accessible as much as possible. More details will be posted in the comments section to this news item.
From the official UWM announcement:
"There are three (3) windows during which services may be interrupted.
All times are CDT (Milwaukee time):
1. Friday August 10, 6:00 PM - 12:00 AM
2. Saturday August 11, 6:00 PM - 02:00 AM
3. Sunday August 12, 12:00 PM - 03:00 PM
The UWM campus data center will be significantly re-configured
during these two outages and there will be DNS outages during those windows."
It might well be that due to the DNS outages Einstein@Home may be unavailable for longer times than the announced ones from your area / provider.
BM
J'aime bien sa théorie :DMoi j'aime bien l'accent :lol:
Super!!! pour celles et ceux qui font du Albert@Home(=projet beta de Einstein@Home), on s'en est déjà apercu et c'etait donc previsible. :hyperbon: :hyperbon: :hyperbon: :sun:Moi, je trouve que ce projet est plus valorisant que DistrGen et consorts.
C'est toujours 500 credits/UT avec ce gain de temps. De toute facon, on reste extremement loin des taux de credits accordés de Distrtgen ou Donate et même Milky ou Poem!!! :/
Y'a qqu'un qui a déjà eu des WU GPU Mac OS X opencl-ati-lion ?Je ne pense pas qu'il soit possible de cruncher sur Einstein en GPU avec une 4850. Il me semble qu'il faut au minimum un 5850.
Chaque fois que mon boinc a fait des demandes il avait toujours 0 retour...
Ils ont dépassé les 800 tFlops grace à RUSSIA qui était l'équipe que nous avions en point de mire pour le FB et qui nous avait mis dan sle vent en septembre dernier... On ne les dépassera jamais...
J'ai mis a jour le premier post avec un lien qui donne le temps de calcul des unités GPU en fonction du GPU et du nombre d'unités faites par GPU. C'est sur la ligne 'temps de calcul' du tableau:oki:
Ah je viens la voir celle-ci:Racine latine ? Péta Flop =
(http://einstein.phys.uwm.edu/forum_thread.php?id=9872#121868)
Congratulations and thank you to all Einstein@Home volunteers: sometime shortly after January 1st 2013, Einstein@Home passed the 1 Petaflop computing-power barrier. To put this in context, according to the current (November 2012) Top-500 computing list, there are only 23 computers on our planet that deliver this much computing power.
(One Petaflop is 1,000,000,000,000,000 floating point operations per second.)
Congratulations and thank you again, and keep on crunching!
Bruce Allen
Director, Einstein@Home
Quelqu'un sait ce qui arrive aux dernières UT Einstein GPU ? Au lieu de 28-34 minutes elles mettent >3h !!! :eek: Alors que je ne tourne exprès que sur 6 coeurs / 8 sur le i7.Ah, moi c'est OK... j'ai pas de problème, c'est proche de 30minutes. Bon avec yoyo en parallèle, ca semble un peu plus long mais plutot dans les 40minutes ...
Exemple d'UT en pending: http://einstein.phys.uwm.edu/result.php?resultid=351534086
Et celle en cours en PJ
j'ai déjà répondu 2 fois à cette question ce soir mais pas dans ce topic :/ :priz2tet: :priz2tet: :priz2tet:Et donc il faut cocher combien de case 1 ou 2 ? a la fois ou en meme temps? :ange:
La réponse (écrite dans le sujet sur le RAID plus un uatre sur le GPU) est qu'il y a une erreur et que la deuxième question c'est 'autoriser un GPU ATI' et pas 'autoriser le CPU'....
En visuel :sun:
(http://img.lbzh.fr/thumbs/514506c37e144_600.jpg)
oui, avec ca , ca devrait carburer...Ya un bug en effet! des fois c'est des histoires de droit sur le dossier. Detaches toi fermes boinc, rouvres le puis reattache toi des fois que...
Je vais même rester à une UT à la fois car si je met 2 UT à la fois je perd un cœur entier pour yoyo..si tu mets une UT Einstein, tu occupes un 1/2 coeur...que fait l'autre demi ? du yoyo ou du Einstein ou...rien??? that is the question
Ha ! Ça fonctionne comme ça avec les mac ! :??:
Sur GNU/Linux c'est pris en compte dès la mise à jour du projet au démarrage d'une unité suivante. Celle(s) en cours continue(nt) avec les précédants réglages. :pt1cable:
"Le pilote d'affichage ne répondait plus et a été récupéré"J'ai souvent cette erreur également sous seven avec une GTX660
Descend un peu la fréquence du GPU !? voir copie écran (elle est au repos là :desole:)
Elle doit être trop overclocké ou chauffe trop.
C'est au repos ca ... on s'en fout un peu ...En activité tu verras la même chose (c'était juste pour prévenir les remarques des cruncher open bar :hyperbon:), il y a les cales sur les compteurs et là OK info sur fréquence, voltage etc
J'ai un petit souci, quand j'ai Einstein qui tourne (une seule UT, calcul sur le GPU), j'ai des fois l'écran qui s'éteint pendant deux secondes, et quand ça se rallume j'ai le message ::hello:
"Le pilote d'affichage ne répondait plus et a été récupéré"
Quand je vais dans le boinc manager, j'ai l'unité Einstein en cours de calcul qui s'est mise en pause et j'ai "not enough free CPU/GPU avalaible !".
J'ai une autre unité qui a commencé entre temps.
Est ce que c'est la mémoire de la carte graphique elle même ? dans ce cas, j'imagine que je peux rien y faire....
Là je ne vois pas, détacher et rattacher, peut-être :desole:
Ca peut venir du réglage des réserves mini/maxi.merci c est vrai que c est une bonne idee vu que je tourne toujours avec mini 0.25 j et max 0.33 j
le cas d'Einstein est un peu particulier. A l'origine, c'était un mixte CPU et GPU (pas Opencl) fait pour NVIDIA. ils l'ont adapté opencl pour les ATIs. Mais meme dans l''ancien temps' pas si ancien que ca, Einstein utilisait beaucoup le CPU. Pourquoi, je ne sais pas encore...
Les unités GPU du projet Einstein sont des unités mixtes (CPU+GPU).le cas d'Einstein est un peu particulier. A l'origine, c'était un mixte CPU et GPU (pas Opencl) fait pour NVIDIA. ils l'ont adapté opencl pour les ATIs. Mais meme dans l''ancien temps' pas si ancien que ca, Einstein utilisait beaucoup le CPU. Pourquoi, je ne sais pas encore...
J'avais cru lire un jour que c'était parce que certains calculs d'Einstein ne pouvaient pas être faits sur le GPU (pour X raison), tout comme chez SETI d'ailleurs.
Tu peux le faire via ton manager, mais aussi dans les préférences générales :jap:
Edit : Outils> préférences de Calcul > Utilisation du processeur
Je n'ai pas non plus compris la raison pour laquelle on doit s'inscrire, hormis d'être informer sur l'évolution du projet, mais je vous partage les différents lien.Pour soutenir le projet J'ai mis un post ici --> http://forum.boinc-af.org/index.php/topic,475.msg353799.html#msg353799
Topic sur les forums d'Einstein@Home : http://www.elisa-ngo.org
Inscription : http://support.elisascience.org
Site internet de eLISA-GO : http://www.elisa-ngo.org
regarde aussi le premier post de ce sujet sur Einstein, dans le tableau, tu as un lien vers un fichier pdf qui donne des temps en fonction du nombre de GPU utilisés et de ta CG...
@quatraille...
Monter un GPU sur un ordi avec un Pentium4. Déjà bravo :eek: :eek:.
Einstein utilise beaucoup le CPU donc c'est sur que si tu utilises un processeur 'prehistorique' en parallele avec ton GPU, ca fait monter en fleche ton temps de calcul. Je pense que c'est la cause de ton problème de temps. Bon maintenant 1180 secondes, c'est impressionnant avec une GTX660Ti, ca fait en gros vingt minutes, moi j'ai plutot plus avec une GTX670 (30minutes) mais 2 à la fois.
:hello:
Spica tu peux me donner le lien pour le tutoriel qui indique comment calculer 2 UT Einstein à la fois stp ? :jap:
Je comprends pourquoi je n'ai pas mieux performé avec une 680 + une 670 pendant le pentathlon :/
@Informat : je vais te piquer ton pc, tu vas moins rigoler :fuck: looool
The main Einstein@home server crashed about half an hour ago with a filesystem error. Checking and repairing this will take a while. We are trying to keep the downtime below 24h.
(since we don't have any means to notify people over at Einstein, I'm doing this here)
Je suis chiant avec çaLe mot est juste :siflotte:
Je suis chiant avec ça, mais certaines personnes disent qu'il faut laisser un core pour les unités GPU, mais apparemment cela ne prend que 0.2 d'un CPU... (13% chez moi)Moi Einstein, je mets 100%... de toute façon, fais des UTS avec 100% puis apres tu fais avec 75%, si tu gagnes peanuts en temps remets 100% comme ca, tu pourras cruncher une unité CPU en plus...
Donc je reste à 80% ou je peux mettre 100% ? Je suis bien à 3 core réelles utilisé...
J'ai cru en apercevoir une entre le Grand carré de Pégase et la diagonale d'Andromède.:??: :??:
J'ai cru en apercevoir une entre le Grand carré de Pégase et la diagonale d'Andromède.
Merci ! je vais en Tester Chez Albert :jap:J'ai cru en apercevoir une entre le Grand carré de Pégase et la diagonale d'Andromède.:??: :??:
Ne pas confondre Perseus =application GPU Einstein et les Perséides, étoiles filantes issues de la constellation de Persée.
En ce moment, je ne fais pas d'Einstein mais du Albert et là, il y a des Perseus...
:bhs: Einstein a fumé la moquette ! :cavapabiendantateute:Tiens... ca m'ai déjà arriver aussi.. Je m'étais demandé si ce n'était pas moi qui avait fumé la moquette... Je crois me souvenir que tu peux mettre fin à ce cirque en arretant le BM et en le relancant... par contre, j'ai pas trouvé les symptomes qui le font délirer
Depuis hier matin je l'ai mis en "pas de nouveau travail". Il me restait alors une 40aine ou une 60aine d'UT.
Ce matin, j'ai113125 UT sur l'ordi :pt1cable: En regardant bien, il me les a chopées par paquets de douze tout au long de la nuit.
Moi qui voulais vider mon cache, c'est un peu foutu :priz2tet: :priz2tet:
juste le souk...je confirme.
non, pas d'appli optimisées, elles le sont déjà, il sont embauché quelqu'un qui le fait et l'a fait dans le passé.
c'est sur que ca crédite 10 ou 20 fois moins que Collatz!!!et 1000 fois moins que BU....
juste le souk...je confirme.
pour etre plus précis avec mes 2 ATIs sur Einstein, c'est du 50k par jour. Avec Collatz c'est visiblement 2Myions soit un rapport de 40!
Je comprends (pas tout ;)) ce que tu dis.L'optimisation sur SETI n'est pas optimale et concerne essentiellment la partie CPU, aussi très importante sur SETI.
Par contre, pour SETI, Lunatics propose des applis optimisées pour CPU et GPU.
Tant mieux si on peut toujours utiliser des cartes moins récentes sur ce projet,
:hello:
Tu mets 0,5 dans les préférences en bas sur les projets.
Ensuite, tu peux redémarrer tout ce que tu veux, ca ne sera effectif QUE quand tu auras fini ton UT Einstein en cours et qu'il redemandera du travail...
tu vas y gagner!!!! presque un facteur 2
Je me suis un peu gouré, je ne fait qu'une tâche à la fois, mais j'ai 2 cartes 560ti, j'essaye avec 2 tâches en // pour voir !
:( plus de 14H de calcul et ma HD6770m n'a toujours rien produit, je passe donc avec la R9 290 sur le projet. :cavachier:
Hello ! :hello:
juste Pour info :
Sur mes cartes, PERSEUS crédite, à peu de chose près, environ 13% - 14 % de mieux que ARECIBO.
PERSEUS = Moyenne de 10750 secondes pour 3333 points
ARECIBO = Moyenne de 3700 secondes pour 1000 points
Pas essayé sur 660Ti, uniquement sur 970
:hello: :kookoo:
Ma 750ti est pas ridicule 3500s pour 1000 :gno:
Je confirme sur collatz c du du 90% sans fluctuation et sur Einstein avec la même config (avec réglages de base) ca fait le yoyo entre 20 et 80%
J'ai mis a jour le premier post avec un lien qui donne le temps de calcul des unités GPU en fonction du GPU et du nombre d'unités faites par GPU. C'est sur la ligne 'temps de calcul' du tableau
Hi guys,
Here's some brief background info:
- We do use NVIDIA's CUFFT in our CUDA apps.
Nous utilisons les fonctions CUFFT (https://developer.nvidia.com/cufft) de nVidia dans nos applications CUDA
- We always try to support as many GPU models as possible, even if that means to sacrifice some performance by not upgrading to later CUDA versions.
Nous essayons depuis toujours de "supporter" le plus grand nombre de modèles de GPU, même si cela implique de ne pas bénéficier de l'augmentation de performances en passant à des versions CUDA supérieures.
- There was a nasty bug in CUDA >3.2 that prevented us from upgrading until the release of CUDA 5.5.
Il y a eu un gros bug en utilisant CUDA > 3.2 qui nous a empêché toute mise à niveau jusqu'à la sortie de CUDA 5.5.
- We do have a CUDA 5.5 version that could be released but up to now the incentive to do so wasn't given (to justify the effort involved).
Nous avons une version CUDA 5.5 qui pourrait être lancée, mais jusqu'à présent les gains espérés ne justifiaient pas de le faire. (ni l'effort pour le faire)
- NVIDIA drops 32 bit driver support and we already began shipping 64 bit CUDA apps, starting with OS X, based on CUDA 5.5.
nVidia arrête de supporter les drivers 32 bits, et nous avons commencé à utiliser des apps CUDA 64 bits, en commençant par OS X, sur base de CUDA 5.5.
- We'll check how much CUDA 6.5 can improve the FFTs we use and whether it would justify a parallel release of CUDA 6.5 binaries.
Nous allons vérifier dans quelle mesure CUDA 6.5 peut améliorer les FFTs que nous utilisons, et si ça vaut la peine de lancer des UT en CUDA 6.5 [binaries]
Cheers,
Oliver
NVIDIA drops 32 bit driver support and we already began shipping 64 bit CUDA apps, starting with OS X, based on CUDA 5.5.
nVidia arrête de supporter les drivers 32 bits, et nous avons commencé à utiliser des apps CUDA 64 bits, en commençant par OS X, sur base de CUDA 5.5.
08/01/2015 01:08:08 | Einstein@Home | [error] Error reported by file upload server: Maintenance underway: file uploads are temporarily disabled.donc, c'est einstein qui a un p'tit souci...
Run beta/test application versions? oui:cpopossib: :o
6 Mar 2015 10:35:33 UTC 20 Mar 2015 10:35:33 UTC En cours --- --- --- --- Binary Radio Pulsar Search (Parkes PMPS XT) v1.39 (BRP5-cuda32-nv270)
Dear Einstein@Home volunteers,
February 19th was the tenth anniversary of the Einstein@Home launch. A lot has happened in
the past decade, and thanks to your support, the project has become one of the largest
distributed volunteer projects on the planet. Thank you for helping Einstein@Home to do
great science!
We would like to begin Einstein@Home's anniversary year by launching the Einstein@Home
newsletter. Four times a year, project scientists and developers will tell you about our
exciting science. In each newsletter, a handful of Einstein@Home team members will report
on what they have been up to, and what their plans for the future are.
Our first newsletter features updates from Bernd Machenschalk on how the project operates,
and from M. Alessandra Papa on Einstein@Home's latest and most sensitive
gravitational-wave hunt. Benjamin Knispel brings you up to speed with the search for
binary radio pulsars and Holger Pletsch has news on the Fermi gamma-ray pulsar analysis.
Enjoy!
Bruce Allen, Director, Einstein@Home
News on the gravitational-wave search (M. Alessandra Papa)
----------------------------------------------------------
The Einstein@Home all-sky search for continuous gravitational-wave signals in LIGO data,
in the frequency range of 50 to 450 Hz, has given us over 16 million candidates to
follow-up in LIGO S6 data. A first stage follow-up is currently running on Einstein@Home
and should end soon. We have already lined up the next step: a second-stage follow-up of
the most promising (some millions) of these candidates. This second stage inspects the
candidates much more closely, and reduces the uncertainty in the signal parameters by
about 90%. This second follow-up digs deeper into the detector noise, and will
significantly increase the sensitivity of our search. This is very exciting because it is
the first large scale deep follow-up we have ever performed!
In addition to these all-sky searches, Einstein@Home is also searching for continuous
gravitational waves from specific targets in the sky. For the next stage of this, studies
are ongoing to determine the optimal search set-up, the most promising target
astrophysical objects, and the appropriate frequency and frequency-derivative search
ranges. The next Einstein@Home targeted-search runs will be based on the results on these
studies.
News on the binary radio pulsar search (Benjamin Knispel)
---------------------------------------------------------
Einstein@Home is currently analyzing data from two different radio telescopes. The BRP4
run is searching data taken very recently with the Arecibo radio telescope as part of the
PALFA survey. This is an ongoing survey: once we catch up with the backlog of
observational data, the search is paused, and resumes when new data arrives. The BRP5 run
that was analyzing data from the Parkes radio telescope, taken in the so-called "Perseus
Arm survey”, has recently finished. So far, we have identified several weak candidates,
but sadly, attempts to re-observe them with the Parkes radio telescope revealed that they
were all false alarms.
The latest binary radio pulsar search, called BRP6, is a further analysis of archival
observations from the Parkes Telescope, from the very successful Parkes Multi-beam Pulsar
Survey (PMPS). Previous Einstein@Home analysis of this data searched for pulsar spinning
up to 130 rotations per second, and led to the discovery of 24 new pulsars
(http://arxiv.org/abs/1302.0467). This new analysis, based on improvements in the
Einstein@Home GPU apps, will go up to 300 Hz. This is interesting territory: fast-spinning
pulsars in short-orbital-period binaries are extremely exciting astronomical objects,
which enable precise tests of general relativity with them and studies of stellar
evolution and the pulsar population in our Galaxy. We feel sure that more treasures remain
to be uncovered!
News on the gamma-ray pulsar search (Holger Pletsch)
----------------------------------------------------
Recently, we developed advanced methods (http://arxiv.org/abs/1408.6962) to improve the
sensitivity of blind searches for unknown gamma-ray pulsars in data from the Large Area
Telescope on board NASA's Fermi Satellite, which was launched in 2008. These techniques
boost the sensitivity significantly: we can now detect gamma-ray pulsars that are 50%
fainter than before, without increasing the computational cost! Our latest Einstein@Home
run, FGRP4, makes use of these improvements to conduct a new blind survey of unidentified,
pulsar-like Fermi sources.
The combination of improved methods, with the extra sensitivity of the latest Fermi data,
makes us optimistic that we will make new discoveries. In fact we have already identified
a large number of highly significant pulsar candidates and are currently carefully
studying them.
News from the project administration (Bernd Machenschalk)
---------------------------------------------------------
We had a busy time around the end of last year! The locality scheduling for the new
gravitational-wave analysis turned out to require much more attention than expected. We
were very busy moving data around and improving the locality scheduler - and still are.
Before the holidays we tried to get the entire project in a shape where it could survive
without us -- we wanted to be with our families and friends and not busy keeping the
project running. But it turned out that we had underestimated the progress that
Einstein@Home would make: we got an unexpected boost of computing power over the holidays,
and ran out of "work"! Fortunately this was easily fixed.
More importantly, there was to a bug in our server monitoring, which resulted in one of
the Einstein@Home servers filling up without any warning. The affected server holds the
uploaded result files from all Einstein@Home clients. Its file system was filled to the
brim, which had severe consequences for the project. It took about a week to get the
project running again smoothly. This was the first unplanned long downtime of
Einstein@Home for quite a number of years. We did use the downtime for some improvements,
which mean that the server is now working better than ever before!
Finally, some security issues turned up (the widely discussed gethostbyname() or "GHOST"
problem) that needed urgent attention, and required updating and rebooting about 20
project servers.
-----------------------------
If you would like to discuss this newsletter with other Einstein@Home volunteers, and the
project developers and scientists, please visit this thread in the discussions forum:
http://einstein.phys.uwm.edu/forum_thread.php?id=11211
Thank you for your continued support,
Bruce Allen, Benjamin Knispel, Bernd Machenschalk, M. Alessandra Papa, and Holger Pletsch
for the Einstein@Home team
Jolie machine.
:oki:
Coolermaster haf-xb
Merci pour l'info, mais trop petit, mais j'ai 3 Graveurs 5 1/2.
:hello:
Pour moi, je ne change les prefs Einstein que sur le site Internet de Einstein, ca marche très bien...oui mais en changant pour 0.5 sur le site de Einstein, dès lors 2 coeurs sont utilisé en GPU
2 UTs GPu à chaque fois (donc coefficient 0,5 sur le site) . Sachant que chacune utilise 0,2 CPU, la somme des 2 est 0,4 CPU. Cela me mange un core CPU et pas besoin d'en libérer un deuxième, ca ne sert à RIEN.. sauf peut-etre pour des projets CPU très gourmands en CPU/RAM...
p2030.20150528.G67.68+01.06.S.b0s0g0.00000_1728_2 224359696 28 Jul 2015 0:24:46 UTC 28 Jul 2015 10:42:40 UTC Terminé et validé 9,848.44 896.24 9.82 1,000.00 Binary Radio Pulsar Search (Arecibo, GPU) v1.39 (BRP4G-opencl-ati)Je sais que ce n'est pas comparable mais sur Collatz ça donne
p2030.20150528.G33.92-01.93.N.b2s0g0.00000_1680_0 224370508 28 Jul 2015 0:24:46 UTC 28 Jul 2015 5:41:59 UTC Terminé et validé 8,307.26 914.90 10.03 1,000.00 Binary Radio Pulsar Search (Arecibo, GPU) v1.39 (BRP4G-opencl-ati)
p2030.20150528.G33.92-01.93.N.b2s0g0.00000_1648_1 224370506 28 Jul 2015 0:24:46 UTC 28 Jul 2015 3:23:32 UTC Terminé et validé 8,226.14 913.42 10.01 1,000.00 Binary Radio Pulsar Search (Arecibo, GPU) v1.39 (BRP4G-opencl-ati)
371,78 crédits/h = 17845,44 crédits/j
20048522 17199051 27 Jul 2015, 22:59:56 UTC 28 Jul 2015, 2:57:33 UTC Terminé et validé 153.53 15.00 778.04 Mini Collatz Conjecture v6.05 (opencl_amd_gpu)Je ne suis pas très regardant pour les crédits, mais là ça frise l'insolence. :cpopossib:
20048508 17184089 27 Jul 2015, 22:59:56 UTC 28 Jul 2015, 2:57:33 UTC Terminé et validé 149.92 12.28 738.14 Mini Collatz Conjecture v6.05 (opencl_amd_gpu)
20048499 17199032 27 Jul 2015, 22:59:56 UTC 28 Jul 2015, 11:04:08 UTC Terminé et validé 149.66 10.21 744.41 Mini Collatz Conjecture v6.05 (opencl_amd_gpu)
17966,94 crédits/h = 431206,56 crédits/j
Pour la Temp j'avais trouvé des liens. ;)
En ce qui concerne la charge GPU elle est de 32% https://lut.im/5HiHsqC2/YXsiPdhL :/... c'est une grosse feignasse cette CG. :siflotte:
Je sens que je vais améliorer ma 'feignasse' avec 3 en parallèle je suis à 65% GPU avec 2...mais TThrottle surveille aussi...
PM0040_01331_26_1 224381320 11995981 28 Jul 2015 12:54:17 UTC 28 Jul 2015 20:25:06 UTC Terminé, en attente de validation 27,017.79 2,686.06 29.43 en attente Binary Radio Pulsar Search (Parkes PMPS XT) v1.53 (BRP6-opencl-ati)Le gars (Chris Kojiro (http://einstein.phys.uwm.edu/show_host_detail.php?hostid=6565066)) qui calcule avec moi la 1ère UT à une GTX 660 (2048MB) avec un Xeon E5-1620 0 @ 3.60GHz sous W$ 7 et met en moyenne 6500/UT :cry:
PM0040_01341_348_1 224381286 11995981 28 Jul 2015 12:54:17 UTC 28 Jul 2015 20:26:08 UTC Terminé, en attente de validation 27,050.51 2,683.42 29.40 en attente Binary Radio Pulsar Search (Parkes PMPS XT) v1.53 (BRP6-opencl-ati)
PM0040_006B1_96_0 223845441 25 Jul 2015 16:15:11 UTC 26 Jul 2015 23:10:53 UTC Completed and validated 14,655.12 4,384.97 34.18 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-opencl-ati)
PM0040_006B1_94_0 223845440 25 Jul 2015 16:15:11 UTC 26 Jul 2015 19:10:34 UTC Completed and validated 14,699.29 4,385.08 34.18 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-opencl-ati)
PM0040_01061_140_1 224338195 27 Jul 2015 12:18:18 UTC 27 Jul 2015 19:14:36 UTC Completed and validated 11,207.56 787.74 9.30 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-cuda32-nv301)Sur GTX980 Gold, 1UT/GPU (flemme de modifier le app config)
The new LIGO magazine is out and it features an article about Einstein@Home. You read a pdf file of the article here (http://www.ligo.org/magazine/LIGO-magazine-issue-7.pdf#page=18) . The article was written by M. Alessandra Papa, Benjamin Knispel, Holger Pletsch and Bernd Machenschalk from the Einstein@Home team, looking at the project's history, infrastructure, and different searches.
Do have a look at this and the earlier issues (http://www.ligo.org/magazine/) of the LIGO Magazine to learn more about the LIGO gravitational detectors.
Benjamin Knispel, project scientist
ca arrive de temps en temps. prends les autres, elles créditent plus en plus. Elles sont un peu plus longues, c'est tout
pas besoin d'app config, dans les préférences de Einstein, mettre 0.5 dans 'GPU utilization factor of BRP apps' au lieu de 1 par défaut, là où c'est 'dangerous'...CiterPM0040_006B1_96_0 223845441 25 Jul 2015 16:15:11 UTC 26 Jul 2015 23:10:53 UTC Completed and validated 14,655.12 4,384.97 34.18 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-opencl-ati)
PM0040_006B1_94_0 223845440 25 Jul 2015 16:15:11 UTC 26 Jul 2015 19:10:34 UTC Completed and validated 14,699.29 4,385.08 34.18 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-opencl-ati)
Sur HD7950, 2UT/GPUCiterPM0040_01061_140_1 224338195 27 Jul 2015 12:18:18 UTC 27 Jul 2015 19:14:36 UTC Completed and validated 11,207.56 787.74 9.30 4,400.00 Binary Radio Pulsar Search (Parkes PMPS XT) v1.52 (BRP6-cuda32-nv301)Sur GTX980 Gold, 1UT/GPU (flemme de modifier le app config)
pas besoin d'app config, dans les préférences de Einstein, mettre 0.5 dans 'GPU utilization factor of BRP apps' au lieu de 1 par défaut, là où c'est 'dangerous'...
Pour que ce parametre fonctionne il ne faut aucune UT Einstein en cours. :kookoo:pas besoin d'app config, dans les préférences de Einstein, mettre 0.5 dans 'GPU utilization factor of BRP apps' au lieu de 1 par défaut, là où c'est 'dangerous'...
chez moi ce parametre n'a jamais eu le moindre effet, il faut tjs que je passe par un app_config :)
Voilà DonP, tu as la réponse :)
Client Messages
Sat Apr 02 23:01:31 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_vela.jpg
Sat Apr 02 23:01:31 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_schem2.jpg
Sat Apr 02 23:01:30 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_vela.jpg
Sat Apr 02 23:01:30 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_schem2.jpg
Sat Apr 02 23:01:30 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_schem1.jpg
Sat Apr 02 23:01:30 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_crab_xr.jpg
Sat Apr 02 23:01:29 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_schem1.jpg
Sat Apr 02 23:01:29 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_crab_xr.jpg
Sat Apr 02 23:01:29 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_crab_opt.jpg
Sat Apr 02 23:01:29 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_Manhattan.jpg
Sat Apr 02 23:01:28 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_crab_opt.jpg
Sat Apr 02 23:01:28 GMT+02:00 2016|Einstein@Home|Finished download of Pulsars_J2007.jpg
Sat Apr 02 23:01:27 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_Manhattan.jpg
Sat Apr 02 23:01:27 GMT+02:00 2016|Einstein@Home|Started download of Pulsars_J2007.jpg
Sat Apr 02 23:01:27 GMT+02:00 2016|Einstein@Home|Finished download of Parkes_full.jpg
Sat Apr 02 23:01:27 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_vacuum.jpg
Sat Apr 02 23:01:25 GMT+02:00 2016|Einstein@Home|Started download of Parkes_full.jpg
Sat Apr 02 23:01:25 GMT+02:00 2016|Einstein@Home|Started download of LIGO_vacuum.jpg
Sat Apr 02 23:01:25 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_seisisol.jpg
Sat Apr 02 23:01:25 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_schematic.jpg
Sat Apr 02 23:01:23 GMT+02:00 2016|Einstein@Home|Started download of LIGO_seisisol.jpg
Sat Apr 02 23:01:23 GMT+02:00 2016|Einstein@Home|Started download of LIGO_schematic.jpg
Sat Apr 02 23:01:23 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_optics.jpg
Sat Apr 02 23:01:23 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_laser.jpg
Sat Apr 02 23:01:21 GMT+02:00 2016|Einstein@Home|Started download of LIGO_optics.jpg
Sat Apr 02 23:01:21 GMT+02:00 2016|Einstein@Home|Started download of LIGO_laser.jpg
Sat Apr 02 23:01:21 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_Livingston.jpg
Sat Apr 02 23:01:21 GMT+02:00 2016|Einstein@Home|Finished download of LIGO_Hanford.jpg
Sat Apr 02 23:01:20 GMT+02:00 2016|Einstein@Home|Started download of LIGO_Livingston.jpg
Sat Apr 02 23:01:20 GMT+02:00 2016|Einstein@Home|Started download of LIGO_Hanford.jpg
Sat Apr 02 23:01:20 GMT+02:00 2016|Einstein@Home|Finished download of GW_BBH2.jpg
Sat Apr 02 23:01:20 GMT+02:00 2016|Einstein@Home|Finished download of GW_BBH1.jpg
Sat Apr 02 23:01:19 GMT+02:00 2016|Einstein@Home|Started download of GW_BBH2.jpg
Sat Apr 02 23:01:19 GMT+02:00 2016|Einstein@Home|Started download of GW_BBH1.jpg
Sat Apr 02 23:01:19 GMT+02:00 2016|Einstein@Home|Finished download of Fermi_satellite.jpg
Sat Apr 02 23:01:19 GMT+02:00 2016|Einstein@Home|Finished download of Fermi_grsky.jpg
Sat Apr 02 23:01:18 GMT+02:00 2016|Einstein@Home|Started download of Fermi_satellite.jpg
Sat Apr 02 23:01:18 GMT+02:00 2016|Einstein@Home|Started download of Fermi_grsky.jpg
Sat Apr 02 23:01:18 GMT+02:00 2016|Einstein@Home|Finished download of Arecibo_platform.jpg
Sat Apr 02 23:01:18 GMT+02:00 2016|Einstein@Home|Finished download of Arecibo_full.jpg
Sat Apr 02 23:01:17 GMT+02:00 2016|Einstein@Home|Started download of Arecibo_platform.jpg
Sat Apr 02 23:01:17 GMT+02:00 2016|Einstein@Home|Started download of Arecibo_full.jpg
Sat Apr 02 23:01:17 GMT+02:00 2016|Einstein@Home|Finished download of Android.jpg
Sat Apr 02 23:01:17 GMT+02:00 2016|Einstein@Home|Finished download of einstein_icon.png
Sat Apr 02 23:01:15 GMT+02:00 2016|Einstein@Home|Started download of Android.jpg
Sat Apr 02 23:01:15 GMT+02:00 2016|Einstein@Home|Started download of einstein_icon.png
Sat Apr 02 23:01:15 GMT+02:00 2016|Einstein@Home|Finished download of p2030.20151015.G187.67-00.43.N.b1s0g0.00000.zap
Sat Apr 02 23:01:15 GMT+02:00 2016|Einstein@Home|Finished download of einsteinbinary_BRP4_1.46_arm-android-linux-gnu__NEONPIE
Sat Apr 02 23:01:14 GMT+02:00 2016|Einstein@Home|Started download of p2030.20151015.G187.67-00.43.N.b1s0g0.00000.zap
Sat Apr 02 23:01:14 GMT+02:00 2016|Einstein@Home|Finished download of stochastic_full.bank
Sat Apr 02 23:01:13 GMT+02:00 2016|Einstein@Home|Started download of stochastic_full.bank
Sat Apr 02 23:01:13 GMT+02:00 2016|Einstein@Home|Finished download of p2030.20151015.G187.67-00.43.N.b1s0g0.00000_2096.bin4
Sat Apr 02 23:01:12 GMT+02:00 2016|Einstein@Home|Started download of p2030.20151015.G187.67-00.43.N.b1s0g0.00000_2096.bin4
Sat Apr 02 23:01:12 GMT+02:00 2016|Einstein@Home|Started download of einsteinbinary_BRP4_1.46_arm-android-linux-gnu__NEONPIE
Sat Apr 02 23:01:10 GMT+02:00 2016|Einstein@Home|New computer location: home
Sat Apr 02 23:01:10 GMT+02:00 2016|Einstein@Home|Scheduler request completed: got 1 new tasks
Sat Apr 02 23:01:09 GMT+02:00 2016|Einstein@Home|Requesting new tasks for CPU and Mali-T760
Sat Apr 02 23:01:09 GMT+02:00 2016|Einstein@Home|Sending scheduler request: Project initialization.
Sat Apr 02 23:01:04 GMT+02:00 2016|Einstein@Home|Master file download succeeded
Sat Apr 02 23:00:35 GMT+02:00 2016||Fetching configuration file from http://einstein.phys.uwm.edu/get_project_config.php
Sat Apr 02 22:56:07 GMT+02:00 2016||Suspending computation - computer is in use
Sat Apr 02 19:23:19 GMT+02:00 2016||Resuming computation
Sat Apr 02 19:15:58 GMT+02:00 2016||Suspending computation - computer is in use
Sat Apr 02 19:06:34 GMT+02:00 2016|Einstein@Home|Detaching from project
Sat Apr 02 19:06:34 GMT+02:00 2016|Einstein@Home|Resetting project
Sat Apr 02 19:06:27 GMT+02:00 2016|Einstein@Home|Scheduler request completed
Sat Apr 02 19:06:25 GMT+02:00 2016|Einstein@Home|Not requesting tasks: "no new tasks" requested via Manager
Sat Apr 02 19:06:25 GMT+02:00 2016|Einstein@Home|Reporting 1 completed tasks
$ curl https://einsteinathome.org
$ wget http://snapshot.debian.org/archive/debian/20141020T103752Z/pool/main/c/ca-certificates/ca-certificates_20141019_all.deb
$ sudo dpkg --purge --force-depends ca-certificates
$ sudo dpkg -i ca-certificates_20141019_all.deb
# aptitude hold ca-certificates
Ou attendre la prochaine update.J'ai fait des essais avec BRP6 avec 2 WUs en simultanée.Ah tiens, depuis 10 jours sur ATI, j'ai ce problème, je n'avais pas fait attention et je ne comprennais aps pourquoi (pas d'app_config our moi)... Pas de problèmes sur NVIDIA...
Y'en a une qui est partie en "validation inconclusive".
Pourtant, on semble y gagner en faisant cela.
6200 secondes pour 2 WUs en simple, l'une après l'autre.
5400 secondes pour 2 WUs en double (2 simultanées) avec une app_config.
Mais s'il y en a une sur deux qui partent en inconclusive... ce ne sera pas rentable.
Je fais d'autres essais.
Je ne sais pas si les inconclusives sont courantes sur Einstein ou le problème vient de chez-moi.
Mine de rien, les BRP6 ont l'air de bien solliciter la GPU !!!
Je ne m'attendais pas à ça.
Les BRP4G sont catastrophiques à ce niveau-là.
(Re)lancement du site web à venir:hello:
Source: Einstein@Home
mercredi 20 juillet 2016 12:10
Après une longue période de développement et de tests, nous sommes prêts à relancer notre site!
Le nouveau site mettra en vedette un nouveau design qui va beaucoup améliorer un site vieux de plus de 10 ans. Le site actuel Einstein@Home n'est ni visuellement attrayant par rapport aux normes actuelles, ni particulièrement accessible en raison de la structuration actuelle de l'information. Les nouveaux visiteurs et bénévoles potentiels peuvent être perdus et nous voulons bien sûr éviter cela. Nous voulons livrer un site Web entièrement remanié avec un tout nouveau design moderne ainsi qu'une refonte complète de la façon dont nous présentons des informations, le tout en gardant l'amélioration de l'expérience utilisateur à l'esprit.
En second lieu, la maintenance du site a toujours été très lourde. De nombreux changements de contenu nécessitent des changements de code! Ce n'est pas la meilleure façon d'encourager les scientifiques à ajouter ou mettre à jour le contenu, comme dans les blogs au sujet de leur travail actuel ou pour fournir des contenus scientifiques supplémentaires. Nous avions besoin d'un moyen de faciliter cela pour élargir l'éventail des renseignements que nous fournissons à notre communauté de bénévoles, d'accroître leur idée de ce qui se passe dans les coulisses. Nous avons choisi d'utiliser Drupal, un vrai système de gestion de contenu, qui nous permet précisément de faire cela. Mais il y a plus: il est possible d'étendre les fonctionnalités de Drupal de façon à inclure pleinement les fonctionnalités des pages Web standards de BOINC. D'autres projets ont séparé leurs pages de contenu scientifiques de leur site web de gestion communautaire du projet, ce qui donne effectivement deux sites différents pour un seul projet BOINC. C'est ce que nous voulions éviter. Nous voulons une solution cohérente entièrement intégrée et Drupal nous permet de faire cela. Cependant, l'inconvénient de ceci est une mise en œuvre relativement complexe qui est la raison pour laquelle il nous a fallu un certain temps pour le développer avec nos ressources limitées. Maintenant, nous pensons qu'il est temps de le livrer.
Nous savons que des changements majeurs comme ceux-ci ne pourront jamais plaire à tout le monde, que ce soit la conception visuelle ou la structure du site modernisé. Nous avons essayé de minimiser ces effets négatifs par la réalisation d'un test public progressif sur albertathome.org. Cette phase de test a commencé il y a deux ans et nous avons invité le top 100 de nos "power-utilisateurs communautaires" et nos modérateurs. Ensuite nous avons entièrement migré notre projet d'essai et invité toute la communauté à faire un tour. Nous avons recueilli vos commentaires et les avons incorporé dans la version qui va maintenant être livrée. Veuillez noter cependant que le nouveau site n'est pas encore 100% complet. C'est juste le début - nous améliorons les fondations pour être en mesure de construire de nouvelles offres par dessus celles-ci au cours des prochains mois et années.
Voici le planning actuel:
20 juillet: première annonce publique
25 juillet: version mise à jour du plan / ajustements
29 juillet: ajustements finaux
1 au 5 août: arrêt des site web / migration de données / relance
Veuillez noter que durant la première semaine d'août le site web du projet sera arrêté car nous avons besoin de migrer tout le contenu de la communauté existante d'une manière cohérente. Nous essayerons de garder le projet lui-même en cours d'exécution afin que la distribution d'unités de travail ne soit pas affectée.
L'équipe Einstein@Home
Tu peux faire ton lâché sans problème :kookoo:
Pas constaté de problème d'envoi et de récupération d'UT pour le moment. La maintenance devrait bientôt se terminer, ils avaient annoncé jusqu'au 5.
Bonjour à tous,Certes, tu peux en faire tourner deux. Mais j'ai remarqué que, depuis quelques mois, c'était devenu Totalement non rentable de faire tourner 2 UTs en même temps et ce sur différents PCs et CGs!!! Donc, je suis repassé à une seule UT à la fois, c'est nettement mieux.
Je viens de vous rejoindre dans le projet Einsten qui effectivement chauffe beaucoup moins que Collatz.
Ce qu'il y a de bien avec Einsten est qu'il fait tourner 2 wu en GPU chez AMD.
Ma GPU : AMD Radeon R9 200 930/1250 @ 1130/1575.
Mes amitiés.
<cc_config>
<options>
<exclude_gpu>
<url>project_URL</url>
[<device_num>N</device_num>]
[<type>NVIDIA|ATI|intel_gpu</type>]
[<app>appname</app>]
</exclude_gpu>
</options>
</cc_config>
<cc_config>
<options>
<exclude_gpu>
<url>https://einsteinathome.org</url>
[<device_num>0 ou 1</device_num>]
[<type>PAS OBLIGATOIRE</type>]
[<app>PAS OBLIGATOIRE</app>]
</exclude_gpu>
</options>
</cc_config>
21 Dec 2016, 11:56:42 UTC 25 Dec 2016, 14:16:02 UTC Error while computing 13.42 8.42 0.06 0.00 Gamma-ray pulsar binary search #1 on GPUs v1.17 (FGRPopencl-ati) windows_x86_64
Einstein@Home Gamma-ray pulsar binary search #1 on GPUs 93.08(ya 18h+ d'avant un redémarrage inopiné dedans, mais pour la même UT)
<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<max_concurrent>4</max_concurrent>
<gpu_versions>
<gpu_usage>0.5</gpu_usage>
<cpu_usage>0.25</cpu_usage>
</gpu_versions>
</app>
</app_config>
:kookoo: zOU
Je ne comprends pas pourquoi persister à faire un app_config.xml sur einstein alors que le nombre d'unités à calculer se règle dans les préférences du projet. :??:
D'autre part, cpu_usage à 0.25 ou pas, l'unité prend 1 core chez moi soit actuellement 4 cores pour les 4 unités simultannées (2 par carte), :/ comme avec milkyWay.
Moi aussi j'ai 2 GPU, 1 GTX780 et 1 GTX1060.
Avec les réglages joints je fais 2 unités FGRP par Carte; c'est étrange que ça ne fonctionne pas pour tout le monde. :priz2tet:
sudo apt-get install nvidia-378
Pour installer la version 378 par exemple.sudo service boinc-client stop
et de faire un redémarrage de l'ordi après l'installation.:hello: à tous et toutes.
Il me semble qu'il y avait des astuces pour faire tourner plus vite les gpu ati et nvidia sur win dans le temps.
genre appli optimisees. Ca vous dit quelque chose? Merci :jap: :kookoo:
<app_config>
<app_version>
<app_name>einsteinbinary_BRP4</app_name>
<plan_class>opencl-intel_gpu-Beta</plan_class>
<avg_ncpus>0.5</avg_ncpus>
<ngpus>1</ngpus>
</app_version>
</app_config>
<app_config>
<app_version>
<app_name>einsteinbinary_BRP4</app_name>
<plan_class>opencl-intel_gpu-Beta</plan_class>
<avg_ncpus>1</avg_ncpus>
<ngpus>1</ngpus>
</app_version>
</app_config>
?
Article très sympa et très clair, je walide :D
Il faut cruncher sur FGRP en GPU de préférence.
Grosse maintenance prévue mardi prochain: https://einsteinathome.org/fr/content/project-downtime-tue-jan-23rd
:hello:
ici https://einsteinathome.org/fr/account/dashboardJ'ai beau chercher dans tous les onglets, je trouve pas. :priz2tet:
Ne pas confondre "calculer plus" et "créditer plus" :D
RGPD : RESTREINDRE L'ACCÈS AUX TÉLÉCHARGEMENTS DES STATISTIQUES DU PROJET
Salut tout le monde,
nous aimerions annoncer que nous allons désactiver l'accès anonyme à nos téléchargements de statistiques de projet, qui entrera en vigueur demain, le 14 juin à 15:00 CEST. La raison de cette décision est le nouveau règlement général de l'UE sur la protection des données (GDPR) et son obligation concernant la publication des informations personnelles de nos utilisateurs. Nous avons déjà discuté de cette question avec notre communauté et nous avons trouvé un moyen qui semble acceptable pour la plupart des gens. N'ayez crainte, les services et projets suivants ont déjà enregistré des comptes d'accès individuels avec nous et seront donc en mesure de recueillir nos données statistiques comme d'habitude :
BOINCstats
Statistiques combinées BOINC
Free-DC
GridRepublic
Gridcoin
Nous prévoyons également d'ajouter une nouvelle fonctionnalité qui permettra aux utilisateurs individuels de récupérer leurs données statistiques automatiquement et sous une forme lisible par machine (vraisemblablement XML). Nous allons annoncer cela et d'autres changements connexes dès qu'ils seront prêts.
Santé,
Oliver
Traduit avec www.DeepL.com/Translator
In order to run a new gravitational wave search on LIGO open data, we are putting the ongoing all-sky gravitational wave search on hold. In part this is because some questions have surfaced related to the de-jittering used in the preparation of the LIGO O2 data. These must first be understood. We will of course make the fullest possible use of the results obtained so far.
Bruce Allen, Einstein@Home Director
M.Alessandra Papa, Lead Scientist for gravitational-wave searches
Afin d'effectuer une nouvelle recherche d'onde gravitationnelle sur les données ouvertes de LIGO, nous mettons en attente la recherche d'onde gravitationnelle "ciel global". Cela s'explique en partie par le fait que certaines questions ont fait surface au sujet du désamorçage utilisé dans la préparation des données du LIGO O2. Il faut d'abord les comprendre. Nous ferons bien sûr le meilleur usage possible des résultats obtenus jusqu'à présent.:hello:
Bruce Allen, Einstein@Home Director
M.Alessandra Papa, scientifique principal pour les recherches par ondes gravitationnelles.
Prochain sprint sur Einstein
du 04/10/2018 15:00 (UTC) au 07/10/2018 14:59 (UTC)
:kookoo: Amélioration du site Web prochainement avec des nouveautés : https://einsteinathome.org/fr/content/gdpr-new-website-features-and-statistics-export-option (https://einsteinathome.org/fr/content/gdpr-new-website-features-and-statistics-export-option)Merci pour l'info ! :jap:
Est-ce que quelqu'un a déjà réussi à faire tourner une RTX sur Einstein ?
:??:
Est-ce que quelqu'un a déjà réussi à faire tourner une RTX sur Einstein ?
:??:
Ils y travaillent. En se plaignant chez nVidia si j'ai bien compris, mais ils y travaillent ;)
https://einsteinathome.org/fr/content/pascal-again-available-turing-may-be-coming-soon?page=23 (https://einsteinathome.org/fr/content/pascal-again-available-turing-may-be-coming-soon?page=23)
C'est du CUDA ou de l'OpenCL ?
Est-ce que quelqu'un a déjà réussi à faire tourner une RTX sur Einstein ?
:??:
Est-ce que ceux d'entre vous qui crunchent sur Einstein avec des RTX ont aussi des WUs qui partent en "Invalide" ?2 sur 540 ça reste supportable :D
Sur 540 WUs calculées, j'en ai 2 en Invalide !
C'est exactement ce que je voulais dire.............puis je sais pas pourquoi j'ai oublié. :??:Est-ce que ceux d'entre vous qui crunchent sur Einstein avec des RTX ont aussi des WUs qui partent en "Invalide" ?2 sur 540 ça reste supportable :D
Sur 540 WUs calculées, j'en ai 2 en Invalide !
2 sur 540 ça reste supportable :D
2 sur 114, pas d'erreur dans les taches
Nabz, je suppose que ta RTX a envoyé plus de WUs que la GTX, ce qui expliquerait le nombre plus élevé d'Invalides pour le RTX.
Enfin elle n'en envoie pas 3 fois plus tout de même, je suppose.
surtout que chez Einstein, invalide c'est hyper vague, pas d'erreur dans la WU ou la tache.....Des tâches en chaise à roulettes ? :gnu:
Pour moi
6 Min pour une tache sur RX64 :eek:
11 Min pour une tache sur RTX 2070...
je regarde les invalide et je vous dirai....
Je suis curieux de voir ce que donneront les Radeon VII.
En espérant que ce soit pour 2019...
Et ceux qui crunchent avec autre chose que des RTX, vous avez aussi un certain taux de "Invalide" ?4 en invalides sur une HD7970, pour 3 valides et 10 en pending. Aucun problème sur les autres GPU. Je suspecte un problème matériel.
Exemple sur une tâche qui part en invalide chez tout le monde: https://einsteinathome.org/fr/workunit/395647957
:hello:
4 en invalides sur une HD7970, pour 3 valides et 10 en pending. Aucun problème sur les autres GPU. Je suspecte un problème matériel.Cette carte semble avoir un problème, elle continue à faire beaucoup d'invalides. Je l'ai arrêtée sur Einstein
Exemple sur une tâche qui part en invalide chez tout le monde: https://einsteinathome.org/fr/workunit/395647957
:hello:
Bien vu fansyl !
Exemple instructif !
Nouveau document de résultats E@H disponible sur arXiv
Soumis le 24 mars 2019 18:40:02 UTC
Un nouvel article décrivant les résultats de la recherche O1MD1 Einstein@Home est maintenant disponible sur le serveur de pré-impression arXiv à https://arxiv.org/abs/1903.09119 . Bien qu'aucun signal astrophysique n'ait été trouvé, "Results from an Einstein@Home search for continuous gravitational waves from Cassiopeia A, Vela Jr. and G347.3" décrit la recherche et fixe les limites supérieures de l'amplitude des ondes gravitationnelles continues des trois restes de supernova à un niveau de sensibilité sans précédent. L'article sera maintenant soumis à une revue pour examen par les pairs et publication.
Les trois cibles ont été choisies en fonction de l'âge estimé et de la distance par rapport aux restes de supernova, sur la base d'une procédure d'optimisation que nous avons développée au cours des dernières années. Bien que nous puissions voir ces objets dans les rayons X, aucune pulsation associée dans les ondes radio ou toute autre partie du spectre électromagnétique n'a été détectée à ce jour. Cela signifie que la fréquence de rotation de ces objets est inconnue et que nous devons donc chercher sur une très large gamme de fréquences et d'évolutions possibles des fréquences. Ce n'est qu'avec l'aide de la puissance de calcul massive fournie par les bénévoles d'Einstein@Home que nous avons pu atteindre ces résultats.
Au fur et à mesure que nos méthodes, notre puissance de calcul et la sensibilité des détecteurs s'améliorent, nous continuons la chasse aux ondes gravitationnelles continues et nous invitons les bénévoles de E@H à continuer à nous soutenir dans cette quête scientifique passionnante.
Au nom de M. Alessandra Papa pour l'équipe Einstein@Home
Le GPU intégré est de catégorie Maxwell quand même, avec 256 CUDA core, il doit arriver à faire tourner des UT dessus via une bricole sous Linux.Oui, mais moins de 500 secondes sur cette machine, c'est un exploit.
:hello:
Il s'agit des UT Arecibo qui se font en 12 minutes sur mon Intel HD4000 donc c'est cohérent qu'elles prennent moins de 10 minutes sur son GPU nVidia.
Je pense qu'il n'y a aucune appli optimisée ou autre magie.
:hello:
Il s'agit des UT Arecibo qui se font en 12 minutes sur mon Intel HD4000 donc c'est cohérent qu'elles prennent moins de 10 minutes sur son GPU nVidia.Ben moi, je n'ai que des UT Gamma-ray pulsar binary search #1 sur tous mes GPU (nVidia et AMD) ! :desole:
Je pense qu'il n'y a aucune appli optimisée ou autre magie.
:hello:
Le mec est surtout un gros gros geek avec un gros gros cerveau... Du genre à être payé pour bricoler des applis optimisées qui tournent sur n'importe quoi ou presque.
-> On n'a pas le level :/
https://www.nytimes.com/2014/12/23/science/an-economical-way-to-save-progress.html (https://www.nytimes.com/2014/12/23/science/an-economical-way-to-save-progress.html)
Avez-vous remarqué le temps de calcul du premier cruncher de la liste ?
Il utilise une app optimisée, vraiment bien optimisée au vu de sa machine :coffeetime:
https://einsteinathome.org/fr/host/12268307 (https://einsteinathome.org/fr/host/12268307)
Mise à jour: Grâce à l'aide de Richard Haselgrove, nous avons pu identifier le problème dans le code du serveur BOINC. J'ai distribué un correctif à ce problème à tous les projets. Si vous rencontrez toujours ce problème après avoir mis à jour vos préférences, vous devez contacter tous vos projets et leur demander de réparer leur planificateur.
Nous constatons des problèmes avec les préférences globales envoyées par certains hôtes à notre serveur. Ces préférences ne sont pas des codes XML valides car il manque généralement une balise </ venue>. J'ai ajusté notre planificateur pour ignorer ces préférences non valides et envoyer un message au client BOINC (ce qui vous a probablement conduit ici). Avec les données accessibles, nous ne sommes pas en mesure de cerner le problème. Nous aimerions donc demander à tous ceux qui reçoivent ces messages de notre serveur de nous fournir des informations qui nous aideront à trouver la cause première de ce problème.
Une solution à court terme pour vous consiste à mettre à jour les préférences ici sur Einstein @ Home, ce qui propagera un ensemble de préférences correct à tous vos hôtes, mais cela ne signifie pas que le problème est résolu. Si le problème se situe dans le client BOINC, il est probable que le problème ressurgisse après un certain temps. Dans ce cas, nous aimerions savoir quelle version de BOINC vous utilisiez après avoir fixé les préférences et à quels projets BOINC vous apparteniez dans ce délai.
Vous pouvez vérifier si vos hôtes sont concernés par cela en accédant au tableau de bord de votre compte, puis en cliquant sur chacun des noms d'hôte répertoriés dans le coin inférieur droit, puis sur l'heure du dernier contact (dernier contact du serveur) ou d'ajouter un / log. à l'URL de votre navigateur. Si vous voyez un message comme celui-ci, vous êtes concerné par ce problème:
2016-09-08 09:35:13.8272 [PID=19551] [debug] [HOST#11767746] MSG(high) Invalid global preferences supplied, please check https://einsteinathome.org/community/forum/19 on how to fix that.
<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<max_concurrent>2</max_concurrent>
<gpu_gpu_usage>1.000000</gpu_gpu_usage>
<gpu_cpu_usage>0.500000</gpu_cpu_usage>
<fraction_done_exact>0</fraction_done_exact>
<report_results_immediately>0</report_results_immediately>
</app>
</app_config>
Il est bizarre ton app_config !?Code: [Sélectionner]<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<max_concurrent>2</max_concurrent>
<gpu_gpu_usage>1.000000</gpu_gpu_usage>
<gpu_cpu_usage>0.500000</gpu_cpu_usage>
<fraction_done_exact>0</fraction_done_exact>
<report_results_immediately>0</report_results_immediately>
</app>
</app_config>
<app_config>
<app>
<name>hsgamma_FGRPB1G</name>
<gpu_versions>
<gpu_usage>1</gpu_usage>
<cpu_usage>0.5</cpu_usage>
</gpu_versions>
...
</app>
</app_config>
Perso, je n'ai réglé aucun app_config et j'ai 3 GPU (sur le même ordi) qui crunchent sur Einstein (2 NVidia et 1 AMD) !
GTX980
1 27-Sep-19 4:10:52 PM Starting BOINC client version 7.14.2 for windows_x86_64
2 27-Sep-19 4:10:52 PM log flags: file_xfer, sched_ops, task
3 27-Sep-19 4:10:52 PM Libraries: libcurl/7.47.1 OpenSSL/1.0.2g zlib/1.2.8
4 27-Sep-19 4:10:52 PM Data directory: C:\ProgramData\BOINC
5 27-Sep-19 4:10:52 PM Running under account conta
6 27-Sep-19 4:10:53 PM CUDA: NVIDIA GPU 0: GeForce GTX 980 Ti (driver version 388.13, CUDA version 9.1, compute capability 5.2, 4096MB, 3961MB available, 7699 GFLOPS peak)
7 27-Sep-19 4:10:53 PM CUDA: NVIDIA GPU 1: GeForce GTX 980 (driver version 388.13, CUDA version 9.1, compute capability 5.2, 4096MB, 3379MB available, 5859 GFLOPS peak)
8 27-Sep-19 4:10:53 PM OpenCL: NVIDIA GPU 0: GeForce GTX 980 Ti (driver version 388.13, device version OpenCL 1.2 CUDA, 6144MB, 3961MB available, 7699 GFLOPS peak)
9 27-Sep-19 4:10:53 PM OpenCL: NVIDIA GPU 1: GeForce GTX 980 (driver version 388.13, device version OpenCL 1.2 CUDA, 4096MB, 3379MB available, 5859 GFLOPS peak)
10 27-Sep-19 4:10:55 PM Host name: GTX980
11 27-Sep-19 4:10:55 PM Processor: 6 AuthenticAMD AMD FX(tm)-6300 Six-Core Processor [Family 21 Model 2 Stepping 0]
12 27-Sep-19 4:10:55 PM Processor features: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 htt pni ssse3 fma cx16 sse4_1 sse4_2 popcnt aes f16c syscall nx lm avx svm sse4a osvw ibs xop skinit wdt fma4 tce tbm topx page1gb rdtscp
13 27-Sep-19 4:10:55 PM OS: Microsoft Windows 10: Professional x64 Edition, (10.00.18362.00)
14 27-Sep-19 4:10:55 PM Memory: 7.96 GB physical, 9.21 GB virtual
Donc t'avais utilisé les options des préférences projet, et en plus le app_config, d'où le blocage / conflit ?
La base : "la prise est-elle bien branchée ?" :D
Il n'y a pas une case à cocher sur Einstein pour autoriser l'export des stats ?
:hello: Quel genre de "catastrophe"?
Dans les options de boinc, le client pas la page web, tu sélectionnes 50% d'utilisation processeur dans le menu préférences de calcul
Il faut aussi que tu vois d'où vient la "catastrophe" :
- manque de RAM de ton portable ? (ce qui va provoquer du "swap" et donc du "lag") : regarde l'occupation mémoire des processus Einstein en train de calculer avec le gestionnaire de tâches windows (1er onglet) et surtout leur occupation mémoire par rapport à la mémoire totale (% en haut de la colonne mémoire du 1er onglet + 2ème onglet et tab mémoire)
- "saturation CPU" car "il serait trop vieux" ? ça normalement c'est bien géré via les priorité de calcul des processus alloué par windows lui même, ça ne doit pas être pénalisant à l'usage de la machine
- tu parles de tâche CPU ou GPU ? car sur un "vieux portable" les tâches GPU peuvent effectivement faire laguer à mort la machine, il y a une petite case à cocher dans les préférences boinc pour mettre en pause le calcul GPU lors de l'utilisation de l'ordi, et ça change la vie (j'avais ce problème sur feu mon vieil iMac :cry: et les 2 seules applis boinc GPU qui pouvaient tourner dessus rendait le mac inutilisable si je la cochais pas)
Et aussi le paramètre mentionné par Xe120 en fait il y en a deux :
- il y a celui du multi-processing : réduit le nombre de cores alloués au calcul, et donc le nombre de tâches (et donc la RAM utilisée, par exemple) mais pas vraiment la réactivité CPU AMHA (cf 2ème point plus haut)
- il y a celui du temps CPU : ça fait une utilisation du CPU en dent de scie, ça va peut-être faire un peu moins chauffer la machine (pour un portable ça peut être bien utile, au début des 2000's j'ai crunché 7 ans sur un portable Toshiba et ça m'était bien utile en effet) mais je vois pas trop en quoi elle serait plus "réactive"
D'autres astuces qui sont bonnes à prendre ?Pour l'instant je te déconseille de jouer avec les fichiers xml. D'ici quelques temps peut-être.
Comme je disais plus haut, j'ai vu des posts sur des fichiers XML mais je suis novice dans ce domaine et je ne sais pas si ce sera très utile vu ma config...
les tâches GPU peuvent effectivement faire laguer à mort la machine, il y a une petite case à cocher dans les préférences boinc pour mettre en pause le calcul GPU lors de l'utilisation de l'ordi, et ça change la vieEn effet, avec une GT 620M, il vaut mieux cocher la case "ne pas utiliser le GPU quand l'ordinateur est actif".
J'ai déjà vu d'autre projet se comporter de la sorte,j'en ignore la raison, mais cela ne dure pas et au bout d'un moment la situation reviens a la normal.
Je m'explique : lorsque mon PC calculait des tâches du projet SETI, 2 tâches étaient en cours de calcul. Une fois l'une des deux terminée, la seconde en cours de travail continuait normalement et une nouvelle tâche remplaçait celle finie.
A l'heure actuelle, BOINC Manager passe d'une tâche à l'autre sans aller jusqu'au bout des 100% (pour le moment). Alors est-ce que c'est une autre façon de procéder selon le projet ??
Par défaut, dans les préférences de Boinc Manager, il permute les tâches toutes les 60 mn (il me semble - ou plus)@Gualterio85
donc si ta tâche Einstein n'est pas à 100 % au bout de ce temps, il la met en pause et il en prend une autre (il la reprendra à la prochaine permutation)...
Pour éviter ça (laisser finir une tâche à 100 %), il faut augmenter la valeur de "Permuter d'une tâche à l'autre toutes les" !
(et c'est valable avec tous les projets)
Bonjour,@philippe VDK
Nouveau sur Einstein il m'est impossible de finir une seule tache GPU (ATI).
Tout va bien jusqu'à +/- 75% puis quand il ne reste +/-5 minutes de calcul l'unité repasse à 0% et le temps restant passe lui à 11 jours et monte jusqu'à ce que j'arrête la tache.
We made a video, where some members of our research group describe what we search for, how and why we do it. It's available on YouTube (https://www.youtube.com/watch?v=7xIAHdDipNg). It is in English, but subtitles are available in Chinese, English, German, Hindi, Italian, Malayalam, and Persian.
Max-Planck-Institut für Gravitationsphysik (Albert-Einstein-Institut)
Nous avons fait une vidéo, où certains membres de notre groupe de recherche décrivent ce que nous recherchons, comment et pourquoi nous le faisons. Elle est disponible sur YouTube (https://www.youtube.com/watch?v=7xIAHdDipNg) . Elle est en anglais, mais les sous-titres sont disponibles en chinois, anglais, allemand, hindi, italien, malayalam et persan. [bientôt en français]
Max-Planck-Institut für Gravitationsphysik (Albert-Einstein-Institut)
Un nouvel article sur les résultats d'Einstein @ Home a été accepté pour publication dans The Astrophysical Journal !
Il décrit un suivi approfondi des résultats de la recherche Einstein@Home sur les données LIGO O1 pour les ondes gravitationnelles d'objets compacts centraux dans trois restes de supernova. Il présente également le premier suivi électromagnétique d'un candidat à l'onde gravitationnelle continue effectué à ce jour.
Un grand merci à tous ceux qui ont rendu ce travail possible en faisant don de cycles à partir de vos ordinateurs!
Chers bénévoles!
Un suivi approfondi des 10 000 résultats les plus intéressants de la recherche Einstein@Home sur les données LIGO O1 ciblant les émissions de l'objet compact central dans les restes de supernova Vela Jr., Cassiopeia A et G347.3-0.5 a été accepté pour publication dans The Astrophysical Journal. Vous pouvez déjà lire l'article sur https://arxiv.org/abs/2005.06544 .
Nous avons utilisé les données O2 LIGO pour suivre les valeurs aberrantes O1. Fait intéressant, un candidat survit à la première enquête de suivi sur l'O2, associée à l'objet compact central dans le SNR G347.3-0.5, mais cela n'est pas confirmé de manière concluante. Afin d'évaluer une possible origine astrophysique, nous avons recherché dans les données d'archives des rayons X un signal pulsé à la fréquence de rotation de l'étoile à neutrons et de ses harmoniques. Il s'agit du premier suivi électromagnétique étendu d'un candidat à l'onde gravitationnelle continue effectué à ce jour. Malheureusement, nous n'avons pu identifier aucun signal associé significatif, mais la recherche aux rayons X avait une sensibilité limitée en raison de la grande distance dans le temps entre les rayons X et les observations des ondes gravitationnelles.
De nouvelles observations aux rayons X contemporaines de l'analyse LIGO O3 permettront une recherche plus sensible d'un équivalent électromagnétique. Une recherche focalisée sur les ondes gravitationnelles dans les données d'O3 sur la base des paramètres fournis par notre recherche devrait être facilement en mesure de faire la lumière sur la nature de cette valeur aberrante. Des études de bruit sur les instruments LIGO pourraient également révéler la présence d'une contamination cohérente.
Un grand merci à tous ceux qui ont rendu ce travail possible en faisant don de cycles à partir de vos ordinateurs!
Dr. M.A. Papa
Chef de groupe de recherche indépendant
Max Planck Institut f. Gravitationsphysik
http://www.aei.mpg.de/continuouswaves
Dernières news :kookoo:
https://www.futura-sciences.com/sciences/actualites/ondes-gravitationnelles-futur-telescope-einstein-sera-capable-detecter-million-ondes-gravitationnelles-an-83063/#xtor%3DAL-80-1%5BACTU%5D-83063%5BLe-futur-telescope-Einstein-sera-capable-de-detecter-un-million-d-ondes-gravitationnelles-par-an---%5D
Pour Einstein, il te suffit d'aller dans les préférences du projet et de modifier le "Facteur d'utilisation du GPU" pour l'application qui t'intéresse.
Ils mettent d'ailleurs un "WARNING!" en-dessous qui n'est pas rassurant du tout, mais ce n'est pas plus dangereux pour le matériel que si tu utilises une app_config.
Si tu veux en faire tourner 2 en même temps, tu mets 0.5.
Si tu veux en faire tourner 3 en même temps, tu mets 0.333.
Si tu veux en faire tourner 4 en même temps, tu mets 0.25.
Etc...
Il faut laisser du CPU libre, mais combien ? La logique voudrait un CPU par UT, quelqu'un peut confirmer avec un exemple concret ?Ca dépend des projets, de si OpenCL ou pas, de l'OS, de la version de l'OS, de comment c'est codé... avec les pieds, avec un seul pied, avec une grosse tête, plusieurs petites... parfois un coeur CPU peut alimenter plusieurs GPU, parfois pas... c'est le grand jeu du Crunch, faut essayer, mais par ici, y'en a qui savent... parfois... :)
J'ai déjà eu ce problème. As-tu essayé de réduire ton cache dans les préférences de calcul de ton BM?
Normalement l'effet est immédiat.
Ce que je voulais dire c'est qu'en principe le fait de réduire le cache après avoir stocké le nombre de tâches voulues devrait résoudre ton problème de GPU. Il faut aussi désactiver le module étrange si utilisé. :siflotte:J'ai déjà eu ce problème. As-tu essayé de réduire ton cache dans les préférences de calcul de ton BM?
Normalement l'effet est immédiat.
Les UT ont une deadline de 3j pour 30mn de durée de calcul... Vachement urgent :lol:
LA DERNIÈRE DÉCOUVERTE EINSTEIN@HOME
Je suis fier d'annoncer la dernière découverte Einstein@Home, qui a été publiée aujourd'hui dans Astrophysical Journal Letters . Cela identifie un pulsar "veuve noire" dans les données du télescope de grande surface à bord du satellite Fermi. Notre découverte résout la nature d'une source mystérieuse, vue pour la première fois il y a deux décennies par le satellite EGRET. On sait maintenant que la puissance au centre de cette source est un système binaire remarquable, constitué d'un pulsar en orbite rapprochée avec une étoile très légère.
Si vous souhaitez en savoir plus, le document est en libre accès et est disponible ici (https://iopscience.iop.org/article/10.3847/2041-8213/abbc02) (extrait dans le cadre ci-dessous).
Merci aux milliers de bénévoles qui ont rendu cette découverte possible en donnant leur temps de calcul à Einstein@Home, et à ceux dont les ordinateurs ont détecté pour la première fois le PSR J1653−0158: Yi-Sheng Wu de Taoyuan, Taiwan, et Daniel Scott d'Ankeny, Iowa , ETATS-UNIS.
Bruce Allen, directeur d'Einstein@homeCiterEXTRAIT :
Nous rapportons la découverte de pulsations gamma de période de 1,97 ms à partir du pulsar binaire de période orbitale de 75 minutes maintenant nommé PSR J1653−0158. On s'attend depuis longtemps à ce que la source de rayons gamma 4FGL J1653.6−0158 associée du télescope de grande surface Fermi héberge un pulsar binaire milliseconde. Malgré le spectre de rayons gamma de type pulsar et les associations optiques / rayons X candidates - dont les modulations périodiques de luminosité suggéraient une orbite - aucune pulsation radio n'avait été trouvée dans de nombreuses recherches. Le pulsar a été découvert en recherchant directement les données de rayons gamma à l'aide du système de calcul volontaire distribué Einstein @ Home accéléré par GPU. L'espace des paramètres multidimensionnels était limité par des contraintes de position et orbitales obtenues à partir de la contrepartie optique. Des analyses plus sensibles des archives et des nouvelles données radio utilisant la connaissance de la solution de synchronisation pulsar donnent des limites supérieures d'émission radio très strictes. Toute émission radio est donc soit exceptionnellement faible, soit éclipsée pendant une grande partie du temps. Le pulsar a l'une des trois intensités de champ magnétique de surface inférées les plus faibles de tout pulsar connu avecB surf ≈ 4 × 10 7 G. La fonction de masse résultante, combinée aux modèles de la courbe optique de la lumière et des spectres de l'étoile compagne, suggère une masse pulsar gsim2 M ⊙ . Le compagnon est léger avec une masse ~ 0,01 M ⊙ , et la période orbitale est la plus courte connue pour tout pulsar binaire à rotation. Cette découverte démontre le potentiel du télescope de grande surface Fermi à découvrir des pulsars extrêmes qui, autrement, ne seraient pas détectés.
All (1015) | In progress (49) | Pending (863) | Valid (103) | Invalid (0)103 valides depuis quelques jours, toutes les UT calculées récentes passent en pending !? :??:
PUBLICATION DES RÉSULTATS DE LA RECHERCHE ALL-SKY DANS LES DONNÉES LIGO O2
Les résultats de notre recherche sur tout le ciel pour les ondes gravitationnelles continues dans les données publiques de la deuxième course d'observation de LIGO (O2) ont maintenant été publiés dans The Astrophysical Journal. La publication décrit la recherche avec la meilleure sensibilité jamais atteinte par une telle étude du ciel jusqu'à 500 Hz.
Un grand merci à vous tous qui avez rendu ce travail possible en faisant don de cycles de vos ordinateurs!
Lisez la publication en libre accès «Einstein @ Home All-sky Search for Continuous Gravitational Waves in LIGO O2 Public Data» (https://iopscience.iop.org/article/10.3847/1538-4357/abc7c9)
et apprenez-en plus sur nos recherches dans notre vidéo YouTube «Searching for Continuous Gravitational Waves» (https://www.youtube.com/watch?v=7xIAHdDipNg)
--> La vidéo avait été traduite sur le portail : https://www.boinc-af.org/einstein-video-ondes-gravitationnelles-continues.html
Je crunche du Einstein en GPU depuis quelques jours et je viens de m'apercevoir qu'il y a une nouvelle applicationElle n’apparaît pas dans mes préférences. :??:
Gravitational Wave search O3AS Engineering O3ASE) [beta test]
https://einsteinathome.org/apps.php
en plus de Gravitational Wave search O2 Multi-Directional GPU (O2MDF)
:coffeetime:
https://einsteinathome.org/fr/workunit/544521517
1) Sélectionnez l'une des applications fonctionnant uniquement sur le processeur. Notez que c'est le CPU et non le GPU. (J'ai choisi la première option, "Binary Radio Pulsar Search (Arecibo)").https://einsteinathome.org/fr/goto/comment/185331 (https://einsteinathome.org/fr/goto/comment/185331)
2) Sélectionnez YES pour le type "Use Nvidia/AMD GPU" et NO pour "Use CPU". La combinaison de #1 et #2 signifie effectivement que vous n'avez rien sélectionné.
3) Sélectionnez YES pour "Allow non-preferred apps". Cela vous permet d'attraper les tâches 03ASE qui ne semblent pas encore avoir une case de sélection sur l'écran des préférences.
En faisant cela, j'ai obtenu un tas de tâches GPU O3ASE et aucune des autres tâches.
Traduit avec www.DeepL.com/Translator (version gratuite)
Deux nouvelles vidéos YouTube à propos d'Einstein@HomeOn peut également régler les sous-titre en français.
Il y a deux nouvelles vidéos YouTube à propos d'Einstein@Home que, nous pensons, vous aimerez regarder.
Si vous souhaitez en savoir plus sur le contexte scientifique du projet et les découvertes récentes, consultez la conférence de Bruce Allen à propos d'Einstein@Home lors de l'atelier BOINC 2021 (https://www.youtube.com/watch?v=MlCz_eNWEc4).
La société Max Planck a publié une vidéo sur notre projet et notre récente découverte du pulsar de veuve noire (https://www.youtube.com/watch?v=QXaprEunJWc) . C'est (principalement) en allemand, mais l'interview de Bruce Allen (à partir de 4h55 et 8h42) est en anglais avec sous-titres allemands. La vidéo présente également une interview avec l'un de nos bénévoles d'Allemagne.
Dites-nous ce que vous en pensez et n'hésitez pas à poser des questions dans les commentaires !
Salut Monsieur Super :hello:
Le graphique fonctionne avec les unités CPU mais pas GPU :jap:
// je parlais de DENIS@home//
[ This attachment cannot be displayed inline in 'Print Page' view ]
:clafete:
JeromeC je vois que tu fait tourner 3 taches simultanées sur ta carte graphique. Pourrais-tu partager ton app_config stp ?
Cordialement,
Kali.
<app_config>
<app_version>
<app_name>hsgamma_FGRPB1G</app_name>
<plan_class>FGRPopencl-ati-mav</plan_class>
<avg_ncpus>0.33</avg_ncpus>
<ngpus>0.33</ngpus>
</app_version>
</app_config>
Merci Jérôme mais ca ne marche pas chez moi.Il me semble que tu peux le faire directement dans ton compte en modifiant la valeur.
Tempis je vais rester sur 1 seule tâche durant le FB.
Kali.
Merci Jérôme mais ca ne marche pas chez moi.Il me semble que tu peux le faire directement dans ton compte en modifiant la valeur.
Tempis je vais rester sur 1 seule tâche durant le FB.
Kali.
Facteur d'utilisation du processeur graphique par les applications FGRP : 1 pour 1 UT GPU ou 0.5 pour 2 UT GPU ou 0.3 Pour 3 UT GPU. :kookoo:
nvidia-smi
Et vérifier la colonne GPU Util (en %) te donnant exactement l'utilisation GPU.
Dear E@H participants!https://einsteinathome.org/fr/content/em-searches-brp-raidiopulsar-and-fgrp-gamma-ray-pulsar (https://einsteinathome.org/fr/content/em-searches-brp-raidiopulsar-and-fgrp-gamma-ray-pulsar)
I did write this occasionally hidden in other forum threads, but I thought I should put this more officially: the electromagnetic (i.e. non-gravitational-wave) searches on Einstein@Home are changing.
* There are currently no more scientifically promising targets for the Gamma-Ray searches than what we currently have prepared "work" for. So the FGRP searches/applications will eventually run out of work.
* We do have a PHD student now who will take a closer, more elaborated look at the Arecibo survey (BRP4). There are quite a few "beams" left there, so we are massively ramping up the throughput to get it done in ("PHD") time. However, the large span of various devices that process these tasks, from small Android phones to modern CPUs (and some GPUs) gives us, and particularly our database, some headache. Therefore we decided to split the search again, as we did in the past for the GPUs: basically the slower ARM-bases hosts will continue to process the current "BRP4" tasks, while the faster Intel x86 based CPUs and GPUs will be shifted to "BRP4G", where these get "bundles" of (currently) 8 BRP4 tasks to process as one task. These will run 8x as long as now, but will also get 8x as much credit. (sorry if you don't like this, our DB is already aching at the flood of small tasks).
* For the better, more modern GPUs we are setting up a new search ("BRP7") that will examine data from MEERKAT and FAST radio telescopes that CPUs are still too slow to process. We're working on that, but are still busy dealing with the side-effects of the increased BRP4 throughput.
Thank you for contributing to Einstein@Home
BM
Un peu de nouvelles du projet ::jap:CiterDear E@H participants!https://einsteinathome.org/fr/content/em-searches-brp-raidiopulsar-and-fgrp-gamma-ray-pulsar (https://einsteinathome.org/fr/content/em-searches-brp-raidiopulsar-and-fgrp-gamma-ray-pulsar)
I did write this occasionally hidden in other forum threads, but I thought I should put this more officially: the electromagnetic (i.e. non-gravitational-wave) searches on Einstein@Home are changing.
* There are currently no more scientifically promising targets for the Gamma-Ray searches than what we currently have prepared "work" for. So the FGRP searches/applications will eventually run out of work.
* We do have a PHD student now who will take a closer, more elaborated look at the Arecibo survey (BRP4). There are quite a few "beams" left there, so we are massively ramping up the throughput to get it done in ("PHD") time. However, the large span of various devices that process these tasks, from small Android phones to modern CPUs (and some GPUs) gives us, and particularly our database, some headache. Therefore we decided to split the search again, as we did in the past for the GPUs: basically the slower ARM-bases hosts will continue to process the current "BRP4" tasks, while the faster Intel x86 based CPUs and GPUs will be shifted to "BRP4G", where these get "bundles" of (currently) 8 BRP4 tasks to process as one task. These will run 8x as long as now, but will also get 8x as much credit. (sorry if you don't like this, our DB is already aching at the flood of small tasks).
* For the better, more modern GPUs we are setting up a new search ("BRP7") that will examine data from MEERKAT and FAST radio telescopes that CPUs are still too slow to process. We're working on that, but are still busy dealing with the side-effects of the increased BRP4 throughput.
Thank you for contributing to Einstein@Home
BM
Chers participants d'E@H !
J'ai déjà écrit ceci, occasionnellement caché dans d'autres fils de discussion du forum, mais j'ai pensé que je devais le dire plus officiellement : les recherches électromagnétiques (c'est-à-dire à ondes non gravitationnelles) sur Einstein@Home sont en train de changer.
* Il n'y a actuellement pas de cibles scientifiquement plus prometteuses pour les recherches Gamma-Ray que celles pour lesquelles nous avons préparé du "travail". Les recherches/applications du FGRP finiront donc par manquer de travail.
* Nous avons maintenant un étudiant en doctorat qui va examiner de plus près et de manière plus élaborée le relevé d'Arecibo (BRP4). Il reste un certain nombre de "faisceaux", et nous augmentons massivement le débit pour que cela soit fait dans le temps du doctorant. Cependant, la grande variété des appareils qui traitent ces tâches, des petits téléphones Android aux CPU modernes (et certains GPU), nous donne, et en particulier à notre base de données, quelques maux de tête. Nous avons donc décidé de diviser à nouveau la recherche, comme nous l'avons fait dans le passé pour les GPU : en gros, les hôtes à base d'ARM, plus lents, continueront à traiter les tâches "BRP4" actuelles, tandis que les CPU et GPU à base d'Intel x86, plus rapides, passeront à "BRP4G", où ils obtiendront des "paquets" de (actuellement) 8 tâches BRP4 à traiter comme une seule tâche. Ces tâches fonctionneront 8x plus longtemps qu'aujourd'hui, mais recevront également 8x plus de crédit. (Désolé si vous n'aimez pas ça, notre base de données souffre déjà de l'afflux de petites tâches).
* Pour les GPUs plus modernes, nous sommes en train de mettre en place une nouvelle recherche ("BRP7") qui examinera les données des radiotélescopes MEERKAT et FAST que les CPUs sont encore trop lents à traiter. Nous y travaillons, mais nous sommes toujours occupés à gérer les effets secondaires de l'augmentation du débit de BRP4.
Merci de votre contribution à Einstein@Home
Traduit avec www.DeepL.com/Translator (version gratuite)
2022-05-02 17:25:34.9196 [PID=12344] Request: [USER#xxxxx] [HOST#12060147] [IP xxx.xxx.xxx.144] client 7.16.11
2022-05-02 17:25:35.0060 [PID=12344] [debug] have_master:1 have_working: 1 have_db: 1
2022-05-02 17:25:35.0060 [PID=12344] [debug] using working prefs
2022-05-02 17:25:35.0060 [PID=12344] [debug] have db 1; dbmod 1636371210.000000; global mod 1636371210.000000
2022-05-02 17:25:35.0061 [PID=12344] [send] effective_ncpus 2 max_jobs_on_host_cpu 999999 max_jobs_on_host 999999
2022-05-02 17:25:35.0061 [PID=12344] [send] effective_ngpus 1 max_jobs_on_host_gpu 999999
2022-05-02 17:25:35.0061 [PID=12344] [send] Not using matchmaker scheduling; Not using EDF sim
2022-05-02 17:25:35.0061 [PID=12344] [send] CPU: req 0.00 sec, 0.00 instances; est delay 0.00
2022-05-02 17:25:35.0061 [PID=12344] [send] Intel GPU: req 17280.00 sec, 1.00 instances; est delay 0.00
2022-05-02 17:25:35.0061 [PID=12344] [send] work_req_seconds: 0.00 secs
2022-05-02 17:25:35.0061 [PID=12344] [send] available disk 95.03 GB, work_buf_min 8640
2022-05-02 17:25:35.0061 [PID=12344] [send] active_frac 0.964150 on_frac 0.994365 DCF 0.450380
2022-05-02 17:25:35.0070 [PID=12344] [mixed] sending locality work first (0.8760)
2022-05-02 17:25:35.0073 [PID=12344] [mixed] sending non-locality work second
2022-05-02 17:25:35.0333 [PID=12344] [send] [HOST#12060147] will accept beta work. Scanning for beta work.
2022-05-02 17:25:35.0747 [PID=12344] [version] Checking plan class 'BRP4X64'
2022-05-02 17:25:35.0775 [PID=12344] [version] reading plan classes from file '/BOINC/projects/EinsteinAtHome/plan_class_spec.xml'
2022-05-02 17:25:35.0775 [PID=12344] [version] plan class ok
2022-05-02 17:25:35.0775 [PID=12344] [version] Don't need CPU jobs, skipping version 133 for einsteinbinary_BRP4G (BRP4X64)
2022-05-02 17:25:35.0775 [PID=12344] [version] Checking plan class 'opencl-intel_gpu-new'
2022-05-02 17:25:35.0775 [PID=12344] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2022-05-02 17:25:35.0775 [PID=12344] [version] GPU RAM calculated: min: 512 MB, use: 360 MB, WU#638199123 CPU: 248 MB
2022-05-02 17:25:35.0775 [PID=12344] [version] [HOST#12060147] device name: 'Intel(R) HD Graphics 4000'; OpenCL driver version: 10.18.10.5161; platform version: OpenCL 1.2; device version: OpenCL 1.2
2022-05-02 17:25:35.0775 [PID=12344] [version] driver version 1018105161, min: 0, max: 1018103906
2022-05-02 17:25:35.0775 [PID=12344] [version] driver version required max: 1018103906, supplied: 1018105161
2022-05-02 17:25:35.0776 [PID=12344] [version] Don't need CPU jobs, skipping version 133 for einsteinbinary_BRP4G ()
2022-05-02 17:25:35.0776 [PID=12344] [version] no app version available: APP#25 (einsteinbinary_BRP4G) PLATFORM#9 (windows_x86_64) min_version 0
2022-05-02 17:25:35.0776 [PID=12344] [version] no app version available: APP#25 (einsteinbinary_BRP4G) PLATFORM#2 (windows_intelx86) min_version 0
2022-05-02 17:25:35.0777 [PID=12344] [version] Checking plan class 'opencl-intel_gpu-new'
2022-05-02 17:25:35.0777 [PID=12344] [version] parsed project prefs setting 'gpu_util_brp': 1.000000
2022-05-02 17:25:35.0777 [PID=12344] [version] GPU RAM calculated: min: 512 MB, use: 360 MB, WU#635808899 CPU: 248 MB
2022-05-02 17:25:35.0777 [PID=12344] [version] [HOST#12060147] device name: 'Intel(R) HD Graphics 4000'; OpenCL driver version: 10.18.10.5161; platform version: OpenCL 1.2; device version: OpenCL 1.2
2022-05-02 17:25:35.0777 [PID=12344] [version] driver version 1018105161, min: 0, max: 1018103906
2022-05-02 17:25:35.0777 [PID=12344] [version] driver version required max: 1018103906, supplied: 1018105161
2022-05-02 17:25:35.0777 [PID=12344] [version] no app version available: APP#19 (einsteinbinary_BRP4) PLATFORM#9 (windows_x86_64) min_version 0
2022-05-02 17:25:35.0777 [PID=12344] [version] no app version available: APP#19 (einsteinbinary_BRP4) PLATFORM#2 (windows_intelx86) min_version 0
2022-05-02 17:25:35.0800 [PID=12344] [version] Checking plan class 'FGRPopencl-ati'
2022-05-02 17:25:35.0800 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0800 [PID=12344] [version] No ATI devices found
2022-05-02 17:25:35.0800 [PID=12344] [version] Checking plan class 'FGRPopencl-intel_gpu'
2022-05-02 17:25:35.0800 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0800 [PID=12344] [version] GPU RAM calculated: min: 766 MB, use: 750 MB, WU#638220295 CPU: 429 MB
2022-05-02 17:25:35.0800 [PID=12344] [version] OpenCL GPU RAM required min: 803209216.000000, supplied: 609012941
2022-05-02 17:25:35.0800 [PID=12344] [version] Checking plan class 'FGRPopencl-nvidia'
2022-05-02 17:25:35.0800 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0800 [PID=12344] [version] No CUDA devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] Checking plan class 'FGRPopencl1K-ati'
2022-05-02 17:25:35.0801 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0801 [PID=12344] [version] No ATI devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] Checking plan class 'FGRPopencl1K-nvidia'
2022-05-02 17:25:35.0801 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0801 [PID=12344] [version] No CUDA devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] Checking plan class 'FGRPopenclTV-nvidia'
2022-05-02 17:25:35.0801 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0801 [PID=12344] [version] No CUDA devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] Checking plan class 'FGRPopencl2-ati'
2022-05-02 17:25:35.0801 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0801 [PID=12344] [version] No ATI devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] Checking plan class 'FGRPopencl2Pup-nvidia'
2022-05-02 17:25:35.0801 [PID=12344] [version] parsed project prefs setting 'gpu_util_fgrp': 1.000000
2022-05-02 17:25:35.0801 [PID=12344] [version] No CUDA devices found
2022-05-02 17:25:35.0801 [PID=12344] [version] no app version available: APP#40 (hsgamma_FGRPB1G) PLATFORM#9 (windows_x86_64) min_version 0
2022-05-02 17:25:35.0801 [PID=12344] [version] no app version available: APP#40 (hsgamma_FGRPB1G) PLATFORM#2 (windows_intelx86) min_version 0
2022-05-02 17:25:35.0802 [PID=12344] [version] Checking plan class 'FGRPSSE'
2022-05-02 17:25:35.0802 [PID=12344] [version] plan class ok
2022-05-02 17:25:35.0802 [PID=12344] [version] Don't need CPU jobs, skipping version 108 for hsgamma_FGRP5 (FGRPSSE)
2022-05-02 17:25:35.0802 [PID=12344] [version] no app version available: APP#46 (hsgamma_FGRP5) PLATFORM#9 (windows_x86_64) min_version 0
2022-05-02 17:25:35.0802 [PID=12344] [version] no app version available: APP#46 (hsgamma_FGRP5) PLATFORM#2 (windows_intelx86) min_version 0
2022-05-02 17:25:35.0836 [PID=12344] [send] [HOST#12060147] is looking for work from a non-preferred application
2022-05-02 17:25:35.0949 [PID=12344] [debug] [HOST#12060147] MSG(high) No work sent
2022-05-02 17:25:35.0949 [PID=12344] [debug] [HOST#12060147] MSG(high) see scheduler log messages on https://einsteinathome.org/host/12060147/log
2022-05-02 17:25:35.0949 [PID=12344] Sending reply to [HOST#12060147]: 0 results, delay req 60.00
2022-05-02 17:25:35.0950 [PID=12344] Scheduler ran 0.179 seconds
Je n'ai plus qu'une seule NVidia 1080Ti, la 2ème étant kaputt. Ma bécane étant viellissante, je ne la pousse pas à fond. Je coupe la tâche Einstein avec du Milkyway pour éviter les plantages. D'ailleurs le GPU plante les O2/O3. Je n'ai pas d'outil pour mesurer la charge GPU, par contre j'ai remarqué que la puissance nécessaire (mesurée par l'onduleur) descendait en début et en fin de tâche Einstein. La température GPU baisse quand il est sur la tâche Milkyway qui elle ne provoque pas de suspension d'une tâche CPU.Pour la charge du GPU il y a un outil graphique que tu peux voir ici :
Voilà, en gros j'ai fini par trouver de façon empirique un réglage qui fait que plus rien ne plante et je m'y tient. :)
Je pense que tu parles d'un sous-projet en particulier (Pulsar search ?) car le gravitational wave pour moi n'a pas bougé depuis longtemps.
Einstein@Home is down due to a (Uni Hanover) campus-wide power outage. The machines keep running on UPS, but the UPS that powers the network failed. It is unclear when power and operation can be restored, but it should be a matter of hours rather than days.
Einstein@Home est en panne en raison d'une panne de courant à l'échelle du campus (Uni Hanover). Les machines continuent de fonctionner sur UPS, mais l'UPS qui alimente le réseau a échoué. On ne sait pas quand le courant et le fonctionnement peuvent être rétablis, mais cela devrait être une question d'heures plutôt que de jours.
Ca tombe bien switche sur WCG on commence à réussir à choper du MCM pour octobre rose ;)
y'en a qui se sont ramenés avec du lourd....
[ This attachment cannot be displayed inline in 'Print Page' view ]
y'en a qui se sont ramenés avec du lourd....
[ This attachment cannot be displayed inline in 'Print Page' view ]
Heu, il y a un problème avec ces stats ou je raconte encore des conneries :blbl:
https://stats.free-dc.org/team/eah/17
y'en a qui se sont ramenés avec du lourd....
[ This attachment cannot be displayed inline in 'Print Page' view ]
Heu, il y a un problème avec ces stats ou je raconte encore des conneries :blbl:
https://stats.free-dc.org/team/eah/17
tu reponds en mars a un message de novembre, donc forcement les stats ont changees.....
C'est le problème avec les captures d'écran[ This attachment cannot be displayed inline in 'Print Page' view ]
:desole:
Je pense que free-dc c'est du RAC XML et StatSeb c'est "le RAC calculé de Seb", et chez SetiBZH t'as les deux
- RAC XML : https://statsbzh.boinc-af.org/list.php?calcrac=false&tri=rac&project_id=einsteinathome
- RAC calculé (de SetiBZH, pas exactement le même que StatSeb) : https://statsbzh.boinc-af.org/list.php?calcrac=true&tri=rac&project_id=einsteinathome
(tu constates la subtile différence dans l'URL avec le calcrac=false ou true)
Parce que sinon c'est pas rigolo :)
Tu remarqueras que les grands totaux de chacun sont eux à peu près les mêmes sur les 3 sites = cf fréquence et période de MaJ des sites de stats.
Merci beaucoup Kali, c'est très intéressant !:jap: :jap:
:jap:
Merci pour la trad, publié sur le portail :jap:
RÉSULTATS DE LA RECHERCHE PROFONDE DANS TOUT LE CIEL SUR LES DONNÉES DE LIGO O3 (https://einsteinathome.org/fr/content/results-deep-all-sky-search-ligo-o3-data)
Soumis le 20 Apr 2023 15:22:16 UTC
Les résultats de notre recherche tout ciel d'ondes gravitationnelles continues dans les données publiques du troisième cycle d'observation de LIGO (O3) ont été publiés sur le serveur de prépublication arXiv : Deep Einstein@Home all-sky search for continuous gravitational waves in LIGO O3 public data (https://arxiv.org/abs/2303.04109). Le manuscrit est actuellement en cours d'évaluation par les pairs pour publication dans The Astrophysical Journal.
Notre publication décrit l'étude Einstein@Home de l'ensemble du ciel à la recherche d'ondes gravitationnelles continues à des fréquences comprises entre 20 Hz et 800 Hz, en utilisant les dernières données LIGO. À ce jour, il s'agit de la recherche la plus sensible dans cette gamme.
La recherche n'a révélé aucun signal d'ondes gravitationnelles. Sur cette base, nous tirons des conclusions sur la population d'étoiles à neutrons dans notre voisinage galactique. Par exemple, dans un rayon de 100 parsecs (~330 années-lumière) autour de la Terre, il n'y a pas d'étoiles à neutrons tournant à plus de 12 000 tours par minute avec des montagnes équatoriales de plus d'un demi-millimètre ; sinon, nous aurions très probablement détecté leurs ondes gravitationnelles continues.
L'équipe LIGO ajoute de faux signaux continus d'ondes gravitationnelles aux données, à des fins de validation. Les paramètres du signal sont connus. Dans son domaine de recherche, notre recherche récupère avec précision les faux signaux. Cela nous conforte dans la sensibilité de notre recherche.
Actuellement, nous effectuons des recherches supplémentaires sur les données publiques de LIGO. Alors que nous continuons à explorer ces données à la recherche d'ondes continues, nous remercions du fond du cœur tous ceux d'entre vous qui rendent ce travail possible en donnant des cycles à partir de leurs ordinateurs !
Si vous souhaitez en savoir plus, répondez à cette nouvelle dans notre forum de discussion.
M. Alessandra Papa
https://www.aei.mpg.de/continuouswaves
A noter aussi une petite news que j'ai dénichée dans une discussion sur leur forum :
--> il n'y aura bientôt plus de tâches FGRPB1G disponibles. Un mec sur leur forum estime que le projet s'arrêtera d'ici 7 mois.
Donc pour les soucieux d'étoiles WUPROP ou pour les mordus de points (car c'est le projet EINSTEIN le plus rentable actuellement) profitez en sans tarder. (ca tombe bien il y a un raid actuellement :lol: )
Kali.
Merci pour l'info. :jap:A noter aussi une petite news que j'ai dénichée dans une discussion sur leur forum :
--> il n'y aura bientôt plus de tâches FGRPB1G disponibles. Un mec sur leur forum estime que le projet s'arrêtera d'ici 7 mois.
Donc pour les soucieux d'étoiles WUPROP ou pour les mordus de points (car c'est le projet EINSTEIN le plus rentable actuellement) profitez en sans tarder. (ca tombe bien il y a un raid actuellement :lol: )
Kali.
J'ai posté la question sur le forum Einstein sur le temps qui reste pour le sous-projet "Gamma-ray pulsar binary search #1 on GPUs" :
https://einsteinathome.org/fr/goto/comment/212793 (https://einsteinathome.org/fr/goto/comment/212793)
Il reste environ 4 moins de calculs donc pour ceux qui veulent augmentez les heures WUPROP sur FGRPB1G, ne tardez pas.
Kali.
En raison de travaux de maintenance nécessaires sur l'alimentation électrique, nous devons fermer les serveurs E@H le lundi 14 août vers 6 heures UTC. Nous prévoyons de revenir en ligne le lendemain, mardi, vers 17 heures UTC.
26 Dec 2023 6:09:50 UTC 26 Dec 2023 11:24:23 UTC Completed, waiting for validation 18 640 16 697 0 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnuEt un PI 5.
26 Dec 2023 6:10:53 UTC 26 Dec 2023 11:24:23 UTC Completed, waiting for validation 18 758 16 790 0 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnu
26 Dec 2023 6:10:54 UTC 26 Dec 2023 11:24:23 UTC Completed, waiting for validation 16 854 15 055 0 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnu
26 Dec 2023 5:18:02 UTC 26 Dec 2023 11:12:17 UTC Completed and validated 10 494 9 489 62 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnuLa différence est impressionnante. :eek:
26 Dec 2023 5:18:02 UTC 26 Dec 2023 11:11:15 UTC Completed and validated 10 877 9 854 62 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnu
26 Dec 2023 5:18:02 UTC 26 Dec 2023 11:01:31 UTC Completed and validated 10 367 9 485 62 Binary Radio Pulsar Search (Arecibo,GBT) v1.61 aarch64-unknown-linux-gnu
Chers croqueurs !
Nous aimerions partager avec vous deux choses :
a) l'application GW accélérée par le GPU est maintenant beaucoup moins gourmande en mémoire et moins susceptible de produire des erreurs. Si vous aviez précédemment choisi de ne pas utiliser l'application GW, nous vous invitons à reconsidérer votre décision et à donner une chance à la nouvelle version.
b) pour célébrer la nouvelle application, nous avons une offre spéciale pour les fêtes de fin d'année pour nos calculateurs : vous obtiendrez deux fois les crédits BOINC pour les résultats de l'application GW.
[voir les détails dans le fil du forum]
Traduit avec DeepL.com (version gratuite)
Nous avons travaillé dernièrement à l'amélioration de l'expérience de calcul lors de l'exécution de l'O3 All Sky Continuous Gravitational Wave Search (O3ASHF search).
Nous avions remarqué que certaines choses n'étaient pas optimales : l'application nécessitait à l'origine près de 4 Go de mémoire sur votre carte graphique, ce qui, il faut bien l'admettre, était trop ambitieux. Nous avons remarqué que de nombreux résultats nous revenaient comme des erreurs de calcul, causées par des erreurs d'allocation de mémoire. Nous avons également remarqué qu'un certain nombre d'utilisateurs ont abandonné l'application sur les ondes gravitationnelles, et nous soupçonnons que le taux d'erreur relativement élevé et les exigences élevées en matière de mémoire sont à l'origine de cette situation. Nous sommes désolés pour les inconvénients que cela a pu causer.
Nous avons donc modifié les unités de travail et l'application de manière substantielle : Au lieu de traiter une certaine quantité d'espace de paramètres en une seule fois par unité de travail (et d'utiliser jusqu'à près de 4 Go de VRAM pour cela), la nouvelle application fonctionnera sur des unités de travail qui parcourent ce même espace mais en deux étapes séquentielles, couvrant à chaque fois la moitié du volume de recherche précédent. L'avantage est que la VRAM maximale utilisée pour cela n'est plus que d'environ 2 Go, et pour créer une marge de sécurité, nous laissons BOINC supposer un besoin d'environ 2,5 Go.
La nouvelle version de l'application a été déployée il y a quelque temps et nous constatons une diminution substantielle du nombre d'unités de travail qui échouent avec une erreur, ce qui signifie que cela fonctionne comme prévu.
Important : Si vous avez précédemment désactivé la recherche d'ondes gravitationnelles en faveur de la recherche accélérée par le GPU BRP7, nous vous invitons à réactiver la recherche d'ondes gravitationnelles dans vos préférences (sous le paramètre "Projet" : notez que vous pourriez vouloir configurer cela dans tous les "lieux" BOINC).
Bonne année 2024 Crédits supplémentaires
Pour vous inciter à essayer la nouvelle application (en particulier si vous avez précédemment choisi de ne pas l'utiliser), et en guise de compensation pour les problèmes potentiels rencontrés dans le passé, nous avons augmenté les crédits pour chaque nouvelle unité de travail générée à partir de maintenant à 10 000, soit le double du montant précédent.
Quelques notes techniques supplémentaires
Si vous disposez d'une carte graphique avec 4GB VRAM ou moins, vous voudrez probablement vous assurer que vous n'exécutez pas accidentellement deux ou plusieurs instances de l'application en même temps. Le "facteur d'utilisation du GPU" dans les préférences de votre projet dans BOINC doit être fixé à 1,0 dans ce cas, ce qui est la valeur par défaut. Si vous avez réduit ce facteur à 0,5 etc. pour permettre plusieurs unités en parallèle dans le passé, et que vous voyez des erreurs dans le calcul (parce que BOINC essaiera de démarrer deux unités avec une utilisation de RAM très proche de 4GB au total, parce que BOINC est trompé par une faible utilisation de VRAM au tout début de l'application), vous devez le régler sur 1,0.
Bon calcul !
KLiK a écrit :CiterUne petite digression, pour une tâche de GW...elles finissent à 99,5% et ensuite elles restent suspendues pendant un moment, faisant seulement du travail CPU alors que le GPU est à un % minimal...est-ce que ces tâches ont vraiment besoin de faire ces évaluations CPU pendant si longtemps ou est-ce que c'est un "glitch" ?
Ce n'est pas un problème, c'est la façon dont l'application OpenCL fonctionne actuellement. La même chose se produit autour de 49.5% ... 50% .
Voici pourquoi : Après l'analyse initiale des données, la validation et les préparations qui sont effectuées sur le CPU uniquement, la partie GPU commence et l'application calcule plusieurs milliers de candidats signaux potentiels, classés en fonction d'une certaine statistique de détection. Cette partie du calcul est très bien adaptée au traitement GPU car (en simplifiant quelque peu), nous pouvons essayer de nombreux modèles de signaux dans une grille de fréquences régulièrement espacées et pour des points de ciel identiques en parallèle, et effectuer les mêmes opérations en parallèle pour des points de données différents mais "similaires" dans une telle configuration est ce à quoi les GPU sont vraiment bons.
Une fois que nous disposons d'une liste de candidats, nous devons effectuer des opérations sur chacun d'entre eux. Comme ces candidats proviennent maintenant d'un sous-ensemble peu dense des grilles de recherche originales et qu'ils sont donc répartis sur l'ensemble du ciel et non plus disposés selon une grille de fréquence régulière, cette étape supplémentaire n'est plus aussi bien adaptée aux calculs GPU. C'est pourquoi l'application OpenCL actuelle effectue désormais ces opérations sur le processeur.
Les "nouvelles" unités de travail contiennent maintenant un paquet de deux sous-unités de travail, de sorte que cette commutation entre le traitement intensif par le GPU et le traitement uniquement par le CPU se produit deux fois par an.
sans aucun calcul CPU, le temps de calcul des All-Sky Gravitational Wave search on O3 était divisé par 3.
Pas d'incidence avec du Milkyway en CPU
A part ça que veux dire: "another scheduler instance for this host is running" ou quelque chose d'approchant
et j'ai l'impression de ne pas avoir tous mes points
Pour ta première remarque, c'est cohérent : All-Sky Gravitational Wave search on O3 demande beaucoup de ressources CPU malgré que cela soit une appli GPU. Surtout si tu as un GPU puissant accompagné d'un CPU modeste. Si tu donnes ta config, je pourrai te confirmer cela.
Milkyway fait du Multi-Thread mais n'occupe pas tous les cœurs, ce qui laisse de la "place" pour Einstein, contrairement à PrimeGrid qui charge à fond ;)
Tu veux dire "si les autres core CPU sont utilisés sur d'autres projets et avec un core réservé pour O3 il met 3 fois plus de temps que si aucun autre projet boinc ne tourne en même temps ?Oui c'est ça.
Je comprends pas bien : tu veux dire "si jamais c'est milky CPU qui tourne en même alors le tâche O3 mais 1/3 du temps que si c'est un autre projet boinc qui tourne" ?Les calculs Milky multithread n'occupent que 32 coeurs (16x2). Et là tout fonctionne normalement (j'ai 40 coeurs en tout). Ce qui accredite la thèse qu'il faut plus qu'un core CPU pour faire tourner une appli GPU O3.
A part ça que veux dire: "another scheduler instance for this host is running" ou quelque chose d'approchantJ'ai vu ça dans le journal de boinc manager. cela ne s'est pas reproduit.
Ca je comprends pas : du mt qui n'occupe pas tous les coeurs tu veux dire "du mt pas trop bien codé" ? et du coup cet heureux effet de bord donne plus d'espace au CPU pour O3 ?
Et quand tu parles de "laisser de la place pour O3" tu sous-entends "même si erik a réservé un code CPU pour O3 ce n'est probablement pas suffisant ?
Très clair.J'ai commencé les test mais ça va prendre un petit peu de temps, pour le moment je suis en job cache full
Faudrait que t'essayes de colmater petit à petit les coeurs libres avec des tâches non mt d'autres projets (en réduisant puis augmentant peu à peu le % de CPU global autorisé dans les réglages boinc) pour voir à partir de quelle limite de coeurs dispo ça commence à merder, parce que dit comme ça "il faut 8 coeurs libres pour 2 tâches" ça paraît aberrant :)
Il a été dit qu'avec les versions récentes (non ancestrales) de Boinc, il réserve les CPU nécessaires pour alimenter le GPU maintenant (c'est pour ça que j'aime bien CUDA car il prend très peu de CPU).
Réserver un CPU peu être utile avec par exemple un programme externe (comme Folding@Home) à qui on veut laisser un coeur logique CPU pour alimenter son GPU.