Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
TestRAM-OC auf AMD Ryzen im Test: Flare X & Trident Z Royal mit optimierten Taktraten & Timings
Betrachten wir dort vor allem mal die zwei Ryzen 1800X Systeme, einmal mit 3200 und einmal mit 3466. Im early Game Bench sind beide noch gleich schnell, beim late Game kann sich das System mit dem schnelleren RAM bereits 4% absetzen. Und das bei FullHD Ultra Preset!
@Jesterfox
Wobei 4% wahrscheinlich nicht wahrnehmbar sind, solange das Spiel ansich flüssig spielbar ist. Sind sie das Zünglein an der Waage, dann hast du Recht, aber ich glaube das dafür der Korridor sehr eng und die Wahrscheinlichkeit damit sehr gering ist. Des Weiteren ging es mir in dem Fall auch um die Timings (so steht es auch in meinen Post) und weniger um den Durchsatz des RAMs.
Die 4% sind aber auch nur der Wechsel von 3200 auf 3466 (und wir wissen nicht wie die Timings sind). Das ganze ist nur ein Ausblick das eben auch Anno (und vermutlich alle anderen Strategiespiele) ebenfalls auf RAM OC reagieren (ich wüste jetzt auch keinen Grund weshalb das nicht der Fall sein sollte)
Meine Güte, es gibt Spiele die reagieren mehr auf bessere Latenzen und Spiele die kratzt das nicht so.
Deine dämlichen Pauschalaussagen sind aber faktisch falsch, da es dutzende Benchmarks zu RAM-Tuning bei Spielen gibt und es dort sehr wohl oft nen gutes Mehr an Leistung bringt.
@Jesterfox
Nochmal, es ging nicht um Taktung, sondern um die Timings des RAM (wie es auch in meinem Post steht). Meine Behauptung bzw. meine Annahme ist, dass dies wahrscheinlich auch keinen großen Einfluss auf CPU lastige Spiele haben wird. Nicht mehr und nicht weniger. Wobei das, von Dir eingebrachte Thema, nichts mehr mit dem Artikel zu tun hat, von daher schweifen wir hier ab.
Aus Taktung und Timings resultiert die Latenz du Experte. Ebenso Durchsatzveränderungen.
Wie man tatsächlich wider etlicher empirischer Beweise (RAM-Tuning Benchmarks in diversen Spielen) hier so dreist auftreten kann und immer und immer wieder die selbe falsche Leier runterspielt, ist mir nicht verständlich.
Guter Test und gute Diskussion hier im Forum, das war beim Thema RAM-OC ja leider nicht immer so gegeben. Daumen hoch dafür!
Was ich persönlich noch gut fände: Könnt ihr von der OC-Community nichtmal simple und einfach Empfehlungen geben, welchen Ram mit welchem XMP/ODCP-Profil man nehmen sollte, wenn man NICHT manuell übertakten will? Ich weiß natürlich, dass das auch erheblich vom verwendeten Board abhängt, aber zumindest sowas wie "RAM X mit Takt Y und CLZ mit ODCP-Profil auf Takt X+ und CL Z+ ist zu empfehlen".
Also einfach kurz und knapp, was man kaufen sollte, wenn man out-of-the-box mit Wahl eines vorkonfigurierten OC-Profils im BIOS einen guten Kompromiss haben will.
Mir ist klar, dass das nicht einfach umzusetzen ist, aber wer, wenn nicht ihr kann es schaffen ;-)
Evtl. als Hinweis:
Takt ist nicht alles. Nur weil da 3200 Mhz steht, weiß man noch lange nicht, ob hier CL12,14,16.. Welche anderen Primärtimings gesetzt sind, welche Sekundärtimings, welche Tertiärtimings, welche tRFC gesetzt ist usw.
Es macht schon einen Unterschied, ob man hier mit 256 tRFC arbeitet oder nur mit 560, denn es wirkt sich auf Latenzen aus.
Genau das ist es ja. Ich habe jetzt 2666er DualRank Speicher mit zufriedenstellenden Latenzen. Wenn ich jetzt auf SingleRank wechsle und mir nicht den Samsung B-Die gönnen kann, macht es Sinn, SR RAM mit schlechteren Latenzen aber mehr Takt zu kaufen oder komme ich gar am Ende bei der gleichen Leistung raus und habe nur Geld verschwendet. Mein Versuch mit 2933er SR ist auf jeden Fall gescheitert, dieser war langsamer.
Demon_666 schrieb:
Vielleicht solltest Du zwei Dinge beachten:
Erstens ist das ein Leser-Test. Das bedeutet, @cm87 hat da viel private Zeit reingesteckt und wegen der Natur der Thematik kann nicht alles abgedeckt werden. Zudem hat @cm87 bestimmt nicht 10 PCs mit 50 verschiedenen RAM-Kits rumliegen (oder doch?? ).
Zweitens liefert der Test trotzdem alle notwendigen Infos. Und selbst wenn as Kit getestet worden wäre, wäre das keine 100%ige Garantie, dass das so auch bei Dir funktioniert: Andere CPU/MB/RAM-Bausteine. Vor allem letzteres weiß man erst, wenn man das Kit in den Händen hält.
Das respektiere ich auch. Ich habe letztens 870 Rechner migriert, dass kannst Du ja auch respektieren, aber es nützt Dir nichts. Ich hatte in diesem Artikel auf Antworten gehofft, aber leider keine erhalten
Und noch ein Hinweis für Dich: Ich habe genau das Kit auf 3400MHz CL14 mit optimierten subtimings stabil gehabt (Ryzen 2600, Asus X470 prime). Ob das bei Dir auch klappen wird? Keine Ahnung, da deine Hardware komplett anders ist und G-Skill nun eventuell andere Bausteine verwendet. Aber zumindest kann es funktionieren. RAM-OC ist immer ein "Glücksspiel", bei dem viele Faktoren einen Einfluss haben...
Ergänzung ()
Also ich habe ganz real mit echten Spielen eine deutliche Verbeserung durch RAM-OC erzielen können. Weniger bis gar keine Ruckler mehr vor allem im minimum fps-Bereich (Ich glaube, ich sollte mir den Absatz mal abspeichern, damit ich copy&paste machen kann. gefühlt schon zigma gepostet ).
Danke für deine Hinweise, 3400Mhz klingt schon ordentlich. Logisch, dass ich das Restrisiko auf meiner Seite habe, im Zweifel tausche ich den RAM halt um.
Ergänzung ()
duskstalker schrieb:
ich hab mir speicher mit hynix C-die chips gekauft, weil ich 32gb wollte und der speicher saubillig ist. man liest hier und da mal sehr interessante dinge über hynix C-die und ich wollte wissen, was da dran ist.
Interessanter Tipp, vielen Dank. Und Du bist Dir sicher, dass es DualRank ist? Wenn das stimmt, sind das aber überraschend hohe Mhz und die Latenzen dafür auch noch gut. Echt eine Überlegung Wert.
@styletunte
Der RAM wird aktuell gerne empfohlen, da es einen guten Mittelweg zwischen Preis und Leistung bietet.
Was deine Problematik angeht:
Zumindest in Spielen (die ich mir angeschaut hatte), war die Regel meist: DR/Vollbestückung = SR + 200 MHz.
Bezüglich timings kann dir das keiner genau durch testen, wir sprechen hier von 25 timings (tcke zähle ich mal nicht dazu), die teilweise sich auch noch gegenseitig beeinflussen können.
Ich kann dir sagen, dass ich (!) zwischen nicht-optimiert und optimierten timings teilweise bis +10% gemessen habe (95% CPU SotT) bzw. bis zu +15% avg (AC:O).
(Im AC:O Test haben dagegen 4Ghz -> 4,2Ghz nichts gebracht)
Das schnellste was eigentlich immer mit Xmp läuft: flare x 3200 cl14
Das günstigste wenn Geld knapp ist: Aegis 3000 cl16 - läuft eigentlich immer mit 2933 Xmp.
Der Kompromiss wenn man nichts dran machen und nicht viel ausgeben will ist für mich irgendein Kit mit 3200 cl16. Da finde ich z.b. die LPX ne Option weil die ripjaws gerne zicken. Im zweiten PC hatte ich jetzt ne Weile die Patriot Viper RGB laufen.
Alles von 2x8 Gb ausgehend.
Insbesondere für 2x16Gb sind derzeit die ballistix 3000 cl15 ein günstiger Tipp. Allerdings ist deren Standard nicht der Burner und man muss fast schon bisschen Hand anlegen.
Klar hab ich da keine alltägliche Denke, aber bei den derzeitigen Preisen sehe ich keine große Diskussion. Ich habe die flare x früher schon für 230€ gekauft, aktuell für 150€ zu haben. Ist natürlich immer noch das doppelte von nem Aegis, aber effektiv geht der Preis dann bei nem gehobenerem PC eh unter.
Kann man so natürlich auf jeden RAM beziehen.
Das ganze dürfte sich mit ryzen 2 aber vermutlich ein wenig ändern. Sollten dann wirklich plötzlich xmps mit 4000+ nutzbar sein wird sich bestimmt was an den Empfehlungen verschieben.
@styletunte
Der RAM wird aktuell gerne empfohlen, da es einen guten Mittelweg zwischen Preis und Leistung bietet.
...
(Im AC:O Test haben dagegen 4Ghz -> 4,2Ghz nichts gebracht)
Vielen Dank für die Infos. Die Einschätzung "DR/Vollbestückung = SR + 200 MHz." halte ich auch für real, wobei es auch Spiele gibt, die SR Bestückung bevorzugen, sind aber nicht die Masse. Ich konnte bei meinen eigenen Test z.B. COH2 als Freund von SR ausmachen. Max und Min Fps waren höher angegeben, average aber nicht bedeutend. Auch mehrfache Wiederholungen kamen zum gleichen Ergebnis.
Öhm, wenn BF5 im Multiplayer für dich nicht CPU fressend ist, dann fress ich einen Besen mitsamt haaren. BF5 ist im 64 Spieler multiplayer extrem CPU fordernd und damit ein gutes Spiel für solche Tests.
azurlord schrieb:
Nochmal, es ging nicht um Taktung, sondern um die Timings des RAM
In Spielen kommt es aber meist auf die Latenz an und die ergibt sich nunmal aus Takt und Timings.
Maine schrieb:
Also einfach kurz und knapp, was man kaufen sollte, wenn man out-of-the-box mit Wahl eines vorkonfigurierten OC-Profils im BIOS einen guten Kompromiss haben will.
hmm, da gabs irgendwo einen Thread mit Kaufberatung für RAM Kits bei Ryzen. Mir fällt der Threadname auf die schnelle nicht ein. Ansonsten die einser Empfehlung. G.Skill Flare X 3200 CL14. Die laufen mit dem XMP Profil zu 99.9% auf jedem Board und CPU.
Solch Szenarien nimm ich mir auch zu Herzen und werde es vlt. hier noch, oder im nächsten Test mit einfließen lassen. Muss mir da zuerst einen Parkour erstellen.
Falls ihr da explizite Ideen habt oder Benchmarks kennt, nur herbei damit.
Was mir zu den bereits genannten noch einfällt: Vielleicht bin ich etwas old-school, aber gelegentlich codiere ich sogar noch größere Mengen MP3 mit LAME unter Audacity. Das ist auch im Jahr 2019 noch single-threaded. Keine Ahnung, wie sich das durch die Speicherperformance beeinflussen lässt.
VeraCrypt bietet ja einen eingebauten Benchmark an, der im RAM läuft. Die Frage dabei wäre aus meiner Sicht, ob beim Benchmark der Einfluss des RAMs eventuell doppelt eingeht - einmal als tatsächlicher Arbeitsspeicher für die zu ver-/entschlüsselnden Daten, wie es auch im realen Einsatz mit einem Datenträger der Fall wäre, und ein zweites Mal als nur im Benchmark eine Rolle spielender virtueller Datenträger. Das hängt davon ab, wie das implementiert ist, das weiß ich nicht.
Gleiches gilt im Grunde genommen für Komprimierungen und Codierungen. Will man den Einfluss des Datenträgers minimieren, nimmt man als Quell- und Zieldatenträger normalerweise eine RAM-Disk. Doch dann belastet man automatisch den RAM mehrfach, verfälscht also möglicherweise das Ergebnis. Also am besten eine schnelle NVMe-SSD als Quelle und Ziel nehmen, oder?
Benchmark ist mit 7-zip, Audacity oder Avidemux meines Wissens nicht möglich, aber man kann immer wieder dieselbe(n), ausreichend große(n) Datei(en) komprimieren bzw. codieren und die Zeit messen. Wenn man die Dateigrößen so wählt, dass der Prozess jeweils wenige Minuten dauert, hält man den Messaufwand gering und kann dann hoffentlich Unterschiede im Sekundenbereich ermitteln, was praktikabel wäre. Wenn selbst nach mehreren Minuten keine Unterschiede im Sekundenbereich auftreten, dann ist das ja auch eine Aussage, dann hat das RAM-Timing einfach keinen (relevanten) Einfluss.
@Rage
Ich habe Deinen Post gelesen, aber er ändert nichts. Ich sehe nicht den Sinn darin, die beste CPU damit zu er testen, da man abseits der Realität (720p) Unterschiede feststellt, die bei realistischen Einstellungen keine Bedeutung mehr haben.
Was mich im Übrigen auch zu der dreisten Aussage verleitet, dass die meisten Spieler mit einer CPU von unter 200€ ganz selten mal in ein CPU Limit laufen würden.
Doch natürlich ändert er was, gerade bei CPU-Fressern wir Strategiespielen oder Spielen mit viel KI wird mit reduzierten Einstellungen auch die CPU ordentlich mit entlastet. Du scheinst Dir nicht vorstellen zu können, dass ein moderner Prozessor auch schon deutlich vor absurd hohen fps in Spielen, die den Fokus auf Grafik legen, limitieren kann; ist aber schon so. Ich verweise Dich auf den Testbericht in meiner Signatur, schau Dir einfach die Ergebnisse von Esenel und mir aufmerksam an. Im besonderen die Ergebnisse von Esenel in Assassins Creed Origins. Die sind nämlich für 720p und 1080p exakt die gleichen, weil der Prozessor limitiert. Selbst in 1440p ohne ordentliches OC bremst der Prozessor. Und wir reden hier von "gerade mal" 120fps, die maximal rauskommen. Noch besser ist Anno 1800, im Lategame kann man sich über 60fps schon freuen.
Welchen Einfluss schärfere Timings bei gleicher Frequenz haben können, kannst Du im Lesertest übrigens auch sehen. Das ist weit entfernt von "kein großer Einfluss".
Dass Du die Frage, wie viele fps ein Prozessor bereit stellen kann, nicht interessant oder relevant findest, tut doch nichts dafür zur Sache, dass es schon Leute gibt, die das relevant finden. Wenn ich zum Beispiel ein Spiel spiele, dann stelle ich das so ein, dass ich möglichst konstant 142fps bekomme. Wie soll ich aber bei Neukauf wissen, welche CPU es ungefähr sein muss, wenn sogenannte "CPU-Tests" in UHD mit maximalen Details gemacht werden, wo spätestens bei um die 100 fps Schluss ist? Und jetzt stell Dir vor: Es gibt Leute, die spielen mit 165Hz Bildschirmen und sogar 240Hz Bildschirmen. Wenn ich in die Top 10 der meistgespielten Steam-Spiele schaue, dann sind 5 von den 10 Titeln schnelle E-Sports Spiele. Und selbst bei Leuten, die nicht so viel Ahnung von Technik haben, setzen sich langsam aber sicher 144Hz Bildschirme durch, weil die eben mittlerweile recht bezahlbar sind.
Wenn Prozessoren und Grafikkarten so getestet werden, wie ich das sinnvoll finde, dann kann jeder da alle Informationen rausziehen, die er braucht. Ganz anders sieht das bei der von Dir vorgeschlagenen Methode aus. Alleine schon deshalb ist es denke ich klar, welche Methode zu bevorzugen ist; praktischer Weise ist die auch noch die, die am wenigsten Aufwand macht. Statt bei den CPU-Tests 3 Auflösungen zu testen, ohne neue Informationen zu bekommen, könnte man dann nämlich jeweils das Top-Modell der beiden Grafikkartenhersteller testen, die es gibt, denn die unterschiedlichen Treiber haben durchaus auch Auswirkungen darauf, wann das CPU-Limit einsetzt.
Als kleiner Zusatz: Der hier getestete Modus "Firestorm" aus Battlefield V ist ein 64 Spieler-Modus. So viel zu 64 Spieler-Multiplayer wurde hier nicht getestet.
Nur weil du "fiktive Zahl" davor schreibst, heißt es noch lange nicht, dass es wahrer oder sinnvoller wird.
Zumal der Drang das Ganze ins Lächerliche zu ziehen sehr stark ersichtlich ist.
Nur als Beispiel: Was klingt denn sinnvoller?
1) 1-3% mehr Leistung für 100€ mehr (deine fiktive Zahl, um RAM OC lächerlich zu machen)
2) 10-15% mehr Leistung für 100€ mehr (Werte die von Usern gemessen wurden)
Merkst was?
Das du nicht nur Spieletests zeigst, sondern auch die synthetischen Benchmarkwerte zeigst zu den Bandbreiten und Latenzen!
Das du tRFC mit bei den Balkenbeschriftungen angibst!
Gut fand ich auch deinen Vergleich, wo du 4x8 und 2x8 maximal übertaktet hast um zu zeigen, was am Ende das bessere Ergebnis bringt!
Und für deinen guten Text, der ohne zu viele Worte exakt beschreibt was passiert und was das aussagt!
usw......
Aber ich wäre nicht ich, wenn ich nicht Kritik äußern würde.
Ich hoffe du siehst sie konstruktiv und nicht als Vorwurf!
Ich sehe an den RTC Screenshots und auch an den tRFC Werten bei den Benchmarks, welche Timings optimiert sind, und welche von XMP/docp/Auto gewählt wurden.
Im Test kommt das aber meiner Meinung nach nicht so gut rüber.
So sehe ich bei 2x8 3200, dass du die Timings optimiert hast und bei 4x8 3200 nicht.
Das ist aus meiner Sicht ein Fehler, weil du hier die Chance verspielst, einen Vergleich bei gleichem Takt/Timings zu machen...im Grunde das was ich schon bei meinem SR vs DR Test getestet habe, aber ich hatte gehofft du würdest es verifizieren oder in Frage stellen.
So sieht man zwar, dass 4x8 trotz schlechterer Timings besser als erwartet abschneidet, aber ohne gleiche Settings kommt es nicht wirklich heraus, wie viel es jetzt ausmacht, eine bessere copy Leistung und GBS zu haben.
20s zu messen ist aus meiner Sicht sehr kurz.
Das kann man natürlich von Spiel zu Spiel optimieren.
Man kann kurz(20-25s).... aber oft Messen, um z. B. unregelmäßige Framtimepeaks, seltener in den Messungen zu haben und dann diese Messungen auszusortieren.
...aber da bringt man seinen eigenen Bias mit rein und die Peaks sind nicht im Ergebnis.
Oder man misst so lange(40, 60, 120s), dass man immer einige Frametimepeaks in jeder Messung hat, dann dauert halt jede Messung sehr lange....dafür kommt man mit weniger aus
Wenn man eine super reproduzierbare Szene hat, kann man natürlich auch selten und trotzdem kurz messen.... ist meiner Erfahrung nach aber eher die Ausnahme für CPU/Ram-Tests.
Der CapFrameX Screenshot ist aus meiner Sicht etwas ungünstig gewählt. rant über Frametimemessungen incoming....
So zeigt er ein anderes Spiel.... ebenfalls sehr kurze Messungen und eine Messszene, die ich so ungerne als Benchmark wählen würde.
Man sieht einen heftigen Sprung in dem Frametimeverlauf, der auf eine Kamerawechsel oder ähnliches hindeutet...sowas ist selten reproduzierbar, und durch die Einteilung der Szene in diese zwei Stufen, macht der Startzeitpunkt einen größeren Unterschied.... etwas früher oder später und mehr von dem Bereich mit den schlechteren Frametimes ist in der Messung.
Ich versuche optimalerweise mit ähnlichen FPS zu starten und zu enden um den Einfluss des Starzeitpunktes zu minimieren.
Und dann würde ich sagen stimmt da was bei der Berechnung nicht.
Unter 2000 Frames, sollten für die P0.1(was wohl der Kehrwert der 99.9th Percentile Frametimes ist) der zweitschlechteste Frametime genutzt werden.
Zumindest ist das so, wenn ich ein professionelles Darstellung/Auswertungsprogramm wie OriginPro auf eine Messung loslasse....dann spuckt der mir für 1700 Frametimes bei 99.9th Percentile, das zweitschlechteste aus.
Hier im Screenshot ist Min(was vermutlich das schlechteste ist)... 0.1% low was der Mittelwert über die schlechtesten 0,1% ist und P0.1 was vermutlich 1000/P99.9 ist alle gleich....so als würde anstatt auf die nächstgrößere Nummer zu gehen, auf die übernächste gegangen werden.
Das dürfte bei über 1000 Frametimes nicht der Fall sein.... ich muss da mal in den Link gucken und mir den Quelltext angucken.
Ist jetzt kein Problem von dir oder deinem Test...du hast ja eh die min Werte genommen....aber es zeigt, wie eine geringe Messdauer die Ergebnisse beeinflusst.
Hättest du die 0.1% low Werte genommen, wären die ihrer Funktion einen Mittelweet zu bilden gar nicht nachgekommen, weil es bei 20s Messung gar nicht genug Werte gibt, die gemittelt werden könnten.
Bei so kurzen Messdauern ist es sogar eine gute Entscheidung die min Werte zu nehmen....die schwanken zwar logischerweise gerne, aber immerhin hast du kein Problem, wenn deine Messungen eine 1000er Menge überschreiten.
Hättest du Messungen bei 20s und um die 100 FPS gemacht, würde (eine korrekt berechnete 0.1P oder 0.1 low Berechnung) für die Messungen mit 999 Frametimes den schlechtesten Frametime nehmen und für 1001 Frametimes den zweitschlechtesten(bzw den Mittelwert der beiden). 1000 wären ein Sonderfall, da nimmt auch der Percentile Wert den Mittelwert aus schlechtestem und zweitschlechtestem.
Das kann durchaus heftige Unterschiede machen, die total unfair der Messung mit 999Frametimes gegenüber ist, wenn 1-2 gemessene Frames mehr den Sprung darstellen.
.... also mit den Min Werten alles richtig gemacht in deiner Situation.... sollte ich für mich auch mal überlegen je nach Spiel.
Aber trotzdem.... längere Messungen, und dann eher die 1% low Frametimes, ergeben meiner Erfahrung nach die reproduzierbareren und genaueren Ergebnisse.
Die Min Werte schwanken mir zu stark und auch von Messprogramm zu Messprogramm ist das nicht so genau wie man denkt.
Fraps und OCAT machen schon das gleiche, aber die einzelnen Frametimes sind nicht genau gleich gemessen.
Die schwanken im Vergleich(gleichzeitig gemessen) durchaus etwas anders und wenn man dann für die Min Werte eben nur einen Frametime nimmt, dann ist nicht nur die Schwankung der Hardware stark, sondern auch die Ungenauigkeit des Timers/Messprogramms nicht unerheblich.
Auch in Bezig darauf ist es sinnvoller für die Frametimes einen Mittelwert über einen kleinen Prozentsatz zu nehmen oder von mir aus auch Percentile Werte(ungerne).
..... sorry für den Wortschwall..... Danke für den Test!!
azurlord schrieb:
Mich würde die Auswirkung in deutlich realistischeren Settings interessieren (WQHD, volle Details etc) . Aber ich vermute dann laufen sowieso alle Test ins GPU und eben nicht ins CPU Limit. Und dann ist alles ganz schön relativ.
Ich habe meine CPU/Ram-Spiele-Tests (fast immer) versucht so zu machen, wie ich sie selbst auch spiele.
Also in 1440p und mit Grafiksettings, die mir optisch gut gefallen aber wenn möglich hohe FPS(70-100) ermöglichen.
Für ältere/anspruchslose Spiele, wähle ich dann natürlich höchste Details, da die GPU eh unterfordert ist.
Diese Spiele laufen dann leider oft sehr schlecht...weil sie einfach hart über einen CPU Kern limitieren.... aber genau hier zeigen sich öfter Unterschiede durch Ram-OC, die auch spürbar sind.
Für die Spiele, die mit der GPU skalieren, optimiere ich die Details so, dass ich einen guten Mix aus Optik und FPS erhalte.
Das ist dann für jedes Spiel anders, aber wenn meine GPU in Hitman 2 z.B. auch auf Ultra 1440p mit flüssigen FPS packt, dann stelle ich höchstens Motion Blur runter weil ich das nicht mag....und dann teste ich halt die Szenen, die viel CPU Last haben und auch wenn da 90% GPU limitiert ist, zeigen sich die Unterschiede eben nur durch die 1%(oder 0.1%) low Frametimes, die dann z.B. in Marrakesh mit Ram-OC starke Unterschiede zeigen....und auch spürbar sind, weil die FPS von 90-100 auf 58(2133MHz Ram) oder nur auf 70(3200MHz Ram) fallen.
....ob die avg FPS 92(2133MHz Ram) oder 102(3200MHz Ram) sind ist mir ziemlich egal.
Aber mit 2133MHZ Ram ist die Testzene eben im Schnitt 7-11 Mal unter 60 FPS gefallen und mit 3200MHz Ram nie.
Um solche Messungen zuverlässig machen zu können muss man allerdings extrem genau arbeiten....extrem oft messen und optimalerweise seine Ergebnisse an anderen Tagen reproduzieren....
Das kostet unglaublich viel Zeit und ich habe großen Respekt vor cm87, dass er sich an BF V herangetraut hat.
Das muss sehr zeitaufwendig und frustrierend gewesen sein... ich würde MultiPlayer Spiele immer vermeiden.
Da dann Messungen zu machen, ergibt nur Sinn, wenn er auch möglichst große Unterschiede durch eine niedrige Auflösung erzwingt.
Ob sich teilweise größere Unterschiede zeigen, wenn man Ultra Details wählt, muss man im Einzelfall immer gucken.
Anno 1800 hat z.B. Auf Ultra Details wegen der Sichtweite und dem Wuselfaktor über großen Städten eher ein CPU limit... und schon der Wechsel auf high Details kann in ein GPU limit führen, weil die CPU nun viel weniger Objekte übermitteln muss....die GPU aber trotzdem gefordert ist.
Im Test von cm78 sieht man Unterschiede mit schnellerem Ram...also hat er es wohl richtig gemacht.
Auch gehe ich davon aus, dass einige Leute dieses Spiel auf low spielen werden, um möglichst reaktionsschnell zu sein.... sehe ich hier gar nicht als so unrealistisch an
In Tomb Raider hätte ich nicht auf low gestellt, aber es ist ein neues Spiel, das die Leute interessiert und wenn er eine gute Skalierung zeigen will, muss er die GPU möglichst ausschließen.
Man kann es nicht allen recht machen und es ist ja gut, wenn im Netz verschiedene Ansätze zu finden sind.
nospherato schrieb:
Da sieht man normalerweise nach wie vor, dass die min fps (und ggfs. avg fps) hoch gehen, auch wenn es auf max fps keinen Einfluss mehr hat.
Jain..... Meiner Erfahrung nach, gehen auch die max FPS oft noch weiter hoch.....auch wenn die avg FPS fast gleich bleiben.
Je nachdem wie die gemessen werden, sind das ja super kurze Momente, wo die GPU nix zu tun hat und dann ist es kurz CPU limitert(wo der Ram hilft) obwohl die avg FPS GPU limitiert sind.
Die Max FPS sind aus meiner Sicht jedoch völlig uninteressant, aber das wäre ein anderes Thema
eyedexe schrieb:
Daisy Chain
Der Weg von der CPU ist zum 2. und 4. DIMM-Steckplatz (A2, B2) kürzer, als zum 1. und 3. DIMM-Steckplatz (A1, B1).
Sicher, dass das so verwendet wird? Woher hast du denn das Schaubild dazu.
Ich war immer der Meinung, dass Daisy chain Mainboards die Fly-by methode verwenden.
Die Leiterbahn geht also über den 1. slot und endet im 2. bzw. geht über den 3. und endet im 4....mit dem Ram-Modulen in 2 und 4.
Denn nur so erklärt sich, warum daisy chain bessere Taktraten ermöglicht....so wie du das zeigst, kann man auch gleich T-topology nehmen.
Meines Wissens nach ist der Vorteil bei einem Daisy Chain Mainboard nicht, dass das Signal 1-2ns kürzer unterwegs ist.
Sondern dass es keine lange zweite Abzweigung gibt, an deren Ende das Signal reflektiert und zeitversetzt das eigentiche Signal überlagert..... das passiert bei T_Topology wenn man nur ein Modul im Channel hat.
Die Slots mit Modul, haben im Modul Endabschlusswiderstände, die richtig gewählt die Signale terminieren und damit keine ungewollte Reflexion zeigen...der unbesetzte Slot ist ein offenes Ende und reflektiert dementsprechend.
Sitzt der offene Slot direkt auf der Leitung richtung besetztem Slot(wo die Leitung endet)...fly-by..ist seine Störung minimal.
Hat man T-Topology, gibt es immer die lange Abzweigung mit dem offenen Slot, die stärker stört...aber bei Vollbestückung die gleichen Signallaufzeiten hat.
Bei Daisy chain sind wie du richtig sagst, die Signallaufzeiten unterschiedlich und das ist für Vollbestückung schlecht für hohe Taktraten.
).
).
