PdM - Internes Race

Meinst du nich, dass man auch eine noch kleinere Renn-Klasse anbieten sollte? wir haben sehr viele Leute, die im Leben nich an 2,5k rankommen...

Sehe ich ähnlich.

Steht denn überhaupt fest bei welchem Projekt das interne Race stattfinden soll?
Oder ist es wieder an das PDM geknüpft?

Fände Riesel Sieve momentan recht gut. ;D
 
Meinst du nich, dass man auch eine noch kleinere Renn-Klasse anbieten sollte? wir haben sehr viele Leute, die im Leben nich an 2,5k rankommen...

I know, wir haben aber auch viele leute die meinten sich mit einem Rac von 0,5 melden zu müssen und im Race auf einmal das 4fache hatten :] - sumasumarum haben wir ein Gleichgewicht.
(Anmerkung: Die 2.5K sollten für Einstein leicht zu machen sein, ein X2@2.4GHz schafft locker 1K-1.5K, (ein Core2Duo >3GHz wird locker um die 2-3K machen) die meisten haben im Race 2 PCs zur Verfügung, dann sollten im Mittel die 2.5K locker drinnen sein)
.
EDIT :
.

Sehe ich ähnlich.

Steht denn überhaupt fest bei welchem Projekt das interne Race stattfinden soll?
Oder ist es wieder an das PDM geknüpft?

Fände Riesel Sieve momentan recht gut. ;D

Ja ans PdM geknüpft, das ist eine der Regeln ;)
 
Ich möchte noch mal was zu den "Steigerungsraten" beim output wärend des race sagen. Wir haben sehr unterschiedliche cruncher.
Das ist an sich nichts schlimmes. Es lebe die Vielfalt. ;D
Das macht es aber schwer, die wahre Stärke abzuschätzen.

Wer sonst seine(n) Rechner an 7 Stunden 5 Tage in der Woche crunchen lässt, erreicht nur durch 24/7 Betrieb fast eine Verfünffachung seines outputs.

Wenn die Rechner dagegen eh schon 24/7 Betrieb machen, ist gar keine Steigerung drin.
Am besten wäre es das für die neuen Teams etwas durchzumischen. ;D
 
richtig, das ist das problem. Am besten wäre es wenn jeder ausnahmslos ehrlich ist ;D

Für unsere alt bekannten Teilnehmer gibt es aber keine Ausflüchte mehr, denn wir haben schwarz auf weiß den jeweils möglichen Race-Output in der Stats-DB hinterlegt :P
Allerdings ist dieser Output mit einem unterdurchschnittlichen Projekt zustande gekommen und das evtl zukünftige PdM hat einen überdurchschnittlichen Output, daher wäre da ein Korrekturfaktor von geschätzten ~2 (muss ich noch genau ermitteln) nötig.
 
'Mich mal einhak'

Mir kommt da gerade 'ne Idee:

Wie wäre es mit 'nem 'Staffellauf', ungefähr so aufbaut (muss nicht wirklich so sein)

1. Spinhenge bis 200.000
2. QMC bis 200.000
3. Einstein bis 200.000

Oder so ähnlich.

Gruß Gunslinger
 
@gunslinger:

Die zugrunde liegende Idee des internen race war es, das Projekt des Monats (PdM) etwas aufzupeppen. ;D
Wenn wir parallel zum PdM noch ein race starten, nimmt am PdM gar keiner mehr teil. ;)
Beim ersten internen race konnte man gut sehen, wie toll das gewirkt hat.
 
richtig, das ist das problem. Am besten wäre es wenn jeder ausnahmslos ehrlich ist ;D

Für unsere alt bekannten Teilnehmer gibt es aber keine Ausflüchte mehr, denn wir haben schwarz auf weiß den jeweils möglichen Race-Output in der Stats-DB hinterlegt :P
Allerdings ist dieser Output mit einem unterdurchschnittlichen Projekt zustande gekommen und das evtl zukünftige PdM hat einen überdurchschnittlichen Output, daher wäre da ein Korrekturfaktor von geschätzten ~2 (muss ich noch genau ermitteln) nötig.
Ui, ui, ui, das mit dem Korrekturfaktor kann aber schwierig werden. Nachdem was ich gehört habe, läuft Einstein ja auf Intel erheblich besser als AMD. Da wäre Faktor 2 für meinen (fast) ausschließlich aus A64 bzw. X2 bestehenden Fuhrpark wahrscheinlich deutlich übertrieben.
Allgemein bin ich aber auch für eine Durchmischung der Teams (nicht, daß die Fischköppe schon wieder gewinnen :]) und auch eine kürzere Laufzeit. Im Moment kann ich zum Beispiel meinen Output in einem Monat schwer abschätzen.
 
Die zugrunde liegende Idee des internen race war es, das Projekt des Monats (PdM) etwas aufzupeppen. ;D
Wenn wir parallel zum PdM noch ein race starten, nimmt am PdM gar keiner mehr teil. ;)
Beim ersten internen race konnte man gut sehen, wie toll das gewirkt hat.

Ich denke auch, wir sollten das KtM-Race weiter am PdM gebunden lassen.

Zu viele verschiedene Veranstaltungen verderben die crunchchips ;D

Eine Verkleinerung der Teams auf Basis der Daten vom letzten Race find ich sinnvoll und eine Verkürzung der Veranstaltung findet ebenfalls meine Zustimmung.
 
mit einem Race zu den 666.666 wäre ich auh dabei. Mir würde es auch am liebsten sein wenn wir das nicht vor dem 10. machen, da bis dahin warscheinlich wieder simap ansteht.

gruß

cumec
 
Die Idee, diesmal nur zwei Teams zu haben, halte ich für sehr gut.
Dann können sich die schweren Jungs zusammen tun und der Rest sieht zu, dass er den Großen mal zeigt, wie ein Zwergenaufstand funktioniert.

Vielleicht könnte man diesmal auch eine Woche vorher eine Newsmeldung schalten, die zur Teilnahme einlädt (nicht auffordert).
 
Ok dann fassen wir mal zusammen:

1. Interes Race: Ja, es besteht offensichtlich genügend Interesse.
2. Die Dauer sollte auf 10 bis max. 14 Tage begrenzt sein
3. Der Starttermin sollte nicht vor dem 10. sein.
4. Es gibt nur einen Ort für das Race -> PdM
5. Ziel soll eine magische Marke ale 666.666,66 sein (sollten wir uns später auswürfeln, abhängig von Teamgrößen/Outputs und max. Zeitdauer)

6. Output der bisherigen bekannten Teilnehmer richtet sich nach dem letzten KtM. Neue Teilnehmer werden in Outputklassen eingestuft [2k, 5k, 7.5K, 10K, 15K, 20K, 30K, 45K]
(diese Regel bräuchte man nur, wenn wir das KtM mit mehr als 2 Teams durchführen)

was noch zu klären gilt:

1. viele kleine Teams?
2. nur zwei Teams: Big vs. many small?
3. externe zugelassen?


EDIT: Ich erstelle einen neuen Thread - damit wir diesen nicht weiter mißbrauchen müssen *g*
 
bei mir bitte daran denken: ich bin ohne arach unterwegs.

schau dir mal meinen output an:

http://de.boincstats.com/search/all_projects.php?cpid=5d87b92e3fcfd78203bfe69a10abaed1

der rac setzt sich dadurch zusammen, dass ich bei poem am freitag die 30k von dem anderen konto gutgeschrieben bekommen habe, was beim letzten race ja nicht passieren durfte.

im moment rechne ich nur rosetta und malariacontrol.

