[Stampede 19] Back to Rosetta@Home

[m_p_g]

Rosetta is "zwaar" voor de systemen, dat wil zeggen een hele goede stabiliteitstest. De meeste Rosetta issues die ondervonden worden, zijn wel terug te voeren op de combinatie van de hardware en settings.

De nadruk is dat vrijwel de overgrote meerderheid van de WU's gewoon goed afgerond kunnen worden.
De problemen met de enkele WU's die maar door blijven gaan, lijkt te liggen aan het niet aanmaken van een checkpoint.
Daardoor kan de Rosetta watchdog ook niet ingrijpen, want er is geen cpu tijd sinds het laatste checkpoint!
Waardoor het checkpoint niet aangemaakt wordt, is nog even de vraag. Herstart van dezelfde WU heeft bij een andere user geen verschil opgeleverd in de uitkomst.

Nu is bij Rosetta besloten om de watchdog op te hogen van 4 naar 10 uur, maar de meningen hierover verschillen. Want als op een "snel" systeem na 24 uur nog geen checkpoint aangemaakt is, zal een totale default looptijd van 8+4(wd)=12 naar 8+(10wd)=18 uur ook niet helpen.

Ik kijk het nog even aan met een "oneindige WU" die op 2 verschillende systemen draait , waarbij de systemen "bewezen" prime stabiel zijn getest. Misschien dat de Rosetta developers er binnenkort achter kunnen komen waardoor sporadisch een WU het genoemde gedrag vertoond.

[teacup]

bierschuit schreef op zaterdag 18 april 2020 @ 22:53:
Volgens mij zijn de meeste issues die mensen hebben toch aan hun systeem gerelateerd. Die abort sommen zijn gewoon vanaf de server gestopt. Maar hangende taken en falen met errors... Misschien toch niet helemaal fris die pc's.

Zou kunnen, maar zonder verdere argumenten blijft je opmerking natuurlijk een mening . Ik kan maar een hardwarematig argument verzinnen dat de foutgevoeligheid van onze PC's relatief groter maakt, geen ECC geheugen gebruiken. Hierbij neem ik aan dat de meeste home build systemen geen ECC hebben. Mijn systemen hebben geen ECC geheugen. De koetjes die deel uitmaken van werkstations of servers hebben een grotere kans op ECC geheugen. Dan zou een verschil in foutgevoeligheid moeten zijn aan te tonen.

Omgevingsfactoren zijn een andere mogelijke oorzaak die ik zie. Laten we die systemen rustig hun ding doen? Draaien de systemen maximaal, of laten we ze omwille van continubedrijf in een lager temperatuurgebied draaien? Klooien we ondertussen met die computers. Zo heb ik een systeem met een draaiende BOINC een reboot gegeven van een systeem. Dat vond BOINC niet zo leuk, koetjes in disarray. Dan moeten we inderdaad niet met een vermoorde onschuld blik in het rond kijken dat processen foutlopen.

Maar al die factoren meenemend kan ik mijzelf niet aan de impressie onttrekken dat er overeenkomsten zijn in de jobs die fout gaan:

Inmiddels heb ik op een PC 3 asymptotische jobs die niet af lijken te willen ronden:


Alle drie beginnen ze met de job names met de string 12v1n_al_12mer_design_

In mijn job historie zie ik ook een drietal Error while computing jobs:

• Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_4ks6zg6l_914748_2_0
• Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_1dj9gl5u_914738_2_0
• Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_1ul0cw9x_913396_3_0

In de job names is de string Junior_HalfRoid_design4_ een gemeenschappelijkheid.

Dit geeft mij de suggestie dat het hier geen random verschijnsel betreft. Wel is het zo dat alle zes issues op een van mijn twee systemen plaatsvond. Een systeemspecifieke oorzaak is dus nog steeds een mogelijkheid.

Vanmiddag start voor de 12v1n_al_12mer_design_ groep een job op mijn tweede systeem. Dit systeem rekent met iets krachtiger cores en heeft per core meer geheugen. Treedt op dit systeem ook het asymptoot gedrag op, dan lijkt het issue wat mij betreft op de 12v1n_al_12mer_design_ batch terug te voeren.

De statement over de Error while computing jobs kan ik veel minder hard maken, omdat van die batch ook dingen goed gaan, op allebei mijn systemen:

• Junior_HalfRoid_design4_cart_COVID-v19_SAVE_ALL_OUT_IGNORE_THE_REST_1xa3ao0g_913396_2_0
• Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_3sg7mr7s_913392_4_0
• Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_1cc7mp1d_913391_4_0

Met iets meer info over de foute jobs kunnen we elkaar misschien helpen onnodig rekenwerk te voorkomen. Zien anderen jobs met:

1. Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST
2. 12v1n_al_12mer_design_

fout gaan, of juist goed? Of zijn er andere job names die aandacht behoeven? Jaag ik spoken na, of heeft het zin om een lijstje bij te houden met job batches die op sommige systemen problemen kunnen opleveren? Het doel is nadrukkelijk geen name en shame, maar meer als assistentie bij foutanalyse.

[Lrrr]

Die Junior_HalfRoid_design4 taken zie ik regelmatig langskomen, die gaan bij mij gewoon goed. Ik draai op een cloud VM dus grote kans dat daar wel ECC geheugen in zit.

Edit: Even de geschiedenis gecheckt en ook die 12v1n_al_12mer_design taken gaan bij mij goed

[ Voor 22% gewijzigd door Lrrr op 19-04-2020 13:08 ]

[teacup]

Lrrr schreef op zondag 19 april 2020 @ 13:03:
Die Junior_HalfRoid_design4 taken zie ik regelmatig langskomen, die gaan bij mij gewoon goed. Ik draai op een cloud VM dus grote kans dat daar wel ECC geheugen in zit.

Dank je Lrrr, zo komen we samen verder . Zelf ben ik ook kritisch over de bewuste client met de fouten, al kan ik de vinger nog niet op de zere plek leggen.

Edit 1

m_p_g schreef op zondag 19 april 2020 @ 12:34:
De nadruk is dat vrijwel de overgrote meerderheid van de WU's gewoon goed afgerond kunnen worden.

Is ook zo, lees mijn reactie alsjeblieft niet als name & shame. Als jobs niet goed gaan dan is het denk ik wel goed die te benoemen, zolang we maar vaststellen dat hun gedrag ook echt systematisch is. Het kan frustratie bij de DC-ers wegnemen als ze kunnen zien dat ze niet de enige zijn met een issue en ze van de andere kant juist alert maken nog eens goed naar hun eigen systemen te kijken als hun fout niet door anderen wordt herkend.

De problemen met de enkele WU's die maar door blijven gaan, lijkt te liggen aan het niet aanmaken van een checkpoint.Daardoor kan de Rosetta watchdog ook niet ingrijpen, want er is geen cpu tijd sinds het laatste checkpoint! Waardoor het checkpoint niet aangemaakt wordt, is nog even de vraag. Herstart van dezelfde WU heeft bij een andere user geen verschil opgeleverd in de uitkomst.

Hier wil ik nog aan toevoegen dat een checkpoint ondervangt dat een job te lang doorloopt. De oorzaak waarom de job te lang doorloopt wordt niet ondervangen. Als ik je goed begrijp tenminste. Ik veronderstel dat de exitstatus dan op iets als Error while computing uitkomt.

Ik kijk het nog even aan met een "oneindige WU" die op 2 verschillende systemen draait, waarbij de systemen "bewezen" prime stabiel zijn getest. Misschien dat de Rosetta developers er binnenkort achter kunnen komen waardoor sporadisch een WU het genoemde gedrag vertoond.

Zelf laat ik die jobs ook lopen, ze leveren waarschijnlijk geen punten op maar mijn nieuwsgierigheid is ook een factor . Ze komen ook nog steeds verder, al gaat dit heel langzaam. Een job bereikt vanavond zijn deadline, en die gaat hij niet halen. Van de ander jobs kan ik het nog niet beoordelen. Straks heb ik wel vier van deze jobs op twee systemen gehad, wat toch best een capaciteitsdrain is, als je bedenkt dat ze qua tijd drie slots innemen (op mijn systemen tenminste). Interessant info zou zijn of deze jobs op een moderne cpu core voor de deadline zijn door te rekenen. Met die info zou Rosetta wat kunnen met de toekenningscriteria.

Edit 2

Lrrr schreef op zondag 19 april 2020 @ 13:03:
Edit: Even de geschiedenis gecheckt en ook die 12v1n_al_12mer_design taken gaan bij mij goed

Oke, dat is dan inderdaad een toevoeging! Kan je iets zeggen over hun doorlooptijd? Het systeem waarop ik het verschijnsel zie is een oudere laptop met een i7 processor. Misschien kan het betekenen dat het geen job is voor oudere langzamere CPU's.

