Auf die Barrikaden!

[laguna]

Ziehen wir also die Windoof Kisten von SIMAP ab und setzten sie dort ein, wo sie bessere Leistung bringen?

[Uwe Sänger Herzke]

Ziehen wir also die Windoof Kisten von SIMAP ab und setzten sie dort ein, wo sie bessere Leistung bringen?

Wär 'ne überlegenswerte Aktion. Das hängt von den Interessen der Cruncher ab.
Wer primär für Credits rechnet, und das konkrete Projekt eher egal ist, der kann ja für Rosetta, WCG, Predictor (wenn sie wieder da sind), Malaria oder anderen medizinischen Projekten rechnen, wo seine Rechenleistung besser ausgenutzt wird.
Wer das Projekt selber gut findet, der sollte natürlich weiter rechen, egal was für Credits 'rüberwachsen, er macht zwar weniger, aber trotzdem was wichtiges.
Und natürlich geht auch alles dazwischen, d.h. Reduzierung des Ressourcenanteils für SIMAP auf das persönlich für richtig befundene.

Für eure Taskforce würd' ich allerdings von Windoof abraten, die Maschinen sind momentan zu ineffizient.

Alternativ gibt's für die versierten Programmierer natürlich noch die Möglichkeit sich in die Entwicklung einer optimierten Windoofanwendung einzuklinken, ob und wie das geht, da hab' ich aber keine Ahnung.

[aalerich]

OK, Du rechnest auf Deiner Windows-Maschine eine WU in - sagen wir mal - 40 Minuten durch. Ich rechne meine - Mac Mini, OSX - in 15 Minuten durch . Beide haben wir die gleiche Arbeit abgeliefert, beide bekommen gleiche Credits. Wo liegt das Problem?

Das Problem ist, daß wir beide die gleiche Rechenleistung zur Verfügung stellen, den gleichen Strom bezahlen. Und das Problem ist auch nicht vergleichbar der Situation der Linuxer unter BOINC. Denn mit Windows wird bei SIMAP effektiv weniger gerechnet während die Linuxer bei anderen Projekten gleiche Leistung erbringen, aber weniger Punkte bekommen. Linux erbringt bei SIMAP einen drastisch höheren wissenschaftlichen Nutzen als Windows, das ist das Problem. Die Kreditierung ist schon gerecht, "gleicher Lohn für gleiche Arbeit". Nur sind es die Projektbetreiber, die, um an Sängers Bild anzuknüpfen, gleichen Autos unterschiedliche Straßen zuweisen. Linux auf den Nürburgring, Windoofs auf den Feldweg. Und das Ergebnis ist, daß der Linux-Trabbi genauso schnell ist wie der Windows-Ferrari. Nur hat der Ferrari natürlich erheblich mehr Sprit verbraucht denn er ist ja genauso durchgehend mit Vollgas gefahren. Mal ganz abgesehen davon, was der Ferrari dem Projekt hätte bringen können, so er denn eine vernünftige Straße hätte benutzen dürfen.

Ist nicht mein Problem ... auch sicher nicht Dein Problem...

Richtig, das ist ein Problem der Projektbetreiber.

Ganz generell sage ich mal: Ich glaube nicht, daß das böse Absicht ist. Die Programmierer dort werden sich halt einfach mit Linux besser auskennen und deshalb aus Linux mehr herausholen können als aus Windoofs. Und es wäre ja dämlich, das nicht zu nutzen. Andererseits entsteht durch diesen erheblichen Vorteil zwangsläufig das Problem mit den Krediten. Die Folge wird sein, daß massiv Windowskisten vom Projekt abgezogen werden. Allerdings halte ich das auch nicht für tragisch; wenn ich das halbwegs richtig verstanden habe ist es relativ egal ob das Projekt nun dieses oder nächstes oder erst in drei Jahren durchgerechnet ist.

Mit freundlichen Grüßen
aalerich

[SpeedKing]

Die Programmierer dort werden sich halt einfach mit Linux besser auskennen und deshalb aus Linux mehr herausholen können als aus Windoofs.

Faktor 4 durch besser auskennen herausholen? Und das, wo der Windows-Client ca. 1% der Zeit Systemfunktionen benutzt? Na wirklich nicht.
Es schaut eher so aus, als wäre der Windows-Client ohne SSE compiliert. Die müssten halt mal die Doku vom Windows Compiler lesen und die richtigen Schalter setzen. Aber - und das hätte ich ja fast schon vergessen - wir müssen ja dankbar sein, daß wir überhaupt für die rechnen dürfen.

[Uwe Sänger Herzke]

