Stampede; algemeen ideeënvergaartopic

[Xaverius]

Zo, de tiende stampede is inmiddels alweer een weekje afgelopen en nu lijkt het ons tijd om eens de neuzen bij elkaar te steken om te kijken of er verbeterpunten zijn bij de stampederegels.

Dit topic is dus om ideeën uit te wisselen, feedback te krijgen en te discusseren over de stampederegels.

Als eerste een belangrijk uitgangspunt, de regels zijn er voor om de stampede goed te kunnen organiseren en ook om een zo mooi mogelijke strijd te krijgen met de stampedeteams. Alles moet wel door de crew goed te regelen zijn en wij kunnen dus niet altijd populaire beslissingen maken als het gewoon niet handig of oneerlijk is. De definitieve regels worden door de crew bepaald, maar we willen natuurlijk het voor iedereen interessant houden.

Waar we zelf al mee komen:

• het uitbreiden van het aantal projecten die in aanmerking komen voor de stampede. Naast dat er niet eerder een stampede op geweest moet zijn lijkt het ons verstandig om ook niet officiele projecten in aanmerking te laten komen en zelf denken we aan de projecten die in de DC-vault zitten, mits ze voldoen aan de eisen voor een officieel project.
• wanneer een cruncher na de start mee wil doen aan de stampede wordt er gekeken welke stampedeteams nog hulp kunnen krijgen. Als eerste vuistregel wordt gedacht aan de laagste 50% van de teams in de overallstats van de vorige dag

Dus, wat vinden jullie. Wat kan er eventueel nog verbeterd worden in de regels van de stampede.

[ Voor 0% gewijzigd door Bubbles op 08-05-2011 14:29 ]

[Elrond-NL]

mocht het oog ooit vallen op een project waar je ook met je GPU aan mee kan doen, hoe gaat dat dan in de stampedestats verwerkt worden? En dan met name projecten waar je alleen met een bepaald soort GPU aan mee kan doen.

[Bastiaan V]

"de laagste 50% van de teams"

dat is precies waar het ook dit jaar weer onduidelijk was.

naar welke stats kijk je dan, huidige? laatste dag status?

En wat doe je als alle teams uit 15 man bestaan, en er komen 50 nieuwe leden door een post op de FP ?
sorry, enkel vragen en geen antwoorden, ik weet het simpelweg ook niet....

[Xaverius]

Qua GPU-kracht van bijvoorbeeld Nvidia... Ik durf dat nu nog niet te zeggen. Volgens mij kan je niet selecteren dat je CPU- en GPU-punten afzonderlijk kan weergeven.

Bastiaan V schreef op zondag 08 mei 2011 @ 17:02:
"de laagste 50% van de teams" dat is precies waar het ook dit jaar weer onduidelijk was.
naar welke stats kijk je dan, huidige? laatste dag status?

Bastiaan V schreef op zondag 08 mei 2011 @ 17:02:
Als eerste vuistregel wordt gedacht aan de laagste 50% van de teams in de overallstats van de vorige dag

Is dat al voldoende antwoord? Dit jaar werd er volgens mij voor het eerst wat soepeler omgegaan met de nieuwe crunchers.

En wat doe je als alle teams uit 15 man bestaan, en er komen 50 nieuwe leden door een post op de FP ?

Wat je vooral niet moet doen is het kijken naar hoeveel mensen in een team zitten. Kijk maar bijvoorbeeld naar DukeBox, die kan op één dag meer punten krijgen dan ik in een heel jaar bij elkaar kan sprokkelen. Daarom is het ook handig om te weten wat voor CPU-, GPU-kracht je kan inzetten.

[DigiK-oz]

Over het algemeen is het bij een project wat GPU ondersteunt, vrij zinloos om met CPU's mee te doen. De verhouding is simpelweg meestal zo scheef dat 1 enkele GPU meerdere PC's overtreft. Dus áls er een GPU project kan worden geselecteerd zou ik voorstellen om 2 afzonderlijke projecten te kiezen voor de stampede : een GPU-project en een CPU-only project.

Wat nieuwe leden en de verdeling betreft : bevries alle teams aan het begin van de stampede. Nieuwe leden die zich melden in de eerste week worden even on-hold gezet. Na de eerste week worden deze nieuwe leden over de bestaande teams verdeeld om een zo gelijk mogelijke strijd te krijgen. Leden die zich NA de eerste week aanmelden komen in 1 enkel extra team met "laatkomers" terecht. Dit team begint dan wel met een enorme achterstand, maar als er nog veel nieuwe leden zich aanmelden (FP-post bijvoorbeeld) kan dit team nog voor grote verrassingen zorgen, zeker in de daily scores.

