Credit Index die zweite [C.I.2] - Probleme/Fragen/Antworten

Es gibt glaub so viele Credits, weil die Applikation wohl die Festplatte recht stark auslastet. Ob das anders nicht besser zu implementieren ist weiß ich nicht.
 
Es laufen (einstellbar) 1-25 WUs gleichzeitig etwa 1:35 bis 1:50 (h:mm). immer paralell zu den anderen WUs die auf dem Rechner laufen. Pro WU gibts 12 Cr. Jede WU braucht momentan bis zu 67Mb Ram, ausserdem wird die Festplatte gefordert. Dies hat aber im Vergleich zu der letzten IMplementation der Anwendung stark nach gelassen. Auch die CPU-Belastung ist extrem zurück gegangen.
Auf einer Maschine mit 4 Gig Ram kann man je nach den anderen Anwendungen (also nicht gleichzeitig Lattice rechnen!) leicht 10-25 Aufgaben zusätzlich rechnen.
Erlaubt sind neben den physikalischen Rechnern auch pro physikalischem Rechner je ein virtueller. Also wer 3 Hosts auf dem Schreibtisch stehen hat, darf zusätzlich noch 3 virtuelle maschines laufen lassen. Ist aber bei dem Ram-Bedarf nicht so ohne.
 
Es laufen (einstellbar) 1-25 WUs gleichzeitig etwa 1:35 bis 1:50 (h:mm). immer paralell zu den anderen WUs die auf dem Rechner laufen. Pro WU gibts 12 Cr. Jede WU braucht momentan bis zu 67Mb Ram, ausserdem wird die Festplatte gefordert. Dies hat aber im Vergleich zu der letzten IMplementation der Anwendung stark nach gelassen. Auch die CPU-Belastung ist extrem zurück gegangen.
Auf einer Maschine mit 4 Gig Ram kann man je nach den anderen Anwendungen (also nicht gleichzeitig Lattice rechnen!) leicht 10-25 Aufgaben zusätzlich rechnen.
Erlaubt sind neben den physikalischen Rechnern auch pro physikalischem Rechner je ein virtueller. Also wer 3 Hosts auf dem Schreibtisch stehen hat, darf zusätzlich noch 3 virtuelle maschines laufen lassen. Ist aber bei dem Ram-Bedarf nicht so ohne.
ja schön und gut, aber mir erscheint die creditvergabe dennoch zu hoch (auch wenn das egal ist ;)), wenn ich 4 Lattice WUs auf einem Quad mit 1-2GB RAM laufen lasse, habe ich mehr Festplattenrattern (Swapping), bekomme aber deswegen nicht mehr (eher weniger, da swapping-pausen) credits...

Es gibt im boinc-system zwei zeiten, einmal die CPU-Zeit und dann wäre da noch die gesamt-laufzeit [welche auch die nicht - rechenintensive Zeit beinhaltet], wenn tobi beide zeiten angeben würde, könnte man es besser verrechnen.
 
jwenn ich 4 Lattice WUs auf einem Quad mit 1-2GB RAM laufen lasse, habe ich mehr Festplattenrattern (Swapping), bekomme aber deswegen nicht mehr (eher weniger, da swapping-pausen) credits...
Wer das tut ist selber schuld:P Festplattenmörder

Es gibt im boinc-system zwei zeiten, einmal die CPU-Zeit und dann wäre da noch die gesamt-laufzeit [welche auch die nicht - rechenintensive Zeit beinhaltet], wenn tobi beide zeiten angeben würde, könnte man es besser verrechnen.
Wie erwähnt, die Zeit soll eigentlich 90 Minuten betragen. Aus welchen Gründen dann daraus 110 werden sind mir nicht bekannt. Kann aber sein das Tobias das ohne Angabe von Gründen (Serverlast?) geändert hat.
 
Wer das tut ist selber schuld:P Festplattenmörder
Darum gehts ja nicht, es sollte ein Vergleich sein.

Wie erwähnt, die Zeit soll eigentlich 90 Minuten betragen. Aus welchen Gründen dann daraus 110 werden sind mir nicht bekannt. Kann aber sein das Tobias das ohne Angabe von Gründen (Serverlast?) geändert hat.
Von den 90 oder 110 Minuten sehe ich aber nichts.

wenn du dir das hier ansiehst: http://freehal.net/freehal_at_home/result.php?resultid=153660
stellst du fest das dort nur die Run-Time angegeben ist, welche in diesem Fall die CPU-Time ist. In der aktuellen Boinc-Server-Version wird zwischen Run-Time [komplette Laufzeit] und CPU-Time [Rechen-Zeit] unterschieden, was die Sache vereinfacht. Ohne dieser Angabe, kann man keine vernünftige Berechnung anstellen. Dann doch lieber FreeHal aus dem CI2 entfernen. (hat ja auch nix mit Rechencredits zu tun, da diese CPU-Unabhängig zustande kommen)
 
Zuletzt bearbeitet:
Die 90 Minuten kamen von Tobias. Irgendwo im Forum . Ich wär auch dafür FH aus dem CI zu löschen. Ist ja auch egal wieviel GHz oder Ram oder was auch immer man einsetzt um die WUs durchzukauen. Es dauert immer ca 90-120 Minuten und gibt 12 Cr.
 
Gibt es die Möglichkeit eingetragene Sachen im C.I.2 nachträglich zu ändern?
Hab mich vertippt :-X
 
nö, löschen und neuen Eintrag machen :)
 
Ich bitte mal ganz bescheiden darum für einen Rechner nicht ein halbes Dutzend Einträge bei einem Projekt zu machen. Wenn sich die Einheiten in der Creditvergabe unterscheiden, macht es Sinn für jede WU Art die durchschnittliche Laufzeit zu ermitteln und die dann einzutragen. Wenn die Creditvergabe nicht fest ist, wird es nochmal ein wenig aufwändiger.