[ Voor 78% gewijzigd door teacup op 19-04-2020 13:44 ]

[bierschuit]

@teacup Mijn kennis omtrent grote en langdurige werkloads is matig. Maar ik kan alleen aangeven met wat ik zie gebeuren op de systemen die ik laat draaien.

Ik heb een AMD en een Intel gebaseerd systeem. Met 2x8GB en 2x16GB non ECC geheugen. Ik zie bij beide systemen dat de taken gereed zijn als ze de 98% aantikken, dan worden ze afgerond naar 100% en gereed gemeldt.

Intel: 9900k / Asrock Phantom Gaming ITX/ac / G.Skill TridentZ 3600C15 / Win10 Home.
Handmatige overklok 4.4Ghz op 1.15V under load en temp van 60 ~ 65C, RAM wordt zo'n 42 tot 45C warm.

AMD 3950x / Asus Crosshair H7 X470 / Corsair Dom 3466C16 @ 3600C16 / Win10 Pro.
AMD PPT limiet op 155W, TDC 100Á, EDC 145Á (Rond de 4050Mhz 24/7) rond de 62C/69C, RAM 43C tot 48C.

Ik krijg dezelfde workloads als iedereen en alle taken worden foutloos uitgevoerd. Als ECC zo belangrijk zou zijn dat het telkens moet corrigeren lijkt mij dat ook niet juist. Dat is toch de bedoeling van ECC? Single bit error correcting?

Bijgevoegd, screenshot takenlijst Rosetta.

[Robinski]

De runtimes van WU's gaan veel minder voorspelbaar worden.
Zie ook: https://boinc.bakerlab.or...thread.php?id=13826#94811

Advies/verzoek vanuit het project:
- Zorg voor minder dan 1 dag aan voorraad
- Hou er rekening mee dat bij default runtime WU's er 18 uur (CPU tijd) over kunnen gaan doen. (maar ook korter)
- Hou de target runtime op default

[uray]

75% van mijn Grazers hebben ECC, en toch heb ik ook een paar van die Oneindige WU's gehad.
( juist op de ECC Grazers )

Just Saying...

[uray]

Na 48 uur + gaan ze bij mij op de Composthoop...

[teacup]

@bierschuit
Nou je systemen bieden een mooie referentie met de bovenkant van het computerspectrum. Wat een joblist (kwijl). Zie in je joblist ook verschillende 12v1n_al_12mer_design jobs staan. Jouw reactie en die van anderen geven in ieder geval meer vertrouwen dat die 12v1n_al_12mer_design jobs in ieder geval zijn af te ronden.

Zelf draai ik (nog) op twee bescheiden Intel systemen:

• i5-4690K met 16GB RAM (2x8) op Asrock Z97 Extreme4 uit 2015 die ik niet boven de 55 graden laat uitkomen. Momenteel geen overklok. Dit systeem draait als een tierelier, maar is ook aan het folden, heeft maar 4 Rosseta threads.
• Het probleemkind: Lenovo T530 uit 2011 (ja ja het oude beest draait nog steeds), i7-3630QM, 8GB geheugen. Mijn verdenking bij dit systeem is het geheugengebruik. Veel van de threads draaien echter minder dan 1GB/thread. Met OS draait het systeem momenteel met 5,7 van de 7,8 effectieve GB's in gebruik. Bij een kleiner geheugen zijn de geheugensectoren ook wat kleiner, dat helpt mij wat mee in het effectief gebruiken van wat beschikbaar is. Maar enige monitoring moet ik wel gaan draaien, zal hwinfo ook eens laten kijken, de laptop puft en blaast maar is nog niet instabiel geweest.

Met mijn opmerking over ECC wil ik alleen maar aangeven dat dat dit het enige is wat bij continue processen de kans zou moeten verkleinen op fouten. Over hoe die fouten dan zouden kunnen optreden en hoe ECC die ondervangt weet ik niet. In pro hardware als werkstations, maar zeker servers is ECC geheugen wel een ding. Of we met onze liefdadigheid ECC zouden moeten gaan gebruiken, dat zou niet nodig moeten zijn. Onze hardware is al betrouwbaar genoeg om Rosetta jobs tot een goed einde te moeten kunnen brengen. Behalve instabiliteit (die we dan ook heel duidelijk zien gebeuren) zie ik weinig redenen waarom hardware rekenfouten kan veroorzaken, zolang ze binnen haar parameters functioneert.

Maar de parameters van het T530 beestje ga ik nog wel even checken .

[bierschuit]

@teacup Ik ben het met je eens over je ECC opmerking.

Heb je misschien al eens een oudere versie van BOINC geprobeerd op je laptop? Alle versies zijn hier te verkrijgen: https://boinc.berkeley.edu/dl/?C=M;O=D
(Geen idee of het iets doet, het is dus een longshot)

[noo]

teacup schreef op zondag 19 april 2020 @ 12:59:
[...]
Met iets meer info over de foute jobs kunnen we elkaar misschien helpen onnodig rekenwerk te voorkomen. Zien anderen jobs met:

1. Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST
2. 12v1n_al_12mer_design_

fout gaan, of juist goed? Of zijn er andere job names die aandacht behoeven? Jaag ik spoken na, of heeft het zin om een lijstje bij te houden met job batches die op sommige systemen problemen kunnen opleveren? Het doel is nadrukkelijk geen name en shame, maar meer als assistentie bij foutanalyse.

Ik heb er eentje die geeindigd is in 'Error':

code:

<core_client_version>7.16.6</core_client_version>
<![CDATA[
<message>
process exited with code 1 (0x1, -255)</message>
<stderr_txt>
command: rosetta_4.16_x86_64-apple-darwin -run:protocol jd2_scripting -parser:protocol jhr_boinc_v3.xml @flags -in:file:silent Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_2tw6xi3w.silent -in:file:silent_struct_type binary -silent_gz -mute all -out:file:silent_struct_type binary -out:file:silent default.out -in:file:boinc_wu_zip Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_2tw6xi3w.zip @Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_2tw6xi3w.flags -nstruct 10000 -cpu_run_time 28800 -watchdog -boinc:max_nstruct 1000 -checkpoint_interval 120 -database minirosetta_database -in::file::zip minirosetta_database.zip -boinc::watchdog -run::rng mt19937 -constant_seed -jran 1437826
Starting watchdog...
Watchdog active.
Starting watchdog...
Watchdog active.

ERROR: Assertion `copy_pose.size() == native.size()` failed. MSG:the reference pose must be the same size as the working pose
ERROR:: Exit from: src/protocols/protein_interface_design/filters/RmsdFilter.cc line: 323
BOINC:: Error reading and gzipping output datafile: default.out
08:36:38 (61298): called boinc_finish(1)

</stderr_txt>
]]>

Maar ook veel van beide die wel succesvol zijn.

[m_p_g]

Hieronder een quote van een Rosetta Moderator op het forum over de langlopende WU's:

Edit: Another report on a 12v1n_ task running over two days.

My suggestion: the maximum CPU time a WU could be configured to run would be the 36 hour maximum runtime preference plus the new 10 hour watchdog. 46 hours of CPU is less than the 2 days you are showing. So I would have to take that as evidence that it is not running normally and should be aborted.
Rosetta Moderator: Mod.Sense

Indien ze al langer dan 48 uur draaien, dan afbreken is het advies....

Lang niet alle 12V1 taken vertonen dit gedrag. Ik heb er ook genoeg bij die wel tot een goed einde worden gebracht. Het lijken op dit moment slechts enkele WU's te zijn van de 12V1 reeks.

[hrothberht]

Ik had ook een paar taken die eindigden in "error while computing". Dat bleek aan te weinig schijfruimte te liggen. Wel een beetje raar, want dat gebeurde eerder niet, maar misschien dat één taak van de rails af ging en opeens de hele schijf volgooide ofzo. Ze moeten bij Rosetta nu zo snel voor zo veel taken zorgen, er kan makkelijk af en toe een rotte appel tussen zitten.

Als je een "error while computing" krijgt, check dan gewoon even de STDERR output, want die wordt netjes gelogged. In je profiel op de site ga je naar je takenlijst en klik je op de Task ID van de gefaalde taak, en dan vind je onderaan de pagina de STDERR output.

[hrothberht]

teacup schreef op zondag 19 april 2020 @ 12:59:
[...]

Jaag ik spoken na, of heeft het zin om een lijstje bij te houden met job batches die op sommige systemen problemen kunnen opleveren? Het doel is nadrukkelijk geen name en shame, maar meer als assistentie bij foutanalyse.

