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

[Kjetil Lura]

Aktivitetsnivå på eldre medlemmer?? Hallo.. både jeg og -alias er vel blandt de eldste her!

 

Er en kommentar til denne. Men er det alderen på oss her inne du og Malvado tenkte på, eller hvor lenge du/jeg har foldet?

[-alias-]

Hmm.. nå er jeg ikke med.

Se i kolonnen helt til høyre, der står datoen da du passerte første record.

[kjellms]

Åja, nei jeg er ikke så retrospektiv! Jeg tok det bokstavelig utrykket eldre må gå på alder, ikke foldingansiennitet.

 

 

Forresten, nå hadde jeg en irriterende omstart pga oppdateringer også ender det med at det ene av to 8800GTS blir underkjent med at drivere er feil! De har jo virka i måneder på begge, så hvorfor skal oppdateringa og omstarten føre til at de ikke funker. Data er herk!

Endret 22. januar 2010 av kjellms

[-alias-]

Så sant så sant! Jeg sverger til "Never change a running system", derfor oppdaterer jeg ikke før jeg evt. er nødt.

Endret 23. januar 2010 av -alias-

[HawP]

Hvordan ligger Hw.no ann forresten i forhold til nye medlemer, aktivitetsnivå på eldre medlemer etc?

På tide med en ny kampanje?

Med forbehold om litt vel søvnige øyne: en kjapp sjekk nettopp viste at vi (i disse dager) har høyere snitt PPD per aktive enn 7 av top 10 lagene

[HawP]

"Never change a running system"

He he, Windows på autoupdate gir en vel ikke alltid så mange valg...

Endret 23. januar 2010 av HawP

[-alias-]

Bruker ikke autoupdate siden det resetter maskinen uten at jeg vil det! Og tror ikke mange foldere bruker det heller.

Endret 23. januar 2010 av -alias-

[HawP]

Bruker ikke autoupdate siden det resetter maskinen uten at jeg vil det!

Ja, "genialt" laget, ikke sant?

[HawP]

important SMP client updates

 

by kasson » Thu Jan 21, 2010 9:55 pm

We have just posted updates for all our SMP-capable clients except for the OS/X-Installer version. These updates do two things:

1. fix a small but important bug

2. enable the clients for the upcoming release of our first SMP2 cores (threads-based SMP)

 

The new client version is 6.29. Please update your clients at your earliest convenience if you are running SMP, particularly if you are running -bigadv work units.

We anticipate swapping over -bigadv work units to use only the new client in the coming weeks.

 

Client downloads are available at:

http://folding.stanford.edu/English/Download

 

and windows SMP at:

http://folding.stanford.edu/English/DownloadWinOther

http://foldingforum.org/viewtopic.php?f=24...=127026#p127026

[kjellms]

Ja, det var ikke noen autoupdate bare så det er sagt. Sitat:"Forresten, nå hadde jeg en irriterende omstart pga oppdateringer...". At den var irriterende betyr ikke (nødvendigvis) auto. Dere leser litt mer mellom linjene enn nødvendig. Man kjører heller ikke Windows i bånn uten updates. Det 8800GTS kortet har vist svakheter før, så nå er det nok for alvor slutt antar jeg.

[-alias-]

Theo eller andre som vet?

VMware kjører med folding client v6.24R3, men i følge Stanford så skal bigadv over på folding client v6.29 fra neste uke etter det jeg forstår. Kan man oppdatere i VMware selv eller vil det bli lagt ut et nytt VMware Linux Disk Image som er oppdatert. Ser at siste Image er fra 20.01.2010, men det står ingenting om v6.29 der.

 

Edit: Eller vil VMware automatisk oppdatere seg selv med siste clientversjon?

Endret 23. januar 2010 av -alias-

[Xell]

Tror neppe den oppdaterer automatisk, men jeg vet ikke om det er noe script eller liknende i VMware imaget som gjør at man lett kan oppdatere.

 

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: stopp prosessen, last ned ny klient, gjør klienten kjørbar (chmod +x), start klienten, kjekk logen for å se at det er den nye klienten som kjører.

 

I forhold til navn/renaming av programmene for å matche script så aner jeg ikke hva VMware imaget har gjort. I mitt oppsett av Ubuntu har jeg sjekket litt hva jeg må gjøre og kom fram til dette:

 

1. last ned ny klient

wget http://www.stanford.edu/group/pandegroup/f...H6.29-Linux.tgz

Det har jeg allerede gjort og startet klienten med -onunit så den ikke skal begynne på en ny enhet. Når den er ferdig går jeg videre til pt2

 

2. stopp servicen (kun hvis man kjører service)

/etc/init.d/folding stop

 

3. pakk ut klienten

tar xzf FAH6.29-Linux.tgz

 

4. gjør klienten kjørbar

chmod +x fah6

 

5. ta bort -onunit flagget (dette er bare fordi jeg ikke starter programmet på komandolinja, men service, så flaggene ligger i en fah_cofig-fil)

 

6. start service (eventuelt start programme slik du pleier)

/etc/init.d/folding start

 

7. sjekk at det er den nye clienten som starter

cat FAHlog.txt (eller åpne logen i en editor)

 

Hvis ingen ting feiler burde det ikke ta mer enn noen få minutter.

 

For ordens skyld; jeg måtte ha gjort akkurat det samme for å gå over til 6.24R3 for å starte -bigadv, men siden de har kommet med ny klient før jeg rakk å gjøre dette er det bare å starte 6.29 med en gang og bare legge til -bigadv-flagget når jeg er klar til det

Endret 23. januar 2010 av Xell

