Folding@Home: BAD_WORK_UNIT

[AlterEgo]

[10:13:42]
[10:13:42] Received faulty work unit.
[10:13:53] logfile size: 2048
[10:13:53] - Writing 2560 bytes of core data to disk.
[10:13:53] end (WriteWorkResults)
[10:13:53]
[10:13:53] Folding@Home2 Core Shutdown: BAD_WORK_UNIT
CoreStatus = 72 (114)
Sending work to server

+ Attempting to send results
- Reading file work/wuresults_01.dat from core
(Read 2560 bytes from disk)
- Connecting to server (171.64.122.120:8080)
Initial: 0000 + Results successfully sent
Trying to send all finished work units
+ Sent 0 completed units to the server

+ Attempting to get work packet
- Connecting to assignment server
Connecting to http://assign.stanford.edu:8080/
Initial: 40AB - Successful: assigned to (171.64.122.120).
+ News From Folding@Home: Welcome to Folding@Home
- Connecting to server (171.64.122.120) on port 8080
+ Requesting work
Initial: 0000 (Got client header, size 512 bytes)
- Receiving payload (expected size: 152913)
Initial: 0000 (Got 152913 bytes of core data)
+ Received work.
+ Closed connections

Dit gebeurt me dus iedere keer na een reboot: het werk van de vorige keer wordt afgekeurd lijkt het, en de core haalt nieuwe data op om opnieuw te beginnen.....
Werk voor niets dus.

Het stomme is, FAH draait op drie machines, en slechts op eentje gaat het mis, dus configuratie-fouten zijn erg onwaarschijnlijk. Ze heben ook allemaal een verschillend machine-ID. Wat is er mis

[Remco]

heb ja al de nieuwste client ? 3.14 ?
Probeer anders eens een nieuwe install van de client

[MrGuide]

Ik denk dat het te maken heeft met het niet optijd naar schijf wegschrijven van de buffers van je systeem. Wanneer een programma (in dit geval de fah client) met de harde schijf communiceerd, zal de data die hij wegschrijft niet direct op schijf gezet worden. Deze wordt vaak eerst in een buffer geplaatst. Het is de bedoeling dat deze buffer dan op een moment dat het systeem even nix te doen heeft, ook daadwerkelijk naar de schijf wordt weggeschreven (buffers flushen heet dat).

Wanneer je je systeem reboot / afsluit is het vaak het geval dat er nog iets in de buffer staat te wachten om weggeschreven te worden. Dit moet dan ook gedaan worden voordat de computer gereboot wordt, anders zou deze data verloren gaan.

Windows Me (mogelijk hebben 95 en 98 er ook last van) heeft een fout waardoor hij op snelle machines nog wel eens eerder wil rebooten/afsluiten dan dat hij de buffers geflusht heeft. Hierdoor heeft een programma uiteindelijk niet alle data op schijf gezet die hij op schijf gezet dacht te hebben. Het resultaat is corrupte data... en dus een corrupte workunit

Oplossing als je win95,98,me hebt: Windows update. Hier is een update te vinden waarmee windows bij het afsluiten een extra pause inlast waardoor er genoeg tijd is om de buffers te flushen

Mocht dit niet werken... dan de volgende workaround gebruiken: Sluit voordat je reboot/afsluit handmatig je fah client af.

[MrGuide]

Dan nog even een opmerking over de machineID... de naam leidt idd tot verwarring, maar de machineID is dus niet bedoeld om meerdere machines van elkaar te onderscheiden. De machineID gebruik je wanneer je wanneer je meerdere clients op 1 computer hebt draaien.

Dit komt bijvoorbeeld voor bij multi-cpu systemen. Daarop moet je meerdere clients draaien omdat 1 client maar van 1 processor gebruik kan maken. Als je bijv 2 processoren hebt, zal je 2 fah clients moeten draaien op zo'n pc. Die clients kunnen dan vervolgens d.m.v. een unieke machineID uit elkaar gehouden worden.

[AlterEgo]

De client is 3.14 op een XP-SP1 machine, die verder geen kuren vertoont.
Verse installatie: maakt niets uit.
Handmatig afsluiten leidt tot hetzelfde probleem
Write-behind-caching uitzetten op de disk lost het probleem ook niet op.
Nog gekker:

[14:06:05] Folding@Home Client Core Version 2.47 (June 14, 2002)
[14:06:05]
[14:06:05] Proj: work/wudata_01
[14:06:05] nsteps: 2500000 dt: 2.000000 dt_dump: 250.000000 temperature: 298.000000
[14:06:05] xyzfile:
[14:06:05] " 343 p610_tetP30_build_ext
[14:06:05] 1 N 51.662709 30.685770 34.950598 ..."
[14:06:05] keyfile:
[14:06:05] "parameters ./opls.prm
[14:06:05] NOVERSION
[14:06:05] ARCHIVE
[14:06:05]
[14:06:05] cutoff 16.0
[14:06:05] taper 12.0
[14:06:05]
[14:06:05] ..."
[14:06:05]
[14:06:05] Hashes matched on file work/wudata_01.dyn
[14:06:05] ARC file integrity verified
[14:06:05] Restarting from checkpointed files.
[14:06:05]
[14:06:05] Protein: p610_tetP30_build_ext
[14:06:05] - Run: 18 (Clone 95, Gen 2)
[14:06:05] - Frames Completed: 1, Remaining: 199
[14:06:05] - Dynamic steps required: 2487500
[14:06:05]
[14:06:05] Writing local files:
[14:06:05]
[14:06:05] parameters work/wudata_01.prm
[14:06:05] - Writing "work/wudata_01.key": (overwrite) successful.
[14:06:05] - Writing "work/wudata_01.xyz": (overwrite) successful.
[14:06:06] - Writing "work/wudata_01.prm": (overwrite) successful.
[14:06:06] - Writing "work/wudata_01.key": (append) successful.
[14:06:06]
[14:06:06] PROJECT="work/wudata_01", NSTEPS=2487500, DT=2.0000, DTDUMP=25.000000, TEMP=298.00
[14:06:07] TINKER: Software Tools for Molecular Design
[14:06:07] Version 3.8 October 2000
[14:06:07] Copyright (c) Jay William Ponder 1990-2000
[14:06:07] portions Copyright (c) Michael Shirts 2001
[14:06:07] portions Copyright (c) Vijay S Pande 2001
[14:14:37]
[14:14:37] Received faulty work unit.
[14:14:47] logfile size: 2053
[14:14:47] - Writing 2565 bytes of core data to disk.
[14:14:47] end (WriteWorkResults)
[14:14:47]
[14:14:47] Folding@Home2 Core Shutdown: BAD_WORK_UNIT
CoreStatus = 72 (114)
Sending work to server

