DerDarius schrieb:
Sollte ich vielleicht doch lieber zum i7 greifen oder ist da ein Xeon schon sinnvoller?
Bei der Anwendung würde ich ECC-RAM (natürlich mit passender Plattform, sonst hängen die Pins nutzlos in der Luft) und damit einen Xeon als Pflicht ansehen, denn die Ergebnisse sollen ja stimmen und ohne ECC-RAM weiß man das nie, weil man nie mitbekommt, wann ein Bit im Speicher kippt, allenfalls am Ergebnis. Das sind normalerweise eben Abstürze oder noch häufiger korrupte Dateien. Bei solchen Simulationen wäre es schwer Fehler zu erkennen die von RAM Fehlern kommen, außer man lässt sie mehrfach mit den gleichen Parametern laufen um die Ergebnisse zu vergleichen.
DerDarius schrieb:
die Anweisung war, "so groß wie nötig so günstig wie möglich" zumal wir davon ein paar bestellen werden...
Wieso ein paar davon? Sollen die alle zusammen an den gleichen Problemen arbeiten? Je nachdem wie SW ist, wie gut sie also über die Kerne skaliert, wäre es ggf. sinnvoller weniger aber dafür leistungsstärkere CPUs zu kaufen, denn neben der CPU kostet bei jedem Rechner auch das Board, das Netzteil, das Gehäuse, die Platte etc. Geld und bei großen Rechnern kostet das zwar auch und pro Stück mehr Geld, im Ganzen bekommt man aber mehr Rechenleistung für gleiche Geld und meist eine zuverlässiger arbeitende HW. Denn das ist auch ein Punkt, kein Rechner ist 100%ig ausfallsicher und wenn man viele Rechner hat, hat man öfter damit zu kämpfen als wenn es wenig sind. Außerdem ist die teure Enterprise-HW auch einen viel mehr auf stabilen Betrieb ausgelegt als einfach Consumer HW und selbst bei den Xeon X5 gibt es gegenüber den Xeon E3 deutliche Unterschiede bzgl. der RAS Feature.
DerDarius schrieb:
Ja, ist auf mehrere Kerne optimiert, momentan auf 4, weil wir immer mit 4 kernen gearbeitet haben
Die wäre aber auch auf mehr Kerne optimierbar? Braucht die SW eine Graphikausgabe?
DerDarius schrieb:
Ich habe bei ECC Speicher verstanden, dass diese nicht anfällig für bestimmte Fehler sind.
Auch da gibt es aber Unterschiede, die kleinen Xeon E3 haben nur die einfachste Form einer ECC, die kann nur Singlebit Fehler korrigieren, aber Multibitfehler nur erkennen. Wenn so ein Multibitfehler passiert, dann muss das Board und das OS darauf reagieren können, wenn man Probleme wie falsche Ergebnisse vermeiden will, i.d.R. wird man eine Kernel Panik auslösen, dann steht die Kisten, gibt aber keine verfälschten Daten weiter.
Es geht ja auch neben dem RAM noch weiter, die Enterprise Plattformen haben z.B. andere Netzwerkadapter bei denen sind die internen Puffer auch durch ECC geschützt:
Bei Netzwerkkarten sind aber gekippte Bits im Puffer meist weniger dramatisch, da sichert ja i.d.R. das übergeordnete Protokoll noch einmal gegen Fehler ab, trotzdem werden auch hier die Inhalten bei den besseren, neueren Modellen gegen gekippte Bits geschützt.
DerDarius schrieb:
Es sollte wirklich in einer mehrtätigen Simulation passieren, dass die Rechner abschmieren...wäre zu ärgerlich, deswegen ja ECC Speicher ist gut, wenn es hilft...
Abschmieren wäre wohl weniger das Problem als unerkannte Fehler in der Berechnung, denn so ein gekipptes Bit im RAM kann immer passieren, durch richtige Fehler des DRAM Chips, die sogenannten hard-errors und auch durch alle Arten von Strahlung, die es ja immer und überall gibt und die man nicht vermeiden kann, die soft-errors und die findet auch kein Memtest, da bei den RAM-Tests die Daten geschrieben und sehr bald danach wieder gelesen werden. Bei der Simulation dürften die Daten zwischen dem schreiben und dem erneuten Lesen aber auch schon mal länger im RAM stehen und damit einer höheren Wahrscheinlichkeit ausgesetzt sein, dass ein Bit kippt. Dann hat man irgendwo 10 hingeschrieben und liest aber dann 30 aus und hat ohne ECC-RAM eben keine Chance zu wissen, dass dort 10 hätte stehen müssen.
