Mal wieder einen Beitrag zu den Systemen selbst:
Hat hier irgendjemand mal Prime95 (FFT 1024K) über längere Zeit laufen lassen? Oder Memtest86+?
Bei mir werden die RAMs unverschämt heiß. So heiß, daß bei diesen speziellen Belastungstests (bei Memtest86+ erst nach einer halben Stunde oder so) das Mainboard Alarm wegen Überhitzung schlägt. Nein, es ist bestimmt nicht die CPU und auch nicht der Chipsatz. Ich kann durch einfaches kurzes "Pusten" auf die RAMs den Alarm
sofort abschalten. *g*
Das Gehäuse ist sehr gut belüftet! Auslasslüfter: 135mm vom Netzteil, 120mm SX2 von Noiseblocker, 2x 80mm von Noiseblocker. Wenn man das Gehäuse öffnet, merkt man gleich, daß es keinen Wärmestau im Inneren gibt. Der Effekt tritt auch auf, wenn das Gehäuse ist und auf der Seite liegt. Es gibt keine Kabel die im Weg wären (alles schön aufgeräumt). Egal ob geschlossen oder offen: Die CPU erreicht mit Core-Damage, Prime95 und ähnlichen Tools (laut HW-Monitor) keine 60°C. Um genau zu sein: 56°C bis 57°C Maximum. Der thermische Alarm des Boards wird erst so bei rund 81°C (HW-Monitor Anzeige) auslgelöst. Die CPU ist es also garantiert nicht, was ja auch schon durch das Pusten und den einfachen "anfass-Test" bewiesen werden konnte, da man sich an den RAMs schon fast die Finger verbrennen kann in diesem Zustand.
Achja: Als Einlass habe ich einen weiteren 120mm SX2 Lüfter, der allerdings unterhalb der RAMs reinbläst und somit (zum Glück) ein wenig den Chipsatz kühlt und den Grakas etwas frische Luft zufächert.
Man merkt auch einen leichten Luftzug in der Nähe der RAMs, aber offenbar nicht ausreichend, bei extremer Dauerbelastung mit Prime95. Wenn man bei Prime95 aber keine großen FFT-Größen nimmt, sondern z.B. nur 8K, dann kühlt der Speicher auch schnell ab. Ebenso, wenn noch irgendetwas anderes die CPU belastet, so daß Prime95 nicht so extrem auf die RAMs einwirken kann. Es ist wohl wirklich ein Grenzbereich.
Wer es nachstellen Will:
Prime95 in der 64bit Version p64v259 (aktuellste Version laut
www.mersenne.org) Torture Test, Custom, für jeden Kern einen Thread (virtuelle Kerne mitzählen, also i.d.R. 8 pro CPU), und als FFT-Größe bei min und max 1024K eingeben.
Das dauert dann eine Weile... Nach ca 15min sollten die RAMs dann glühen.
Nun ist die Frage: Wer von euch hat ein Board, welches Thermo-Sensoren auf den RAMs überwachen kann und wer hat solche auf seinen RAMs? Ist die Überwachung auch im BIOS aktiviert?
Wenn ja, wie verhält es sich bei euch?
Falls keine Sensoren vorhanden sind: Wie fühlen sich eure RAMs an?
Liegt es vielleicht auch ein wenig an meinen Modulen? Die sind ja sogar doppelreihig mit Chips bestückt und haben nicht ohne Grund die Heat-Spreader montiert, die es laut Datenblatt in dieser Baureihe nur bei den 4GB und 8GB Modulen gibt. Die kleineren kommen noch ohne aus.
Fehler hatte ich
keine, weder bei memtest86+ noch bei Prime95, obwohl das Board bereits kurzzeitig Alarm schlug, bis ich eingegriffen habe. Das ist ja wohl auch der Sinn eines Alarms. Achja: Es reicht sogar schon, wenn man etwas Luft zufächert.
Irrwitziger Weise gibt es keine LOG-Einträge für einen solchen Alarm.
Wozu dann LOG-Files? Dafür, daß mir der Rechner bei jedem Boot reinschreibt: "Keine Tastatur gefunden", nur da ich von PS/2 auf USB gewechselt habe und das auch brav bei jedem Boot als Tastaur erkannt wird (und auch im BIOS funktioniert)? Soetwas regt mich dann schon ein wenig auf. Ein Board mit 3 Millionen Sensoren, Fehlerüberwachung, -erkennung und teiweise sogar -behebung, aber in den LOGs taucht irgendwie herzlich wenig davon auf.
Nochmals die Bitte: Wer seien RAMs mal mit Prime95 und 1024K FFTs stressen könnte und dann die Temperatur der RAMs nach ca 25 Minuten "beschreibt", würde mir schon einen Gefallen tun. Besser wäre es natürlich mit TS auf den Modulen und einem Board, das diese Infos ausliest.
-----------
Zusatzinfo für merkwürdiges Verhalten beim Boot des X8DAH+:
Bei Basteleien hatte ich es geschafft, wie auch immer, das BIOS dermaßen kaputt zu konfigurieren, daß bei jedem zweiten oder dritten Bootvorgang das optische Laufwerk am IDE-Port gar nicht mehr erkannt wurde. Eventuell hatte sich auch nur das BIOS "verschluckt", da ich die Positionen der Grakas wild getauscht habe. Da ich leider mehrere Dinge gleichzeitig machte, kann ich den Fehler beim besten Willen auf keine einzelne Tat eingrenzen. So oder so, war der Effekt sehr merkwürdig, da erstmal nicht reversibel. In Windows stand dann innerhalb der Systemsteuerung eine Fehlermeldung (Gelbes Dreieck mit Ausrufungszeichen, also ehr "Hinweis" als "Fehler"), daß dem IDE-Controller kein IRQ zugewiesen werden konnte. Alle sinnvollen Einstellungen habe ich im BIOS ausprobiert: Plug'n'Play OS aktiviert und deaktiviert, NVRAM löschen lassen, Grakas wieder so eingebaut wie zuvor, eine Graka ausgebaut, sonstige Einstellungen im BIOS wieder auf standard-Werte zurückgedreht, etc, etc. Nichts half.
Manchmal war es beim Booten sogar so, daß ein Bluescreen erschien (sinngemäß: Ein Gerät funktioniert nicht mehr, der Rechner wurde angehalten, um Schaden zu vermeiden). Im Errorlog des BIOS stand dann etwas von einem Fehler im PCI oder PCIexpress Bus, der behoben werden konnte.
Alle erdenklichen Einstellungen im BIOS haben nicht geholfen, um dieses Problem zu beseitigen. Irgendwann hatte ich die Faxen dicke und habe einfach "Load optimal defaults" gewählt und Grundeinstellungen vorgenommen, die nötig waren:
Problem gelöst!
Danach wieder alles (nach und nach) so eingestellt wie vorher: Es läuft alles fehlerfrei. Auch die Einstellungen, die ich zuletzt vor dem Auftreten des Fehlers verstellt hatte (ECC Background scrubbing, Open Loop Throtteling, Closed Loop Throtteling, Link States,...) sind alle wieder so, wie ich es für "optimal" halte. Was auch immer es verursachte, es ist verschwunden.
Wer etwas ähnliches erleben sollte, der möge sich die Zeit doch bitte sparen und gleich im BIOS einmal die "optimal Defaults" laden und den Rechner danach neu starten. Irgendwie hat es bei mir Wunder bewirkt und ich habe nicht den blassesten Schimmer, was sich prinzipiell verändert hat. Außerdem hat "load Optimal defaults" einige Einstellungen garantiert nicht zurückgesetzt, die ich vorher manuell eingestellt hatte, was ich zwar auch verwunderlich fand, aber da das Board wohl teilweise eh nicht auf den "Defailt"-Werten war, zumindest nicht auf denen, die im Handbuch stehen, kann ich dazu auch nicht allzuviel sagen.
Nun habe ich sogar vor der Installation von Server 2008 R2 gleich auf ACPI v3 gestellt und auch die Velociraptor gleich im AHCI-Modus laufen lassen. Kein Treiber war nötig, Server 2008 R2 Standard läuft auf dem System perfekt.
Server 2008 Standard (ohne R2 aber ebenfalls 64bit) war irgendwie nicht so toll. Auf meinem dual-CPU Opteron läuft es wunderbar seit Monaten. Auf dem Xeon wollte es nicht so recht und "ruckelte" irgendwie.
Nur der NVidia-Treiber schreibt manchmal in die LOG-Dateien, daß er sich in einem unbekannten Status befindet. (Genauer:
Der Dienst "NVIDIA Display Driver Service" hat einen ungültigen aktuellen Status gemeldet: 32) Allerdings gibt es noch keine Server 2008 R2 Treiber von NVidia, weshalb ich die Desktop-Treiber verwende, die auch für Win7 gedacht sind. Etwas googlen zeigt aber, daß auch Win7-User den Fehler kennen.
Dann bin ich mal auf Antworten gespannt und hau' mich nun auf's Ohr.
