F@H Team "hardware.no" (lagnr: 37651)

[Theo343]

Jeg bruker ramdisk for work katalogen, så cpt tar kun 2-3 sekunder selv med bigadv og samme på slutten av WUen. Men dette er et generelt råd jeg kom frem til tidligere for å unngå korrupt WU/Cpt filer. Dere vil kunne se at jeg beskriver et slikt scenario i detalj litt tidligere i tråden hvor jeg selv opplevde dette. Jeg bruker i tillegg en sterk UPS som gjør at jeg ikke har problemer med strømleverandører eller sikringer, den sørger også for at jeg har Internett og all komunikasjon oppe når strømmen går i nabolaget.

 

LinuxFah bruker XFS.

 

I tillegg for å sikre en bigadv WU bør man ta en filbackup av workområdet ca. 1 gang i timen eller lengre intervaller som man selv føler for. Om CPT kjører for ofte og tar lang tid som det gjør på SATA HDD med bigadv WU så øker risikoen for at du også kjører backup midt i en cpt skriving som gjør backupen korrupt.

 

Xell:

Lang skrivetid på slutten av WUen er ikke bare for de med Ext4. Problemene med Ext4 er godt kjent blant linuxfolderne og går ikke innunder årsaken til at jeg ga dette rådet.

 

Ei57:

Jeg bruker Killall fah6 for en litt penere shutdown av prosessene. Og et generelt råd til mange kan være å skrive "top" for å se om den jobber eller ei og avsluttes.

 

Kill -9 pid for fah6 er dog nødvendig om den ikke vil avslutte. Jeg har også opplevd å måtte kjøre kill -9 pid for hver fahcore_a2.exe i noen tilfeller. (selv om jeg ventet i opptil 20min fordi det er kjent at dette kan ta tid)

Endret 23. januar 2010 av Theo343

[-alias-]

Hvis ikke så er jo dette imaget bare en linux med alt av folding allerede installert så det burde ikke være noe problem å oppdatere klienten på samme måte som man oppdaterer i linux

Det er et image med folding ferdig installert ja. Har ferdig bigadv til i natt ca. 01.30 så jeg tror jeg venter til i morgen hvis jeg ikke er våken når det skjer. Har ikke lyst til å eksperimentere nå og kaste bort 84% av jobben. Trenger jeg mer hjelp så kommer jeg heller tilbake i morgen en gang, takker så langt.

[Xell]

Jeg skjønner at det er surt å miste WU når man har jobbet lenge med en, men hvor ofte skjer det. Hvis det sjer pga shutdown under skriving av checkpoint (hvis jeg forstår ei57 rett) og denne skrivingen tar få sekunder hvert 15. minutt så vil man ha under 3% sannsynlighet for at en shutdown skjer under skriving (3% tillater 27sek skrivetid). Hvor ofte har dere ukontrollerte shudowns? Eller er det noe vitalt her som har gått meg totalt forbi?

[Theo343]

Den tar ikke få sekunder på en bigadv på en sata hdd. Men for all del, la den stå på 15 min med bigadv om man ønsker å øke risikoen

 

Jeg har kun hatt 1 tilfelle av ukontrollert shutdown på bigadv og i det tilfellet ble CPT korrupt og i tillegg viste det seg at alle timesbackuper hadde korrupte CPTer pga for ofte kjøring (15min) som brukte tid og gikk i konflikt med backup. Den WUen var på 93% ferdigstilt. Ganske surt bare fordi jeg ikke hadde stilt opp tiden for CPT til et mer gunstig intervall.

 

Jeg anbefaler 27min på bigadv.

 

De andre tilfellene jeg har hatt hvor bigadv WUer har blitt skrotet har vært fordi det har vært problemer med mottakelsen hos stanford så de til slutt har blitt korrupt av en eller annen buggy årsak i klientet etter mange forsøk og så slettet.

Endret 23. januar 2010 av Theo343

[Xell]

For all del, jeg mener ikke at det er feil å sette opp eller ned eller hva man måtte finne på, jeg prøver bare å fremme min egen forståelse for hva som er hva og hvorfor ting gjøres. Erfaring tilsier at mange "triks" gjøres på feil grunnlag, og siden jeg bruker denne maskina til mye annet som stadig fører til at jeg starter systemet på nytt (kontrollert reboot, ikke strømfeil e.l.) vi en økt checkpoint føre til økt andel av "dobbelt arbeide". I mitt ønske om å ungå dette vil jeg vite så mye som mulig om hvorfor og hvilken risikoendring slike tiltak har.