Es schaut eher so aus, als wäre der Windows-Client ohne SSE compiliert. Die müssten halt mal die Doku vom Windows Compiler lesen und die richtigen Schalter setzen. Aber - und das hätte ich ja fast schon vergessen - wir müssen ja dankbar sein, daß wir überhaupt für die rechnen dürfen.

Ist der entsprechende Compiler propriätär oder Open Source?
Ich hab, wie gesagt, nur wenig Ahnung außer vom Hörensagen, aber afaik gab's bei Seti z.B. Probleme, den korrekten Compiler legal zu bekommen, weshalb dann ja die optimierten Anwendungen aus der Community kamen und kommen.

[huraxprax]

Jetzt jammert nicht alle gleich so rum. HMMER ist erst einige Tage in Betrieb, da ist klar dass noch nicht alles reibungsfrei laeuft und optimiert ist.

Zu den Credits: die Benchmarks von Boinc sind nicht aussagekraeftig und ausserdem beliebig manipulierbar. Feste credits pro WU sind dagegen fair, ausserdem ist das was wirklich zaehlt die geleistete Arbeit und nicht die zur Verfuegung gestellte Zeit, sonst muesste ein 486 gleich viel bekommen wie ein Core Duo.

Und wer in der Lage ist ein DC-Programm runterzuladen und zum Laufen zu bringen kann nicht zu dumm sein ein SuSE oder Ubuntu zu installieren, ob er das will ist eine andere Sache, ich kann es persoenlich aber empfehlen, unabhaengig von SIMAP.

Benno

[Michael H.W. Weber]

Genau: Es zählt die Zahl abgelieferter Ergebnisse. Wie und womit das geleistet wurde, bei welchem Stromverbrauch auch immer, darf da keine Rolle spielen.

Michael.

[Uwe Sänger Herzke]

Genau: Es zählt die Zahl abgelieferter Ergebnisse. Wie und womit das geleistet wurde, bei welchem Stromverbrauch auch immer, darf da keine Rolle spielen.

Na ja, das "darf" find ich ein wenig hart. Imho wär's genausogut vertretbar die zur Verfügung gestellte Rechenleistung, unabhängig von deren tatsächlicher Ausnutzung zu "vergüten", d.h. schlechte Programmierung/Compilierung wäre ein Problem des Projekts, nicht des Benutzers.
Aber angesichts der wie erwähnt äußerst manipulationsfreundlichen Bewertung des Rechners auf der Benutzerseite ist die jetzt eingeschlagene Richtung die bessere.

Kurz:
Die "Methode Benchmark" ist gut für Besitzer generell leistungsstarker Rechner, und "bestraft" diese nicht für ungenügend angepasste/optimierte Anwendungen seitens des Projekts. Sie ist allerdings leicht zu manipulieren.
Die "Methode geleistete Arbeit" ist gut für Besitzer optimal zum Projekt passender Rechner, und sie ist sehr wenig manipulierbar. Sie gibt allerdings High-End-Maschinen mit der "falschen" Architektur weniger Lohn als alten Rechnern, die passen.

Beides ist gut und richtig, leider geht vermutlich nicht beides gleichzeitig. Ich bevorzuge die "Methode geleistete Arbeit".

[SpeedKing]

Ist der entsprechende Compiler propriätär oder Open Source?

Der gcc, den ich installiert habe, ist nicht der neueste, unterstützt aber bereits alles bis zumindest SSE2.

[Michael H.W. Weber]

Ich bleibe dabei: Die beste Vergütungsmethode ist ein fester Punktewert pro abgelieferter WU gleichen Rechenaufwands. Problem: Manche WUs sind nicht deterministisch, d.h. konvergieren ggf. nicht - z.B. Nano-Hive@home. Da müßte dann ein alternativer Weg beschritten werden.

Michael.

[Uwe Sänger Herzke]

Ich bleibe dabei: Die beste Vergütungsmethode ist ein fester Punktewert pro abgelieferter WU gleichen Rechenaufwands. Problem: Manche WUs sind nicht deterministisch, d.h. konvergieren ggf. nicht - z.B. Nano-Hive@home. Da müßte dann ein alternativer Weg beschritten werden.

So wie bei Seti, mit dem Flop-Zähler? Da wird ja auch immer verschieden lang berechnet.
Eigentlich müsste das auch für LHC gehen, die sind afaik auch nicht optimiert, da sie sonst zu ungenau sind.
Und was macht Einstein eigentlich genau? Die haben ja auch von der Benchmark Abstand genommen.

[Michael H.W. Weber]

So wie bei Seti, mit dem Flop-Zähler?

Kenne kein SETI.

Michael.