[Xell]

Hvordan ligger Hw.no ann forresten i forhold til nye medlemer, aktivitetsnivå på eldre medlemer etc?

På tide med en ny kampanje?

Med forbehold om litt vel søvnige øyne: en kjapp sjekk nettopp viste at vi (i disse dager) har høyere snitt PPD per aktive enn 7 av top 10 lagene

 

Men desverre ligger vi godt under snittet når det gjelder andel aktive brukere . Mange middels aktive brukere tar fort igjenn det en ekstrem-folder gjør.

 

Det hadde vært godt med en boost så vi får tilbake noen av de som har gitt seg det siste året.

[ei57]

Nå har jeg oppdatert en Win SMP og en Linux SMP til 6.29.

 

Win er dropp in replacement - stopp klient og bytt ut Fah6.exe (eller hva en måtte ønske å kalle fila).

 

I Linux må en laste ned en tgz-fil - se linken til Xell.

Stopp klienten (det er greit å gjøre det rett etter at checkpoint er skrevet - .ckp og .cpt i work-katalogen) og bytt ut fah6.

Start klienten - den kommer ferdig kjørbar, slik at punkt 4 i guiden til Xell kan sløyfes.

[Xell]

Fin oppdatering ei57. Gjør kjørbar var noe jeg tok med fordi det står i installasjonsbeskrivelsen til PandeGroup.

 

Jeg har opplevd at bytte av klient/overskrivning av installasjonen har ført til at hele køen blir nullstilt ved oppstart, så jeg velger å vente til Wuen er ferdig. Men det er sikert trygt å bytte slik du sier.

[ei57]

Passer en på at en ikke avbryter klienten når den skriver checkpoint, skal det ikke være noe problem. Fo å stoppe klienten, bruke jeg dette:

 

kill -9 <prosess ID>

 

For de som er like bevandret som meg i Linux, finner en den i System Monitor - Processes. Det er fah6 som skal drepes og da fortrinnsvis når den ikke er opptatt med å skrive checkpoint.

 

Ved bytte av klient har jeg også opplevd at avbrutte WU'er har gått i vasken, så jeg var litt spent når jeg startet opp bigadv'en igjen på 40%, men det ser ut til å gå bra. Har iallefall passert 44% uten noe tull. Testet først i Win med en WU som bare hadde gått 3%, og når det gikk bra, tok jeg Linux'en i samme slengen. Litt lenge å vente 30-40 timer og det er greit å få unna mens en husker det.

[Xell]

Jeg klarte selvsagt ikke å dy meg. Testet først på maksinen med Core2duo, den ar på ca 60% på WUen. Siden det gikk bra byttet jeg også på i7'en. Litt risikabelt siden den var på 93% (vente en drøy time?? nææsj ). Men det gikk bra. Tror nok jeg hadde sagt noen stygge ord hvis den hadde gått føyken (7+ timer med arbeide).

 

I morgen blir det kanskje start på -bigadv

[Xell]

EDIT/NB!

Med bigadv bør du i -configonly endre checkpoint fra default 15min til 25-30min. Dette fordi den er ekstremt IO krevende på disse WUene og du bør ikke ha de kjørende så tett.

 

Hvilket filsystem er det på området som filene skrives til? Jeg vet at det har vært store problemer med FaH og ext4, at det tok evigheter å få gjort skrivingene mellom wu-slut og neste wu start, men jeg trodde dette var rettet opp i VM'en slik at denne brukte ext2. Jeg har satt hjemmeområdet på PCen til ext2 nettopp av denne grunnen, men jeg kommer utansett til å sette opp checkpoint-tiden. Ulempem med dette er selvsagt at man mister mye ved avbrudd.

[ei57]

Hos meg tar det 90 sekunder fra 100% til at klienten melder "shutting down core", deretter er det 2 minutter pause som er standard. Sending tar et drøyt kvarter, så går det 5 minutter før antall innsendte kommer opp. Så ryddes gammelt skrot og ny WU lastes ned og er igang etter drøye 2 minutter. Totalt tar hele prosessen i underkant av en halvtime. Alt dette med ext4 og på SSD.

 

Fordelen med lengre tid mellom checkpoints er at faren fo å miste alt halveres. Avbrudd mens checkpoint skrives = havarert WU. Har nå kjørt 30+ av disse uten andre problemer enn strømleverandøren, som tilfeldigvis kom til å kutte strømmen under skriving av checkpoint, uten varsel.

 

Det er også forskjell mellom Win SMP og Linux SMP, ved at førstnevnte både lagerer ved checkpoint og per %. Sistnevnte lagrer kun ved checkpoint, som i praksis vil si at dersom en avbryter ved 10% ferdig, så starter den opp ved siste checkpoint, ikke på 10%.

[Xell]

At det tar så lang tid skyldes forholdet mellom FaH-core og ext4. Måten ting skrives til disk på passer veeeeelsig dårlig med ext4 og xfs.

 

Det er flere tråder om dette på foldingforum. Jeg valgt å bruke ext2, men ser at ext3 også skal gjøre dette bedre, så det blir spennende å se hvilke tider jeg ender opp med på bigadv (spesielt disse store pakkene som gir utslag på tiden). Forhåpentlig vis får de rettet opp dette i koden etter hvert.

 

Godt poeng i forhold til checkpoint. Har ikke tenkt så mye på dette før nå siden "normale" wuer bruker relativt liten tid på checkpoints. For det første må man jo føst være plaget av avbrudd i programmet, så må avbruddet komme på "feil sted" som ved 15 min er en relativ liten andel av total run-tid.