Tapasztalatok a SETI@home futtatásáról BP6-os alaplapon, NT alatt |
|
Üdv!
Kedvelem a SETi@home projektet, áldozok is rá... Alaplapot cseréltem,
beszereztem egy évvel ezelőtt egy BP6-os dual, azaz két processzort tartalmazó alaplapot.
Érdekes tapasztalataim vannak vele kapcsolatban, ezt osztom meg itt a betérőkkel :-)))
Először is a felállásról, amit ugan nem ezen állítottam össze, de itt is használok, hiszen nincs
se kábeltévés, se bérelt vonalas összeköttetésem :-)))
A csomagokat egy általam kiötlött sorban - queue, FIFO, azaz first in, first out - tárolom hogy
a gépnek ne legyen holt ideje, s reggelenként, egy-két naponként küldöm el, frissítem.
Az egész konstrukció egy alkönyvtár struktúrára és egy vezérlő batch-re épül.
Egy alapkönyvtárban benne van a kliens, a batch, a SETILog, a SETIWatch
Van egy furcsa jelenség:
Időnként - 1-2-3 hetente - a gép elszáll, pontosabban furcsán megfagy,
s ekkor az a furcsa helyzet áll elő néha, hogy a SETI kliens - egyik, másik,
mindkettő - azt 'hiszi', hogy kész van.
Ez annyit jelent,
hogy a result_header.sah-ot átnevezi result.sah-ra,
a mérete valamivel nagyobb, mint az eredeti state.sah és az outfile.sah összege,
az elején ott van a teljes result_header.sah, viszont utána van egy halom 0x00,
a bg_pot értékek egy része (a lista vége a state.sah-ból) és megint
egy csomó 0x00...
A work_unit.sah ilyen esetekben mindig eltűnik, de a boot utáni CHKDSK mindig megtalálja,
és csak ezeket találja meg! Sajnos a mérete nem jó,
de sértetlen szokott lenni a tartalom. A letöltés után épp ezért a batch-em mindig elmenti
az új work_unit.sah-ot egy alkönyvtárban, ahonnan visszamásolom.
Az elrontott result_header.sah-t ilyenkor hex editorral visszaállítom, átnevezem,
és az estek nagy részében folytatja, van viszont, amikor elölről kezdi, bármit is csinálok,
kombinálok, ezért gondolom, hogy ilyenkor a key.sah-ot is átírja,
mondván munka vége volt...
Ma hajnalban - 2000 október 25. - ismét sikerült elszállni a BP6-on mindkét
SETI kliensnek, a fene egye meg... Ma nem voltak result
állományok, WU, viszont rossz volt az outfile tartalma...
Hálózatról még elértem a gépet - fura módon nem hal el teljesen -, így lementettem mindkét
taszk SAH-jait. Nem volt WU, nem volt sem result,
sem result_header egyik taszkon sem, az utolsó állományok ideje 0:45 volt
mindkét esetben... S a state taralma:
ncfft=12836
cr=-5.288614e+000
fl=131072
cpu=31706.312500
prog=0.63245469
potfreq=-1
potactivity=0
outfilepos=703
bs_power=177.333878
bs_score=0.646732
bs_bin=120027
ésncfft=9741
cr=-9.963520e-001
fl=131072
cpu=22708.359375
prog=0.49036637
potfreq=-1
potactivity=0
outfilepos=1855
bs_power=184.444443
bs_score=0.663806
...
azaz egyik processz 63%-nál járt már, a másik 49%-nál... Hálózatról visszatettem a WU-t - mert azt, és minden SAH-ot letöltés után egy batch nekem mindig elment -, a result_header-t, s indítottam a processzeket:
p0_F:
Data Info:
Sky coordinates: 17.900 R.A., 27.130 Dec
Recorded on: 2451605.96941 (Thu Mar 02 11:15:57 2000)
Source: Arecibo Radio Observatory
Base Frequency: 1.418906250 GHz
Starting work unit without key.
Found data file: yes. Found result header file: no.
Beginning analysis...
A másik process:p1_A:
Data Info:
Sky coordinates: 5.678 R.A., 9.560 Dec
Recorded on: 2451605.46222 (Wed Mar 01 23:05:36 2000)
Source: Arecibo Radio Observatory
Base Frequency: 1.419062500 GHz
Starting work unit without key.
Found data file: yes. Found result header file: no.
Beginning analysis...
Azaz mindkettő eldobta a már meglévő eredményeket, holott odatettem az eredeti állapotokat!!! Úgy látszik, hogy a key.sah - ami szintén mindig mentve van -, olyan infókat taralmaz, ami kell, hogy korrekten újraindulhasson egy leállított taszk...
Mivel az NT-n processzorhoz lehet rendelni a SETI taszkokat, s nem kell ezt NT-val vezérelni - azt is lehetne -, s talán ezt kezelik rosszul, mert semmi mással nemprodukálja a gép ezt a jelenséget... No az is igaz, hogy mindig megy két SETI kliens, hisz azért is cseréltem ilyen alaplapra :-)))
A megoldás számomra most az lesz, hogy írok egy kis progit, ami X percenként elmenti a változások történetét, hogy elszállás esetén vissza lehessen állni, ne vesszen el az eredmény...
2000 október 25.
|