Gå til innhold

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

Arve1234567890

Anbefalte innlegg

Videoannonse

Videoannonse
Annonse
Rayline TWB

Rayline TWB

Skrevet
Skrevet (endret)

Aner ikke. Hvor finner jeg ut det - i loggen kanskje?

 

Dette er det som står i logfile:

 

[10:35:39] - Ask before connecting: No

[10:35:39] - User name: Rayline_TWB_1 (Team 37651)

[10:35:39] - User ID: 6DE75C77E005F1B

[10:35:39] - Machine ID: 2

[10:35:39]

[10:35:39] Gpu type=2 species=30.

[10:35:39] Loaded queue successfully.

[10:35:39] Initialization complete

[10:35:39]

[10:35:39] + Processing work unit

[10:35:39] Core required: FahCore_15.exe

[10:35:39] Core found.

[10:35:39] Working on queue slot 07 [October 14 10:35:39 UTC]

[10:35:39] + Working ...

[10:35:40]

[10:35:40] *------------------------------*

[10:35:40] Folding@Home GPU Core -- Beta

[10:35:40] Version 2.09 (Thu May 20 11:51:02 PDT 2010)

[10:35:40]

[10:35:40] Compiler : Microsoft ® 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86

[10:35:40] Build host: amoeba

[10:35:40] Board Type: Nvidia

[10:35:40] Core :

[10:35:40] Preparing to commence simulation

[10:35:41] - Looking at optimizations...

[10:35:41] - Files status OK

[10:35:41] sizeof(CORE_PACKET_HDR) = 512 file=<>

[10:35:41] - Expanded 45021 -> 171683 (decompressed 381.3 percent)

[10:35:41] Called DecompressByteArray: compressed_data_size=45021 data_size=171683, decompressed_data_size=171683 diff=0

[10:35:41] - Digital signature verified

[10:35:41]

[10:35:41] Project: 11165 (Run 4, Clone 16, Gen 7)

[10:35:41]

[10:35:41] Assembly optimizations on if available.

[10:35:41] Entering M.D.

[10:35:47] Will resume from checkpoint file work/wudata_07.ckp

[10:35:47] Tpr hash work/wudata_07.tpr: 469083794 2491314733 1717857175 1055332937 406990280

[10:35:47] Working on ALZHEIMERS DISEASE AMYLOID

[10:35:47] Client config found, loading data.

[10:35:47] Starting GUI Server

[10:35:49] Resuming from checkpoint

[10:35:49] fcCheckPointResume: retreived and current tpr file hash:

[10:35:49] 0 469083794 469083794

[10:35:49] 1 2491314733 2491314733

[10:35:49] 2 1717857175 1717857175

[10:35:49] 3 1055332937 1055332937

[10:35:49] 4 406990280 406990280

[10:35:49] fcCheckPointResume: file hashes same.

[10:35:49] fcCheckPointResume: state restored.

[10:35:49] fcCheckPointResume: name work/wudata_07.log Verified work/wudata_07.log

[10:35:49] fcCheckPointResume: name work/wudata_07.trr Verified work/wudata_07.trr

[10:35:49] fcCheckPointResume: name work/wudata_07.xtc Verified work/wudata_07.xtc

[10:35:49] fcCheckPointResume: name work/wudata_07.edr Verified work/wudata_07.edr

[10:35:49] fcCheckPointResume: state restored 2

[10:35:49] Resumed from checkpoint

[10:35:49] Completed 72%

[10:40:43] Completed 73%

[10:44:35] Completed 74%

[10:48:23] Completed 75%

[10:52:11] Completed 76%

[10:55:59] Completed 77%

[10:59:47] Completed 78%

[11:03:34] Completed 79%

[11:07:21] Completed 80%

[11:11:09] Completed 81%

[11:14:57] Completed 82%

[11:18:45] Completed 83%

[11:22:32] Completed 84%

[11:26:20] Completed 85%

[11:30:07] Completed 86%

[11:33:55] Completed 87%

[11:37:43] Completed 88%

[11:41:30] Completed 89%

[11:45:18] Completed 90%

[11:49:06] Completed 91%

[11:52:53] Completed 92%

[11:56:41] Completed 93%

[12:00:28] Completed 94%

[12:04:18] Completed 95%

[12:08:06] Completed 96%

[12:11:54] Completed 97%

[12:15:41] Completed 98%

[12:19:29] Completed 99%

[12:23:16] Completed 100%

[12:23:16] Finished fah_main

[12:23:16]

[12:23:16] Successful run

[12:23:16] DynamicWrapper: Finished Work Unit: sleep=10000

[12:23:26] Reserved 2445008 bytes for xtc file; Cosm status=0