Meerdere keuzes voor het project lijkt me een must, omdat de spoeling met officiele projecten wel dun wordt.

Having said that, hulde aan de crew voor de afgelopen stampede . We hebben onwaarschijnlijke scores behaald (voor een groot deel te danken aan de FP-posts) en de strijd onderling was, zeker in de eerste weken van de stampede, zeer spannend. Van de nieuw toegestroomde koetjes is er een flink aantal blijven hangen bij malaria en/of hebben zich gemeld bij andere projecten. En dat is goed voor DPC!

[DukeBox]

Xaverius schreef op zondag 08 mei 2011 @ 17:31:
Dit jaar werd er volgens mij voor het eerst wat soepeler omgegaan met de nieuwe crunchers.

Klopt, komt ook door mij misschien omdat ik een stuk code had gemaakt dat voor de eerste week voor alle teams en daarna alleen een week voor niet top3 predicties deed op gehaalde punten bij andere projecten en (mits toegankelijk) het aantal, en snelheid van, systemen welke bekend waren op mc.

Bij users waarbij geen distributed computing history bekend was bij andere projecten werd deze check alleen gedaan over de opgehaalde punten (omdat default iedereen dezelfde queue groote voor 0,1 dagen heeft) om zo te bepalen of deze 24/7 of minder aanstond i.c.m. het bekende systeem in de stats.

Zo heb ik geprobeerd zo optimaal mogelijk te verdelen en als ik dat vergelijk met bijv. einstein vorig jaar of mc is daar toch een aardig verschil, kijk maar naar de eerste 14 dagen:

Einstein@Home:


Malariacontrol:


Bij Einstein stond in de eerste week al vrijwel vast wie er in de top 3 zou komen.
Dit jaar was zelfs FoKSchaap niet zeker voor de laatste plaats.

[_Sunnyboy_]

DigiK-oz schreef op zondag 08 mei 2011 @ 21:30:
...

Wat nieuwe leden en de verdeling betreft : bevries alle teams aan het begin van de stampede. Nieuwe leden die zich melden in de eerste week worden even on-hold gezet. Na de eerste week worden deze nieuwe leden over de bestaande teams verdeeld om een zo gelijk mogelijke strijd te krijgen. Leden die zich NA de eerste week aanmelden komen in 1 enkel extra team met "laatkomers" terecht. Dit team begint dan wel met een enorme achterstand, maar als er nog veel nieuwe leden zich aanmelden (FP-post bijvoorbeeld) kan dit team nog voor grote verrassingen zorgen, zeker in de daily scores.

...

DIt lijkt me niet zo'n goed idee. Niet zo zeer voor de eerlijke verdeling, alswel voor de nieuwe joiners. Wat je dit jaar ook weer zag is dat in de eerste week heel veel nieuwe mensen zich bij de stampede aansluiten. Misschien interessant om te kijken hoe de totale productieverhouding licht tussen mensen die voor & na de offficiele start zijn begonnen. Het zoiu me niet verbazen als meer dan 50% na dag 0 zijn begonnen. Als je de eerste week niet mag meedoen, of als je keuze voor teams dan weg is dan heeft dat (In ieder geval op mij) nogal een afschrikkend effect. Dat lijkt me toch niet het doel.

Op zich vond ik de huidige regel wel ok. Er weas wat onduidelijkheid over wat precies de regel was (welke stats) maar dat was ook vrij snel verhelderd. Wat misschien wel handig zou zijn is om elke dag te posten welke teams vandaag gejoint kunnen worden. Op die manier wordt elke nieuwe joiner er gelijk op gewezen welke teams open zijn die dag.

[ Voor 13% gewijzigd door _Sunnyboy_ op 09-05-2011 08:02 ]

[Verwijderd]

Ik ben van mening dat er helemaal geen subteams gemaakt moeten worden.
De stampede is bedoeld om andere DC-teams te verpulveren; dat is waar iedereen die meedoet naar moet kijken. Nu heb ik het gevoel dat er "op eieren gelopen moet worden" om alle subteams tevreden te houden. De scores mogen vooral niet teveel uiteen lopen!

Ik zou best wel eens samen met Dukebox en Elteor in team "Resistance Is Futile" willen zitten bij de volgende stampede

[R0SSI]

