sciencetalk

ALLE VOUWERS OPGELET

Folding heeft een vertragend probleempje.

Ik had dit al eens eerder gepubliceerd, maar ik heb het idee dat het verzuipt in het grote folding-topic. Ik wil iedereen die vouwt verzoeken hier antwoord te geven zodat we het probleem kunnen inventariseren.

Heb je meer dan één machine draaiend, vul dan niet de poll in , maar meld dan in een bericht hoeveel van je machines het wél of niet hebben.

Gebruik dit topic aub niet voor andere Folding dingetjes.....

We weten zo zoetjes aan wel dat de folding-software niet perfect is. Ik heb, zoekend naar een ander probleem, iets ontdekt waardoor Folding soms tot wel 120 % trager vouwt. (dat is minder dan half zo snel!!!)

1: open je verkenner

2: open fahlog-prev.txt (als je standaard hebt geïnstalleerd in de map C:Program FilesFolding)

Iedere keer dat Folding start schrijft hij dit in dat logboek:

--- Opening Log file [December 24 16:14:15]  

# Windows Graphical Edition ###################################################

                      Folding@Home Client Version 5.03

                         http://folding.stanford.edu

###################################################

Launch directory: C:Program FilesFolding@Home

[16:14:15] - Ask before connecting: No

[16:14:15] - User name: Jan_van_de_Velde (Team 48658)

[16:14:15] - User ID: B876EB215A509B0

[16:14:15] - Machine ID: 1

[16:14:15]  

[16:14:15] Loaded queue successfully.

[16:14:15] Initialization complete

[16:14:15] + Benchmarking ...

[16:14:18]  

[16:14:18] + Processing work unit

[16:14:18] Core required: FahCore_78.exe

[16:14:18] Core found.

[16:14:18] Working on Unit 00 [December 24 16:14:18]

[16:14:18] + Working ...

[16:14:27] + Working...

[16:14:32]  

[16:14:32] *------------------------------*

[16:14:32] Folding@Home Gromacs Core

[16:14:32] Version 1.90 (March 8, 2006)

[16:14:32]  

[16:14:32] Preparing to commence simulation

[16:14:32] - Looking at optimizations...

[16:14:32] - Files status OK[16:14:32] - Expanded 41411 -> 235757 (decompressed 569.3 percent)

[16:14:32]  

[16:14:32] Project: 2126 (Run 67, Clone 16, Gen 13)

[16:14:32]

Let op dat vette gedeelte. Meestal wordt dat ergens verderop nog gevolgd door een regeltje :

[16:14:32] Extra SSE boost OK

Het blijkt nou dat op de een of andere manier het de afsluitprocedure van Windows niet gelukt om Folding netjes af te sluiten. Bij de volgende opstart concludeert het programma dan (onterecht) dat de versnellingsprocedures (de boosts) de vorige keer de boel instabiel hebben gemaakt, en past ze niet toe. Hij gaat dan werken met de veel tragere standaard-loops, en dan lees je dit in de logs:

[21:04:22] Preparing to commence simulation

[21:04:22] - Ensuring status. Please wait.

[21:04:39] - Looking at optimizations...

[21:04:39] - Working with standard loops on this execution.  

[21:04:39] - Previous termination of core was improper.

[21:04:39] - Files status OK

Vanwege een zg. "improper termination" gaat hij draaien met "standard loops", en dat gaat trager, en voor sommige WU's véél trager. Op mijn computer draaide p2126 2 uur en 50 minuten voor 1% van de WU na een improper shutdown. Na een goeie afsluiting voor hetzelfde aantal stappen minder dan 1 uur en 20 minuten. Dat kun je zien aan het tijdsverschil tussen de meldingen:

[08:52:06] Completed 8492788 out of 50000000 steps  (17)

[08:54:55] Writing local files

[08:54:56] Completed 8500000 out of 50000000 steps  (17)

[11:44:52] Writing local files

[11:44:52] Completed 9000000 out of 50000000 steps  (18)