Heb je de STDERR output van de gefaalde taken gecontroleerd? Op basis van alleen de taaknamen een oorzaak zien te vinden is wel heel lastig.

[teacup]

m_p_g schreef op zondag 19 april 2020 @ 18:45:
Lang niet alle 12V1 taken vertonen dit gedrag. Ik heb er ook genoeg bij die wel tot een goed einde worden gebracht. Het lijken op dit moment slechts enkele WU's te zijn van de 12V1 reeks.

Dit kan ik inmiddels beamen. De 12v1n_al_12mer_design job die op mijn tweede systeem heeft gedraaid gedroeg zich als een Gazelle. In 4,5 uur was de job klaar.



Vanmiddag heb ik zelf ook wel een moment gedacht om 12v1n_al_12mer_design jobs op voorhand al uit de wachtrij weg te knippen, zal ik eerlijk toegeven. Maar jouw opmerking en de ervaringen van Lrrr, bierschuit en mijzelf nuanceren dat beeld.

Laten we dus niet op voorhand de 12v1n_al_12mer_design jobs gaan cancellen. Gewoon dus lekker laten doorlopen en soms de voortgang een beetje in de gaten houden. Deze job, en misschien juist die grotere, kunnen juist essentieel zijn voor het counteren van Covid-19. Ondanks het advies laat ik trouwens mijn jobs nog even doorlopen...gewoon nieuwsgierig .

Edit 1

hrothberht schreef op zondag 19 april 2020 @ 19:21:
[...]
Heb je de STDERR output van de gefaalde taken gecontroleerd? Op basis van alleen de taaknamen een oorzaak zien te vinden is wel heel lastig.

Het is de eerste keer dat ik dit doe, dank je voor de tip. Om verwarring voor anderen te voorkomen, het ondergaande gaat over de Junior_HalfRoid_design4_ jobs die waren vastgelopen:

Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_4ks6zg6l_914748_2_0
ERROR: Assertion `copy_pose.size() == native.size()` failed. MSG:the reference pose must be the same size as the working pose
ERROR:: Exit from: ..\..\..\src\protocols\protein_interface_design\filters\RmsdFilter.cc line: 323
BOINC:: Error reading and gzipping output datafile: default.out
16:49:50 (16400): called boinc_finish(1)

Junior_HalfRoid_design4_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_1dj9gl5u_914738_2_0
ERROR: Assertion `copy_pose.size() == native.size()` failed. MSG:the reference pose must be the same size as the working pose
ERROR:: Exit from: ..\..\..\src\protocols\protein_interface_design\filters\RmsdFilter.cc line: 323
BOINC:: Error reading and gzipping output datafile: default.out
15:28:34 (5828): called boinc_finish(1)

Junior_HalfRoid_design4_cart_COVID-19_SAVE_ALL_OUT_IGNORE_THE_REST_1ul0cw9x_913396_3_0
ERROR: Assertion `copy_pose.size() == native.size()` failed. MSG:the reference pose must be the same size as the working pose
ERROR:: Exit from: ..\..\..\src\protocols\protein_interface_design\filters\RmsdFilter.cc line: 323
BOINC:: Error reading and gzipping output datafile: default.out
18:53:02 (15356): called boinc_finish(1)

Issues zijn dus identiek. Voor zover ik het kan interpreteren lijkt het voorbereiden van de output fout te gaan. De jobs zijn gespreid in de tijd fout gegaan. Nu heb ik wel het systeem met een lopende BOINC reboot zonder die jobs even stil te zetten. Dit kan corruptie veroorzaken verwacht ik. Maar de spreiding van bijna een dag maakt dit als oorzaak minder waarschijnlijk. Mijn harde schijf heeft trouwens zo'n 100GB vrije ruimte. Dat lijkt dus wel goed te gaan. Maar dank je voor de tip om hier even naar te kijken.

Edit 2 20:30 uur
Net kom ik erachter dat er best wat 12v1n_al_12mer_design jobs vanuit de server zijn gecancelled met als exit status: 202 (0x000000CA) EXIT_ABORTED_BY_PROJECT. In totaal 6 jobs op de probleem computer zijn er nu weg. Op de andere computer is er niets meer verwijderd. @synoniem Helemaal een witte raaf zijn die taken dus blijkbaar ook niet geweest.

[ Voor 48% gewijzigd door teacup op 19-04-2020 20:53 ]

[synoniem]

Niet allemaal maar er zitten er wel een paar slechte tussen:

Sun 19 Apr 2020 08:19:43 PM CEST | Rosetta@home | Result 12v1n_al_12mer_design_00546_010155_0001_SAVE_ALL_OUT_914644_365_0 is no longer usable

In het algemene Boinc manager overzicht is status Aborted by project, hoewel die pas 2,5 uur gelopen had.

[ari2asem]

ik heb op mijn 2 systemen ecc-reg staan. en op alle 2 krijg ik foutmeldingen. dus het heeft niets met ecc-reg te maken.

ik draai nu in totaal 3 systemen, 2 met ecc-reg, 1 met gewoon memory. 2 systemen met 250gb ssd, 1 met 1tb ssd.

op mijn meest krachtig systeem (128gb ecc-reg, 1tb m2 nvme ssd, 128 threads) krijg ik heel vaak (meerdere per dag) meldingen dat rosetta meer ssd ruimte nodig heeft (iets van 2gb meer nodig heeft), terwijl mijn 1tb ssd nog maar 50% vol is. oftewel hij zeurt om meer ruimte (2gb) terwijler ruim 450gb vrij beschikbaar is.
dit heeft niks met mijn instellingen te maken, want ik heb mijn instellingen (op de computer en op de web) allemaal zelfde staan. en al 7-8 keer gecheckt of ze overeenkomen en correct staan.

anders gezegd, ik negeer nu al deze meldingen binnen boinc.

wat ik zeggen wou...ik denk dat we niet zo veel kunnen doen aan die wu-foutmeldingen. zoveel controle hebben we niet.

[uray]

Vandaar dat ik ze 48 uur geef... En wat die Schijfruimte fouten betreft. Die heb ik al sinds de start van de Spampede. Heb ze niet serieus genomen en (bijna) alles complete netjes, dus.....

[Resistor]

Meldingen dat de schijven vol zouden zijn heb ik ook op mijn Windows computers gezien. Iedere keer dat er nog een paarhonderd MB's nodig was.

Ik heb de limieten uitgezet, qua verbruik weinig veranderd, maar de meldingen zijn weg.

[A-Jay]

WE HEBBEN DE 100M GEHAALD

Met al onze 1204 koeien zijn we samen de 100M voorbij in de stampede stats.

Gisteren hebben 698 koeien 5.1M weggezet, waarbij er 54 badges zijn behaald.

Alle details hier A-Jay in "[Stampede 19] Rosetta@Home week 4"

[DerManiak]

A-Jay schreef op maandag 20 april 2020 @ 08:15:
WE HEBBEN DE 100M GEHAALD

Met al onze 1204 koeien zijn we samen de 100M voorbij in de stampede stats.

Gisteren hebben 698 koeien 5.1M weggezet, waarbij er 54 badges zijn behaald.

Alle details hier A-Jay in "[Stampede 19] Rosetta@Home week 4"

Nice! En morgen pakken we BOINC@Poland

Voor mij m'n 3e badge, en zet straks een 2e aan het grazen. Eens zien wat m'n nieuwe werklaptop kan produceren in de laatste 10 dagen van de stampede.

[A-Jay]

Alle stats A-Jay in "[Stampede 19] Rosetta@Home week 4"

66 badges voor 66 koeien

748 koeien hebben samen 5.4M weggezet.

Ook zijn er weer 3 nieuwe koeien bij wat het totaal op 1207 brengt.

[bierschuit]

Hopelijk brengt deze wat punten op; Het gaat om de rb_04_20_xxxx serie. Die hebben aardig wat rekentijd nodig zeg. Dit is de langst durende die ik tot nu toe nog heb gehad.

Meer mensen die deze extra lange workunit's krijgen?
/edit. Als ik het over de duuvel heb... na 11 uur en 16 minuten staat ie op 100%: ready to report.

[ Voor 7% gewijzigd door bierschuit op 21-04-2020 12:50 ]

[uray]

Ja, meerdere...

[A-Jay]

58 badges voor 58 koeien.

Met 733 mensen hebben we 5.5M weggezet.

Het totaal is nu 111M.

Alle details A-Jay in "[Stampede 19] Rosetta@Home week 4"

[Tux3.14]

Boven de 200.000 punten

[teacup]

Vanmorgen op 1 PC 4 gecancelde jobs (4021451):


In mijn job list stonden er nog wat meer die nog niet eens waren gestart, maar allemaal deel uitmaakten van mijn andere PC (4157093):