Verwijderd schreef op dinsdag 10 mei 2011 @ 00:03:
Ik ben van mening dat er helemaal geen subteams gemaakt moeten worden.
De stampede is bedoeld om andere DC-teams te verpulveren; dat is waar iedereen die meedoet naar moet kijken. Nu heb ik het gevoel dat er "op eieren gelopen moet worden" om alle subteams tevreden te houden. De scores mogen vooral niet teveel uiteen lopen!

Ik zou best wel eens samen met Dukebox, Witlof, BurnHard, Elteor en andere grote crunchers in team "Resistance Is Futile" willen zitten bij de volgende stampede

Uhm, de grote jongens tegen de kleintjes? Dat lijkt mij ook wel een keer grappig om te zien / te doen.

[ Voor 4% gewijzigd door R0SSI op 10-05-2011 09:02 ]

[DukeBox]

Dan nog, hoe definieer je een 'subteam' in dit geval,
Meerde members virtuele samenvoegen als één user.
Of zoals Delft in het huis ,dat is een enkele user waar verschillende users onder dezelfde naam meedoen.
Dat is allemaal niet anders dan wat ik doe, met meerdere systemen onder dezelfde naam mee doen.

[hjvg]

Verwijderd schreef op dinsdag 10 mei 2011 @ 00:03:
Ik ben van mening dat er helemaal geen subteams gemaakt moeten worden.
De stampede is bedoeld om andere DC-teams te verpulveren; dat is waar iedereen die meedoet naar moet kijken. Nu heb ik het gevoel dat er "op eieren gelopen moet worden" om alle subteams tevreden te houden. De scores mogen vooral niet teveel uiteen lopen!

ik ben aan het einde van de stampade gejoind. en ik vond het juist mooi dat er subteams zijn. ik had geen kans om met mijn pc in de buurt van de eersten te komen echter in ons team had ik wel de mogelijkheid om redelijk mee te draaien wat mij aanmoedigde om te proberen nog iets meer er uit te halen.

ik doe op dit moment nog even mee met het jojo project van dc-vault gisteren stond ik 27ste daily maar ik zie hier geen uitdaging in om nog te proberen 1 of 2 plaatsen hoger te komen. ik zie wel op welke plek ik kom elke dag. terwijl met destampade ik toch wou proberen hoog in me subteam te staan

[JDVB]

Ook ik vind de subteams een aanmoediging om meer punten te scoren.
Om te kijken of het eigen subteam daardoor nog net wat hoger kon komen.

Niet dat het uiteindelijk wat uitmaakt, of je in een subteam wint of verliest, toch is een heel groot deel van de lol van DC het kijken naar stats.
En de stats overal in een stampede zijn toch redelijk saai.

Waarom saai? DPC staat elke dag heel ruim op 1.
Ten opzichte van andere teams veranderd er per dag maar heel weinig (relatief).

Daartegenover veranderd er binnen subteams wel redelijk veel.
Maar meer nog, hierdoor ga je meer naar individuele users kijken en zien waarom jouw subteam die dag goed of juist iets minder goed scoorde dan verwacht.
Het geeft de stampede zeker wel een boel extra.

Dit blijkt ook wel uit de verhouding punten uit subteams en van mensen die hier niet bij aangesloten waren.
Vind je een subteam niets, dan hoef je je ook niet aan te melden hiervoor, om toch mee te kunnen doen met de stampede.

Het gaat m.i. dan ook niet over het op eieren lopen, maar meer om, wanneer de scores dicht bij elkaar liggen, dat het dan het meest een motivatie wordt om dat kleine beetje extra CPU/GPU power in te gaan zetten. Om toch die eerste plek in de subteams te gaan pakken. Of om die ene plaats te stijgen.
Stats zijn verslavend, ze smaken naar meer.

Zonder subteams denk ik dat ik uit zou zijn gekomen op 20-30K punten, door het "zet ons subteam omhoog in de standen" gebeuren toch gemotiveerd om te kijken wat ik nog meer kon doen.
Dit is vanzelfsprekend meer dan goed voor de stampede in zijn geheel.

[ Voor 8% gewijzigd door JDVB op 10-05-2011 11:34 ]

[Verwijderd]

^^ Ik zie niet echt het verschil tussen "hoog willen eindigen binnen je subteam" of "hoog willen eindigen binnen de totaalstats van DPC als individu".

