Stampede; algemeen ideeënvergaartopic

[Xaverius]

Van mij kan dat gewoon in dit draadje. Ik heb weinig tijd om alles even inhoudelijk door te nemen. Maar volgende week lijkt het weer wat beter qua tijd vrij maken.

[Camulos]

@iconized: Je gaat er vanuit dat dit meteen het slechtste in de gemiddelde enthousiaste stampede koe naar boven haalt?! In principe gaat iedereen vol gas vanwege de stampede (ook flushes etc zijn uitgesloten).

Ik haal enkel een issue aan die ik al in twee stampedes heb mogen ervaren/frustreren. Dit komt omdat de overall stand van de vorige dag niet altijd even representatief is, als men die afzet tegen huidige daily-output. De vertraging van 3 dagen is behoorlijk kritiek in de eerste dagen, en mogelijk op de langere termijn niet meer goed te maken. Dat is de reden om liever werving te baseren op huidige overall scores en/of de daily-score van vorige dag.

Enkele alternatieven:
- Laagste 50% van de team, op basis van huidige Overall stats (en niet van de dag ervoor)
- Zolang een team niet laatste staat maar wel in de onderste 50% staat, mag deze niet langer dan 2 dagen werven als haar daily score in de bovenste 50% van de teams staat.
- DPC Crew geeft aan welke teams mogen ronselen (op basis van eigen inzicht)
- Nieuwe leden kunnen alleen in het laagste team joinen (op basis van huidige stats)
- No rules at all! Iedereen mag elk team joinen
- etc

[Verwijderd]

@Camulos: Het leuke is dus juist niet op volledige kracht te starten. Als Overdose Docking zich een klein beetje had ingehouden in het begin, had TDK niet zolang kunnen ronselen.

Even voldoende energie bijelkaar geschraapt om nog wat puntjes van kritiek te noteren. Alvorens ik ze hier toevertrouw wil ik er de crew gaarne op wijzen dat het niet persoonlijk bedoeld is.

Na de malariastampede heeft de crew zelf aangedragen om ook de "geschikte" DC-Vaultprojecten mee te laten dingen als stampedeproject. Dit was een goed plan daar het lijstje van officiële DPC-projecten die nog in aanmerking kwamen voor een stampede nogal karig was geworden. Dit jaar was het eerste jaar dat de Vaultprojecten meedongen.

Nu is het zo dat de doelstelling van de DC-Vault is het promoten van kleinere projecten (sommige commercieel, sommige zelfs niet interessant maar de meeste gelukkig wel) die anders maar weinig rekentijd krijgen. Dit heeft ervoor gezorgd dat de Vault een bonte verzameling is van merkwaardige en eigenaardige projecten. Met andere woorden, een stampede die Vaultprojecten laat meedingen, moet op tijd en goed worden voorbereid.

kritiekpunten:
- Voorbereiding stampede was niet grondig genoeg en te laat.
- Stemmen op het stampedeproject was pas halverwege de maand maart mogelijk, nog later dan in 2011.
- Het contact zoeken naar de projectmanagement van Docking gebeurde veel te laat. Dit had wellicht eigenlijk nog voor het stemmen gemoeten. En bij geen contact had Docking wellicht niet eens mee moeten dingen als stampedeproject. Dat alles toch nog goed gekomen is, lijkt zo achteraf meer geluk dan wijsheid.

Laat ik het hier maar bij houden. Gaarne kunnen we ook de discussie over GPU-projecten afronden. Er liggen nog steeds 2 zinnige voorstellen, of eens per jaar één CPU-project en één GPU-project waarbij voor de laatste geen stampedeteams worden gemaakt. Of zoals ook is voorgesteld, tweemaal per jaar een stampede.

[Blord]

In plaats van zelf de teams te mogen kiezen waarom niet vijf teams maken met als top-5 de lijsttrekkers van de teams maken en rest gewoon random aan toevoegen. Vijf leuke namen verzinnen en gaan met de banaan.
We weten heus wel wie de grootverbruikers zijn en zo de teams goed in balans houden.

Of de top-5 tegen de rest. Dan zullen we zien of "resistance is futile" stand houd.

[ Voor 12% gewijzigd door Blord op 08-05-2012 00:31 ]

[Verwijderd]

Ik denk dat afgelopen stampede leuk genoeg heeft verlopen. De goal was om tweede te worden daar elk team met Vipeax toch eerste zou worden. De strijd gedurende april heeft zich ontvouwd om tweede te worden.

[Verwijderd]

<recalcitrante modus>
Krigen we (weer) de laat-maar-lullen-behandeling? Dit heeft mijn torn eerder gewekt, alhoewel het geen tweede keer zal gebeuren. Maar laten we wel wezen. Een groepje mensen hier claimt autoriteit. Vervolgens spreiden deze mensen ten toon dat ze geen zin hebben in een grondige of goede voorbereiding, of gewoonweg wat werk verzetten. Maar als je geen werk wilt verzetten (of niet kan door drukte), moet je je wellicht niet als vrijwilliger inzetten voor een verenigde niet-vereniging.

De niet-verenigingsstatuur geeft je de vrijheid om je ook niet te hoeven verantwoorden maar derhalve kan één en ander ook uitmonden in een anarchie. Wie heeft er zin in het organiseren van een GPU-stampede in oktober?
</recalcitrante modus>

[Xaverius]

Beste iconized, ik ben inmiddels wel gewend dat je posts kan geven die wat minder netjes kunnen overkomen, die heb ik al een paar keer voorbij zien komen. De stampede wordt zeker met zorgvuldigheid gepland en we proberen, waar dat kan, met iedereen rekening te houden. Ik snap dat geen reactie in dit topic vanuit onze kant uit niet zo netjes is geweest maar onze posts zijn in ieder geval netjes.

Mijn excuses dat er tot nu toe geen reactie is geweest in dit topic, eerlijk gezegd was het even bij mij uit de scope verdwenen door inderdaad een wat grote persoonlijke tijdsbelasting. Ik zal dit binnen de crew eens een schopje geven.
<edit>schop gegeven </edit>

[Bubbles]

[recalcitrante modus]DPC zou eerder een stichting dan een vereniging worden, denk ik zo.[/]

Dat gezegd hebbende... Je hebt een aantal kritiekpunten waar ik even wat op in wil gaan.

- Voorbereiding stampede was niet grondig genoeg en te laat.

Zou je misschien kunnen toelichten wat er niet grondig genoeg aan was? Aan die informatie zouden we namelijk veel kunnen hebben. En wanneer zou jij die voorbereiding hebben gedaan?

- Stemmen op het stampedeproject was pas halverwege de maand maart mogelijk, nog later dan in 2011.

[Stampede 11] planning OP op 8 maart. Beetje overdreven dus. 2 dagen later dan vorig jaar. Toegegeven, het had ook iets eerder mogen zijn, zeg, een weekje.

- Het contact zoeken naar de projectmanagement van Docking gebeurde veel te laat. Dit had wellicht eigenlijk nog voor het stemmen gemoeten. En bij geen contact had Docking wellicht niet eens mee moeten dingen als stampedeproject. Dat alles toch nog goed gekomen is, lijkt zo achteraf meer geluk dan wijsheid.

Over optijd voorbereiding gesproken:
Bubbles in "DC Vault-projecten leuk voor een 2012 stampede*" waarin ik het volgende aangaf:

Het beste is als de actieve mensen van de Vault met een paar voorstellen komen (hoeft niet beperkt te zijn tot 1).
[...]
Bovendien moet er gegarandeerd voldoende rekenwerk beschikbaar zijn. Een stampede kan een enorme impact daarop hebben. Bij voorgaande stampedes was de output van DPC veelal 3x zo hoog als normaal, maar er zijn stampedes geweest waar de output 50x zo hoog was, of dat DPC ineens dagelijks de helft van alle output wereldwijd bij elkaar flushte. De impact bij DC-vault projecten kan nog wel eens veel groter uitpakken, aangezien er nu slechts een klein clubje (toegegeven, met best een leuke hoeveelheid rekenkracht) actief is. Informeer hiernaar bij zo'n project bij twijfel.

Wat ik niet zie terugkomen in dat topic is een gedestileerd lijstje aangedragen door actieve mensen van de DC-Vault. Uiteindelijk heeft de crew zelf een lijst moeten samenstellen waarvan wij dachten dat die projecten geschikt waren.

Het mailtje naar de Docking organisatie is 3 of 4 dagen na het openen van het stemtopic geopend. Wij wisten van te voren ook niet dat er zo massaal op docking gestemd zou worden. Hadden we dat kunnen inschatten? Wellicht. Ervaring leert dat medische projecten bij de stemronde vaak voorkeur genieten. Het is in ieder geval wel een punt wat heel goed kan worden meegenomen bij een volgende keer.

[Qazwaplol]

Klopt,in november was er wel een start gemaakt met het maken van een lijste van dc-vault projecten. Maar aangezien dat weinig zin heeft zo ver van te voren is dat topic een beetje doodgebloed. Van een hoop vault projecten is nu eenmaal niet te voorspellen of ze over x tijd werk hebben.

En is daarna uiteindelijk pas weer wat mee gedaan nadat FreezeXJ met crewpet op kwam buurten in het dc-vault topic (hier ongeveer).

Verwijderd schreef op maandag 21 mei 2012 @ 08:03:
<recalcitrante modus>
[..]
De niet-verenigingsstatuur geeft je de vrijheid om je ook niet te hoeven verantwoorden maar derhalve kan één en ander ook uitmonden in een anarchie. Wie heeft er zin in het organiseren van een GPU-stampede in oktober?
</recalcitrante modus>

Ik hoor een vrijwilliger?

[Camulos]

even een enorm schop(je)

Het is alweer even geleden, maar er is nog niet echt een antwoord op het CPU dan wel CPU+GPU dan wel GPU-only discussie. Wat is daar nu de bedoeling van? Gaan er bij de volgende stampede-stemfase ook GPU dan wel CPU+GPU projecten meedingen?

Ik meende verder nog iets te horen in de trant van "oktober-stampede", indien dat gebeuren gaat dan mogen we daar wel een topic voor aanmaken ff animo-check + disussie aanzwengelen.

[Pyrus]

Goede schop

Het lijkt mij een bijzonder goed idee om twee spamedes per jaar te houden, eentje CPU only en eentje GPU only. Nouja, bij de GPU mag je natuurlijk ook wel je CPU er tegen aan smijten als dat kan, maar dat is vrij zinloos natuurlijk. Ik zal eens een rondje gaan maken langs alle projecten die nu officieel zijn om te zien wat er aangeboden wordt.

[Pyrus]

Wat ik tot nog toe heb kunnen achterhalen is het volgende voor wat volgens mij alle officiele projecten zijn:

Project	NVidia	ATi	CPU
PrimeGrid BOINC	PPS Sieve, GFN**	PPS Sieve	Ja, alles
PrimeGrid PRPNet/manual	GFNSieve, WWWW	WWWW	Beide
Seti@home	Ja	Nee	Ja
Folding@home	Ja	Ja	Ja
Seventeen or Bust	Nee	Nee	ja
RC5-72	Ja	Nee	Ja
OGR-27	Nee	Nee
DPAD	Nee	Nee
World Community Grid	Nee	Nee
Docking	Nee***	Nee
MalariaControl	Nee	Nee
Leiden Classical	Nee	Nee
Rosetta	Nee	Nee

*Onbekend hoe lang het nog duurt.
**Er wordt mogelijk gewerkt aan een ATi client. Onbekend wanneer dat die klaar is
***Er wordt aan gewerkt. Laatste berichtgeving is uit mei dat ze een nieuwe student zoeken om het werk voor hun te doen, maar op aangeboden hulp van uit de community wordt niet gereageerd.

Van de officiele projecten lijken PrimeGrid en Folding dus het interessantste, omdat ze beide architecturen ondersteunen. Bij PG is met name WWWW volgens mij aardig gelijkwaardig als het op prestaties aankomt en PPS Sieve wat minder. Nadeel daar aan is dan weer dat het niet in BOINC zit maar in PRPNet, wat veel mensen afschrikt. Oplossing daarvoor zou zijn een config tooltje te bouwen. Geloof dat ik zo'n ding al eens had gemaakt, dus ik kan hem ook best aanpassen naar dit subproject.

Daarnaast zijn er natuurlijk nog een hele sloot onofficiele projecten, maar hoe daar mee omgegaan wordt binnen de stampede in het vervolg was volgens mij nog niet besloten. Daar heb ik dus ook nog even geen mening over en niks over uitgezocht

[ Voor 0% gewijzigd door Pyrus op 31-08-2012 12:42 . Reden: GCW wordt morgen afgesloten. ]

[AtHomer]

Ter info; Rosetta@home werkt alleen met cpu. Gpu is wel ooit over gesproken, maar gpu's lijken zich niet goed te lenen voor R@h.

[Pyrus]

Thanks, blijkbaar vergeten die er tussen te zetten

[Xaverius]

Humor, gisteren tijdens mijn duurloop van 20km bedacht ik me dat ik nog met dit topic aan de slag moet, wordt die vandaag gekicked.

[Camulos]

@Pyrus: meine liebe, jij laat er ook geen gras over groeien! Top werk
Als het Primegrid wordt, dan stel ik voor om die te bewaren tot in winter solstice challenge ( 18-21 december) ^^

@Xav: Toevallig

[Pyrus]

Camulos schreef op maandag 16 juli 2012 @ 19:57:
@Pyrus: meine liebe, jij laat er ook geen gras over groeien! Top werk
Als het Primegrid wordt, dan stel ik voor om die te bewaren tot in winter solstice challenge ( 18-21 december) ^^

@Xav: Toevallig

Ja ik moet toch iets met mijn tijd...

[devino]

*hatjoe*
Wie heeft er hier al dat stof laten ronddwarrelen?

Op zich wel een leuk idee om in april CPU en in het najaar GPU, maar wat ik zelf zie en merk is dat de groep die actief is, steeds kleiner wordt en ik vind wel dat bij een stampede we de DC wereld weer wel moeten laten beven....
Maargoed als er een stampede komt en mijn koetje kan het aan, zal ik het uiteraard niet nalaten om hem mee te laten grazen.

[Pyrus]

* Pyrus kijkt eens wat er in deze oude doos zit.

Oh heej! Een goed idee! Wordt daar nog wat mee gedaan?

[Xaverius]

In het dc-vault topic hebben we het al over een GPU hunt, vooralsnog hebben we nog te veel variabelen voor een gedegen GPU-stampede waar iedereen aan mee kan doen.