bei poem rechnet zwar der eine oder andere singlecore von freunden für mich, die werden zum internen race aber auch nicht switchen. )((
 
wäre auch für groß gegen klein.. da kann man dann ja notfalls einfach noch den größten der kleinen oder den kleinsten der großen ins jeweils andere team switchen um das etwas auszuwiegen.

Sicher mal interesant zu sehen wie der Fliegenschwarm den Elefanten erlegt oder umgekehrt ;-)
 
Kleiner Tip an Twodee:
Man kann die Daten vom Poemrace etwa x2,5 nehmen. Das gilt aber wiederum nur für die denn SSE optimierten client. Hatte zb bei Poem etwa 8k und komme bei Einstein hochgerechnet auf ~20k . Der optimierte client funktioniert ausnahmslos mit allen SSE fähigen CPU´s, auch die Älteren.

Nochn Tip:
Beim installieren des neuen clients 4.36 sollte man unbedingt vorher keine EinsteinWU´s runterladen, weil die sonst wieder mit der 4.26 laufen wollen.
 
Kleiner Tip an Twodee:
Man kann die Daten vom Poemrace etwa x2,5 nehmen. Das gilt aber wiederum nur für die denn SSE optimierten client. Hatte zb bei Poem etwa 8k und komme bei Einstein hochgerechnet auf ~20k . Der optimierte client funktioniert ausnahmslos mit allen SSE fähigen CPU´s, auch die Älteren.

Nochn Tip:
Beim installieren des neuen clients 4.36 sollte man unbedingt vorher keine EinsteinWU´s runterladen, weil die sonst wieder mit der 4.26 laufen wollen.

Haben wir shcon nachgerechnet.
für AMD user muss der Faktor unter 2 liegen, für Intel User über 2.

Das mit den 4.36 Tausch hängt nicht von den WUs ab sondern davon ob Boinc läuft und die appinfo xmldatei gerade verwendet wird. hält man boinc an, überschreibt den client mit der 436er dann rechnet er die WU mit dem neuen client weiter, zugleich löscht er den alten client. So war das bei allen meinen Maschinen. ;)
 
Haben wir shcon nachgerechnet.
für AMD user muss der Faktor unter 2 liegen, für Intel User über 2.

Das mit den 4.36 Tausch hängt nicht von den WUs ab sondern davon ob Boinc läuft und die appinfo xmldatei gerade verwendet wird. hält man boinc an, überschreibt den client mit der 436er dann rechnet er die WU mit dem neuen client weiter, zugleich löscht er den alten client. So war das bei allen meinen Maschinen. ;)

Bei mir eben nicht!
Schon komisch*suspect*
Hatte boinc beendet und den neuen client rein, alten gelöscht, Boinc gestartet und er hat munter mit dem alten wieder weiter gemacht. Wu`s gelöscht, neue geladen und siehe da es ging. Sehr seltsam.
 
Bei mir eben nicht!
Schon komisch*suspect*
Hatte boinc beendet und den neuen client rein, alten gelöscht, Boinc gestartet und er hat munter mit dem alten wieder weiter gemacht. Wu`s gelöscht, neue geladen und siehe da es ging. Sehr seltsam.

aber das hatten wir doch schon öfters bei boinc, es verhält sich bei jeweiligen nutzern unterschiedlich, aber auf den systemen pro nutzer dann gleich ;D - muss dann am user liegen ;D

ich habe boinc überall als service laufen, mein vorgehen war dann so
1. service stoppen: "net stop boinc"
2. neuen client + app xml-datei reinkopieren (nix löschen
3. service starten: "net start boinc"
4. guggen, der alte client verschwindet dann von selbst

die results-logs protokollieren sogar den wechsel des clients ;), wennde drauf bestehst dann such ich die raus, sofern die noch nicht gelöscht wurden.
 
aber das hatten wir doch schon öfters bei boinc, es verhält sich bei jeweiligen nutzern unterschiedlich, aber auf den systemen pro nutzer dann gleich ;D - muss dann am user liegen ;D

ich habe boinc überall als service laufen, mein vorgehen war dann so
1. service stoppen: "net stop boinc"
2. neuen client + app xml-datei reinkopieren (nix löschen
3. service starten: "net start boinc"
4. guggen, der alte client verschwindet dann von selbst

die results-logs protokollieren sogar den wechsel des clients ;), wennde drauf bestehst dann such ich die raus, sofern die noch nicht gelöscht wurden.

Ne lass mal, scheinbar bin ich echt zu blöd;D
Ich bekomme auch mit dem 64bit client keine cosmo WU`s. Schon alles probiert, keine chance.
 
Zurück
Oben Unten