[12:23:26] Allocated 2445008 bytes for xtc file

[12:23:26] - Reading up to 2445008 from "work/wudata_07.xtc": Read 2445008

[12:23:26] Read 2445008 bytes from xtc file; available packet space=783985456

[12:23:26] xtc file hash check passed.

[12:23:26] Reserved 76080 76080 783985456 bytes for arc file=<work/wudata_07.trr> Cosm status=0

[12:23:26] Allocated 76080 bytes for arc file

[12:23:26] - Reading up to 76080 from "work/wudata_07.trr": Read 76080

[12:23:26] Read 76080 bytes from arc file; available packet space=783909376

[12:23:26] trr file hash check passed.

[12:23:26] Allocated 544 bytes for edr file

[12:23:26] Read bedfile

[12:23:26] edr file hash check passed.

[12:23:26] Allocated 120841 bytes for logfile

[12:23:26] Read logfile

[12:23:26] GuardedRun: success in DynamicWrapper

[12:23:26] GuardedRun: done

[12:23:26] Run: GuardedRun completed.

[12:23:31] + Opened results file

[12:23:31] - Writing 2642985 bytes of core data to disk...

[12:23:32] Done: 2642473 -> 2486993 (compressed to 94.1 percent)

[12:23:32] ... Done.

[12:23:32] DeleteFrameFiles: successfully deleted file=work/wudata_07.ckp

[12:23:32] Shutting down core

[12:23:32]

[12:23:32] Folding@home Core Shutdown: FINISHED_UNIT

[12:23:35] CoreStatus = 64 (100)

[12:23:35] Sending work to server

[12:23:35] Project: 11165 (Run 4, Clone 16, Gen 7)

[12:23:35] - Read packet limit of 540015616... Set to 524286976.

Endret av Rayline TWB
Lenke til kommentar
-alias-

-alias-

Skrevet
Skrevet (endret)

Merkelig tidsbruk i denne loggen, hva kan ha forårsaket måten loggen er skrevet på?

 

 

 

[17:20:04] Completed 250000 out of 250000 steps (100%)

[17:20:18] DynamicWrapper: Finished Work Unit: sleep=10000

[17:20:28] Finished Work Unit:

[17:20:28] - Reading up to 52629024 from "work/wudata_07.trr": Read 52629024 [17:20:29] trr file hash check passed.

[17:20:29] - Reading up to 46985500 from "work/wudata_07.xtc": Read 46985500 [17:20:29] xtc file hash check passed.

[17:20:29] edr file hash check passed.

[17:20:29] logfile size: 295630

[17:20:29] Leaving Run

[17:20:32] - Writing 100078098 bytes of core data to disk...

[17:20:34] ... Done.

[17:20:45] - Shutting down core

[17:20:45] Folding@home Core Shutdown: FINISHED_UNIT

[17:20:48] CoreStatus = 64 (100)

[17:20:48] Sending work to server

[17:20:48] Project: 2684 (Run 0, Clone 11, Gen 29)

[17:20:48] + Attempting to send results [October 16 17:20:48 UTC]

[18:09:40] + Results successfully sent

[18:09:40] Thank you for your contribution to Folding@Home.

[18:09:40] + Number of Units Completed: 86

[18:09:47] - Preparing to get new work unit...

[18:09:47] Cleaning up work directory

[18:09:48] + Attempting to get work packet

[18:09:48] Passkey found

[18:09:48] - Connecting to assignment server

[18:09:50] - Successful: assigned to (171.64.65.54).

[18:09:50] + News From Folding@Home: Welcome to Folding@Home

[18:09:50] Loaded queue successfully.

[18:09:59] + Closed connections

[18:09:59] + Processing work unit

[18:09:59] Core required: FahCore_a3.exe

[18:09:59] Core found.

[18:09:59] Working on queue slot 08 [October 16 18:09:59 UTC]

[18:09:59] + Working ...

[18:09:59] *------------------------------*

[18:09:59] Folding@Home Gromacs SMP Core

[18:09:59] Version 2.22 (Mar 12, 2010)

[18:09:59] Preparing to commence simulation

[18:09:59] - Looking at optimizations...

[18:09:59] - Created dyn

[18:09:59] - Files status OK

[18:10:00] - Expanded 1765394 -> 2254597 (decompressed 127.7 percent) [18:10:00] Called DecompressByteArray: compressed_data_size=1765394 data_size=2254597, decompressed_data_size=2254597 diff=0

[18:10:00] - Digital signature verified

[18:10:00] Project: 6061 (Run 1, Clone 10, Gen 46)

[18:10:00] Assembly optimizations on if available.

[18:10:00] Entering M.D.

[18:10:06] Completed 0 out of 500000 steps (0%)

