Problem mit Supermicro X9DRi-F

Kullberg

Kullberg

Computer Schach Freak
Thread Starter
Mitglied seit
18.02.2005
Beiträge
5.916
Ich hab mir o.g. Board zugelegt, bestückt mit meinen beiden E5-2680 und 8 x 4 GB reg. ECC 1600er, eingebaut in ein SuperChassis 825TQ-R720LPB. So schön, so gut. Dann hab ich versucht XP x64 mit AHCI zu installieren - geht nicht, die mitgelieferten Treiber erkennen den Controller nicht. Dann hab ich es ohne AHCI versucht - das geht, ist aber nicht optimal. Dann hab ich Windows 7 mit AHCI installiert - probehalber. Geht auch. Aber XP x64 muss doch auch gehen - also hab ich das BIOS neu geflasht. Hat nichts gebracht, ausser dass jetzt beim Versuch der Installation von XP x64 ein BSOD kommt. Windows 7 läuft aber. Das AHCI Problem scheint anderweitig lösbar: es geht wohl der Treiber für ICH10R.
Am liebsten würde ich das alte BIOS wieder draufmachen - aber das hab ich dummerweise nicht gespeichert. Hat jemand ne Bezugsquelle dafür?

p.s. im BIOS hab ich keinerlei Informationen zu CPU Temperatur, Lüfterdrehzahl... gefunden und SuperDoctor III zeigt nur Unsinn an.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Windows Server 2003 steht drin, das ist praktisch das Gleiche.
Und bei Deinem Link gibt es leider nur das neueste BIOS - nicht das Vorherige.
 
Ich hatte ja XP x64 schon laufen, aber nur ohne AHCI. Nur nach dem BIOS Update funktioniert es nicht mehr. Und ich muss XP x64 verwenden, sonst kann ich den Rechner nicht von nem anderen Rechner mit XP x64 drauf per powershell remoting fernsteuern.
 
p.s. im BIOS hab ich keinerlei Informationen zu CPU Temperatur, Lüfterdrehzahl... gefunden und SuperDoctor III zeigt nur Unsinn an.
Zum Vergrößern anklicken....

Jao, die werden im BIOS nicht angezeigt. Während meines Tests mit W2K8 R2 lief der SuperDoctor zwar problemlos, aber so wirklich brauchbar fand ich die Ergebnisse nun nicht. Die CPU Temps und Drehzahlen wedern ansonsten nur im IPMI angezeigt, wobei es da bei den CPU Temps keine Gradzahlen gibt sondern nur "low", "medium" und "hot" -.-

Wegen XP: Installier das mal ohne ACHI und wenn es dann läuft, spiel die Treiber auf und stell es im BIOS wieder auf AHCI um. Mit den passenden Treibern sollte deine XP Installation dann auch ohne Bluescreen booten
 
Problem: seit dem BIOS Update kann ich XP x64 überhaupt nicht mehr installieren :(
 
Komisch. Also zumindest im IDE Modus sollte die Installation ja laufen. Was bekommst du denn für nen Fehler? Gehst du über die normalen SATA Ports oder die der SCU?
Ich hab bei mir halt nur W2K8 ausprobiert, da mit für 2003 oder XP einfach die Disketten für die Treiber fehlen und auf ne selbst gebastelte CD hatte ich keine Lust...

Btw: Ist ja schon irgendwie komisch, dass dein Board noch ne alte BIOS Version drauf hatte, obwohl du es (vermutlich) nach meinem gekauft hast und das BIOS ja noch vom Februar ist...
 
SCU ist abgeschaltet. Es kann aber sein, dass das Board ne Macke hat - wenn man im BIOS AHCI umschaltet, startet es danach oft erst, wenn man den Rechner aus- und wieder eingeschaltet hat. Der BSOD ist immer gleich: eine Adresse angegeben und sonst keine weiteren brauchbaren Informationen. Ist immer die gleiche Adresse.
 
Und dein RAM ist auch in Ordnung? Nicht das der da irgendwo ne Macke hat, wenn dein Bluescreen immer auf die selbe Speicheradresse zeigt. Die umschalterei zwischen IDE Mode und AHCI hab ich ehrlich gesagt noch nicht ausprobiert (und hab grad auch keine Lust deswegen den ganzen Host zu vMotion)
Hast du denn ne Möglichkeit das ganze testweise mal mit W2K3 zu testen? Das wird immerhin seitens Supermicro noch supportet und wenn du das Problem damit immer noch hast, kannste dem SM SUpport ja mal deswegen ein Ohr abkauen ;)
 
Hab nochmal alles neu geflasht - mit allen Optionen. Jetzt verhält er sich wieder wie am Anfang: ich kann XP x64 wieder installieren, aber der AHCI Controller wird nicht vom Treiber erkannt - und wenn AHCI eingeschaltet ist, gibt es den Crash.
Glücklicherweise hab ich ja noch den anderen Rechner mit dem Asus Board. Bei dem installier ich jetzt XP x64 mit AHCI - was problemlos geht. Ich werde dann mal die SSD clonen und in den Rechner mit dem Supermicro Board einbauen.