[A-Jay]

De stats zijn er weer A-Jay in "[Stampede 19] Rosetta@Home week 4"

Gisteren 720 koeien die 5.6M weg hebben gezet mede omdat tijn weer op stoom is.

Ook waren er weer 64 badges voor evenveel koeien.

[Aardwolf]

Justberry schreef op maandag 13 april 2020 @ 23:53:
Ik was deze maand nog zo trots dat mijn waterkoeling al die jaren het heeft overleeft!
& nu vandaag in idle 80 graden.. denk dat die het heeft begeven.
Mooi excuse voor een nieuwe case met een 240rad mogelijkheid

Water verdampt door de load. Of is je pomp kapot? Arme computer.

[Aardwolf]

M-spec schreef op donderdag 16 april 2020 @ 18:18:
Nu vind ik het credit systeem nog niet echt kloppen bij dit project. Je kan er weinig van op aan. Het verschilt te veel per WU, van een 10K tot soms richting 20K totaal per dag, en er zit zeker geen 50% verschil in output.

Wat bedoel je met "bij dit project", Rosetta doet niet alleen covid bij mij weten? Kan best zijn dat die andere subprojecten minder punten leveren. Ik heb bijv. nu een rits taken in de rij staan met niks over covid. Tis maar afwachten of ze ook even veel punten geven. Maar het maakt me minder uit, de bijdrage gaat het om. En ik neem aan dat dergelijke verdeling gelijk is over de participanten, waardoor het voor de stampede ook wat minder uitmaakt.

[Aardwolf]

m_p_g schreef op zondag 19 april 2020 @ 12:34:
Rosetta is "zwaar" voor de systemen, dat wil zeggen een hele goede stabiliteitstest. De meeste Rosetta issues die ondervonden worden, zijn wel terug te voeren op de combinatie van de hardware en settings.

Dat klopt, maar definieer zwaar. Folding is wel minder dan een Prime95 of andere linpack stresstest. Simpelweg omdat bij folding meestal niet al het geheugen wordt gebruikt. Als beide testen stabiel zijn, dan lukt folding prima en gaming helemaal. Dus: computer onstabiel, testen met dergelijke programma's en met voltages rommelen (en/of koeling verbeteren). puur baseren op een foldingload vind ik dan wat onvoorspelbaar waar het aan ligt, welke component, welk voltage.

[M-spec]

marcel87 schreef op donderdag 23 april 2020 @ 13:58:
[...]

Wat bedoel je met "bij dit project", Rosetta doet niet alleen covid bij mij weten? Kan best zijn dat die andere subprojecten minder punten leveren. Ik heb bijv. nu een rits taken in de rij staan met niks over covid. Tis maar afwachten of ze ook even veel punten geven. Maar het maakt me minder uit, de bijdrage gaat het om. En ik neem aan dat dergelijke verdeling gelijk is over de participanten, waardoor het voor de stampede ook wat minder uitmaakt.

Het viel mij gewoon op dat de WU's van Rosetta (nog) niet echt een redelijk gemiddelde credit uitgave hebben. De laatste paar dagen gaat het ook weer omhoog. Van een goede 10K naar weer 19-21K gemiddeld per dag op mijn rekenkoe.

De bijdrage is wat voor te zeggen, tuurlijk. Ik doneer ook al wel 15 jaar rekenwerk in plaats van sponsoring aan de deur (voor die onredelijke graaiers die zich directeur noemen van een stichting). En dan vooral in de maanden dat de elektriciteit en warmte ook niet weg is zeg maar. Soms komen er veelbelovende en nuttige resultaten uit projecten, niet altijd maar we doen met z'n allen in ieder geval een poging tot.

Credits zijn dan een getal maar het maakt het wel leuker als je daarmee redelijk goed kan zien wat we allemaal bijdragen. En iedereen de koe(ien) toch wel de nodige middelen moet geven om te blijven grazen.
Met de jaarlijkse stampede blijkt in ieder geval maar weer dat deze kudde in verhouding tot ons landje heel groot is.

[hrothberht]

Weet iemand of er al wat concreets is gekomen uit al het coronarekenwerk van Rosetta?

marcel87 schreef op donderdag 23 april 2020 @ 13:58:
[...]

Ik heb bijv. nu een rits taken in de rij staan met niks over covid.

Dat er geen COVID in de task name staat wil volgens mij niet per se zeggen dat de taken niet coronagerelateerd zijn. De naamgeving is redelijk arbitrair. Ik neem eigenlijk aan dat zo'n beetje alle taken nu coronagerelateerd zijn, omdat we begin april alle taken die Rosetta in reserve had afgewerkt hadden, en ik neem aan dat de taken die sindsdien gegenereerd zijn voornamelijk voor corona zijn (omdat daar nu het meeste onderzoek naar gedaan wordt en omdat ze waarschijnlijk makkelijk gewoon veel taken daarvoor kunnen genereren door steeds wat parameters te variëren). Maar goed, ik kan er ook naast zitten natuurlijk

[noo]

hrothberht schreef op donderdag 23 april 2020 @ 16:51:
Weet iemand of er al wat concreets is gekomen uit al het coronarekenwerk van Rosetta?


[...]


Dat er geen COVID in de task name staat wil volgens mij niet per se zeggen dat de taken niet coronagerelateerd zijn. De naamgeving is redelijk arbitrair.

Klopt, er was een aantal weken geleden een discussie over het gebrek aan het woord 'COVID' in de naam van de WUs en mensen die om die reden niet (meer) mee wilden doen. Wat ik uit die thread begreep is dat een wetenschapper zelf de naam van zijn WUs kan bepalen (het aantal WUs met 'COVID ' in de naam is volgens mij wel toegenomen de laatste week of twee, drie.)

[ari2asem]

zijn er hier ook mensen die last hebben van connectiviteit met het project.

soms gaat uploaden heel langzaam, soms het rapporteren (als het klaar is en geupload is)...in de boinc-logs zie iets van PROJECT SERVER DOWN. CHECKING TEMPORARLY SERVER


iemand ook zoiets meegemaakt? bij mij duurt dit al paar dagen.

[synoniem]

ari2asem schreef op donderdag 23 april 2020 @ 19:03:
zijn er hier ook mensen die last hebben van connectiviteit met het project.

soms gaat uploaden heel langzaam, soms het rapporteren (als het klaar is en geupload is)...in de boinc-logs zie iets van PROJECT SERVER DOWN. CHECKING TEMPORARLY SERVER


iemand ook zoiets meegemaakt? bij mij duurt dit al paar dagen.

Ja maar in de log staat dan een paar minuten later dat de upload of download klaar is. Waarschijnlijk worden de servers behoorlijk zwaar belast.

Ik had overigens een paar validate errors en ingetrokken taken in WU's met dezelfde namen als hier eerder genoemd zijn. Maar ook een paar die wel gevalideerd zijn dus er is geen peil op te trekken.

[teacup]

Op een computer zie ik bij het uploaden soms ook wat problemen. WU's blijven dan even in Transfers staan:

4/23/2020 9:12:41 PM | | Project communication failed: attempting access to reference site
4/23/2020 9:12:41 PM | Rosetta@home | Backing off 00:03:17 on upload of r3x_2938_fold_SAVE_ALL_OUT_919913_472_0_r627634219_0
4/23/2020 9:12:43 PM | | Internet access OK - project servers may be temporarily down.
[...]
4/23/2020 9:19:16 PM | | Project communication failed: attempting access to reference site
4/23/2020 9:19:16 PM | Rosetta@home | Backing off 00:07:23 on upload of r3x_2938_fold_SAVE_ALL_OUT_919913_472_0_r627634219_0
4/23/2020 9:19:17 PM | | Internet access OK - project servers may be temporarily down.
[...]
4/23/2020 9:34:44 PM | | Project communication failed: attempting access to reference site
4/23/2020 9:34:44 PM | Rosetta@home | Backing off 00:03:09 on upload of hugh2020_HHH_rd4_0636_K6L__HH_run17_step403_fragments_abinitio_SAVE_ALL_OUT_924315_495_0_r1419775829_0
4/23/2020 9:34:47 PM | | Internet access OK - project servers may be temporarily down.

Gelukkige bereiken alle WU's bij mij uiteindelijk de status ready to report. Some een beetje geduld hebben dus.

[A-Jay]

En weer een hoop stats A-Jay in "[Stampede 19] Rosetta@Home week 4"

Het totaal aantal koeien blijft gelijk en we zijn de 120M voorbij.

Gisteren hebben 715 koeien 5M weggezet, waarbij er 51 badges te verdelen waren.

[A-Jay]

Alle stats A-Jay in "[Stampede 19] Rosetta@Home week 4"

53 badges zijn er weer verdiend.

701 koeien zetten 7.6M weg.

[synoniem]

Voor mensen die net als ik Boinc in een docker container draaien: Ik zie bij één specifieke machine regelmatig staan "Waiting for memory" en maar één taak die draait. Als ik de container stop en opnieuw opstart gaan er gelijk weer vier taken draaien. Ik vermoed omdat de betreffende machine niet zoveel schijfruimte heeft dat het herstarten de gereserveerde schijfruimte voor tijdelijke bestanden weer vrij geeft.

[Aristo]

synoniem schreef op zaterdag 25 april 2020 @ 11:17:
Voor mensen die net als ik Boinc in een docker container draaien: Ik zie bij één specifieke machine regelmatig staan "Waiting for memory" en maar één taak die draait. Als ik de container stop en opnieuw opstart gaan er gelijk weer vier taken draaien. Ik vermoed omdat de betreffende machine niet zoveel schijfruimte heeft dat het herstarten de gereserveerde schijfruimte voor tijdelijke bestanden weer vrij geeft.

De melding "Waiting for memory" gaat over het RAM, niet over de schijfruimte. Rosetta geeft zo nu en dan vrij resource-heavy taken uit die nogal wat RAM vragen. Vooral de COVID-19 taken zijn doorgaans veeleisend vanwege de complexe eiwit structuur.

Het RAM gebruik loopt bij die taken verder op naarmate ze langer draaien. Bij het herstarten van de docker container is dat geheugen weer (even) vrij. Zodra de taken weer wat langer lopen gaan ze langzaamaan weer meer RAM nodig hebben, en zal BOINC een of meerdere taken stoppen om RAM vrij te maken voor die taak/taken met de hoogste prioriteit.

Je kan dit voorkomen door, indien mogelijk, meer RAM toe te wijzen aan je VM / docker container of (meer) swap ruimte beschikbaar te stellen voor BOINC. Hoewel dat laatste misschien niet heel wenselijk is omdat BOINC dan veel gaat lezen/schrijven naar je HDD/SSD.

[synoniem]

Aristo schreef op zaterdag 25 april 2020 @ 20:28:
[...]


De melding "Waiting for memory" gaat over het RAM, niet over de schijfruimte. Rosetta geeft zo nu en dan vrij resource-heavy taken uit die nogal wat RAM vragen. Vooral de COVID-19 taken zijn doorgaans veeleisend vanwege de complexe eiwit structuur.

Het RAM gebruik loopt bij die taken verder op naarmate ze langer draaien. Bij het herstarten van de docker container is dat geheugen weer (even) vrij. Zodra de taken weer wat langer lopen gaan ze langzaamaan weer meer RAM nodig hebben, en zal BOINC een of meerdere taken stoppen om RAM vrij te maken voor die taak/taken met de hoogste prioriteit.

Je kan dit voorkomen door, indien mogelijk, meer RAM toe te wijzen aan je VM / docker container of (meer) swap ruimte beschikbaar te stellen voor BOINC. Hoewel dat laatste misschien niet heel wenselijk is omdat BOINC dan veel gaat lezen/schrijven naar je HDD/SSD.

Dat zou ik ook verwachten maar ik heb ongeveer 2 GB per taak beschikbaar en ik heb vier verschillende systemen waarvan alleen deze dit verschijnsel heeft. Het enige verschil wat ik tussen die systemen zie is de schijfruimte. En Boinc benut nog geen kwart van de swap. Maar ik zal eens kijken of het met een lagere swappiness beter wordt.

[Aristo]

synoniem schreef op zaterdag 25 april 2020 @ 20:40:
[...]

Dat zou ik ook verwachten maar ik heb ongeveer 2 GB per taak beschikbaar en ik heb vier verschillende systemen waarvan alleen deze dit verschijnsel heeft. Het enige verschil wat ik tussen die systemen zie is de schijfruimte. En Boinc benut nog geen kwart van de swap. Maar ik zal eens kijken of het met een lagere swappiness beter wordt.

2 GB per taak lijkt mij wel voldoende inderdaad, hoewel ik een taak wel eens meer heb zien gebruiken, maar dat heb ik maar een hand vol keren gezien.

Kan je in de docker container zien hoeveel geheugen bepaalde procesjes pakken? Wanneer die melding weer tevoorschijn komt, geeft dat misschien meer inzicht of het daadwerkelijk om een veeleisende Rosetta taak gaat, of om iets anders wat veel geheugen vraagt.

[JustMyOpinion]

Nu het einde bijna daar is.... (eerste echt volledige stampede hier) Krijgen we aan het eind nog een mooi overzicht hoe "we" het gedaan hebben ten opzichte van de vorige jaren?

Ben wel benieuwd of de hoeveelheid deelnemers en punten stijgen/dalen.

[KuuKe]

Een vergelijking met voorgaande jaren is wel lastig te maken omdat de punten per project nogal verschillen.

Echter qua deelnemers was deze stampede echt een topper. Dit hebben we de laatste jaren niet meer meegemaakt.

Zal grotendeels komen voor Covid-19 maar ook de frontpage aandacht die we hebben gekregen heeft veel volk getrokken.

[JustMyOpinion]

Verschillen de punten per project joh? Ik dacht dat dat wel gelijk getrokken zou zijn om "a level playing field" te krijgen. (Daar je ook totale BOINC ranking hebt)

Leuk om te horen dat er dit jaar weer meer mensen bij betrokken zijn. Hoop dat het weer beetje aantrekt. En idd zal zeker komen door corona, maar toch, positief!

[DaMoUsYs]

We kunnen toch de procentuele stijging nemen tijdens het project ?
Dan heb je wel een redelijk vergelijk toch ?

[teacup]

DaMoUsYs schreef op maandag 27 april 2020 @ 20:14:
We kunnen toch de procentuele stijging nemen tijdens het project ?
Dan heb je wel een redelijk vergelijk toch ?

Bedoel je de stijging van de situatie na de stampede ten opzichte van de situatie vlak voor de stampede? Zoiets lijkt mij in ieder geval zinnig.

[DaMoUsYs]

Ja dat bedoel ik, dan gebruik je de stijging van beide projecten in procenten.
Dat is altijd een eerlijk vergelijk volgens mij

[Bubbles]

JustMyOpinion schreef op maandag 27 april 2020 @ 20:12:
Verschillen de punten per project joh? Ik dacht dat dat wel gelijk getrokken zou zijn om "a level playing field" te krijgen. (Daar je ook totale BOINC ranking hebt)

[...]

Niet alle projecten zijn boinc. En ook binnen de boinc-projecten zijn er wel verschillen hoeveel punten er worden uitgekeerd voor een bepaalde rekentijd, dus nee, op die manier is het zeker niet te vergelijken.

Procentueel kan een idee zijn om een indruk te krijgen hoe succesvol de stampede voor dat project is geweest, maar zelfs dan is het niet goed tussen projecten te vergelijken; sommige projecten hebben sowieso al meer gebruikers/rekenkracht dan anderen, waardoor een procentuele stijging dan ook anders kan uitpakken.

Maar wat @KuuKe ook al zei: dit is 1 van de meer succesvollere stampedes als we puur kijken naar het aantal deelnemers. En dan te bedenken dat er ook nog een enorme stijging bij F@H is geweest tijdens min of meer dezelfde periode.

[APClll]

Bubbles schreef op maandag 27 april 2020 @ 22:42:
[...]

Niet alle projecten zijn boinc. En ook binnen de boinc-projecten zijn er wel verschillen hoeveel punten er worden uitgekeerd voor een bepaalde rekentijd, dus nee, op die manier is het zeker niet te vergelijken.

Procentueel kan een idee zijn om een indruk te krijgen hoe succesvol de stampede voor dat project is geweest, maar zelfs dan is het niet goed tussen projecten te vergelijken; sommige projecten hebben sowieso al meer gebruikers/rekenkracht dan anderen, waardoor een procentuele stijging dan ook anders kan uitpakken.

Maar wat @KuuKe ook al zei: dit is 1 van de meer succesvollere stampedes als we puur kijken naar het aantal deelnemers. En dan te bedenken dat er ook nog een enorme stijging bij F@H is geweest tijdens min of meer dezelfde periode.

Tja, het is natuurlijk ook maar net hoe je "succesvol" wilt definiëren. Nieuwe DPC-leden, extra power, impact op het project, sfeer hier in de topics. Of het krijgen van een setje nieuwe klompen ( )

[Bubbles]

APClll schreef op maandag 27 april 2020 @ 22:48:
[...] Of het krijgen van een setje nieuwe klompen ( )