Wenn aber jeder 7 Einträge des gleichen Rechners einstellt, wird das einfach nur unübersichtlich und hilft keinem. Wenn die eingetragenen "System Day Credits" mal eben um 40% variieren, wo dran sollen sich dann andere Cruncher orientieren?
 
Ich arbeite ja schon daran WUs von der gleichen Serie und Host zusammen zu fassen. Dann dürfte das nicht mehr optisch stören.
 
Wäre es dann nicht die bessere Lösung, einfach alle WUs eines Hosts zusammenzufassen? Das gibt vielleicht sogar nen brauchbaren Mittelwert.
 
nein. schau dir mal die aqua-einträge an. da liegen 2 Wu-Serien, bei gleichem host, um ca. 300% auseinander. oder wo es weniger schlimm aber dennoch bemerkbar wird: YoYo, Simap, Poem

zusammenfassen würde das bild nur verzerren und nicht der realität entsprechen, außer verschiedene WU-serien würden zeitgleich auftreten (wie bei Poem und Simap, bei YoYo kann man die WU-Reihe selektieren)
 
Zuletzt bearbeitet:
Hmm, vielleicht könntest du WU-Laufzeiten des gleichen Creditlevels errechnen? Ich lasse derzeit ein kleinen Skript laufen bei dem ich nur die Results-URL (+offset) eines System parse und mir die durchschnittliche Laufzeit und Credits ausliefern lasse. Dass lässt sich ja für fixe Credits einfach umsetzen, bzw. von dem Result auf den Host schließt du ja ohnehin schon...

Ist so nicht auf alle Projekte anzuwenden, das ist klar...
 
Hmm, vielleicht könntest du WU-Laufzeiten des gleichen Creditlevels errechnen? Ich lasse derzeit ein kleinen Skript laufen bei dem ich nur die Results-URL (+offset) eines System parse und mir die durchschnittliche Laufzeit und Credits ausliefern lasse. Dass lässt sich ja für fixe Credits einfach umsetzen, bzw. von dem Result auf den Host schließt du ja ohnehin schon...

Ist so nicht auf alle Projekte anzuwenden, das ist klar...
das is das problem, ich brauche etwas, was überall geht, wenn ich wieder bei jedem projekt hand anlegen muss, ist das von nachteil.

ich geb dir im laufe des tages einen link, bei dem du die sotierung beobachten kannst, vllt fällt dir ja noch was dazu ein :)
 
nein. schau dir mal die aqua-einträge an. da liegen 2 Wu-Serien, bei gleichem host, um ca. 300% auseinander. oder wo es weniger schlimm aber dennoch bemerkbar wird: YoYo, Simap, Poem

zusammenfassen würde das bild nur verzerren und nicht der realität entsprechen, außer verschiedene WU-serien würden zeitgleich auftreten (wie bei Poem und Simap, bei YoYo kann man die WU-Reihe selektieren)

Spaßeshalber habe ich mal den besten und schlechtesten Wert meines Q8200 bei Malariacontrol herausgesucht, die liegen (bedingt durch das Creditsystem) auch um 443% auseinander. So macht der C-Index meiner Meinung nach keinen Sinn, daher werde ich die bald wieder löschen

Die Eigenheiten von Aqua sind mit nicht vertraut, aber wie rechtfertigen die Betreiber sowas? Wird die CPU bei einer Serie so wenig gefordert und vor allem, wiederholen sich diese unterschiedlichen Serien? Wenn ja, macht das Zusammenfassen meiner Meinung nach wieder Sinn.

Aber wie wird der C-Index überhaupt von euch genutzt? Ich würde ihn mir zu Gemüte führen, wenn ich mal wieder AMD und Intel bei gleichem Takt bzw. gleichem OS vergleichen möchte und da macht ein brauchbarer Mittelwert meiner Meinung nach mehr Sinn.

Ich sehe aber auch den Vorteil, eine Berechnung auf alle Projekte anwenden zu können. Es ist sicher nicht leicht Lord of the Stats zu sein. ;D
 
Nun es macht eben nur Sinn verschiedene Systeme mittels gleicher WU-Serie zu vergleichen. Doch diese Erkenntnis ist jetzt nicht wirklich neu, oder?
 
Das heißt aber auch, dass der Credits Index für Projekte wie Malariacontrol weniger Sinn macht.
 
Das heißt aber auch, dass der Credits Index für Projekte wie Malariacontrol weniger Sinn macht.
Ich hab jetzt die genauen Daten von Malariacontrol nicht überprüft (was ich aber weiß, ist, das wir 7 verschiedene WU-Serien von MC im CI2 haben), aber wenn die Streuung so "breit" sein sollte muss man eben den Durchschnitt errechnen. Wenn ich an diesem Punkt mit der Auswertung angelangt bin, sprechen wir uns nochmal :). (es gibt afaik auch andere Projekte, wo das ähnlich schlimm ist).
 
Geht in Ordnung.
Eine letzte Bemerkung noch zu Mc und seinen WUs. Wenn sich das Schema nicht grundlegend geändert hat, dann kann man die WUs z.B. wu_677_509_258402_0_1260643456 wie folgt aufschlüsseln:
Die 677 steht für die "run number", die 509 für die ID des simulierten Szenarios, die 258402 für die ID des Parameter-Sets, die 0 ist irgendwas für nen Zufallszahlengenerator und die 1260643456 ist endlich eine einzelne WU-ID. Für mich stellt sich das so dar, dass Mc sehr viele verschiedene WU-Typen hat.
 
Zurück
Oben Unten