Ik blijf bij mijn mening dat subteams ertoe leiden dat er irritatie ontstaat, als ineens 1 van de teams er hard vandoor gaat. Neem de laatste stampede; ik zag daar toch wel wat felle reacties op het forum over de "ineens toegenomen output van Dukebox".
Ik denk dan: wat fantstisch voor DPC dat Duke dat voor elkaar weet te krijgen!

Nou ja, alles heeft z'n voor en nadelen; voor volgend jaar zie ik wel erg uit naar de toevoeging van nieuwe projecten die in aanmerking komen voor de stampede

[Pyrus]

Verwijderd schreef op dinsdag 10 mei 2011 @ 12:03:
^^ Ik zie niet echt het verschil tussen "hoog willen eindigen binnen je subteam" of "hoog willen eindigen binnen de totaalstats van DPC als individu".

Het verschil is dat je binnen een subteam betere kans maakt hoger te komen dan binnen de hele club. Alhoewel ik net een nieuwe pc heb, kwam ik binnen DPC zelden de top 30 daily binnen de afgelopen stampede. Binnen het subteam kwam ik echter nog zo nu en dan best in de top 5 daily (en daarmee de DPCH).

[Qazwaplol]

Is een beetje dubbelop, het zou enorm veel makkelijker zijn om geen subteams te doen en als 1 DPC tegen de rest van de wereld.

Voordeel van subteams is dat je een extra laag concurrentie hebt bij kleinere projecten, Bij WCG moeten we moeite doen om als geheel in de top5 te komen, bij malaria doen we dat met 2 vingers in de neus. Dan is de onderlinge strijd tussen subteams een extra motivatie bron. Maar dan moeten we teams wel in evenwicht zijn anders is het juist demotiverend, als je stampede team toch al zo slecht gaat vergeleken met de rest.

Het is ook maar net hoe de persoon er zelf in zit.


Wel of geen subteams maakt mij niet zoveel uit, zoek zelf de concurrentie meer om een bepaalde plek te bemachtigen/behouden binnen DPC

[arnold_m]

Dit was de eerste stampede waar ik aan meegedaan heb. De belangrijkste bron van motivatie was voor mij het belang dat ik aan het project malariacontrol.net hecht. De strijd tussen de subteams maakt het wel veel spannender en heeft me er ook toe aangezet te kijken of ik nog iets extra kon doen.

Ik vond het jammer om te zien dat de inzet voor het rekenen en posten van stats op het laatst wat afnam. Valt natuurlijk wel te verklaren uit het al gehaald hebben van de eerste plek overall en de 50M mijlpaal door DPC, maar bij een wedstrijd hoort natuurlijk eigenlijk gewoon een prijsuitreiking.

[DukeBox]

Qazwaplol schreef op dinsdag 10 mei 2011 @ 18:20:
Is een beetje dubbelop, het zou enorm veel makkelijker zijn om geen subteams te doen en als 1 DPC tegen de rest van de wereld.

Dat is er dan toch ? Gewoon op de project site naar de stats kijken (of bij een van de andere niet DPC statsbouwers). En al helemaal de stampede stats niet bekijken.
Subteam stats en Stampede stats zijn alleen maar additioneel.

[Qazwaplol]

bedoelde kwa organisatie, in tegenstelling tot goed gebalanceerde stampedeteams

[VictordeHolland]

Even een lichte bump

Merk op dat we (expres) dit jaar de GPU-projecten eruit gelaten hebben, omdat vele daarvan een duidelijke voorkeur hebben voor AMD of NVidia, en dat dus de helft van de kudde buiten werking zou stellen.

Wat is de reden dat PrimeGrid, RC-72 en GIMPS er dan wel bij staan?
PG kan goed overweg met CPU's, maar high end GPU's scoren hier meer dan 10x zoveel. Voor zover ik weet is dit bij RC5-72 ook min of meer het geval. GIMPS heeft ook GPU clients voor AMD en NVidia, maar deze scoren relatief iets minder (ongeveer 5x wat een CPU doet)

Misschien wordt er bedoelt dat er geen GPU-projecten in staan die alleeneen client hebben voor één van de 'kampen' (AMD/NVidia), maar dit word niet geheel duidelijk uit de post.

[Arjant2]

Ik ging even kijken bij Docking maar de accountregistratie werkt op dit moment niet.
Ik weet niet hoe dat bij anderen is, maar lijkt me niet handig als er ineens tig koeien proberen te registreren en het werkt niet.

Of je wacht 5 minuten en dan werkt het wel ineens... typisch...
Dit op het het docking forum kan overigens wel een probleem opleveren:
http://docking.cis.udel.e...um/thread.php?id=555#6013

[ Voor 32% gewijzigd door Arjant2 op 08-03-2012 20:02 ]

[DigiK-oz]

Werkt het gewoon helemaal niet? Foutmeldingen?

Op zich niet heel ernstig, aangezien je ook gewoon in BOINC manager met een project kan connecten en dan direct een nieuw account aanmaken. Moet je daarna alleen niet vergeten om DPC te joinen op de webpage van Docking. Maar het zou toch handig zijn als ze het even fixen.

EDIT: Lijkt gewoon te werken, heb er een account bij
EDIT2: ff een paar WU's testen op W7 64-bit, lijkt bij mij OK

[ Voor 15% gewijzigd door DigiK-oz op 08-03-2012 20:13 ]

[Bubbles]

VictordeHolland schreef op donderdag 08 maart 2012 @ 18:50:
Even een lichte bump


[...]

Wat is de reden dat PrimeGrid, RC-72 en GIMPS er dan wel bij staan?
PG kan goed overweg met CPU's, maar high end GPU's scoren hier meer dan 10x zoveel. Voor zover ik weet is dit bij RC5-72 ook min of meer het geval. GIMPS heeft ook GPU clients voor AMD en NVidia, maar deze scoren relatief iets minder (ongeveer 5x wat een CPU doet)

Misschien wordt er bedoelt dat er geen GPU-projecten in staan die alleeneen client hebben voor één van de 'kampen' (AMD/NVidia), maar dit word niet geheel duidelijk uit de post.

Dat. En inderdaad, is niet helemaal duidelijk in de OP.

[Verwijderd]

@Arjant2: Ik heb één Docking-WU getest hier en ook geen problemen gehad maar mijn processor is niet een oudje, op forum daar wordt gesuggereerd dat het voornamelijk een probleem is met oudere CPU's/chipsets in combinatie met Win7 x64. Probleem etaleert zich niet met x86, ze kunnen het niet reproduceren en het zijn voornamelijk dezelfde weinige cliënts die er last van hebben. Zal wel loslopen...

[Arjant2]

DigiK-oz schreef op donderdag 08 maart 2012 @ 20:02:
Werkt het gewoon helemaal niet? Foutmeldingen?

Op zich niet heel ernstig, aangezien je ook gewoon in BOINC manager met een project kan connecten en dan direct een nieuw account aanmaken. Moet je daarna alleen niet vergeten om DPC te joinen op de webpage van Docking. Maar het zou toch handig zijn als ze het even fixen.

Via boinc werkte dus niet, wel een account aanmaken maar vervolgens niet mijn naam ingeven en ook geen team kiezen. Vervolgens ingelogd op de site zelf, account was wel aangemaakt maar kon nog steeds mijn naam niet aanpassen en geen team kiezen.
5 minuten later werkte het wel.

[Camulos]

Ten eerste: KUDO's voor de DPC crew na deze goede stampede!

Dan toch nog even wat (constructieve) opmerkingen:
Als me er 1 ding opviel bij het begin van deze Stampede dan was het wel de vraag:

Kan ik ook met mijn GPU meedoen?

Het lijkt me op zijn minst nuttig om eens serieus te kijken niet of we deze kunnen inzetten, maar HOE deze ingezet kan worden
Wellicht een idee om naast het main CPU-stampede project, een GPU-project aan te wijzen waarop mensen hun GPU kunnen inzetten? Gewoon als richtlijn, niet als verplichting.. Elke extra credit is er 1 Voor de vaste stampers is het wellicht minder relevant, maar nieuwelingen die enkel voor de stampede willen crunchen kun je op dit manier een houvast geven.
(Er zijn natuurlijk ook projecten die zowel CPU als GPU applicaties hebben, echter geeft dat een oneerlijker gevoel voor koeien die enkel voor de stampede stampen met hun CPU. Dit komt omdat er dan geen verschil gemaakt kan worden in de punten tellen tussen CPU en GPU.. daarom lijkt me een apart CPU en GPU project de meest voor de hand liggende constructie)

Een ander punt dat een paar keer terug kwam in het team-maak-topic is dat het onduidelijk is welke teams nu gejoined mogen worden. Hoewel de regel zegt dat het onderste 50% van overall van de vorige dag moet zijn, duurt dit 'vrij lang' voordat effecten heeft. Persoonlijk zou ik liever zien dat dit de onderste 50% van de daily zijn.

Wat mij namelijk opvalt is het sommige stampede teams tamelijk frustreerd (zeker in het begin wanneer er veel aanwas is) moeten toezien dat ze aan alle kanten voorbij worden gelopen in de daily.. maar mogen met lede ogen aanzien dat ze GEEN nieuwe leden mogen werven. Dit geldt ook wanneer teams erg dichtbij elkaar liggen (zoals de nummer 2,3,4 van dit jaar tot en met een dag of 15).

Fictief statistieken voorbeeldje: Stel dat stampede teams X en Y net op het lijntje zitten tussen mogen werven en niet (bv: plaats 3 en 4). Elke dag wordt de daily-stats bij de voorgaande overall stats geteld, en staat erbij wie er mag werven voor de volgende dag. Let vooral even op dag 6 als X nog mag werven voor dag 7 volgens de huidige regels, wat toch een wat on-aangenaam gevoel achterlaat voor team Y.

Based on overall
Dag 4 - Daily: X doet 500; Y doet 750 - Overall: X heeft 1500 punten; Y heeft 2000 punten - X mag werven
Dag 5 - Daily: X doet 700; Y doet 750 - Overall: X heeft 2200 punten; Y heeft 2750 punten - X mag werven
Dag 6 - Daily: X doet 1100; Y doet 750 - Overall: X heeft 3300 punten; Y heeft 3500 punten - X mag werven
Dag 7 - Daily: X doet 1400; Y doet 750 - Overall: X heeft 4700 punten; Y heeft 4250 punten - Y mag werven
Dag 8 - Daily: X doet 1400; Y doet 1000 - Overall: X heeft 6100 punten; Y heeft 5250 punten - Y mag werven

Based on Daily
Dag 4 - Daily: X doet 500; Y doet 750 - Overall: X heeft 1500 punten; Y heeft 2000 punten - X mag werven
Dag 5 - Daily: X doet 700; Y doet 750 - Overall: X heeft 2200 punten; Y heeft 2750 punten - X mag werven
Dag 6 - Daily: X doet 1100; Y doet 750 - Overall: X heeft 3300 punten; Y heeft 3500 punten - Y mag werven
Dag 7 - Daily: X doet 1100; Y doet 1000 - Overall: X heeft 4400 punten; Y heeft 4500 punten - Y mag werven
Dag 8 - Daily: X doet 1100; Y doet 1300 - Overall: X heeft 5500 punten; Y heeft 5800 punten - X mag werven

Het klinkt wellicht als een beetje gezeur/gezever, maar ik het in de afgelopen (Docking) als de vorige stampede (Malaria) ervaren dat het soms erg frustrerend is om niet te mogen werven omdat je overall te hoog is, maar je in de daily dik ingemaakt wordt.

[Paprika]

Daar zat ik ook mee (voelde het voor andere teams, waaronder jullie des tijds). Wij wonnen toch wel, maar de 2e plek had denk ik anders uitgezien als TDK niet een heel lange tijd nieuwe leden kreeg en daardoor een behoorlijke daily voorsprong kreeg. Overigens niets tegen TDK, maar het is wel een typisch voorbeeld.

Overigens was de activiteit dit jaar een stuk lager, waarschijnlijk doordat de 1e plek al zo vast stond (volgend jaar maar splitten of geen team voor mij als het dan weer lukt die ouput te krijgen)...

[ Voor 24% gewijzigd door Paprika op 02-05-2012 09:34 ]

[Cow_tipping]

De activiteit mocht dit jaar dan wel een stuk lager zijn in het stampedestats gedeelte, de output van DPC gedurende de hele maand was vrijwel continu zeer hoog.
Er waren jaren dat de output halverwege ook behoorlijk inzakte en dat was dit jaar gelukig niet het geval.

Vwb een GPU stampede:
ik zou het wel leuk vinden om een jaarlijkse CPU stampede in april te blijven houden, en het starten van een GPU stampede in oktober (een half jaar later).

[Verwijderd]

@Camulos: Het probleem wat je krijgt met jouw voorstel is dat mensen even een PC stoppen om te kunnen ronselen. Een team dat al ruim voor anderen staat, staakt even het werk voor een dagdeel, ronselt nieuwe leden en gaat daarna nog harder dan de rest.

Ik vraag me af of de DPC-crew deze draad wil gebruiken voor evaluatie of dat ze een nieuwe willen beginnen want ik heb nog wel het één en ander te zeggen.

[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