You remembered! Was persoonlijk wel 1 van de beste stampedes ja. Heb ze toevallig vandaag nog in mijn handen gehad, moest een kastje waar ze in stonden leegruimen om te verplaatsen.

[APClll]

Natuurlijk, dat soort momenten vergeet je toch niet?

[lasermen]

Bubbles schreef op maandag 27 april 2020 @ 22:42:
[...]

Niet alle projecten zijn boinc. En ook binnen de boinc-projecten zijn er wel verschillen hoeveel punten er worden uitgekeerd voor een bepaalde rekentijd, dus nee, op die manier is het zeker niet te vergelijken.

Procentueel kan een idee zijn om een indruk te krijgen hoe succesvol de stampede voor dat project is geweest, maar zelfs dan is het niet goed tussen projecten te vergelijken; sommige projecten hebben sowieso al meer gebruikers/rekenkracht dan anderen, waardoor een procentuele stijging dan ook anders kan uitpakken.

Maar wat @KuuKe ook al zei: dit is 1 van de meer succesvollere stampedes als we puur kijken naar het aantal deelnemers. En dan te bedenken dat er ook nog een enorme stijging bij F@H is geweest tijdens min of meer dezelfde periode.

En ook nog een mooie eind sprint om wellicht mogelijk toch de Italianen voor het einde van de maand in te kunnen halen Al ben ik bang dat het begin mei gaat gebeuren.

Owja, voor wie het nog niet door had, "het pctje" waar ik vorige maand over had, het werkt! en staat lekker te grazen

[A-Jay]

We kunnen wel een vergelijking maken dankzij https://www.boincstats.com/stats/-1/cpcs
Tussen de score's van de afgelopen 5 jaar, zowel aantal users, score....etc..

[synoniem]

Aristo schreef op zaterdag 25 april 2020 @ 20:47:
[...]


2 GB per taak lijkt mij wel voldoende inderdaad, hoewel ik een taak wel eens meer heb zien gebruiken, maar dat heb ik maar een hand vol keren gezien.

Kan je in de docker container zien hoeveel geheugen bepaalde procesjes pakken? Wanneer die melding weer tevoorschijn komt, geeft dat misschien meer inzicht of het daadwerkelijk om een veeleisende Rosetta taak gaat, of om iets anders wat veel geheugen vraagt.

Afgelopen dagen de boel een beetje in de gaten gehouden maar dit verschijnsel niet meer waargenomen. Kennelijk toch een (aantal) incidentele taak(en) geweest?

[Terrible T]

Op Rosetta forum valt de score van [DPC] Nifhack sommigen op.

Als hij leest kan hij misschien direct beantwooorden?

https://boinc.bakerlab.or...thread.php?id=13833#95449

[vdr01]

Wie bovenstaande link volgt, het staat op page 3 van het draadje

[KuuKe]

LOL, ze zijn vergeten dat Nifhack een aantal jaren geleden ook al eens zo gruwelijk heeft huisgehouden op Rosetta@Home.

@lasermen : https://boinc.bakerlab.or...=13833&postid=95449#95449

[vdr01]

Use your Raspberry Pi to join the fight against COVID-19

https://www.notebookcheck...st-COVID-19.463108.0.html

[Aristo]

synoniem schreef op dinsdag 28 april 2020 @ 11:45:
[...]

Afgelopen dagen de boel een beetje in de gaten gehouden maar dit verschijnsel niet meer waargenomen. Kennelijk toch een (aantal) incidentele taak(en) geweest?

Ik vermoed van wel dan. Zo nu en dan komen wat flinke taken voorbij. Heb ook een poosje Einstein@home geprobeerd, maar de taken daarvan vroegen teveel resources voor het systeem waar ik het destijds op wou draaien. Sommige taken vroegen ruim 4GB RAM per stuk. Dat gaat erg hard met RAM gebruik als je er 8 tegelijk wil draaien.

[JustMyOpinion]

vdr01 schreef op dinsdag 28 april 2020 @ 17:37:
Use your Raspberry Pi to join the fight against COVID-19

https://www.notebookcheck...st-COVID-19.463108.0.html

Iemand al geprobeerd? Hoe kan je je eigen account koppelen?

[GoldenLeafBird]

vdr01 schreef op dinsdag 28 april 2020 @ 17:37:
Use your Raspberry Pi to join the fight against COVID-19

https://www.notebookcheck...st-COVID-19.463108.0.html

Enigszins het vermelden waard: Dit werkt enkel op de Raspberry Pi 4.
De RPi 3 heeft te weinig geheugen.

Edit omdat 2x achter elkaar posten zonde is:

Zijn er nog meer mensen die Boinc op hun telefoon draaien?
Op mijn OnePlus 5 draait nu ook Boinc en die haalt zo'n 1500 punten per dag, wat gelijk staat aan mijn werklaptop (Latitude E6530 met i7-3520M). Ter vergelijking draait mijn Ryzen 3600X ongeveer 7000 ppd.

[ Voor 29% gewijzigd door GoldenLeafBird op 29-04-2020 13:17 ]

[ClementL]

GoldenLeafBird schreef op woensdag 29 april 2020 @ 13:11:
[...]


Enigszins het vermelden waard: Dit werkt enkel op de Raspberry Pi 4.
De RPi 3 heeft te weinig geheugen.

Het lijkt echter wel mogelijk te zijn als je zram inschakelt.

[GoldenLeafBird]

ClementL schreef op woensdag 29 april 2020 @ 13:27:
[...]


Het lijkt echter wel mogelijk te zijn als je zram inschakelt.

Deze informatie is nieuwer dan mijn meest recente poging, ik ga het even proberen.
Ben zo terug met een update.

Update: stappen gevolgd. Nu is het, zoals ook op reddit genoemd werd, wachten tot er weer een batch vrijkomt.

Update2: Het lijkt te werken, eens zien wat dit qua punten binnenhaalt.

[ Voor 40% gewijzigd door GoldenLeafBird op 29-04-2020 15:14 . Reden: Ik had beloofd terug te komen met een update, en zie hier. ]

[vdr01]

Zram moest ik toch even opzoeken. RAM disk en/of SWAP disk.

[lasermen]

Mijn excuus voor de late reactie, maar bij deze hopelijk de meeste vragen beantwoord.

Het "pctje" is:
64x Lenovo SR655 systemen waarbij het gros is voorzien van AMD EPYC 7702P en 512GB ram.
Het staat in 4x 19" kasten.
Elk systeem heeft een Mellanox Connect LX4 die met 2x 25Gbit/s naar het netwerk aangesloten.
Subset van de systemen zijn voorzien van GPU's.

We hebben zelfs een nieuws artikeltje op onze website staan: https://www.nikhef.nl/new...-het-coronavirus-rekenen/

Ik weet dat jullie ieder geval vragen hadden: @bierschuit @KuuKe @Bubbles @Terrible T en als ik iemand vergeet dan is dat niet expres

[Tux3.14]

GoldenLeafBird schreef op woensdag 29 april 2020 @ 13:42:
[...]


Deze informatie is nieuwer dan mijn meest recente poging, ik ga het even proberen.
Ben zo terug met een update.

Update: stappen gevolgd. Nu is het, zoals ook op reddit genoemd werd, wachten tot er weer een batch vrijkomt.

Update2: Het lijkt te werken, eens zien wat dit qua punten binnenhaalt.
[Afbeelding]

Gaaf! Welke distributie gebruik jij? Ik heb boinctui ook op mijn RPi4+ met 4GB ram draaien. Ik gebruik de officiële Raspbian build in 64bit modus. Maar Boinctui geeft constant de melding bij het ophalen van taken ''This project doesn't support computers of type arm-unkwown-linux-bgnuabihf''. Hoezo unkwown

[DaMoUsYs]

@lasermen lees ik dat nu goed en kan F@H ook in BOINC toegevoegd worden?
Dacht dat je daar de F@H client voor nodig had?

[lasermen]

DaMoUsYs schreef op woensdag 29 april 2020 @ 17:56:
@lasermen lees ik dat nu goed en kan F@H ook in BOINC toegevoegd worden?
Dacht dat je daar de F@H client voor nodig had?

Wij draaien alleen Rosetta op dit moment. In het artikel op de website wordt F@H wel genoemd, maar meer om een completer verhaal van te maken voor de gemiddelde lezer.

[wildhagen]

DaMoUsYs schreef op woensdag 29 april 2020 @ 17:56:
@lasermen lees ik dat nu goed en kan F@H ook in BOINC toegevoegd worden?
Dacht dat je daar de F@H client voor nodig had?

Volgens mij niet. Ze hebben het in 2006 wel geprobeerd, maar dat is toen in de diepvrieskist gestopt: https://foldingathome.org...performance/fah-on-boinc/