[18:13:38] Completed 5000 out of 500000 steps (1%)

 

 

 

Det tar altså ca. 50 minutter fra P2684 er ferdig, fra resultatet er sendt og til start av P6061. Dette er helt unormal lang tid, det normale er 8 - 9 minutter. Hva kan ha skjedd her?

Endret av -alias-
Lenke til kommentar
Theo343

Theo343

Skrevet
Skrevet (endret)

Det blir godsaker Knopfler :)

 

Ang. dette med mangel på Bigadv WUer så viser det seg at ganske så mange foldere har kjøpt AMD 1055, 1095T hexacore CPUer og forsøker å bruke dem til BigAdv. folding. Siden den kun har 6 kjerner (uten HT) og yter dårligere enn Intel Ci7 4C/8T. så har ikke SF tillatt at disse folder BigAdv.

 

Men dette har mange av disse gitt en lang marsj i og benyttker workarounds som sneakernetting, modifisering av klienten osv. for å få BigAdv til disse alikevel. Det foregår omtrentlig storstilt "juksing" på dette og det har pågått et par måneders tid.

 

Det kan derfor være at SF har begynt å gjøre om prioriteringer på hvem som får BigAdv WUer tildelt og ikke. "7im" på foldingforum.org hinter litt om det.

Det ene var at det ble en god del fler BigAdv maskiner aktive når de slapp klienten for native Windows men det ser ut til at dette med AMD hexacore juks har skapt en del hodebry for SF.

 

I tillegg sies det at man ikke bør kjøre BigAdv med mindre man klarer en Ci7 24/7 stabil klokk på 4GHz (hvor 3.8GHz er det absolutte minimum og omtrent ikke ønskelig) dette fordi SF har en helt anne prioritet med BigAdv enn andre prosjekter, og det er at de skal leveres så fort som overhodet mulig.

 

Ergo jo flere det er med dårlig margin jo større sjangs for at vi mister muligheten til å folde BigAdv på 4C/8T Ci7ene våre. Så ser dere noen som snakker om at de folder BigAdv med AMD Hexacore så vet du hvem som "stjeler" WUene dine ;)

 

 

Utdrag fra 7im og dette med at PD på BigAdv.

There are 2 differences between -bidadv and all other work units. 1. The points are much higher, because the work is expected to be turned in VERY quickly. 2. There is an 8 core minimum entry to the -bidadv bonus program. And #2 assures that #1 is true, regardless of where the pref deadline is set. 8 core systems were assumed to always finish the WUs with days to spare before the pref deadline, not just hours to spare.

 

The pref-deadline is not the line of permission, and certainly not the intention of this bonus program to have WUs turned in just before that deadline. The deadline is a safety net for when WUs get lost or deleted, so they can be reassigned. The deadline was never assumed to be a minimum performance level. And if people are playing the margins that tightly, you best not complain about missing a deadline if there is ever an upload problem. The 8 core minimum also allows for a margin of error so -bigadv can be uploaded, even if the first upload attempt fails. The auto send a few hours later will upload it with time to spare when you have 8 cores.

 

But if that's the way people want to play the game, so be it. rbpeake, your wish might be granted.

 

 

p.s. Also consider if you start missing a few deadlines, you might fall below the 80% completion rate. It could cost you the bonus points on all your systems, not just your x6s.

http://foldingforum.org/viewtopic.php?f=55&t=15882&start=15

 

Dette er også grunnen til at jeg ikke kjører BigAdv for tiden så lenge maskinen ikke kan kjøre dedikert for hver WU jeg henter. Mulig kommer jeg til å gjøre det slik at jeg kjører en BigAdv. innimellom når jeg skal bort i helger, ferier osv. eller kan klare meg med laptopen noen dager.

Endret av Theo343
Lenke til kommentar
Theo343

Theo343

Skrevet
Skrevet (endret)

Kunne faktisk spille Civ5 mens jeg folder både på GPU3 og SMP2 (-smp 7). Turnskifte i Civ5 tar ca. dobbelt så lang tid men ellers flyter spillet helt fint og PPD blir halvert på begge klienter. Ikke ille, og jeg får jo faktisk produsert mens jeg spiller.

 

post-38451-1287271483,9139_thumb.png

 

Spilt et par timers tid nå i type "end game" med mye som skjer og PPD har holdt seg stabil på nivået over.

Endret av Theo343
Lenke til kommentar
Taxman

Taxman

Skrevet
Skrevet

Kunne faktisk spille Civ5 mens jeg folder både på GPU3 og SMP2 (-smp 7). Turnskifte i Civ5 tar ca. dobbelt så lang tid men ellers flyter spillet helt fint og PPD blir halvert på begge klienter. Ikke ille, og jeg får jo faktisk produsert mens jeg spiller.

 

post-38451-1287271483,9139_thumb.png

 

Spilt et par timers tid nå i type "end game" med mye som skjer og PPD har holdt seg stabil på nivået over.

 

Det hadde jeg garantert ikke orket - turnskiftet i civ 5 er langt nok som det er, selv med kraftig i7 tar det jo en halv evighet når en har kommet "litt ut i spillet". Er jo nesten ikke verdt å spille dersom tiden hadde blitt doblet.

 

Mern du folder i det minste - må innrømme at jeg ikke har foldet på denne siden av sommerferien :-(

Lenke til kommentar
Theo343

Theo343

Skrevet
Skrevet (endret)

Enig i den Taxman, derfor tunet jeg litt :p

 

Leste meg opp på temaet og det viser seg at Civ5 er en veldig dårlig flertrådet applikasjon (ingen stor overaskelse vel). All AI går i kun en tråd mens andre tråder tar helt andre oppgaver. Utfra tester og gjennomganger er det klokkehastighet som har mest å si (min kjører på 4GHZ) og det er maksimalt 4 kjerner spillet klarer å utnytte. Men på 4 kjerner bruker den kun 50% maks av hver kjerne som gjør at man faktisk klarer seg fint med en dualcore på høy frekvens i dette spillet.

 

Men utfra dette satt jeg -smp 4 mens GPU folder for full guff og konfigurerte Civ5 til å bruke maks 4 tråder. Da får jeg samme hastighet på turns i Civ5 som om jeg ikke foldet og får kun redusert hastighet på SMP men ikke i særlig grad på GPU.

post-38451-1287327178,829_thumb.png

Stor forbedring både i PPD og i Civ5 samtidig.

Et lite tilleggstriks er å sette spillet i "strategic view" før man skifter turn. Da shaver man av ca. 25% per turntid der også. Og spiller man så mye som mulig i "strategic view" så klarer også GPU å folde omtrent med full PPD.

 

Gotta love it.

 

Knopfler:

Fader så du folder da :D Du paserer meg som om jeg stod stille om en dag og sparker heftig i konkuranse instinktet mitt her. Men jeg skal stå i mot så godt jeg overhodet kan.

Endret av Theo343
Lenke til kommentar
knopflerbruce

knopflerbruce

Skrevet
Skrevet

Enig i den Taxman, derfor tunet jeg litt :p

 

Leste meg opp på temaet og det viser seg at Civ5 er en veldig dårlig flertrådet applikasjon (ingen stor overaskelse vel). All AI går i kun en tråd mens andre tråder tar helt andre oppgaver. Utfra tester og gjennomganger er det klokkehastighet som har mest å si (min kjører på 4GHZ) og det er maksimalt 4 kjerner spillet klarer å utnytte. Men på 4 kjerner bruker den kun 50% maks av hver kjerne som gjør at man faktisk klarer seg fint med en dualcore på høy frekvens i dette spillet.

 

Men utfra dette satt jeg -smp 4 mens GPU folder for full guff og konfigurerte Civ5 til å bruke maks 4 tråder. Da får jeg samme hastighet på turns i Civ5 som om jeg ikke foldet og får kun redusert hastighet på SMP men ikke i særlig grad på GPU.

post-38451-1287327178,829_thumb.png

Stor forbedring både i PPD og i Civ5 samtidig.

Et lite tilleggstriks er å sette spillet i "strategic view" før man skifter turn. Da shaver man av ca. 25% per turntid der også. Og spiller man så mye som mulig i "strategic view" så klarer også GPU å folde omtrent med full PPD.

 

Gotta love it.

 

Knopfler:

Fader så du folder da :D Du paserer meg som om jeg stod stille om en dag og sparker heftig i konkuranse instinktet mitt her. Men jeg skal stå i mot så godt jeg overhodet kan.

 

Jeg har litt redusert PPD i dag fordi ene GTX275 COOP-kortet døde, så riggen hadde frosset, og ved reboot var det artifacts all over the place... satte i et 9800GTX, så har vel mistet en GTX275-GPU totalt sett.

 

Blir CPU-folding på mandag, da... går vel ytterligere ned inntil jeg får big og bonus.

Lenke til kommentar
knopflerbruce

knopflerbruce

Skrevet
Skrevet

Blir RMA på den GTX275 vel? Var det noe spes temp eller annet du merket deg på den? Jeg kommer ikke til å forsøke å ta deg igjen uanset, forsøker å være disiplinert ift. hvor mye jeg skal delta.

 

Blir vel RMA på begge COOP-korta, ja. Tar de med til Tyskland i januar :) Spent på hva de gir i retur, håper på GTX460 1GB SLI :p

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste

  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...