Let op de tijden!
14:06 sucesvolle (?) hervatting na reboot, hij gaat mooi verder met frame 2.
en pas om 14:14 (8 minuten later) komt ie erachter dat er een BAD_WORK_UNIT is

[MrGuide]

Hmmz.. vreemd

Wat gebeurd er dan als je de client handmatig afsluit, ff wacht en dan weer handmatig start?

[ Voor 0% gewijzigd door MrGuide op 03-11-2002 15:22 . Reden: typo ]

[MrGuide]

Nog een paar vraagjes:

Hoe heb je de client geinstalleerd? als service, als hidden programma of gewoon in een zichtbare dosbox? En heb je de service parameter gebruikt bij het starten van de client?

[AlterEgo]

MrGuide schreef op 03 november 2002 @ 15:28:
Nog een paar vraagjes:

Hoe heb je de client geinstalleerd? als service, als hidden programma of gewoon in een zichtbare dosbox? En heb je de service parameter gebruikt bij het starten van de client?

geprobeerd met de text-only client:
1) dosbox
2) service via firedeamon

Ofwel gewoon (zonder parameters) gestart; ofwel via FAH3Console -local -verbosity 9 vanuit de FAH-directory

En de full-graphics client 3.14:
Same shit


In alle combinaties: geen verschil.
* AlterEgo is gebaffeld

[ Voor 0% gewijzigd door AlterEgo op 03-11-2002 16:28 . Reden: typo ]

[STW]

Soms wil het wel eens gebeuren dat de client constant BAD_WORK_UNIT blijft roepen, een nieuwe op gaat halen, daar aan begint en dan weer BAD_WORK_UNIT zegt, etc.
Dit probleem ligt niet bij de WU maar bij de CORE !!. Wat je moet doen is dus de CORE weggooien, deze wordt dan opnieuw opgehaald, en als het goed is is het probleem dan opgelost.

[MrGuide]

Wat je evt nog kan proberen, is een werkende client van een andere pc compleet overkopieren naar die pc waarop je problemen hebt en dan daarmee nog eens testen.

Als dat niet gaat werken, dan ga ik toch echt weer denken aan dat buffering probleem. Naast software disk-buffering (in windows) heeft je schijf ook een buffer. Mischien dat deze het probleem veroorzaakt. Een ide-controller zou evt ook roet in het eten kunnen gooien wat dit betreft.

Mogelijk zit het probleem ook in de geheugenhoek... fouten in het geheugen kunnen ook dit soort instabiliteit en onverklaarbare fouten veroorzaken.

Ik denk dat het al met al een heleboel uitzoekwerk gaat worden wil je het probleem localiseren en kunnen oplossen. Maar als je een echte die-hard folder bent (ja natuurlijk ben je dat als je bij dpc zit ) dan heb je dat er vast wel voor over.

Wat je nog kan proberen:
- andere harddisk
- andere ide-controller (m.a.w. ander moederbord waarbij dus ook een windhoos re-install nodig is als je winxp gebruikt)
- geheugen testen (daar zijn progjes voor te vinden op internet)

[MrGuide]

STW schreef op 03 november 2002 @ 16:45:
Dit probleem ligt niet bij de WU maar bij de CORE !!. Wat je moet doen is dus de CORE weggooien, deze wordt dan opnieuw opgehaald, en als het goed is is het probleem dan opgelost.

Eej, daar had ik nog niet aan gedacht. Dit zou ook zeer goed een oorzaak van het probleem kunnen zijn.

[AlterEgo]

Hartelijk bedankt voor jullie moeite
* nieuwe core: been there, done that: geen resultaat:
* de client is een kopie die uitstekend draait op een andere PC hier op het netwerk.
* Het computer-ding heeft enige dagen terug nog 24 uur lang memtest86 gedraaid, en hiervoor ruim 2 jaat SETI en Probleemloos.

Tenzij iemand nog een geniaal idee heeft, gooi ik de handdoek in de ring.

[STW]

AlterEgo schreef op 03 november 2002 @ 16:54:
Hartelijk bedankt voor jullie moeite
* nieuwe core: been there, done that: geen resultaat:
* de client is een kopie die uitstekend draait op een andere PC hier op het netwerk.
* Het computer-ding heeft enige dagen terug nog 24 uur lang memtest86 gedraaid, en hiervoor ruim 2 jaat SETI en Probleemloos.

Tenzij iemand nog een geniaal idee heeft, gooi ik de handdoek in de ring.

Heb je die work unit al weg gegooid en een nieuwe gehaald. Je MOET dan wel de work dir en de queue.dat weggooien. Dan zou die een nieuwe WU op moeten halen. Let er dan even op dat het een andere is dan degene die je nu aan het doen was.