[Arjant2]

Als ik daar zo zie dan is POEM een vrij geschikte kandidaat.
Is relatief eenvoudig met Boinc, draait prima op zowel AMD als NVIDIA zonder al te grote krachtsverschillen tussen beide merken.

[VictordeHolland]

We hebben het over een mogelijke DC-Vault maandHunt op POEM voor de maand oktober .

[JDVB]

Iemand ideën over de komende stampede?
Kunnen we al stemmen over een doel?

Kritiek puntjes van voorgaande keren was dat dit vrij laat mogelijk was, wellicht een idee om dat nu dan eerder mogelijk te maken

Waar kunnen we ons opgeven voor een team? Het wordt tijd voor een nieuwe avatar voor mij

[ Voor 18% gewijzigd door JDVB op 18-02-2013 14:26 ]

[Loose Ends]

VictordeHolland schreef op vrijdag 31 augustus 2012 @ 14:46:
We hebben het over een mogelijke DC-Vault maandHunt op POEM voor de maand oktober .

Het is nog ver weg maar ik zou dit wel eerst met de beheerders bespreken. Ik doe momenteel POEM en al enige tijd hebben zij moeite met werkstukjes leveren. Vooral in het weekend is er niets of heel mondjesmaat wat te downloaden.

Het schijnt dat enige WCG gpu giganten (gelezen op POEM forum)) bij onvoldoende werk bij henzelf de POEM weide steeds leegvreten.

[VictordeHolland]

Loose Ends schreef op dinsdag 19 februari 2013 @ 00:35:
[...]

Het is nog ver weg maar ik zou dit wel eerst met de beheerders bespreken. Ik doe momenteel POEM en al enige tijd hebben zij moeite met werkstukjes leveren. Vooral in het weekend is er niets of heel mondjesmaat wat te downloaden.

Het schijnt dat enige WCG gpu giganten (gelezen op POEM forum)) bij onvoldoende werk bij henzelf de POEM weide steeds leegvreten.

Mijn reactie was van 31 augustus 2012 , de DC-Vault Oktober-hunt POEM@home was ook in 2012 . Stampedes zijn overigens altijd in april .

Ontopic: Er zijn niet zoveel officiële DPC projecten meer die nog geen stampede hebben mogen ontvangen. Blijft het dit jaar dat projecten geen 2x een stampede mogen ontvangen? Mogen (geschikte) DC-Vault projecten dit jaar ook weer meedingen?

[FreezeXJ]

Yep, de Vault-projecten doen weer gewoon mee, anders wordt de spoeling wel heel dun inderdaad.
Een ander puntje is de GPUs, deze projecten beginnen aardig op stoom te komen, alleen zouden we dan wellicht een dubbele stampede kunnen houden, nu 1 voor de CPUs, en later dit jaar een voor GPUs. De andere optie is om gewoon alle projecten te mixen, en dan mogen de koeien zelf bepalen of we dit jaar op een CPU of GPU-project gaan knallen.

[Mulder_fox]

Liever twee apparte dan.
Ik heb alleen een machine tot mijn beschiking met cpu niet gpu

[JDVB]

Dan ga ik ook voor het CPU project

[FreezeXJ]

Let op, het idee is dat we bij 1 stampede/jaar gaan kiezen of het een CPU of een GPU-project wordt, het zal dus niet snel beide worden ivm credit-verschillen, die als de GPU ondersteund wordt de processordivisie meestal volkomen zinloos maakt.

[ongekend41]