[GoldenLeafBird]

Tux3.14 schreef op woensdag 29 april 2020 @ 17:36:
[...]


Gaaf! Welke distributie gebruik jij? Ik heb boinctui ook op mijn RPi4+ met 4GB ram draaien. Ik gebruik de officiële Raspbian build in 64bit modus. Maar Boinctui geeft constant de melding bij het ophalen van taken ''This project doesn't support computers of type arm-unkwown-linux-bgnuabihf''. Hoezo unkwown

Ik heb het op Ubuntu Server 18.04 draaien, op Raspbian lukte het me niet .

[Bubbles]

lasermen schreef op woensdag 29 april 2020 @ 17:29:
Mijn excuus voor de late reactie, maar bij deze hopelijk de meeste vragen beantwoord.

Het "pctje" is:
64x Lenovo SR655 systemen waarbij het gros is voorzien van AMD EPYC 7702P en 512GB ram.
Het staat in 4x 19" kasten.
Elk systeem heeft een Mellanox Connect LX4 die met 2x 25Gbit/s naar het netwerk aangesloten.
Subset van de systemen zijn voorzien van GPU's.

We hebben zelfs een nieuws artikeltje op onze website staan: https://www.nikhef.nl/new...-het-coronavirus-rekenen/

Ik weet dat jullie ieder geval vragen hadden: @bierschuit @KuuKe @Bubbles @Terrible T en als ik iemand vergeet dan is dat niet expres

Nice, bedankt voor de info! Ze waren op het forum van rosetta vooral benieuwd hoe schijnbaar 1 systeem zo'n hoge RAC kon hebben. Is dat systeem toevallig een soort proxy of host waar de andere 64 lenovo's achter zitten ofzo?

[DaSuperGrover]

Bij mij staat er soms 1 taak te wachten: wacht op geheugen. Ik heb BOINC ingesteld dat hij in idle 90% mag gebruiken, geheugen is voor 61% benut, dus waarom loopt hij niet verder? Ergens een instelling gemist?

Ryzen 2600 met 16Gb

[KuuKe]

Nog meer info in jip-en-janneke taal over wat lasermen zo in het dagelijks leven doet

[lasermen]

Bubbles schreef op woensdag 29 april 2020 @ 18:22:
[...]
Nice, bedankt voor de info! Ze waren op het forum van rosetta vooral benieuwd hoe schijnbaar 1 systeem zo'n hoge RAC kon hebben. Is dat systeem toevallig een soort proxy of host waar de andere 64 lenovo's achter zitten ofzo?

We hebben erover nagedacht en vermoeden dat er toch een bug in de website zit. Elk systeem draait z'n eigen boinc unit en praat direct terug naar Rosetta. Geen zwarte (gaten ) magie in gebruik naar mijn weten.

KuuKe schreef op woensdag 29 april 2020 @ 20:07:
Nog meer info in jip-en-janneke taal over wat lasermen zo in het dagelijks leven doet

Je bedoeld wat onze IT-Architect zoal in het dagelijkse leven doet Hij heeft ook mee gewerkt aan dit artikel https://tweakers.net/revi...oor-met-rappe-opslag.html
Maar ik ben het met je eens dat hij het best goed doet op de radio. Hij is wel vaker op BNR te horen.

[JustMyOpinion]

Goed... wie zou mijn "even" kunnen helpen?

Ik heb gisteren BOINC headless geinstalleerd op een RPI. Netjes de cc_config.xml aangepast dat ik heb via mijn laptop kon benaderen en dat is allemaal gelukt.

Einstein@home WU werden gedownload en berekend.

Echter kon ik geen Rosetta draaien i.v.m. te weinig ram. N.a.v. een post hier over ZRAM op internet gezocht en deze handleiding gevolgd: https://boinc.bakerlab.or...thread.php?id=13795#94371

Naar mijn idee alles goed uitgevoerd, er wordt echter nog niets gedownload of gerekend.

MAAR.... ik kan niet meer via mijn laptop (met BOINC Manager) inloggen op mijn RPI.

cc_config.xml ziet er nu zo uit:

code:

<cc_config>
  <log_flags>
    <task>1</task>
    <file_xfer>1</file_xfer>
    <sched_ops>1</sched_ops>
  </log_flags>
  <options>
    <alt_platform>aarch64-unknown-linux-gnu</alt_platform>
    <allow_remote_gui_rpc>1</allow_remote_gui_rpc>
  </options>
</cc_config>

Iemand een idee hoe ik weer verbinding kan maken met BOINC Manager?

[ Voor 7% gewijzigd door JustMyOpinion op 30-04-2020 20:18 . Reden: Verbetering ]

[Lrrr]

Zo, mijn koetjes zijn afgeschakeld. Het was gezellig!

[Xanquezer]

Ik loop mn taken uit... daarna zien we wel weer verder

[synoniem]

JustMyOpinion schreef op donderdag 30 april 2020 @ 19:09:
Goed... wie zou mijn "even" kunnen helpen?

Ik heb gisteren BOINC headless geinstalleerd op een RPI. Netjes de cc_config.xml aangepast dat ik heb via mijn laptop kon benaderen en dat is allemaal gelukt.

Einstein@home WU werden gedownload en berekend.

Echter kon ik geen Rosetta draaien i.v.m. te weinig ram. N.a.v. een post hier over ZRAM op internet gezocht en deze handleiding gevolgd: https://boinc.bakerlab.or...thread.php?id=13795#94371

Naar mijn idee alles goed uitgevoerd, er wordt echter nog niets gedownload of gerekend.

MAAR.... ik kan niet meer via mijn laptop (met BOINC Manager) inloggen op mijn RPI.

cc_config.xml ziet er nu zo uit:

code:

<cc_config>
  <log_flags>
    <task>1</task>
    <file_xfer>1</file_xfer>
    <sched_ops>1</sched_ops>
  </log_flags>
  <options>
    <alt_platform>aarch64-unknown-linux-gnu</alt_platform>
    <allow_remote_gui_rpc>1</allow_remote_gui_rpc>
  </options>
</cc_config>

Iemand een idee hoe ik weer verbinding kan maken met BOINC Manager?

Je kan kijken of als je met ssh naam@host -L 31417:127.0.0.1:31416 in je Boincmanager contact kan maken met host 127.0.0.1:31417

[A-Jay]

De stats van afgelopen dag A-Jay in "[Stampede 19] Rosetta@Home hitparade week 5"

Er zijn op de valreep nog 35 badges binnen gehaald.

Met 695 koeien hebben we gisteren nog 9.6M weggezet.

[A-Jay]

Ook de eind totaal stats zijn er weer A-Jay in "[Stampede 19] Rosetta@Home hitparade week 5"

In de eerste kolom je totaal tijdens de stampede, daarna je gemiddelde daily, daarna je overall totaal score en daarachter je huidge rang op de totaal lijst.

[Gwannoes]

GoldenLeafBird schreef op woensdag 29 april 2020 @ 13:11:
[...]
Zijn er nog meer mensen die Boinc op hun telefoon draaien?
Op mijn OnePlus 5 draait nu ook Boinc en die haalt zo'n 1500 punten per dag, wat gelijk staat aan mijn werklaptop (Latitude E6530 met i7-3520M). Ter vergelijking draait mijn Ryzen 3600X ongeveer 7000 ppd.

Ik had laatst op m'n Redmi Note 8 Pro ook Boinc geinstalleerd, maar er waren toen geen taken beschikbaar dus had hem weer afgesloten. Nu ik jouw bericht lees, gelijk weer aangezet, en nu staat hij lekker te draaien.

edit:

https://boinc.berkeley.edu/wiki/Android_FAQ:

Using BOINC with Android 9+
Starting with version 9, Android has policies that can cause problems with BOINC.

1) Android kills BOINC if it is running in the background. For BOINC to run, you much open it when you leave your phone to recharge at night.

2) Android kills BOINC if the display is turned off. For BOINC to run, you must either a) use a screensaver or b) configure your phone not to go to sleep (Settings / Display / Sleep). Note: on some phones the longest no-sleep option is 30 minutes.

Hier heb ik dus ook last van. Ik draai Android 10.
Als m'n telefoon aan staat, lijkt hij lekker snel te grazen, maar als ik hem een tijdje (aan de lader) uit heb staan, stopt hij er mee. Schiet niet op.
Denk dat ik hem toch maar weer verwijder.

[ Voor 41% gewijzigd door Gwannoes op 01-05-2020 11:21 . Reden: Nieuwe inzichten... ]

[A-Jay]

Voor de mensen die van meer stats houden, deze stampede met daaronder de laatste 5

Rosetta@Home 2020
1232 koeien
Totaal 187,215,495.24
Gemiddelde score per dag per koe 5,065.35

RakeSearch 2019
55 koeien
Totaal 198,160,529.61
Gemiddelde score per dag per koe 118,885.17

Milkyway@Home 2018
71 koeien
Totaal 334,661,233.95
Gemiddelde score per dag per koe 157,117.95

Seti@Home 2017
253 koeien
Totaal 74,639,147.16
Gemiddelde score per dag per koe 9,833.88

World Community Grid 2016 (Mei)
394 koeien
Totaal 332,899,666.00
Gemiddelde score per dag per koe 27,255.58

Primaboinca 2015 (Mei)
59 koeien
Totaal 100,053,600.01
Gemiddelde score per dag per koe 54,703.99

[A-Jay]

Super bedankt alle 1232 koeien voor het meedoen!

Maar naast alle gewone koeien wil ik ook even een de koeien benoemen die elke stampede lijken terug te komen....

Zoltan
[DPC]Division_Brabant~Totalmind
Crack

Hun waren hier nu 3 keer achter elkaar in een stampede

[DPC]Blah.NET
Panzer_V
HenkM
Dylan111111

Doen al 4 keer op rij mee

KEESsie
Damic
Destrega
Jelle

Deden voor de 5e keer op rij mee en hebben hun stampede lustrum

Theadalus
[DPC]Division_Brabant~Cow_tipping
[DPC] hansR
[DPC]_Fatal_Error_Group~Bubbles
Suicyder
Bassiexp
Xanquezer
BetelgeuseFive
[DPC]Division_Brabant~grass460
Arjant2
A-Jay

Doen allemaal al 5+ jaren op rij mee aan de stampede

Maar iedereen weer bedankt voor de inzet en de prestatie die we samen neerzetten.

[JustMyOpinion]

synoniem schreef op vrijdag 1 mei 2020 @ 09:11:
[...]

Je kan kijken of als je met ssh naam@host -L 31417:127.0.0.1:31416 in je Boincmanager contact kan maken met host 127.0.0.1:31417

Dank voor je antwoord. Heb het nu opgelost door helemaal opnieuw te beginnen. Kost je een uurtje, maar dan heb je wel wat

Is nu gelukt!

[HenkM2]

Het was een bijzondere stampede met een overweldigende deelname. Prachtig hoor.
De deelname heeft vast iets te maken met het Covid-19 virus. Zo zie je maar dat ellende mensen ook weer kan verenigen.

Ik ga nog een paar weekjes door.
Misschien levert het, indirect, wel een werkend vaccin op tegen dit akelige virus waar de hele wereld verschrikkelijk veel last van heeft.

[-JP-]

Xanquezer schreef op vrijdag 1 mei 2020 @ 08:27:
Ik loop mn taken uit... daarna zien we wel weer verder

Kan dit met Rosetta? Ik vind die optie niet zoals bv bij Folding.

[GoldenLeafBird]

-JP- schreef op vrijdag 1 mei 2020 @ 13:14:
[...]


Kan dit met Rosetta? Ik vind die optie niet zoals bv bij Folding.

Boinc manager > Projects tabblad > Project selecteren > No new tasks aanklikken uit het linker Commands menu.

[geenwindows]

mijn koeien zijn nu met hun laatste taken bezig. dan komt er even een "cooldown" periode aan, temperaturen in huis mogen wel wat lager worden
ook even het koelsysteem flushen, deze heeft bijna 2maanden de cpu rond de 55c moeten houden.
daarna gaan we met een lagere aantal verder met rosetta en WCG
(de 2 raspi2 hier, die doen al een tijdje werk voor einstein@home)

[Panzer_V]

Het was weer een mooi avontuur. Mijn vierde Stampede

Ondanks de oudere hardware toch nog 10% boven het gemiddelde weten te scoren.

Iedereen bedankt voor jullie inzet en tot volgend jaar

[DerManiak]

Was een hele mooie (en flinke) stampede, goed werk koetjes! Opgeklommen naar plek 9 bij de teams (zeker ook dankzij Nifhack/Nifhek/@lasermen)!
Voor mij persoonlijk toch ook aardig meegedaan, met (uiteindelijk) 2 systemen in de top 300 geëindigd en de 100k badge ruim gehaald.

Ik laat Rosetta nog wel draaien, maar niet meer 24/7, terug naar oude settings. Volgend jaar weer hoor!

[JustMyOpinion]

Kloppen onderstaande getallen? Zijn er bijna een factor 25x meer "koeien" dan vorig jaar?
Verschil lijkt me zo bizar groot, helemaal als je kijkt naar de totale punten.


Rosetta@Home 2020
1232 koeien
Totaal 187,215,495.24
Gemiddelde score per dag per koe 5,065.35

RakeSearch 2019
55 koeien
Totaal 198,160,529.61
Gemiddelde score per dag per koe 118,885.17

Milkyway@Home 2018
71 koeien
Totaal 334,661,233.95
Gemiddelde score per dag per koe 157,117.95

[A-Jay]

JustMyOpinion schreef op vrijdag 1 mei 2020 @ 15:00:
Kloppen onderstaande getallen? Zijn er bijna een factor 25x meer "koeien" dan vorig jaar?
Verschil lijkt me zo bizar groot, helemaal als je kijkt naar de totale punten.


Rosetta@Home 2020
1232 koeien
Totaal 187,215,495.24
Gemiddelde score per dag per koe 5,065.35

RakeSearch 2019
55 koeien
Totaal 198,160,529.61
Gemiddelde score per dag per koe 118,885.17

Milkyway@Home 2018
71 koeien
Totaal 334,661,233.95
Gemiddelde score per dag per koe 157,117.95

Ja die stats kloppen...

Maar, punten zijn niet per project 1 op 1 met elkaar te vergelijken. Ook zijn er grote verschillen in performance sommige projecten gebruiken CPU en GPU, anderen zijn CPU only, waarbij bijvoorbeeld RakeSearch wel tot een factor 10x sneller kon afhankelijk van welke instructie set je cpu had. (RakeSearch geoptimaliseerde client)

[JustMyOpinion]

Owkee, maar is er dan zo'n groot verschil in aantal deelnemers?! Zou leuk zijn als volgend jaar er weer een boel mensen mee doen. Misschien in mei wat "exposure" op Tweakers frontpage

Voor mezelf, geeindigd op een mooie 128e plaats! Deel gaat uit, deel gaat tandje terug. In 2013 mee gedaan, toen hele tijd niks... nu proberen te laten kabbelen tot volgend jaar!

[PD2JK]

Hier zijn de koeien ook klaar met grazen. Was leuk om even weer wat oude tijden te doen herleven. Hopelijk heb ik wat bij kunnen dragen.

[Suicyder]

Ik heb weinig vermogen gedraaid dit jaar, maar blij weer onderdeel geweest te zijn van de opzet.

@JustMyOpinion
Vorig jaar was ook wel echt een heel matig stampedejaar met tal van uitdagingen, zo was er oorspronkelijk gekozen voor een ander project dan RakeSearch maar viel deze weg door een (gigantisch) gebrek aan werk en storingen. Hierdoor viel de hele stampede een beetje uit elkaar helaas genoeg.
Daarbij wouden ook veel mensen niet meedoen ivm die optimized cliënt (vertrouwen erin miste) en met een standaard cliënt was er niet tegenop te boksen.

[ Voor 15% gewijzigd door Suicyder op 01-05-2020 15:44 ]

[JustMyOpinion]

Nou, hopen dat volgend jaar dan weer net zo'n succes wordt als dit jaar!

[KuuKe]

We hebben dit jaar een heel mooi artikel gehad op de frontpage. Dat hebben we niet ieder jaar. Wat dat betreft is er goed samengewerkt.

Daarnaast heeft de Tweakers-redactie veel aandacht geschonken aan de inzet van rekencapaciteit ivm onderzoek naar Covid-19. Eerst een artikel over Folding@Home dat al veel aandacht trok en daarna ook Rosetta@Home. Tweakers/DPC zijn verschillende malen in de pers genoemd.

Beiden zijn medische projecten en die worden ook al snel zinvoller geacht dan niet-medische projecten.
We hebben een prima stampede achter de rug. Het is in tijden niet zo druk geweest in /5. Ik hoop dat er links en rechts toch mensen blijven hangen.

Aan iedereen, zowel organisatie als alle deelnemers: bedankt!

[Suicyder]

Kijk en dan krijgen wij een mooi artikel van Olaf erop toe.

Dank!

geek: Dutch Power Cows staan ruim bovenaan in Rosetta@Home-ranglijst dankzij ...