Übrigens: Irrtum meinerseits - der Treiber für ICH10 geht nicht, es geht nur der C600er.

p.s. Speicher hatte ich schon gecheckt ;)
 
Danke für diesen besonders intelligenten und hilfreichen Kommentar.
 
Powershell 2.0 - ältere Versionen haben kein remoting.

p.s. Ich hab es eben nochmal probiert, mit nem XP x64 Rechner in nen W7 Rechner zu remoten. Jetzt (mit service pack 1) geht es :)
Ohne SP1 ging es nicht. Seltsam, aber sehr erfreulich. Zwar hat Windows 7 bei meinen Anwendungen keinerlei Vorteile, aber XP x64 Lizenzen zu kriegen wird immer schwieriger.
 
Zuletzt bearbeitet:
Windows Remote Shell scheint auf den gleichen Prinzipien zu basieren wie powershell remoting (WinRM) - nur dass ich mit powershell scripts laufen lassen kann. Meine scripts steuern vollautomatisch den gesamten Cluster. SSH geht dafür nicht. SSH hab ich zur Datenübertragung eingesetzt. Das hab ich aber inzwischen durch ein selbstgeschriebenes Server / Client tool (C++) ersetzt. Nächster Schritt wird sein, auch die Steuerung des Clusters über dieses Tool zu erledigen.
Und: Hardwareunterstützung ist (fast) egal. Die Rechner müssen rechnen und sonst nichts - kein Multimedia...
 
Ah, schön zu hören. :)
Für ssh gäbts halt ein paar "Clients" um Befehle auf x Clusterknoten gleichzeitig auszuführen ohne es bei jedem einzeln per Hand anzustoßen. Aber du scheinst dir ja helfen zu können.
 
Kullberg schrieb:
Powershell 2.0 - ältere Versionen haben kein remoting.

p.s. Ich hab es eben nochmal probiert, mit nem XP x64 Rechner in nen W7 Rechner zu remoten. Jetzt (mit service pack 1) geht es :)
Ohne SP1 ging es nicht. Seltsam, aber sehr erfreulich. Zwar hat Windows 7 bei meinen Anwendungen keinerlei Vorteile, aber XP x64 Lizenzen zu kriegen wird immer schwieriger.
Zum Vergrößern anklicken....


schön zu hören

wenn ich da mal in meinen Ulas rumstochere, sehe ich ein paar Erfordernisse für ps 2.0 remoting:
-.net framework 2.0 sp1 oder später
-windows remote management (WinRM) 2.0 (sollte es hier geben: Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0))
wobei die bei w7 und ws2008r2 per default mitinstalliert sind, also nur bei frühreren windows versionen extra installiert werden müssen

bei remoting auf client os sind noch ein paar weitere Sachen, zb. den status des users betreffend der das remote script ausführt, oder auch den status der nics betreffend, gegebenenfalls muss bei xp-rechnern die lokale Sicherheitsrichtlinie manuell angepaßt werden und die IP adressen aller gesteuerten clients in die trusted host liste aufgenommen werden, hat man es mit gemischten domains zu tun, muss die localaccounttokenfilter-richtlinie angepaßt werden, weil sonst über domain-grenzen hinweg nur user privilegien bestehen, etc.,
aber nachdem es nun läuft ...

hätte auch keinen Grund gesehen, warum das zwischen xp und w7 nicht funktionieren sollte

und was die ps version angeht, es gab in ps 1.0 bloss keine native remoting schnittstelle, aber das wmi konnte hierfür genutzt werden und zb. mit get-process und get-service können remote maschinen verbunden werden
 
Es läuft schon ziemliche lange (ca. 2 Jahre), nur mit Mischbetrieb W7 / XP x64 läuft es erst seit SP1 für W7.
Für XP x64 muss man übrigens noch nen patch einspielen, damit das mit den Rechten auch funktioniert.
Wenn man innerhalb des Netzwerkes keine Sicherheit braucht, geht auch "set-item trustedhosts *"
Meine Scripts senden übrigens scriptblocks auf die slaves, die dann kontinuierlich laufen und jede Sekunde Statusdaten (CPU Load, aktive tasks, PID des parent tasks...) zurücksenden. Sowas geht erst mit ps 2.0.
 
Update: Ich konnte das Problem lösen - und es lag weder an den Treibern, noch am Board direkt, sondern wahrscheinlich an der Unterstützung der USB-Floppy.
Ich hab ne slipstream CD mit integrierten AHCI Treibern gemacht, und damit funktioniert alles :)
 
Nun hab ich doch noch ein Problem:
der Rechner mit dem Supermicro Board verbraucht zuviel Strom:

Im Vergleich:

Rechner 1:
ASUS Z9PE-D8 WS
2x Xeon E2687W
8x 8 GB RAM Kingston 1600er reg. ECC
Kingston SSD 240 GB V+ 200
ATI Radeon HD 6450
Sea Sonic X-Series X-650 (80+ Gold)

Rechner 2:
Supermicro X9DRi-F
2x Xeon E2680
8x 4 GB RAM Kingston 1600er reg. ECC
Solidata SSD 240 GB
Supermicro 825TQ-R720LPB (auch 80+ Gold)

Rechner 1 verbraucht idle 115W
Rechner 2 verbraucht idle 145W :(

Bei Volllast (32 threads Schach) verbraucht:
Rechner 1: 417W
Rechner 2: 380W

Da stimmt das Verhältnis bei Volllast - aber im idle ist der Rechner mit dem Supermicro Board im Vergleich ne Katastrophe.
 
Das ist durchaus möglich, dass sich das redundante Netzteil etwas mehr zieht (bei meinem IBM X3650 sind das gut 20-30W)
Was sagt denn der CPU Takt im Ilde bei dem SM Brett?
 
mr.no-name schrieb:
Nimmt sich evtl. das redundante Netzteil etwas mehr im Idle?
Zum Vergrößern anklicken....


sowas würde ich auch annehmen

und falls da jetzt wieder XP installiert ist, kommt hinzu, dass Hardware-Treiber Windows in Quere kommen könnten beim Versuch, Energie zu sparen
denn das setzt ja voraus, dass Windows die Geräte in einen definierten Energiesparzustand versetzen kann, und danach auch wieder in einen Normalzustand versetzen kann
klappt diese Prüfung mit den Hardware-Treibern nicht, wird erst gar kein geringerer Energiezustand erreicht oder höchstens S1, mit dem nur minimal gespart wird

außerdem ist ein Ruhezustand unter XP (auch nicht unter 64bit xp) nicht möglich, wenn mehr als 4 GB ram installiert sind
 
Zuletzt bearbeitet:
Das Netzteil schließe ich mal aus. Das SM Netzteil hat bei 20% Last (also bei 144W Abgabe bei 230V Netzspannung) 88,7% Wirkungsgrad, das Seasonic 87,5% (bei 130W Abgabe bei 115V).

Den Asus Rechner hatte ich mit Windows 7 und mit XP x64 gemessen. In beiden Fällen war der Verbrauch gleich.

Wenn CPU-Z läuft, steigt beim SM Rechner der Verbrauch auf ~160W und die CPU Frequenz wird wechselnd mit 3,1 und 3,5 GHz angezeigt. CPU-Z selbst verbraucht dann Unmengen an Rechenzeit.
 

Anhänge

  • cpuz.PNG
    cpuz.PNG
    99,1 KB · Aufrufe: 63
Kullberg schrieb:
Wenn CPU-Z läuft, steigt beim SM Rechner der Verbrauch auf ~160W und die CPU Frequenz wird wechselnd mit 3,1 und 3,5 GHz angezeigt. CPU-Z selbst verbraucht dann Unmengen an Rechenzeit.
Zum Vergrößern anklicken....

Scheint so, als hätten wir da schon einen Knackpunkt. Wenn sich deine CPUs langweilen, dann sollten die sich eigentlich so wie bei mir im Test auf 1,2GHz drosseln (das mit dem Speicher einfach ignorieren ;))
Unbenannt.jpg
 
Eigentlich schon.... aber:
Ich hab eben dem Rechner mit dem Asus Board nochmal W7 aufgesetzt. Da zeigt CPU-Z 1200 MHz an und er verbraucht 115W. Mit der anderen SSD mit XP x64 drauf zeigt CPU-Z Werte um 3,4 GHz an, aber der Verbrauch ist ~1W niedriger. Sehr merkwürdig.
Übrigens funktioniert CPU-Z 1.60.1 auf dem Rechner unter XP x64 überhaupt nicht.
Ich werde das mit dem Netzteil nochmal checken müssen. Vermutlich war meine Rechnung falsch: bei ~140W läuft das redundante Teil nicht auf 20%, sondern auf 10% Last, da ja beide Teile laufen. Bei 10% Last ist allerdings der Wirkungsgrad nur noch ~83%. Allerdings reicht das auch nicht, um 30W Unterschied zu bekommen - das würde gerade mal 5-7W erklären.
 
Wieso testest du nicht einfach ein Netzteil mal an beiden Rechnern? Dann weißt du immerhin schon mal den Unterschied welches dieses Netzteil alleine ausmacht. Und in der Regel sind die Desktop Netzteile bei 230V etwas effizienter als im 110V 80+ Test gemessen.

Man sollte auch nicht vergessen, das die Netzteillüfter bei diesen 80+ Tests nicht mit gemessen werden!
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh