PC-Update: Entscheidungshilfen
-
scrub schrieb:
Sgt. Nukem schrieb:
Im BIOS muß man FireWire aktivieren, sonst stehen die 2 RAID-Controller nicht zur Verfügung... WTF??
es scheint aber normal zu sein, daß die RAID-controller als irgendwas anderes angesprochen werden. mein BIOS hält das ding für nen SCSI-controller
Aber auch nur bei Anzeige der "Boot Settings", oder?!
Gut, die RAID-Dinger erscheinen unter Windows ja auch unter "SCSI-Geräte"...
Aber trotzdem: Das mit FireWire ist einfach nur hirnrissig.
Auch find' ich eine Option "Performance Mode: [Auto] [Turbo]" hirnrissig!
Auf [Turbo] wird CnQ ausgeschaltet (und das System läuft die ganze Zeit wie unter Volllast) - ich kann mir nicht vorstellen, daß die Option sonst noch was bewirkt...
Achja, um nochwas über die BIOS-Coder zu motzen: So'n Schwachsinn wie im Jahr 2005 sich noch mit Intel-Steinzeit-Einstellungen wie "A20-Gate" rumplagen zu müssen, oder etwa eine Möglichkeit für "15-16 MB Memory Hole" noch zu haben, die das BIOS unnötig aufblähen, ist UNTERSTE SCHUBLADE!!!
-
Sgt. Nukem schrieb:
rapso schrieb:
btw. noch was, ist der boxen kühler ok? oder laut ?
Öhhh was?!
Deine Lautsprecher produzieren so 'ne Hitze, daß sie aktiv gekühlt werden müssen?!?!?
Ich denke mal Du meinst den "boxed" Lüfter auf den AMD Prozzies?! Tjaaaa... ich habe keinen von diesen neuen X2 Mega Geschossen...
-> Keinen Schimmer.gefixt, war ein dipfehler
ich werd es mal mit den boxed ausprobieren und mein raytracer wird heute abend auf multithreading portiert
danke für die ganzen tips an euch
rapso->greets();
-
Ich hab jetzt nicht alles gelesen...
Aber gut, dass Du dich für das ASUS Board entschieden hast. Ich hatte eben jenes MSI Board, ebenfalls mit einer XFX 7800 GTX Extreme und Corsair TWINX 1024 RAM. Lief ums verrecken nicht stabil!
Nach 2 Wochen habe ich aufgegeben und letztes Wochenende das Board gegen das Asus A8N SLI getauscht. Seitdem habe ich keine Probleme mehr...
-
Sgt. Nukem schrieb:
Nobuo T schrieb:
Nur schade, dass es hier anscheinend weder so lustige POST Diagnose-LEDs/Displays, noch Sprachausgabe gibt.
Hat ASUS doch?!?
Mag sein, das ASUS-Board, das ich gekauft habe, hat offenbar aber nicht von alledem.
Ich habe das Teil jetzt hier und keine POST Diagnose-LEDs gefunden. Von Sprachausgabe stand auch nichts in der Artikelbeschreibung...Joe_M.:
Na wunderbar - wenn das Teil also instabil laeuft, wird's wahrscheinlich am Netzteil liegen.
-
hast du denn immer noch das tagan mit 380W ?
rapso->greets();
-
@Nobuo T: Nein es lag definitiv nicht am Netzteil. Ich hab nur das Board getauscht und habe jetzt seit letztem Samstag keinen Absturz mehr gehabt. Mit dem MSI Board hatte ich alle 30-60 Minuten einen.
Und das Problem wurde durch den Arbeitsspeicher verursacht. Mit dem Corsair XLS PRO und Auto Einstellung (2-2-2-5) kam der Rechner nicht viel weiter, als bis zum Windows-Login. Mit 3-3-3-8 lief es dann für 30-60 Minuten. Nicht mal mit Standard RAM (2.5-3-3-8, Corsair Value Select) und 166 MHz war das stabil zum Laufen zu bewegen. Die Speichermodule habe ich alle schon seit einem Jahr im Einsatz, die sind definitiv nicht defekt.
Vielleicht war das MSI-Board auch einfach nur defekt. Mein Händler hat sich noch nicht gemeldet.
Das Asus Board stellt bei Auto-Timing zwar nur 2.5-3-3-5 ein, aber es läuft stabil. Am Wochende werde ich testen, ob es auch mit 2-2-2-5 stabil läuft.
-
zum Neztteil:
Mein Händler hat mit diese Netzteil empfohlen (für SLI-Betrieb, falls ich mir noch eine zweite GraKa hole):
http://www.alternate.de/html/shop/productDetails.html?showTechData=true&artno=TN6X40&#tecData
http://www.alternate.de/html/shop/productDetails.html?showTechData=true&artno=TN5G12&#tecData´
Das ausschlaggebende ist nicht die Watt-Zahl, sondern die 18, bzw 20 Ampere auf den PCIE-Anschlüßen. Für die 7800er-Serie werden 25A empfohlen. Bei läuft es aber auch mit 18A stabil.zur GraKa:
Ich hab die XFX 7800 GTX Extreme. Diese wird, selbst bei offenem Gehäuse, sehr heiß. Als ich die Kühlkörper runter genommen habe, hab ich bestimmt 3 Tütchen Wärmeleitpaste darauf verteilt gefunden.
Im Windows-Modus (auf 250 MHz getaktet) wurde die GPU schon 55-58°C warm, beim spielen wurde sie definitiv zu heiß und hat gedrosselt. Nun ja, mit der WaKü wird sie unter Vollast maximal 56°C warm.
-
rapso schrieb:
hast du denn immer noch das tagan mit 380W ?
Ja. Das Netzteil werde ich voraussichtlich naemlich nicht los.
Den Rest der alten Hardware kann ich guenstig an meinen Bruder verticken, sein altes Netzteil sollte es aber noch tun...@Joe_M.:
Jo, ich wollte deinem Netzteil auch nichts unterstellen.
Bin dann mal gespannt, wie heiss die GT-Version wird...
-
Nobuo T schrieb:
Den Rest der alten Hardware kann ich guenstig an meinen Bruder verticken, sein altes Netzteil sollte es aber noch tun...
Weiß der das?
Nobuo T schrieb:
Jo, ich wollte deinem Netzteil auch nichts unterstellen.
Hab ich auch nicht falsch verstanden. Da ich aber das Netzteil neu gekauft habe, passend zu den Komponenten, habe ich Probleme in dieser Richtung als unwahrscheinlich eingestuft (möglich ist ja alles...).
Nobuo T schrieb:
Bin dann mal gespannt, wie heiss die GT-Version wird...
Na ja, die WaKü war sowieso vorgesehen. Zwar erst zum nächsten Sommer, aber da ich keine Lust hatte die GraKa zu untertakten....
-
So, schreibe nun von der neuen Konfiguration aus.
Folgende Eindruecke so weit:
1. Tagans Netzteile sind eindeutig gar nicht mal schlecht. Hat bisher sogar 3DMark05 stabil ueberstanden.
2. Asus-Software ist nicht so gut. *rangrang* Die Uebersetzungen in diesem tollen "Multi language BIOS" sind alle gleich schlecht (google-Niveau). Die Auswahl "Chinesisch" hat irgendwie noch gefehlt.
3. Die Pins fuer die Kabelanschluesse auf dem MainBoard sind teilweise ziemlich unguenstig angeordnet.
4. Einer der Tachosensoren scheint nicht zu funktionieren.
5. NVidias Software ist auch nicht so gut.
-
Sgt. Nukem schrieb:
Achja, was bei ASUS geil ist: Das easy anpassbare BIOS Startbild!
...Die Dinger kann man ändern ?
Wie haste das gemacht ? Wird wohl kaum auf der Festplatte liegen oder ?
-
mein neuer rechner läuft super, mein raytracer läuft auf 2cores und dem höheren takt nun ca 3mal schneller, sehr geil!
das einzige prob das ich hatte, dass meine 2*512MB so nicht angenommen werden, ich muss (festhalten!), entweder nur einen oder 4 davon reinstecken! o-O und dabei kann alternate diese marke nicht liefern... sehr strange. werde wohl auf 2gb updaten müssen.
das gehäuse mit den ganzen lüftern ist wirklich nice, schön ist dass man die meisten sachen rausnehmen kann um die komponenten darauf zu montieren, so entspannend war der aufbau nicht mehr seit den "eco" gehäusen von "highscreen" (gab's bei vobis).
die graka ist auch ziemlich gut, hab aber noch nicht viele meiner programme darauf testen können, aber ein paar hardcore sachen plane ich schon, was mich stört ist das unnötige grüne leuchten... nur stormverschwendung.
rapso->greets();
-
@rapso:
Bringt der Dual-Core bei Spielen was ?
Würde mich mal interessieren.
-
Nein, eher im Gegenteil. Alle mir bekannten Spiele unterstützen nur eine CPU. Und da es einen gewissen Verwaltungsaufwand gibt, um die beiden CPUs auf die Systemressourcen zugreifen lassen zu können, geht ein wenig Performance verloren (so änhlich wie bei 2 SLI-GraKas, dort erreicht man auch nicht die doppelte Leistung). Dafür kannst Du im Hintergrund rechenintensive Programme laufen lassen, ohne dass Du das im Spiel merkst.
-
die meisten spiele benutzen ein paar threads, einfach weil die programmierer zu lazy sind um die verwaltung von z.b. netzwerk und sound selber richtig zu sheudlen, aus diesem grund laufen die spiele ein wenig fixer, aber aufgrund dessen, dass sie die threads meist nicht an die cpus binden, haben sie dann verlust an leistung, aber mit den aufkommenden patches hollen die das nach. manche spiele wie z.b. collin ralley sind ja eh schon auf HT ausgelegt, die laufen mit dualcore dann natürlich noch besser.
ich hab aber nicht gerade soviel zeit spiele zu testen bzw zu spielen und kann dir nur von der theorie erzählen.
rapso->greets();
-
rapso schrieb:
die meisten spiele benutzen ein paar threads, einfach weil die programmierer zu lazy sind um die verwaltung von z.b. netzwerk und sound selber richtig zu sheudlen
Und ich dachte, daß sei einer ger großen Gründe für Threads, daß man die Sachen nämlich nicht "richtig handeln" muß, sondern parallele Abläufe auch einfach parallel beschreiben kann.
rapso schrieb:
, aus diesem grund laufen die spiele ein wenig fixer, aber aufgrund dessen, dass sie die threads meist nicht an die cpus binden, haben sie dann verlust an leistung, aber mit den aufkommenden patches hollen die das nach.
Eigentlich ist es doch gut, das nicht an ne CPU zu binden. Ist schließlich Aufgabe des OS und nicht der Programme selbst.
-
Jester schrieb:
rapso schrieb:
die meisten spiele benutzen ein paar threads, einfach weil die programmierer zu lazy sind um die verwaltung von z.b. netzwerk und sound selber richtig zu sheudlen
Und ich dachte, daß sei einer ger großen Gründe für Threads, daß man die Sachen nämlich nicht "richtig handeln" muß, sondern parallele Abläufe auch einfach parallel beschreiben kann.
auf singlecores läuft das nicht parallel und trotzdem haben viele leute threads verwendet, was relativ sinnlos ist/war. daten die per netzwerk ankommen und von einem thread empfangen werden, werden irgendwo in eine queue geschoben bis der hauptthread soweit ist sie zu verarbeiten, diese daten werden also aus der queue vom OS in eine eigene verschoben anstatt sie vom MainThread gleich von dort abzuhollen -> unnützer overhead.
IBM hat darüber irgendwo paper bei dem sie beide vorgehensweisen anhand eines sql-servers gegeneinander getestet hatten und die doppelte queue mit unnützen threads war unterlegen.aber wie gesagt, das ist sehr viel einfacher zu realisieren.
und ja, für den sound gilt das selbe, die hardware IRQs laden sich die buffer schon zur richtigen zeit, es ist unnütz dafür noch einen extra thread zu haben.
Jester schrieb:
rapso schrieb:
, aus diesem grund laufen die spiele ein wenig fixer, aber aufgrund dessen, dass sie die threads meist nicht an die cpus binden, haben sie dann verlust an leistung, aber mit den aufkommenden patches hollen die das nach.
Eigentlich ist es doch gut, das nicht an ne CPU zu binden. Ist schließlich Aufgabe des OS und nicht der Programme selbst.
afaik ist das problem ist, dass das os versucht beide cpus gleichmässig auszulasten, dadurch wird wird der hauptprozess hin und her geschoben, das resultat davon ist dann auch, dass der ganze cache dauernt umgelagert werden muss (zwischen den cpus). dieser overhead ist wohl ziemlich hoch, auf jedenfall gibt es patches bei denen die processe dann an cpus gebunden werden und man dann sagen hafte 20% leistung dazubekommt *lol*
ich such ma ob ich ne patchbeschreibung dazu finde
rapso->greets();
[edit]
so eine patchbeschreibung find ich nicht auf anhieb, aber ne probembeschreibung von anderen die praktische erfahrungen damit haben
-
-
Cpp_Junky schrieb:
Sgt. Nukem schrieb:
Achja, was bei ASUS geil ist: Das easy anpassbare BIOS Startbild!
...Die Dinger kann man ändern ?
Wie haste das gemacht ? Wird wohl kaum auf der Festplatte liegen oder ?Nö. Wird ins BIOS "einkompiliert".
Das lustige ist, daß bei den neueren Updates wohl mehr Funktionen zur Verfügung stehen, und daher weniger Speicher für das Bild. Daher mußt Du das dann noch kleiner machen.Das Tool heißt glaub' ich ASUS MyLogo! oder so...
-
rapso schrieb:
auf singlecores läuft das nicht parallel und trotzdem haben viele leute threads verwendet, was relativ sinnlos ist/war.
Das Argument verstehe ich nicht. Wenn man objektorientiert programmiert sind nachher, wenn man kompiliert hat die OO-Strukturen auch weg. Trotzdem denke ich, wir sind uns einig, daß OOP was nützliches und sinnvolles ist. Genauso ist es mit Threads. Abgesehen davon, daß Dinge die auf irgendwelche Hardware warten müssen mit Threads durchaus schneller sein können als ohne.
rapso schrieb:
afaik ist das problem ist, dass das os versucht beide cpus gleichmässig auszulasten, dadurch wird wird der hauptprozess hin und her geschoben, das resultat davon ist dann auch, dass der ganze cache dauernt umgelagert werden muss (zwischen den cpus). dieser overhead ist wohl ziemlich hoch, auf jedenfall gibt es patches bei denen die processe dann an cpus gebunden werden und man dann sagen hafte 20% leistung dazubekommt *lol*
Dann ist das scheduling vom OS scheiße. Die Cache-Umlagerung sollte man natürlich beim Entwurf der Scheduling-Strategie beachten. Das wird sich aber hoffentlich auch bald ändern, sodaß solche Anpassungen vermutlich bald Geschichte sind.