Steeds als hij 1 % van de workunit gevouwen heeft meldt hij dat als hierboven. Hier dus 2 uur en 50 minuten om van 17 naar 18 % te gaan.

Dat gaat de hele sessie zo door.

Je hebt zelf waarschijnlijk niks misdaan, gewoon op de normale manier je computer afgesloten de vorige keer.

KOM JE DIT REGELMATIG TEGEN IN JE LOGS, SLUIT DAN IN HET VERVOLG FOLDING AF VIA:

1: rechtse klik op icoontje in taakbalk

2: kies "Quit"

3: sluit dan pas je computer af.

Dat helpt al veel. Standaard 2 extra klikjes voordat je je computer afsluit en je zult dus gemiddeld rapper vouwen.

Op drie van mijn 4 machines kom ik regelmatig "improper terminations" tegen.

Ik ben al enkele weken niet meer thuis geweest maar hier op kot doet ie het nog altijd perfect.

Hier werkt ook alles normaal hoor

Ik kan ook die teksten zogauw niet terugvinden

Ik heb af en toe ingevuld.



In 13 maal opstarten heb ik 9 maal gewoon goed,

1 maal: - Working with standard loops on this execution.

Dat is de vertragende regel waar je het over had.

Dan hen ik nog 3 maal de volgende :

[12:33:24] - Looking at optimizations...

[12:33:24] - Not checking prior termination.

[12:33:24] - Expanded 79189 -> 420497 (decompressed 531.0 percent)



Blijkbaar wordt hier niets gechecked, er volgt ook geen status ok.

Ik weet niet wat de vouw snelheid is geweest na deze opstarts.

Bij mij is het enkele keren voorgekomen. Ik sluit F@H dus iedere keer netjes van tevoren af.

Ik heb gestemd op: "heel af en toe". Ik herinner me de 'improper terminations' alleen nog van de tijd dat ik met 5.03, de GUI-versie, werkte. Nu gebruik ik nog uitsluitend 5.04, de text-only console, en heb dit verschijnsel niet meer gehad. Ik kan eigenlijk niet zeggen of het echt aan het type client ligt of aan aan m'n hardware omdat ik nu veelal op andere, nieuwere systemen draai. Wel 'schijnt het zo te zijn' dat 5.04 stabieler is dan 5.03.

In het geval van meerdere 5.04 clients op dual-/quadcore en multiprocessor systemen is wel aanbevolen om de tags '-local' (=betere scheiding tussen de 2 applicaties) en '-verbosity 9' (=meer info in je logboek) toe te voegen.

Wat dus opgemerkt is, is dat de F@H software niet foutloos is. Het sluiten van de client middels z'n eigen 'close' lijkt de 'improper terminations' (grotendeels?) te verhelpen. Het lijkt erop dat Stanford dit probleem onderschat. Vandaar ook het terechte verzoek van Jan om hier te proberen zicht in te krijgen. Als je dus even tijd hebt, even in je logs kijken of jouw F@H dit probleem ook wel eens heeft.

Ah, ik zie nu pas dat ik de poll niet had moeten invullen. Hmm, naja. Het is hoe dan ook wel lastig zicht te krijgen over hoe vaak het verschijnsel zich voordoet en waar het aan ligt. Vollediger zou zijn: type pc, aantal keer 'improper' van totaal aantal keer F@H opstarten, etc. Maar dit is niet te doen voor ons, eingelijk is het iets dat Stanford zou moeten bekijken..

geen enkele keer slecht hier

Even een opfrissertje: kijk nog eens goed naar deze topicstart met zijn allen. Dit probleem van improper terminations is mogelijk een niet onbelangrijke reden dat onze productie fors daalt. De paar keer dat ik per ongeluk nog een improper termination krijg (zoals gisteren) draait mijn 3038 maar liefst 1:53 per frame ipv 0:47 .

Dan doe je er dus ruim 2½ keer zo lang over... [rr] ...