[BOINC] maximaal sparen

[grass460]

weet iemand hoe je het beste maximaal kan sparen bij Seti
ik weet dat je de buffer max op 10 dagen kan zetten
Maar het verbinden in x zoveel dagen heeft dat nog invloed op het aantal WU wat je dan krijgt?

[Xaverius]

Misschien dat het handiger is om dit BOINC-wijd te vragen in plaats van alleen SETI. Dit is volgens mij gewoon een BOINC-kwestie.

Heb je al in de DPC-WIKI gekeken?
Overigens kijkt de server volgens mij ook in je korte geschiedenis hoeveel werk je verricht hebt. Aan de hand daarvan zou je meer kunnen krijgen als werkbuffer.

Als je je netwerk opschort maakt de BOINC-manager geen contact dus worden er tussentijds geen WU's verstuurd. Maar dit had vast ook in het SETI-DPCH beantwoord kunnen worden?

[ Voor 47% gewijzigd door Xaverius op 16-11-2009 00:18 ]

[grass460]

klopt
maar wat ik wil bereiken is dat ik ruim meer dan 10 dagen werk krijg.
zodat ik niet tussentijds hoef te connecten en dus zo lang mogelijk kan sparen, id de trend van 10 a 15 dagen.
Dat had ik zelf dus in gedachten.

[KuuKe]

De titel verandert van Seti naar BOINC omdat de manier van sparen niet afhankelijk is van het project maar van de BOINC-client.

Volgens mij gaat sparen heel simpel: zowel in de voorkeuren van de client als de voorkeuren van het project verhoog je het aantal dagen dat je werk wilt hebben. De client haalt werk op maar zal ook kijken naar wat je aan kan. Ik heb dit bij een aantal rojecten al gedaan en ik krijg nooit meer werk dan ik in een bepaalde periode aan kan. Onder normale omstandigheden ga je dus geen werk versturen dat over datum heen is. Daarnaast zijn er projecten (Milkyway@Home) gaf me bijvoorbeeld maar voor maximaal 2 dagen werk) waar je gelimiteerd bent in de hoeveelheid werk die je krijgt.

[grass460]

Dat is mij allemaal bekend
Ik vraag dit specifiek omdat het bij seti op dit moment een verval datum heeft van tussen 2 en 4 januari

Dus zou ik theoretisch ook zolang kunnen sparen, wat nu niet mogelijk is in de huidige instellingen.

[Verwijderd]

Sommige projecten verlangen dat de resultaten binnen zijn in 2 dagen, SZTAKI bijvoorbeeld.
Rapporteer je later dan krijg je geen credit en de te laat gerapporteerde wu's worden opnieuw uitgedeelt.
Dan heeft het uiteraard geen zin om voor een langere periode werk op te halen maar goed dat zal wel duidelijk zijn.
Andere projecten zijn uitermate spaarzaam in het geven van wu's zoals Colatz, de spare GPU wu's die ik heb zijn er nooit meer dan 2.
Wat me opviel van de BOINC client is dat deze zo af en toe een benchmark uitvoerd van het systeem.
Waarschijnlijk wordt aan de hand van deze benchmark en project rules (server sided) een afweging gemaakt hoeveel wu's je krijgt.
Welnu wellicht een mogelijkheid om de zaak een beetje te flessen (hoop dat dit niet als cheating wordt gezien indien zo graag een reactie), deze benchmark resultaten worden opgeslagen in een document:
\Documents and Settings\All Users.WINXP\Application Data\BOINC\client_state.xml
Voor een ander OS dan XP zal het een beetje anders heten.
Probeer eens met de tags <p_fpops>...</p_fpops> en <p_iops>...</p_iops> te spelen en opnieuw te verbinden met de server om te kijken of je meer wu's kan binnenhalen.

Edit: Doet me denken aan die ene aflevering van "Married with Children" waarin Al een privé toilet bouwt. Eind van de aflevering trekt hij door, de kijker ziet een plaatje van een grote fontein die stopt met water spuiten en Al zegt:"That's a man's flush"

[ Voor 10% gewijzigd door Verwijderd op 16-11-2009 11:13 ]

[APClll]

Je kunt wat handmatig in de client_state.xml zitten rommelen, waardoor je aangeeft dat Boinc je computer 24uur per dag benut, voor 100%.

Hierdoor vraag je meer werk aan dat eigenlijk nodig zou zijn. Risico is dan wel dat je 't nooit voor de deadline op kunt maken.

Bij onderstaande quotes ging het over Boinc 4.5, sinds versie 6 zijn een aantal bestandslocaties wat gewijzigd. Uit mijn hoofd staat het tegenwoordig in de boinc-data map

Zie deze post voor de volledige beschrijving: APClll in "BOINC client vragen/antwoorden"

1.stop de boinc-client(s) (bij mij zijn dat er nogal wat )
2.wijzig/verhoog <work_buf_min_days>xx</work_buf_min_days> in het bestand global_prefs.xml. Houdt daarbij rekening max. houdbaarheid van een WU bij SETI.
3.start de boinc-client(s) en laat ze hun workbuffer aanvullen (ik heb ze een dag de tijd gegeven).
4.stop de boinc-client(s) en wijzig <user_network_request>1</user_network_request> in client_state.xml in de waarde 3, zodat het netwerk op disabled staat en er dus geen uploads/updates plaats kunnen vinden.
5.start de boinc-client(s) en laat ze xx dagen met rust.
6.stop de boinc-client(s) op de dag voor flushday zo vroeg mogelijk en maak de wijzigingen uit stap 2 & 4 weer ongedaan .(ik heb 03:00 GMT+1aangehouden i.v.m. de universal-time waarop berkely/SETI werkt).
7.start de boinc-client(s) en geniet van een snelstijgend dagtotaal.

(...)Zo veel mogelijk handmatig WU's binnenhalen, en versturen. Doel hiervan is je gemiddelde zo snel mogelijk omhoog krikken.
(...)
http://setiathome.berkele...hread.php?id=30777#305236
You could try to manually adjust that value in the client_state.xml file, located in \program files\boinc.

If you want to take the risk of messing with the boinc system files and maybe messing something up, here's the steps to take:

- shut down BOINC. (alltogether, check your task manager to be sure)
- backup your BOINC folder
- edit the client_state.xml file, located in your BOINC folder
- look for the line <active_frac>0.046481</active_frac> (your value could be different)
- change this value in something higher like 0.746481 (make sure to keep below 1, and use same number of digits)
- save the changes
- restart BOINC
(...)
Nog even ter aanvulling: in de client_state.xml file staat inderdaad de key <active_frac>, deze stond alleen bij mij al op 0,99973, maar vlak daarboven staat de key <on_frac> en deze stond op 0,252969 waarvan ik nu 0,992969 gemaakt heb en na het opnieuw opstarten van mijn Boinc client werden er meteen een kleine 15 nieuwe job opgehaald

[ Voor 3% gewijzigd door APClll op 16-11-2009 12:25 ]

[grass460]

hmm ik ben niet z'n voorstander van het teveel rommelen in die xml files. Te veel gezeik mee gehad in het verleden.
ik heb wel deze aangepast Global_prefs.xml waar je oa iets met connection time kan spelen
daarnaast heb ik de buffer op 10 dagen gezet en connect every 30 dagen

Nu heb ik dus een slordige 2960 taken in de pipeline staan. is wel incl de pending WU

quote: http://wiki.dutchpowercow...php/BOINC_Faq#Megaflushen

Handmatig wijzigen aantal voorraaddagen

Per computer is het mogelijk om handmatig het aantal dagen voorraad te wijzigen. BOINC accepteert maximaal 15 dagen bij SETI.
Na het uitvoeren van de aanpassing is het niet noodzakelijk is om op 'bijwerken' te klikken.

Voer de volgende handelingen uit voor het wijzigen van de dagen:

* Sluit BOINC en de BOINC-manager (Controleer voor de zekerheid alle actieve processen)
* Maak een backup van de BOINC-map
* Open het bestand global_prefs.xml. Dit bestand bevindt in de BOINC installatiefolder (standaard \program files\boinc, op Mac /Library/Application Support/BOINC Data)
* Wijzig/verhoog (work_buf_min_days)xx(/work_buf_min_days).
* Bewaar de wijzigingen
* Start BOINC opnieuw op

[ Voor 52% gewijzigd door grass460 op 16-11-2009 12:58 . Reden: quote ]

[soulrider]

wat je ook kan doen is gebruik maken van virtuele clientes:
je maakt een zo leeg mogelijke windows xp installatie in vmware of virtual pc of soortgelijken (of een linux installatie natuurlijk)
je installeert daar ook een boinc-client op
en je laat die ook een voorraad wu's opslagen en verwerken.

Dit is vooral handig voor als je in de Top5-flushstats wilt geraken:

je copieert die virtuele pc zo vaak mogelijk (nadat die client geinstalleerd is, maar voordat ie gestart is en wu's heeft binnengehaalt), je laat elke virtual os om buurt een volledige (10 dagen) voorraad binnenhalen en verwerken en nadat die zijn voorraad wu's verwerkt zijn, zet je die boinc-client in pauze en dan dat os. en dan start je de volgende os en boinc-client met zijn eigen voorraad. (eventueel kunnen deze al parallel draaien: de 'volgende pc' al wu's laten ophalen tijdens de verwerken van de laatste wu's op 'de vorige pc')

Let hierbij wel telkens op het laatste upload moment.
de dag ervoor laat je elke client zijn voorraad vernieuwen en dus alle verwerkte wu's uploaden.
(de dag ervoor zodat je een buffer hebt van 24u om problemen met bv internetconnectie op te vangen)

die virtuele OS'en verwerken de wu's iets trager, maar op die manier hoef je niet elke 10 dagen je voorraad te flushen en kan je gerust even doorsparen tot bijna aan de verval datum.
Ook bij projecten die je slechts voor 2dagen een voorraad laten opvragen, maar een vervaldatum hebben die 2weken later is, lukt dit trucje.

flush je je virtual pc's te laat, is die zijn gehele voorraad verloren. dus hou die tijden goed in het oog.

(voor het project dat je meld, kan je dus voor 10dagen wu's vragen, die pas in januari terug gestuurd moeten worden, en kan je dus met 3 virtuele OS'en en je gewone OS een voorraad van een maand aanleggen. en in januari toch bijna 3 a 4x zoveel flushen indien je dan alle sluisen openzet)

is dit hetgene wat je bedoelt, of wil je echt een buffer van meer dan 10 dagen op 1 boinc-client aanleggen?
(want elke virtuele pc wordt gezien als een andere pc onder je boinc-user)

deze truc is vooral (en eigenlijk _alleen_) handig bij boinc-projecten waarbij de rapporteer (wu-deadline) veel verder ligt dan de maximale dagen dat je wu's default (Zonder gerommel in de xml's) kunt opvragen.
(bv rapporteren pas over een maand, en maar een voorraad mogelijk van 10 dagen)

bij projecten waar je elke wu moet terug gestuurd hebben binnen bv 48 uren is dit dus niet bruikbaar.

[ Voor 10% gewijzigd door soulrider op 03-12-2009 03:49 ]

[grass460]

dat is ook heel leuk natuurlijk.
deze vp os'n kan je die allemaal tegelijk laten draaien?
en zien die dan ook je quad koe ?
Hoeveel vm/vp kan je draaien dan ?

je leest het al niet veel ervaring mee


Wat ik nu gedaan had is de buffer op 10 dagen gezet en de verbindt elke zoveel dagen op 30.
als ik een gok moet doen dan had ik voor ca 20 dagen cpu werk en 9 dagen cuda werk.
Dit was voor SETI

[soulrider]

ik zette er voor mijn boin-projecten 4 of 5 Os'en en liet ze om de buurt werken.
in vmware workstation 6.* kon ik maximaal 2 van de 4 cores toewijzen aan een virtuele machine en had ik dus een paar dualcores extra.
Eerst de native OS (het echte OS op die pc of verder nOS) op 4 cores de volledige voorraad laten verwerken,
in de laatste uren de eerste virtuele-OS (vOS) opgestart en een voorraad laten binnenhalen en parallel laten werken met die andere BOINC-client. beiden gingen dan wat trager dan anders want die vOS pakte natuurlijk 2 cores af en ging die zwaar proberen te belasten, terwijl de boinc op de nOS nog steeds de 4 cores probeerte te gebruiken. (Daarmee niet direct alles tegelijk wu's laten verwerken)

nadat de BOINC op de nOS alles gedaan had, ging die in pauze: geen netwerkverbinding, geen nieuw werk afhalen en "werk onderbreken".
en kreeg de BOINC op de eerst vOS full access tot zijn 2 cores.
je kan dan eventueel ook de 2de vOS al opstarten en mee laten werken
(en via je takenbeheer die virtuele machine op 2 andere cores toewijzen)

door de overhead van het virtueel zijn verlies je wel wat verwerkingskracht en ga je bv ipv 1u per wu er 1u15 over doen, maar alle beetjes helpen om een schone flush-actie te doen eh.

en met die vOS'en kan je dan telkens de vOS die klaar is in pauze zetten of zelfs stopzetten en de volgende starten zodra er weer een voorraad verwerkt is.

start je alle virutele systemen op en laat je die allemaal BOINC doen op zoveel mogelijk cores als je vritualisatie-programma/-tool je toelaat om toe te kennen per virtuele host, dan krijg je het effect dat je met 1 native OS op een quadcore en bv 5 virtuele hosts en 2 cores per virtuele host je werk voor 1x4 + 5x2 = 14 cores op 4 cores draait, en met alle overhead van de virtualisatie enzo heb je dan zekers niet meer de snelheid die je anders had, en dus ook veel minder credits voor je wu's. wat dan de gehele actie teniet doet.
ps: elke BOINC-client op een vOS wordt gezien als een gewone aparte BOINC-client, dus in je lijst van computers krijg je dan plots wel een paar bij. Ze hebben ook elk hun eigen verwerkingstijd en dus eigen credits per verwerkte wu. Dus als je gaat voor de meeste punten in een bepaalde periode (bv geflushed tijdens de maand december) kan je beter gewoon je standaard BOINC-client laten werken. Ga je echter voor de grootste flush op een bepaalde datum. (bv een eindejaars- of nieuwjaarsflush) dan kan je op deze manier zoveel mogelijk verwerkte wu's in voorraad houden.

wederom: die einddatum van de BOINC op je nOS in het oog houden en zodra die datum heel kortbij is, alle sluizen om buurt opzetten, in dezelfe volorde als je ze telkens hebt opgestart. (zet dan ev. bij elke vOS "geen nieuw werk ophalen" aan.. anders heb je direct terug nieuwe voorraden, wat niet altijd wenselijk is )

Dit is toch telkens de manier geweest waarop ik een poging deed naar een top5 positie in de megaflush-stand in de projecten waar ik mee doe.

het is me onbekend of ook cuda lukt met virtual pc en/of de nieuwste vmware (7.0) maar dat laat ik graag aan jou over om dat te testen.

je probeert mss ook best voor beiden voor evenveel dagen te krijgen - of toch zeker zoveel mogelijk voor de client op je gewone OS. want daar is de minste overhead en dus de hoogste snelheid.

Moge de flushes die volgen de moeite waard zijn eh

(ps: niet elk boinc-project vind het leuk dat er plots veel wu's achter blijven tot net voor de einddatum om dan de server te overstelpen met alles, of verdelen de wu's over bv 3 of 4 clients waarbij enkel de eerste 2 die overeenkomen punten krijgen)

(ik zette op mijn quadcore dus telkens 2vOS'en tegelijk actief met 2 cores per vOS en in elke client stond buffer en netwerktoegang op 10dagen en dan in het menu: geen netwerkverkeer toestaan ofzo aanvinken want anders flushde die tussentijds alsnog)

[ Voor 19% gewijzigd door soulrider op 04-12-2009 16:58 ]