Nadeel is wel dat er steeds minder CPU-only projecten zijn. In combinatie met de andere Stampede-eisen (voldoende werk, niet al te lange WU's, niet al te ingewikkelde clients, etc) blijft de spoeling vrij dun ben ik bang. Ik heb zelf alleen CPU graaskracht tot mijn beschikking. Niet dat ik tijdens een CPU stampede in de top zal staan maar bij een mixed project zal ik zeker ergens onderaan bungelen. Alle beetjes helpen maar een beetje deprimerend is het wel. Mijn koeien staan overigens nog steeds vrolijk in de PG weide terwijl ik weet dat ze wat punten betreft niet echt meedoen. Het is geweldig dat het graaswerk een stuk sneller / efficienter gedaan wordt maar voor al-dan-niet tijdelijk competities is het wel wat lastig.

Afijn, ik ga dus voor een CPU project. Mixed doe ik ook mee maar GPU-only moet ik overslaan.

Is er ergens een overzicht van alle puur CPU projecten, liefst inclusief prognose of er binnenkort GPU WU's beschikbaar komen?

[JDVB]

FreezeXJ schreef op dinsdag 19 februari 2013 @ 22:17:
Let op, het idee is dat we bij 1 stampede/jaar gaan kiezen of het een CPU of een GPU-project wordt, het zal dus niet snel beide worden ivm credit-verschillen, die als de GPU ondersteund wordt de processordivisie meestal volkomen zinloos maakt.

Kan er dan een pol komen waarin de opties staan? GPU en CPU projecten en vervolgens kijken welk project de meeste stemmen krijgt? Wanneer in de naam van de optie ook staat of dit een GPU of CPU project is denk ik dat slechts 1 keer stemmen noodzakelijk is.

Ik ben blij als we daadwerkelijk kunnen stemmen en we ook weer mooie subteams kunnen gaan maken (met mooie avatars!)
En liever gisteren dan vandaag

[Pyrus]

CPU en GPU tegelijk is sowieso niet leuk, want door GPU's wordt de CPU inderdaad compleet irrelevant. Om nou daarom maar direct één stampede per jaar te doen op CPU óf GPU lijkt me ook niet helemaal tof. Met de C-only stampede zul je allemaal mensen met goede G's hebben die mekkeren en met G-only zul je een nog meer mensen zonder G hebben die niet eens mee kunnen doen. Resultaat: allerlei mensen kunnen/willen een jaar lang niet mee doen aan de stampede.

[Bubbles]

En dat is nou precies het probleem waar de crew al jarenlang tegenaanloopt. Het voordeel van een stampede met CPU only projecten is dat iedereen in ieder geval mee kan doen. En daarom is er tot nu toe altijd voor die optie gekozen. Alleen een aantal van de mensen zou ook nog meer kunnen doen als ze hun GPU zouden kunnen inzetten. We willen dit jaar kijken of we het toch ook op een andere manier kunnen doen zodat mensen ook hun GPU kunnen inzetten, alleen we lopen nog steeds een beetje tegen de implementatie daarvan aan...

[DigiK-oz]

Misschien een C-only project én een G-only (of G-supported) project in één stampede? De stats van beide projecten zijn dan apart, en het G-project zal veel meer punten per persoon leveren. Maar die stats zijn dan natuurlijk prima te combineren door een vermenigvuldigingsfactor te introduceren voor het C-project. Deze factor kan domweg bepaald worden door de totaalscores van DPC op beide projecten dagelijks te vergelijken.

Naar mijn idee moet de stampede 1 keer per jaar blijven, en niet eens per jaar CPU en eens per jaar GPU. Het kiezen van een GPU-supported project sluit erg veel mensen uit denk ik. Dus een stampede met van beide smaken 1 project lijkt me wel de meest logische oplossing.

[DukeBox]

Ik zou eerst kijken welk project het wordt.. als daar geen GPU mogelijkheden zij kan je altijd nog een 2e uitzoeken voor GPU only..

[MAB The Frisian]

Is het misschien zinvol om voor de Stapede te inventariseren welke cpu's en kaarten beschikbaar zijn ?
Sommige projecten doen het beter op nvidia en andere op ati.
De Stampede is er primair voor om DPC een boost bij een bepaald project te geven dus misschien rekening houden met de beschikbare rekenkracht. Moet dan dus vantevoren al bekend wie meedoet en waarmee.

[R0SSI]

Ik zou het volgende zeggen: Zoek een CPU-only project en een project die beide merken GPU's ondersteund. Tussen- en eindstand van de teams wordt bepaald door positie bij het CPU-project + de positie bij het GPU-project gedeeld door twee. Dus als je team alleen GPU power heeft, kun je nog niet winnen en andersom geldt hetzelfde...
Is dit dan geen idee?

[MOmax]

R0SSI schreef op woensdag 20 februari 2013 @ 11:55:
...
Is dit dan geen idee?

Zeker! Of iets gebalanceerder:

code:

totale_team_score = ( team_cpuscore / totale_dpc_cpuscore ) + n * ( team_gpuscore / totale_dpc_gpuscore ) 

n > 0 ; n < 1

In jouw voorbeeld dan dus n = 0,5.

[VictordeHolland]

Bij PrimeGrid, GIMPS en WCG is die aanpak wellicht te doen, aangezien daar verschillende subprojecten zijn, waar ook stats van zijn (alleen even de vraag of de statsbakkers die ook kunnen opvragen). Maar bij RC5-72, Collatz, Milkyway, POEM, etc staan de CPU/GPU stats door elkaar heen.

Voorbeeld PrimeGrid:
GTX480 doet een PPS sieve (à 3000 punten) in ~20 min = 216.000 punten per dag
3770k @4,2 doet 4x SGS LLR WUs (à 39 punten) tegelijk in 712 sec = ~19.000 punten per dag
In dit geval: GPU punten/11 = CPU punten

[MOmax]

Grinnik. Als we nu alle Stampede-deelnemers vragen om hun CPU/GPU ratios vast te stellen en deze door te geven aan de statsbakkers...

[JDVB]

DigiK-oz schreef op woensdag 20 februari 2013 @ 10:41:
Maar die stats zijn dan natuurlijk prima te combineren door een vermenigvuldigingsfactor te introduceren voor het C-project. Deze factor kan domweg bepaald worden door de totaalscores van DPC op beide projecten dagelijks te vergelijken.

Op moment dat er slechts 1 GPU user zou zijn zou deze dus automatisch 50% van de DPC totaal score behalen, lijkt me niet helemaal gebalanceerd. Ik stel dan toch een ander soort vergelijking voor welke meer kijkt naar de verhouding waartoe een cpu minuut versus een gpu minuut op een project staat.

Leverd een project 200x zo gemakkelijk punten op met een GPU dan GPU punten / 200 = CPU punten.
Nu weet ik niet of dit haalbaar is om dat op deze manier te vergelijken, maar zoiets lijkt me reëler dan simpelweg te stellen dat totale GPU effort == totale CPU effort

VictordeHolland schreef op woensdag 20 februari 2013 @ 14:04:Voorbeeld PrimeGrid:
GTX480 doet een PPS sieve (à 3000 punten) in ~20 min = 216.000 punten per dag
3770k @4,2 doet 4x SGS LLR WUs (à 39 punten) tegelijk in 712 sec = ~19.000 punten per dag
In dit geval: GPU punten/11 = CPU punten

Zoiets lijkt me inderdaad beter dan een vergelijking van totale scores, al is het hierbij natuurlijk nog de vraag welke graka tegen welke cpu afgezet moet worden.

[ Voor 42% gewijzigd door JDVB op 20-02-2013 14:36 ]

[VictordeHolland]

R0SSI schreef op woensdag 20 februari 2013 @ 11:55:
Ik zou het volgende zeggen: Zoek een CPU-only project en een project die beide merken GPU's ondersteund. Tussen- en eindstand van de teams wordt bepaald door positie bij het CPU-project + de positie bij het GPU-project gedeeld door twee. Dus als je team alleen GPU power heeft, kun je nog niet winnen en andersom geldt hetzelfde...
Is dit dan geen idee?

Bedoel je dat als in '2 projecten' een CPUproject (Cp) en een GPUproject (Gp) met de positie van de teams als gemiddelde van de twee?

Voorbeeld waarin 5 teams meedoen:
Team met alleen GPU: #5 op Cp en #1 op Gp => (5+1)/2 = 3
Team met alleen CPU: #1 op Cp en #5 op Gp => (1+5)/2 = 3
Team met beide: #3 op Cp en #2 op Gp => (3+2)/2 = 2.5 => winnaar

[Pyrus]

Een goede manier om de stats te combineren van verschillende projecten is dezelfde tactiek gebruiken als bij de PrimeGrid challenges klassement gebruikt worden. Zie hier. Er zouden wel wat kleine aanpassingen nodig zijn, bijvoorbeeld dat elke positie punten oplevert in plaats van alleen de top X en in plaats van de duur van een challenge bepaalt CPU/GPU hoeveel het maximum aantal punten is.

Als je het zo doet heb je direct je punten genormaliseerd

[DukeBox]

Ik snap niet waarom je een berekening op cpu/gpu verhouding zou moeten toepassen.. er zijn altijd al scheve getallen geweest door mensen met een simpele cpu of een heel pc park onder dezelfde naam. Juist nu hebben de pc parken eens tegenstand van de multi gpu thuis pc.

[MAB The Frisian]

DukeBox schreef op woensdag 20 februari 2013 @ 23:36:
Ik snap niet waarom je een berekening op cpu/gpu verhouding zou moeten toepassen.. er zijn altijd al scheve getallen geweest door mensen met een simpele cpu of een heel pc park onder dezelfde naam. Juist nu hebben de pc parken eens tegenstand van de multi gpu thuis pc.

Vind zelf de competitie binnen DPC tijdens een Stampede ook niet belangrijk. Zoals al eerder aangehaald gaat het bij een Stampede primair om een boost van DPC bij een bepaald project.
Daarom ook mijn vorige reactie vwb inventarisatie van de rekenkracht van cpu en gpu en op basis daarvan een bepaald project kiezen.
Uiteraard kun je die inventarisatie ook gebruiken om binne DPC teams samen te stellen als men daar prijs op stelt.

[JDVB]

Indien we met twee projecten mee gaan doen, kunnen er dan twee pols gemaakt worden (door crew) waarin we kunnen gaan kiezen? Als het maar 1 project wordt, kan er dan 1 lijstje komen waaruit we mogen kiezen?
Indien we nog (veel) langer wachten dan gaat het verbeter puntje van vorig jaar in ieder geval niet gehaald worden, dit vroeger te doen.
Wanneer dit nu nog niet kan, wanneer mogen wij dit dan verwachten?

En een maand van te vooren crunchen op een project wat stampede project gaat worden is ook al leuk namelijk

[ Voor 7% gewijzigd door JDVB op 22-02-2013 07:03 ]

[Bubbles]

Normaliter wordt het stemtopic ergens begin maart geopend en een weekje of 2 later een topic om teams samen te gaan stellen. Als hier totaal zo'n 3 tot 4 weken voor wordt uitgetrokken is dat voldoende tijd voor de crew om de boel verder te organiseren. Eerder de boel starten is wel mogelijk, zodat mensen wel eerder kunnen beginnen op een project, maar het idee van de stampede was juist om ineens uit het niets enorm te knallen op een project, in plaats van dat geleidelijk te laten groeien in de weken voorafgaand aan de daadwerkelijke start van de stampede. Daarom dus ook dat de organisatie richting jullie (in de vorm van een stemptopic) pas begin maart ergens wordt gestart.

[bassiexp]

ik lees al een tijdje mee en ik zat eens te denken. Kunnen we bij de virtuele statistieken niet een vinkje toepassen of zoiets waarbij je kan aangeven of je cpu gpu of beide gebruikt en dan daar een scheiding in maken bij de ranglijsten op persoon en per team kan je dan ook zoiets doen.

Gewoon een hersenspinsel.

[FreezeXJ]

Als ik zo eens het lijstje afga (beetje laat, ben opgehouden door wat huiswerk dat ook nog moest) kom ik hierop uit:

PSP-PRP - rot-client, handmatig instellen
GPUGRID (NV)
Yoyo
QMC
Correlizer
RNA@H
Cosmo
NFS
Collatz (NV/ATI)
ABC
GIMPS (NV/ATI)
Milkyway (NV/ATI high end)
eOn2
POEM (NV/ATI)
LDC
Rosetta
WCG(ATI/NV)
F@H (NV)
SETI (NV)
RC72 (ATI/NV)

Heeft iemand hier nog aanvullingen op, of opmerkingen bij? Er zijn 3 meer NVidia-projecten, maar an sich begint de ondersteuning best te lopen... hoewel er altijd verschillen blijven.

Losse GPU en CPU-stats lijken me wat zinloos, ik ben persoonlijk meer voor 1 lijstje stats, en als er GPUs in het spel zijn zal het lastig worden om een significante score te halen met een CPU, that's life. Van de andere kant, als er een CPU-project gekozen wordt gaat m'n GPU werkeloos toekijken (ok... niet helemaal )

[Verwijderd]

Ik ben even ontzettend lui, maar is F@H nog mogelijk met een PS3? Wellicht dat dat dan een pluspunt is om dat project te kiezen. PSP-PRP zou ik eigenlijk al afschrijven, lange WU, lastig in te stellen en getuige de enorme lijst me projecten waar we uit kunnen kiezen zou ik zeggen dat we zonder al te veel diepgaand onderzoek even een vlugge filter over de lijst heen gooien.
Ik doe zelf alleen maar primegrid waar dit project een onderdeel van is en ik vind het gewoon een scheissen task.
Wellicht is het handig om eerst definitief te bepalen of voor GPU of CPU gaan?

Milkyway is High end. Waarom zou dit dan een goed project zijn t.o.v. de rest? Ik denk dat niet iedereen een high end kaart heeft.

[ Voor 21% gewijzigd door Verwijderd op 28-02-2013 01:04 ]

[VictordeHolland]

Wat ik met een snelle zoek even kon vinden:
Linkje naar discussie over DC-Vault projecten voor stampede 2012

Kleurcodes projecten (zelfde als in dat topic):
Groen = Geschikt
Blauw = Twijfelachtig
Rood = Ongeschikt

Projecten van de vorige stampedes:
Stampede 1 - ECC2 (reeds afgelopen)
Stampede 2 - Distributed Folding (reeds afgelopen)
Stampede 3 - TSC (reeds afgelopen)
Stampede 4 - Find a Drug (reeds afgelopen)
Stampede 5 - Rosetta@Home
Stampede 6 - Folding@Home
Stampede 7 - SeventeenOrBust
Stampede 8 - WorldCommunityGrid
Stampede 9 - Einstein@Home
Stampede 10 - Malaria Control
Stampede 11 - Docking@Home

Officiële projecten:
Leiden Classical - onvoldoende werk
PrimeGrid - diverse subprojecten, badges, altijd werk, GPU ondersteuning voor zowel AMD/NV, NV kaarten presteren beter.
SETI@home - problemen met werk binnen krijgen, serververbinding zit op z'n max van 100mbit
RC5-72 - altijd werk, GPU ondersteuning voor zowel AMD/NV, AMD/ATi kaarten presteren veel beter.

Waarom staat OGR-27 bij uitgesloten in de openingspost van het topic waar ik naar link? We staan er nu #2 en het project heeft nog minder dan een jaar te gaan.

Projecten die niet leuk/weinig zin hebben voor een Stampede:
MUON DPAD (we staan al #1 daar)

DC-Vault projecten:
NFS@Home - vast aantal credits geen 'wingman' nodig, ideaal voor stampede, admin is actief op het mersenneforum.org en kan extra werk inladen indien nodig
Collatz Conjecture - GPUs van rode en groene kamp aardig aan elkaar gewaagd
GIMPS - eventueel P-1 voor CPUs, TF voor GPUs, veel bekendheid door recent WR
Yoyo@home - alleen OGR-27 even uitzetten bij voorkeuren
MilkyWay@Home - CPU, GPU heeft Double Precision nodig (high-end kaarten)
POEM@Home - CPU en GPU, AMD/NV goed aan elkaar gewaagd, recentelijk wat berichten over lastig werk binnenhalen?
SZTAKI Desktop Grid
PSP-PRP - lastige client+ handmatig aanmelden op forum, veeel punten voor Vault, mogelijk #1 te halen bij succesvolle stamp
GPUGRID - GPU (alleen NVidia) lijkt mij iets te beperkend?
RNA World @ Home - XXL WUs, short WUs beperkt beschikbaar
Cosmology@Home - mogelijk lange WUs met veel geheugengebruik, hoewel ik dit zelf niet heb ondervonden.
eOn 2 - Linux client is om onbekende reden sneller, redelijk korte WUs en beperkte mogelijkheid om buffer op te bouwen
Correlizer - werk in batches
ABC@Home - onvoldoende werk
The Lattice Project - sporadisch werk
SIMAP - alleen eerste paar dagen van de maand werk
Climate Prediction - Extreem lange WUs, niet handig voor stamp
LHC@Home SixTrack project - niet altijd voldoende werk

Overig DC-Vault:
QMC@Home wordt binnenkort (tijdelijk) verwijderd uit de Vault aangezien het project al 2 maanden geen werk heeft en bezig is om te verhuizen en de admins niets van zich laten horen. bron
Asteroids@Home wordt bij goedkeuring van de admins toegevoegd aan de Vault. bron

[ Voor 2% gewijzigd door VictordeHolland op 03-03-2013 14:17 . Reden: zie mijn onderstaande bericht ]

[Zonar]

Ik heb het lijstje van Freeze gepakt en daar wat projecten van uitgelicht (daarom staat bijv. Sztaki er niet bij), Victor heeft gelijk alle projecten gepakt

Hier even wat opmerkingen van mijn kant over een aantal projecten:

QMC - Project verhuist naar een nieuwe universiteit, nieuwe site is nog niet functioneel.
Correlizer - Heeft in het afgelopen jaar een aantal keer voor langere tijd zonder werk gezeten, op dit moment is er wel genoeg werk.
RNA@H Op dit moment alleen XXL-wu's. Deze lopen van ongeveer 25 uur tot vele weken, geen checkpointing (of je moet dat via een VM regelen).
ABC Af een toe wordt er een batch met werk toegevoegd die snel uitgeput is.
eOn2 Draait veel beter op Linux dan op Windows, onder Win kun je dit beter via een VM draaien.
LHC Op dit moment is er al een paar weken weinig tot geen werk beschikbaar, er zal wel weer nieuw werk moeten komen. In de afgelopen maanden heeft dit project wel vaker even stilgelegen, maar niet zo lang als nu.

Onderstaande projecten zijn naar mijn gevoel wel geschikt voor een Stampede, de andere projecten heb ik geen ervaring mee (tot nu toe heb ik me niet op GPU-crunching gericht en ik ga geen CPU-cycles verspillen als het veel sneller op een GPU kan).
Yoyo
Cosmo
NFS
Rosetta

[ Voor 6% gewijzigd door Zonar op 28-02-2013 01:28 . Reden: Victor was sneller ;) ]

[VictordeHolland]

Nog een paar extra opmerkingen (even geen zin om eigen post te editen):

eOn2 toch naar twijfelachtig verplaatst, max buffer is daar 2x aantal cores. Dus bij een Quadcore kun je maximaal 8 WUs tegelijk hebben (4 in progress + 4 in de wacht) met maar een paar minuten per WU is dat niet echt ideaal.
Cosmology wil ik vragen of een aantal verschillende mensen/PCs een paar WUs willen doen om te verifiëren of het geschikt is, dan mogelijk ook naar geschikt
Leiden Classic: Serverstatus geeft op dit moment aan ~200 WUs ready to send, Docking@home had vorig jaar moeite en had veel meer werk klaar om te verzenden. Gewijzigd naar ongeschikt.
Asteroids@home: Kan zodra toegevoegd aan de Vault naar geschikt wat mij betreft.

----------------------------------------------------------------------------------------------
Lijstje van geschikte* CPU projecten zou dan ongeveer zo zijn:
NFS@Home
Yoyo@home
SZTAKI Desktop Grid
OGR-27
PSP-PRP - indien goede instalguide en support van admin
Cosmology@Home - met bovenstaande 'maar'
Asteroids@Home - met bovenstaande 'maar'
PrimeGrid - indien subproject stats beschikbaar, zoals bij PG challenges

* = voldoende werk, geen connectie problemen
----------------------------------------------------------------------------------------------

Lijstje van geschikte** GPU projecten zou er dan zo uit zien:
Collatz Conjecture
PrimeGrid
GIMPS

** = voldoende werk, gering/acceptabel verschil tussen NVidia en AMD/ATI performance
----------------------------------------------------------------------------------------------

Iets minder geschikte*** GPU projecten:
RC5-72
GPUGRID - enkel NVidia
Milkyway@home

*** = aanzienlijk verschil in performance NVidia en AMD/ATI

[JDVB]

Mijn GPU stelt niet zo veel voor, dus zou ik voor Need For Speed @ Home stemmen.
(De PC is nooit snel genoeg)

[ Voor 3% gewijzigd door JDVB op 28-02-2013 15:11 . Reden: zie post hieronder over linux vs windows punten verschil ]

[FreezeXJ]

quote: VictordeHollander

Waarom staat OGR-27 bij uitgesloten in de openingspost van het topic waar ik naar link? We staan er nu #2 en het project heeft nog minder dan een jaar te gaan.

Destijds stonden we daar op #1, waardoor er weinig te doen was. Dat was ook de reden waarom RC72 nooit echt in the picture was, en nu een beetje tricky is, ivm anon-clients die haast niet te verslaan zijn.

Met dank aan Victors lijstje:
*PrimeGrid - diverse subprojecten, badges, altijd werk, GPU ondersteuning voor zowel AMD/NV, NV kaarten presteren beter.
*RC5-72 - altijd werk, GPU ondersteuning voor zowel AMD/NV, AMD/ATi kaarten presteren veel beter.
*NFS@Home - vast aantal credits geen 'wingman' nodig, ideaal voor stampede, admin is actief op het mersenneforum.org en kan extra werk inladen indien nodig
*Collatz Conjecture - GPUs van rode en groene kamp aardig aan elkaar gewaagd
*GIMPS - eventueel P-1 voor CPUs, TF voor GPUs, veel bekendheid door recent WR
*Yoyo@home - alleen OGR-27 even uitzetten bij voorkeuren
*MilkyWay@Home - CPU, GPU heeft Double Precision nodig (high-end kaarten)
*POEM@Home - CPU en GPU, AMD/NV goed aan elkaar gewaagd, recentelijk wat berichten over lastig werk binnenhalen?
*SZTAKI Desktop Grid
*GPUGRID - GPU (alleen NVidia) lijkt mij iets te beperkend?
*SETI@home - problemen met werk binnen krijgen, serververbinding zit op z'n max van 100mbit
*RNA World @ Home - XXL WUs, short WUs beperkt beschikbaar
*Cosmology@Home - geen problemen denk ik *
*eOn 2 - Linux client is om onbekende reden sneller, redelijk korte WUs en beperkte mogelijkheid om buffer op te bouwen. Geen buffer, wel vlot werk (zover ik getest heb), en dus ook vlotte credits. Hoeveelheid beschikbaar werk kan een probleem zijn, maar ik denk dat we een eind komen.
*Asteroids@Home wordt bij goedkeuring van de admins toegevoegd aan de Vault. Hier kunnen we ook zelf nog kijken of het nodig is er meteen te stampederen, of dat we power elders inzetten... Maar inderdaad, er zou geen reden moeten zijn om het niet te doen
*PSP-PRP - De enige reden om deze te includen is omdat er zoveel vault-punten te halen zijn... Anders had ik het project al lang vaarwel gezegd...


Totaal dus 9 groene projecten en 16 opties... Ik zou zeggen dat we vooruit kunnen
Overigens zitten we ook met het idee te spelen om projecten na 1-3 jaar gewoon weer kans te laten maken op een stampede, wat betekent dat Rosetta, Folding, SoB en WCG weer mee kunnen doen. MC staan we #2, en Einstein nu #32, het zou dus kunnen, pending debate...

(*) Wat Cosmology betreft, de WU-lengte-melding was van mij en ik heb het project al tijden niet meer gedraaid, het kan zijn dat het inmiddels verbeterd is, of dat ik het gewoon verward heb met Climate Prediction. Als het inderdaad 10 uur is met checkpointing zie ik er geen problemen meer mee.

[ Voor 4% gewijzigd door FreezeXJ op 28-02-2013 10:55 ]

[DukeBox]

Hebben jullie ook meegenomen of er (raw)stats beschikbaar zijn om een stampede dpch van te bakken ?

[FreezeXJ]

DigiK-Oz heeft volgens mij van alles ergens stats weten los te peuteren, behalve RC5-72, en iets doet me vermoeden dat dat het probleem niet is. Daarnaast zijn het meestal BOINC-projecten, waardoor er hopelijk iets gestandaardiseerd is (ik ben niet zo into de statsbakkerij). Mocht jij of een andere bakker problemen verwachten bij een project dan horen we dat graag natuurlijk

[JDVB]

Ik zit net even te kijken naar de top computers op NFS@Home, lijkt me dat je dan alle PC's op linux wilt laten draaien. In de top 40 zitten welgeteld 2 windows bakken, welke op fractie van vergelijkbare systemen lopen.

Waarbij de eerste i7-3770 op linux bijna 2x zoveel punten verzet als de eerste i7-3770 op windows.
En ja, beide machines draaien de 1GB variant, geheugen lijkt niet mee te spelen in beide gevallen (16GB op linux vs 32GB op windows).
Zelfs een 2600K doet bijna 20K waar de 3770 op windows de 11 niet haalt.

Dit zou ervoor zorgen dat ik iig niet voor NFS zou stemmen.

[ Voor 62% gewijzigd door JDVB op 28-02-2013 15:11 ]

[VictordeHolland]

JDVB schreef op donderdag 28 februari 2013 @ 14:38:
Ik zit net even te kijken naar de top computers op NFS@Home, lijkt me dat je dan alle PC's op linux wilt laten draaien. In de top 40 zitten welgeteld 2 windows bakken, welke op fractie van vergelijkbare systemen lopen.

Waarbij de eerste i7-3770 op linux bijna 2x zoveel punten verzet als de eerste i7-3770 op windows.
En ja, beide machines draaien de 1GB variant, geheugen lijkt niet mee te spelen in beide gevallen (16GB op linux vs 32GB op windows).
Zelfs een 2600K doet bijna 20K waar de 3770 op windows de 11 niet haalt.

Ik zal het even testen met W7 en een Linux distro in Oracle VirtualBox, maar ik vermoed dat je wel eens gelijk kan hebben, de Linux heeft ook een hogere/nieuwere versie namelijk (01-Sep-2010 vs. 04-May-2012).

Edit: Confirmed
Win7: 3770k @4,2 (16e Lattice Sieve v1.09) - 2363 sec - 65,00 credits
Linux (DotschUX in VirtualBox): 3770k @4,2 (16e Lattice Sieve v1.10) - 1800 sec - 65,00 credits

[ Voor 7% gewijzigd door VictordeHolland op 28-02-2013 16:51 ]

[FreezeXJ]

NFS heeft inderdaad een fikse Linux-boost, en ouwe Phenom2s rennen er ook als de beste gek genoeg... Geldt ook voor eOn2, die heeft ook een bias.

[Qazwaplol]

RNA geen optie, maar handje vol short wu's beschikbaar. en de xxl wu's duren regelmatig veel langer dan deadline, veel posts op forum voor verlenging van xxl taken.

[JDVB]

VictordeHolland schreef op donderdag 28 februari 2013 @ 15:20:
Confirmed
Win7: 3770k @4,2 (16e Lattice Sieve v1.09) - 2363 sec - 65,00 credits
Linux (DotschUX in VirtualBox): 3770k @4,2 (16e Lattice Sieve v1.10) - 1800 sec - 65,00 credits

En dat in in virtualbox, lijkt me dat een verschil van bijna 50% dan inderdaad klopt wanneer je dit normaal draait (buiten virtualisatie om).
Wellicht nog wel de moeite even te vragen wanneer de versie 1.10 voor windows beschikbaar komt.

[Peregrine]

Misschien een idee om per project nog even kort aan te geven wat het doel is? (kan ik zelf ook opzoeken, maar ik ben even druk en als 'iedereen' dat moet doen kan het net zo goed even onder elkaar worden gezet) Ik reken graag mee (met mijn geupgrade koetje dit jaar ) maar wel graag voor een project dat ook enigszins nut heeft. For the record, het zoeken naar het n^e priemgetal o.i.d. vind ik niet bijzonder nuttig...

Ik had zelf al eens gekeken naar Correlizer, die een medisch nut heeft. Is het niet te regelen bij hun admins dat ze een maandje genoeg werk genereren?

[Cow_tipping]

*bump*

Een weekje eerder dan vorig jaar. Misschien dat dit de mensen weer in /5 laat terugkomen.

[Witlof]

Kunnen we dat wel aan?

[Bubbles]

Hmm. Je bent me voor met schoppen. Wilde eigenlijk eerst de crew nog een schop geven, voordat dit topic er een kreeg, maar vooruit.

[devino]

Huh, wie haalt mij uit m'n winterslaap?

[Witlof]

Maar goed, waar gaan we op grazen?

[Cow_tipping]

Laten we eens een voorzetje doen:
OGR28!

[Witlof]

Als die er komt doe ik zeker mee

[Bubbles]

Witlof schreef op dinsdag 11 februari 2014 @ 20:47:
Maar goed, waar gaan we op grazen?

Cow_tipping schreef op woensdag 12 februari 2014 @ 00:09:
Laten we eens een voorzetje doen:
OGR28!

Daarvoor komt er t.z.t. een stemtopic. Als we niet op #1 staan, komt OGR daar zeker tussen te staan. Dit topic is meer voor ideëen om projecten onder de aandacht te brengen die we anders zouden missen (en ja, er zal ook wel weer in de Vault worden gekeken. Ik meen te herinneren dat alle projecten daarin ook gewoon in aanmerking kwamen vorig jaar), of om te zien of ze überhaubt zinvol/handig zijn om te draaien (denk aan specifieke GPU ondersteuning only, etc.).

[Verwijderd]

Wat ik leuk zou vinden dit jaar is om gezamenlijk een frontale aanval te lanceren op onze conculega's uit het noorden. Gewoon eens kijken of onze totaal-power in staat is om een klap uit te delen.
En de gevoeligste plek is: PSP

[Robinski]

Cow_tipping schreef op woensdag 12 februari 2014 @ 00:09:
Laten we eens een voorzetje doen:
OGR28!

Dat is nog eens een zeer goed idee... we moeten uiteraard goed van start!
Het is slechts een kwestie van enkele dagen voordat OGR27 voorbij is... waarna OGR28 direct van start zal gaan.

[Witlof]

Zijn er al nieuwe clients en proxy's dan?

[Robinski]

Witlof schreef op woensdag 12 februari 2014 @ 23:14:
Zijn er al nieuwe clients en proxy's dan?

Is niet nodig

As a reminder, no new dnetc client binaries or configuration will be necessary since all existing OGR-27 (OGR-NG) clients are already capable of working on OGR-28 once we begin sending out those workunits.

Bron: http://blogs.distributed.net/2014/01/22/09/28/bovine/

[Witlof]

Oh, das wel netjes

[Crack]

Verwijderd schreef op woensdag 12 februari 2014 @ 20:17:
[...]
En de gevoeligste plek is: PSP

Ik heb geen probleem met dat project, maar er is teveel rompslomp nodig om ermee aan de gang te gaan. Daardoor zullen m.i. veel potentiële deelnemers afhaken.

Ik weet niet of het mogelijk is bij dat project, maar misschien kan iemand een eenvoudig te installeren tool in elkaar zetten, waarmee via een proxy op een gemeenschappelijke account ge-flust wordt? De stampede-stats zouden dan van de proxyserver gehaald moeten worden.

[Bubbles]

Het gebruik van een proxy maakt de toegankelijkheid van een project inderdaad wel aanzienlijk minder, maar zoals gesteld hoeft dat niet belemmerend te zijn als er een gemeenschappelijke proxy kan worden opgezet. Ik meen te herinneren dat Dukebox eerder wel eens had aangegeven hier geen problemen mee te hebben om op te moeten zetten. Voordeel ervan was ook dat hij dan gelijk stats kon voorzien. Maar pin me hier niet op vast, voordat ik mensen woorden in de mond ga leggen.

[VictordeHolland]

OGR-28 lijkt mij inderdaad wel een mooi project om een vliegende start te geven. We gaan dit jaar toch weer gewoon stemmen neem ik aan?

[ongekend41]

VictordeHolland schreef op zaterdag 22 februari 2014 @ 22:53:
OGR-28 lijkt mij inderdaad wel een mooi project om een vliegende start te geven. We gaan dit jaar toch weer gewoon stemmen neem ik aan?

Lijkt me wel. Het lijstje van vorig jaar van Victor/Freeze is een mooie start FreezeXJ in "Stampede; algemeen ideeënvergaartopic". Paar aanpassingen ( o.a. OGR-28 en Skynet) en discussies en we kunnen beginnen

[miyazakiman]

Is er al iets meer bekend over de stampede van dit jaar?

[enthernal]

*enthernal komt wakker uit zijn jaar-slaap*

Nog niet begonnen met kiezen? Het is maar een paar weken tot het zo ver is...

[R0SSI]

Ik ben ook benieuwd welke projecten dit jaar een keuze voor mag komen

[hydrargyrum]

Ik ben in ieder geval wel voorstander van een project dat je met de gpu een flinke boost kan geven, want mijn 4670K kan wel wat, maar als mijn 770 zijn ding kan doen, dan begint de lol pas Iemand die al een paar foto's/specs van zijn rig(s) heeft voor deze stampede? misschien zelfs miners?

[enthernal]

De vaste klanten staan reeds klaar, een i7-2600k, een Xeon E3-1240 en een i7-3570k based rig, waarvan een over een van een 670 GPU voorzien is. Met zo'n opzet zie ik natuurlijk liever een project komen waar de GPU niet te doorslag gevend is, een goede boost daar kan ik best me leven

Welke loslopende koetjes er nog zullen bijkomen, dat is natuurlijk de vraag

[Cow_tipping]

Tot op heden is de april stampede altijd een CPU-only evenement geweest. Er is wel sprake geweest van een extra GPU-only editie maar dat is niet van de grond gekomen.
Gecombineerde CPU en GPU projecten zijn verworpen omdat het verschil te groot is in output.

[hydrargyrum]

Maar hoezo zou dat dan een nadeel zijn? ik gok dat een redelijk groot gedeelte van de tweakers wel een flinke grafische kaart heeft, en alle punten zijn welkom!

[Sterkwachtwoord]

hydrargyrum schreef op woensdag 05 maart 2014 @ 17:39:
ik gok dat een redelijk groot gedeelte van de tweakers wel een flinke grafische kaart heeft

Met de stampede staan er ook clustertjes klaar, en ander soort omgevingen die vaak alleen CPU draaien.

[jellebaris]

Mijn persoonlijke voorkeur gaat uit naar skynet. Een jong project waar we op dit moment grote potentie hebben te stijgen richting top 3 en mogelijk nr. 1. Skynet werkt makkelijk (standaard boinc project) en ik heb geen klachten gezien betreffende de werkvoorraad.
Afgezien dat mijn voorkeur uitgaat naar een project met fysische of medische doelstelling vind ik het ontbreken van een simpele installatie voor PSP idd een nadeel.

[Bubbles]

Cow_tipping schreef op dinsdag 04 maart 2014 @ 22:49:
[...]
Gecombineerde CPU en GPU projecten zijn verworpen omdat het verschil te groot is in output.

Het grootste probleem waar je inderdaad tegenaan loopt is dat er ook een hoop gebruikers* zijn die niet een denderende grafische kaart hebben, of de verkeerde chip (NVidia/ATI), waar het project uiteraard net de ander zwaar prefereert. Als je dan alleen met je cpu kan meedoen, is het verschil met degenen die wél de goede videokaart hebben vaak gelijk zo ontzettend groot, dat de lol om überhaubt nog mee te willen doen heel snel weg is.

*Meestal is er een behoorlijke aanwas van nieuwe mensen die via een posting op de frontpage meedoen, die over het algemeen wat minder in de materie zitten en daarmee vaak ook niet high-end spul hebben.

Ik zal overigens nog eens even de rest van de crew een schop geven om ervoor te zorgen dat er deze week nog een stemtopic de lucht in komt.

[enthernal]

Bovendien is het ook zo dat de de gewenste high end GPU's enkel in een gaming rig terug te vinden zijn. Dat wil ook zeggen dat je vaak maar 1 GPU per tweaker hebt, en dat het vinden van extra geschikte koetjes ook een stuk moeilijker wordt.

[hydrargyrum]

Oke, dan zijn gpu projecten niet echt geweldig (ondanks dat het wel een eerlijke kans zou bieden tegen de superclusters, maar goed). Dan zou ik wel iets adviseren met relatief kleine wu's, omdat ik vorig jaar er maar 1 of 2 heb kunnen doen omdat ze zo groot waren.

[Pyrus]

Bubbles schreef op woensdag 05 maart 2014 @ 23:09:
[...]

Het grootste probleem waar je inderdaad tegenaan loopt is dat er ook een hoop gebruikers* zijn die niet een denderende grafische kaart hebben, of de verkeerde chip (NVidia/ATI), waar het project uiteraard net de ander zwaar prefereert. Als je dan alleen met je cpu kan meedoen, is het verschil met degenen die wél de goede videokaart hebben vaak gelijk zo ontzettend groot, dat de lol om überhaubt nog mee te willen doen heel snel weg is.

*Meestal is er een behoorlijke aanwas van nieuwe mensen die via een posting op de frontpage meedoen, die over het algemeen wat minder in de materie zitten en daarmee vaak ook niet high-end spul hebben.

Ik zal overigens nog eens even de rest van de crew een schop geven om ervoor te zorgen dat er deze week nog een stemtopic de lucht in komt.

Even wat schaamteloze promotie voor PrimeGrid: op de GFN projecten zijn clients voor zowel ATi als NVidia beschikbaar. ATi top-range zijn net wat sneller dan NVidia top-range, maar dat zou je als NVidiaan kunnen compenseren door een ander subproject te doen waar de NVidia's weer een voordeel hebben.

[Bubbles]

Als ik overigens het stemtopic van vorig jaar erbij pak, zie ik wel dat er daar ook op GPU projecten kon worden gestemd. Het gros ervan is dan wel geschikt voor zowel NVidia, als Ati/AMD kaarten. Dit heeft, vanuit de crew, uiteraard ook de voorkeur, zodat het de kansen minimaliseerd dat je buiten de boot valt.

[enthernal]

Al enig nieuws over een stem topic? Het is nog maar een goeie 2 weken voor de start

[Witlof]

Ik stem voor

[Bubbles]

Ik ben, as we speak, bezig met het in elkaar draaien van een stemtopic. Hopelijk kan ik die vanavond nog live gooien, en anders wordt het morgen; dan heb ik toch een vrije dag. E.e.a. betekend wel dat als we nog steeds op 1 april willen beginnen, er minder tijd is voor zowel het stemmen als het vormen van teams. (lees: stemmen 1 weekje, en dan nog anderhalve week voor het maken van teams, een statsbakker vinden die dat in elkaar wilt zetten en testdraaien voor hen die dat alvast willen)

[Witlof]

Ach, de meeste leden komen toch pas na de start Dus ik zeg doen!

[enthernal]

Daar kan ik me volledig in vinden

[Bubbles]

Op de valreep: [Stampede 13] planning

[ Voor 62% gewijzigd door Bubbles op 13-03-2014 23:58 ]