[Theo343]

Krever linux noe særlig reboot da? Trodde de fleste linux brukere sier at det er forbeholdt windows verdenen.

 

For min del er ikke dette et "triks" eller på feil grunnlag men noe jeg mener Stanford burde ha informert om og kanskje endret på ift. bigadv.

Endret 23. januar 2010 av Theo343

[Xell]

Det kommer ann på hva man holder på med. Generelle oppdateringer påvirker ikke kjernefunksjonaliteten slik som under windows, men gjør man ting som påvirker kjernefunksjonaliteten kreves det like mye reboot som i windows. Eller hvis man driver å tweaker systemet på hardwarenivå. Innimellom er det også enklere å bare gjøre en reboot enn å logge ut å restarte x når det trengs, spesielt når det kombineres med en strekk på beina (tur på do eller finne noe å spise ). Selvsagt har jeg mange dager uten reboot, men så har jeg har enda ferre dager med ukontrollert strømstans. Kan faktsik ikke huske sist jeg hadde det.

 

Når jeg først får en dag som jeg sitter og leker meg så kommer antallet fort oppi 10-20. 15 reboot med 27 min mellom checkpoint er gjennomsnittlig 20*27/2= 3 timer og 22min med arbeide som må gjøres om igjenn. Så kan du kanskje argmentere med at det blir mye med halvparten (15min) også, men når checkpoint skrives hvert 15. minutt så er det i snitt 7,5 minutter til neste checkpoint skal skrives, og man kan ta et besvist valg på å vente med å reboote til rett etter at chekcpoint er skrevet. Hvis jeg skal øke denne ventetiden vil jeg vite hvorfor og om det strengt talt er nødvedig i min situasjon. Mer enn det ligger det ikke bak disse uendelige spørsmålene mine

 

Jeg er helt åpen for at det kan være lurt å øke denne checkpoint-tiden, men da må det ligge noe mer bak enn risiko for korrupte filer ved ukontrollert shutdown. Feks hvis det er mange andre faktorer som fører til at disse filene blir korrupte, eller at så hyppig skriving gir enormt mye mer overhead på bigadv en på normale smp.

 

 

--

Jeg er ikke en PC-bruker, jeg er en PC-fikler

 

 

Snakker om sola (eller djevelen som det heter på engelsk, passer bedre nå), jeg la inn nvidia-driveren og nå går PCen helt i spinn.

Endret 23. januar 2010 av Xell

[Theo343]

Hehe forstår hva du mener Xell. Men med så mye avansert fikling vet jeg ikke om jeg ville kjørt bigadv på den maskinen

 

Jeg har ikke hatt noen ukontrollerte strømstans, har hatt to-tre kræsj hvor to var forårsaket av Nvidia driver og en hvor VMen plutselig gikk i frø. (for lite minne tildelt)

Endret 23. januar 2010 av Theo343

[Xell]

hehe... jeg vet heller ikke om jeg skal kjøre bigadv eller ikke. Eneste måten å finne ut på er å prøve og se om de når tidsfristen.

 

VM i frø ser jeg på som det samme som en ukontrollert shutdown. Så hvorvidt det skyldes strøm eller systemcrash er vel ett fett. Jeg opplevde systemcrash her nå, men heldigvis er jeg en dreven ubuntu-installerer, så nå er alt oppe og går igjenn. Sånn sett er det mye mer systemcrash med nye oppsett der man fortsatt driver å ekperimenterer. Nå er jeg spendt på om den kommer til å crashe igjenn for jeg la til nvidiadriveren med en gang. Fordelen med å få lagt til nvidia-driveren var at den gira ned vifta på skjermkortet.

 

4 WUer til nå. Venter i spenning og håper ting er stabilt nå.

[knopflerbruce]

Noen som har prøvd å kjøre 6 GPUer på P6T6? Lurer på å bestille noe stæsj...

[Theo343]

Ikke prøvd men vet mange har kjørt 6 gpuer.

Endret 23. januar 2010 av Theo343

[Xell]

hrmf. Nå hadde den heldig vis ikke crashet, men det hadde slått seg av. Eller rettere sagt; systemet har sendt et terminerings-signal til servicen Dette må forskes på.

[Theo343]

VM i frø ser jeg på som det samme som en ukontrollert shutdown.

`

Hvor har jeg sagt at jeg ikke har opplevd ukontrollert shutdown/kræsj?

Endret 23. januar 2010 av Theo343

[Xell]

Hvor har jeg sagt at du ikke har sagt det? heheh

 

Jeg kommenterte det bare fordi jeg, i mine foregående poster, hadde fokusert veldig mye på strømstans/strømfeil, når det jeg egentlig tenker på (som strømstans faller under) er ukontrollerte shutdowns. Om det er strømmen som forsvinner, systemet som henger eller en VM som går i frø, det faller i samme katergori.

 

Nå har jeg blitt kilt fast i en WU som endten stopper på en ukorrekt sigterm eller dør med en corestatus=ff. Problemet er at hvis den blir stoppet (skjer på 3% begge deler) så starter den opp igjenn på forrige checkpoint og stopper på nytt på 3%, mens hvis den dør får je gbare tilsent ny WU. qfix påstår at det ikke er noe galt i queue.dat og -send all går bare rett ut av programmet igjenn. Nå gjør je gett forsøk på å kjøre programmet manuelt i stede for serviceså får vi se hva som skjer.

[-alias-]

Noen som har prøvd å kjøre 6 GPUer på P6T6? Lurer på å bestille noe stæsj...

Har kjørt 8 på MSI K9A2 (et billigkort) i 6 måneder uten spesielle problemer, så 6 GPU på P6T6 burde gå. Eneste problemet var å få nok strøm, noe som ble løst ved å benytte 2 stk. PSU i samme rigg. Så ikke undervurder hvor mye strøm du trenger og all varmen du må lede bort. Jeg måtte gi opp 8 X GPU-riggen da disse nye WUene (548p) kom på grunn av varmen som oversteg hva kortene tålte. Jeg kjører ennå med de samme kortene, men nå fordelt med 4 GPU i hver rigg.

 

Hvilke skjermkort hadde du tenkt å bruke?

[Theo343]

Det fine med P6T6 er at du enten kan velge 6 stk SingleGPU kort eller 3xDualGPU kort. Men her må man tenke total strøm, samt termiske egenskaper per kort osv.

[kjellms]

Det 8800GTSkortet som jeg trodde trøbla var et 8800GS viste det seg. Hadde ett GTS og et GS i denne PCen og i system ble det antydet feil på 8800GTS 512(også i enhetsbehandling og Rivatuner). Så jeg ble passe overrasket da det viste seg at det var 8800GS som trodde det var blitt GTS. Putta det inn i en annen PC og det samme skjer der, vises som 8800GTS 512. Kortet sendes til innleggelse med diagnosen senilitet og "stormannsgalskap".

Endret 24. januar 2010 av kjellms

[Xell]

Kortet har ikke fått noe feil FW-oppgradering på noe tidspunkt, vel?

 

Man pleier jo å si at prosessorer gjør aldri feil, de gjør bare det de har fått beskjed om. Spørsmålet er; hvordan har kortet "blitt" et 8800GTS 512?

Endret 24. januar 2010 av Xell

[Xell]

Til informasjon; hvis man får WUer som feiler ved at det ser ut som om service får et terminerings signal fra systemet (logen sier at programmet ble lukket av bruker, men det er ikke tilfelle), så kan løsningen være å slette FahCore.

 

Siden reinstall i går hadde jeg bare feiling på FahCore_a2-pakker. Den feilet og fikk samme pakke 3 ganger, fikk så en ny pakke som også brukte FahCore_a2 som feilet (alle etter 2-3%). Så fikk den en pakke som lastet ned FahCore_a1. Den feilet ikke. Men neste pakke var en A2 og den feilet også på ca 3%. Så slettet jeg core-program-filene og startet på nytt og nå ser det ut til at den klarer å jobbe videre (enn så lenge). Irriterende for dette slår så til de grader ut på 80%'en som kreves for å få bonus på bigadv. Tror denne skal få rusle på vanlig SMP en god stund til.

Endret 24. januar 2010 av Xell

[HawP]

kill -9 <prosess ID>

kill -2 <prosess ID> vil jeg tro er et bedre valg. Den sender INTerrupt til fah6, samme som om den skulle kjørt i forgrunnen og en trykket ctrl+c.

-9 etterlater vel alle core'ene som "døde" prosesser, i og med at fah6 da bare blir brutalt avsluttet...

 

killall alternativet blir: killall -s2 fah6