Hallo Jungs muss mich mal melden bin der Entdecker dieses Phänomens.Ist nicht nur in Crysis so sondern auch in anderen Games.Nur in Benchmark Tests (3Dmark06)ist es genau andersrum.Hat jemand mit einer ATI Karte das auch,oder nur Nvidia Besitzer.
Druckbare Version
Hallo Jungs muss mich mal melden bin der Entdecker dieses Phänomens.Ist nicht nur in Crysis so sondern auch in anderen Games.Nur in Benchmark Tests (3Dmark06)ist es genau andersrum.Hat jemand mit einer ATI Karte das auch,oder nur Nvidia Besitzer.
Ist ja wunderschön für dich.Zitat:
Zitat von Tünnüf
Hab noch nie was von dir gehört.
Weiß einer wie das bei einem Takt von Einkernern aussieht?
Hallo Du "Entdecker". :D
kwinz hat es eigentlich sehr verständlich erklärt. Aus irgendwelchen Gründen orientiert sich die Spielgeschwindigkeit und damit der benchmark am FSB, die im BIOS festgelegt wurden und ignoriert nachträgliche Änderungen.
Der 3dMark ist da cleverer und gibt deshalb bessere Werte.
Was ich mich nur frage gerade: Wenn das Spiel beim Untertakten langsamer wird, wird es beim Übertakten ja nicht nur schöner (weil mehr fps), sondern auch wirklich schneller und dadurch schwieriger, oder? Woher weiß ich also, was die von Crytek gewollte Standard-Geschwindigkeit ist? Bzw. wie kann ich Übertakten und trotzdem die richtige Geschwindigkeit haben. Da gibt es doch sicher ein cfg-file, in dem die Taktrate festgehalten ist und auch geändert werden kann. :-)
Grüße
FatBaron
Ist Ja Ok. Aber wenn das so ist,kann man Fraps in einem von Windos aus übertakteten System auch vergessen.Zitat:
Zitat von FatBaron
Wenn ein Benchmark zur Berechnung des Gesamt Ergebnises auch nur irgendwas verwendet was Windows aus dem BIOS ausgelesen hat, ist sowieso Hopfen und Malz verloren. Windows kann nicht einmal den Prozessortakt richtig erkennen.
Beispiel bei mir: Ich hab meinen q6600 auf 400Mhz FSB laufen und den multi auf 8, also 3.2Ghz.
Windows kommt an und sagt: hmm der FSB is auf 400, der q6600 hat normalerweise nen multi von 9, also muss der Prozi mit 3.6Ghz laufen und zeigt das dann auch so an.
Windows hat also vom BIOS auslesen so gut wie kein Plan, nur wenige Programme wie zb. CPUz koennen das, allerdings oft auch nicht fehlerfrei.
Irgendwie is das aber auch gut, denn wenn das Betriebssystem vollen Zugriff auf das BIOS haette, dann haetten Viren ein leichtes Spiel damit unsere Hardware zu schrotten.
Ich selber merk beim CPU runtertakten keinen Unterschied in Crysis.
(edit: ich merk allerdings, dass Vista es hasst wenn der Takt ploetzlich anders ist, da ich dann so nette Bugs wie verschwundene Systemsteuerung hab, die dann erst nach 2 Neustarts wieder weg sind. Es muss wohl glauben das da der CPU ausgetauscht wurde oder so...)
Stimmt. Habs ja getestet. Erbringt die gleichen Werte wie der ingame-bench in Crysis. Aber das liegt daran, dass der bench einfach länger dauert, als eingestellt. Siehe mein post oben.Zitat:
Zitat von Tünnüf
Grüße
FatBaron
Ich habe einen Athlon64 4000+ @ 2860MHzZitat:
Zitat von M3nTo5
habe genauso viele FPS wie ein Kumpel mit AM2 Athlon64 6000+ Dualcore. Meßwerte unterliegen der üblichen Tolleranz. Wir beide benutzen eine HD2900XT @ 845/945 mit DX10 Tweak unter XP.
Settings alle HIGH (außer das, was durch den MOD auf Custom geht). 2xAA und ein paar CFG Tweaks.
Normal läuft man so zwischen 13 und 25FPS durch.
Okay, ich bind mir mal die Zeit für eine genaue Erklärung ans Bein.
Kurze Erklärung
@ kwinz: Glückwunsch. Du warst der Erste, der es geschnallt hat.
Lange Erklärung
Um in Windows Zeiten zu messen gibt es mehrere Möglichkeiten. Die Ur-Methode ist eine API-Funktion namens "GetTickCount()". Die liefert als Wert zurück, wieviele Millisekunden seit dem Start von Windows vergangen sind. Man hat also eine Auflösung von 1kHz. Für genaue Zeitmessungen war GetTickCount() also eher unbrauchbar, liefert aber immer konstante Ergebnisse. (Der Rückgabewert ist 32bittig, läuft also nach 49 Tagen über und beginnt wieder bei 0. Damit kamen bei Windows95 einige Systemdienste und Programme nicht klar, was zu den berühmten Abstürzen nach 49 Tagen Dauerbetrieb führte.)
Mit dem Pentium führte Intel den Zeitstempelzähler (Time Stamp Counter, ab jetzt TSC genannt) ein. Der TSC ist ein spezielles 64-Bit-Prozessorregister, welches die vergangenen Takte seit dem letzten Reset/Kaltstart mitzählt. Die Auflösung entspricht also der CPU-Taktfrequenz, was endlich genaue Messungen bis in den ns-Bereich möglich machte. Problem war nur, dass man als Programmierer nie wusste, wie schnell der TSC denn nun beim jeweiligen Anwender läuft. Das war aber früher nicht so schlimm. Da hat man den TSC mal eine Sekunde lang mit "GetTickCount()" verglichen und wusste danach die Taktfrequenz.
Der Ärger ging los, als die ersten Laptops mit Speedstep rauskamen. Da wurde der Prozessor je nach Last rauf- und runtergetaktet. Wenn jetzt ein Programm aber erstmal den TSC "eingemessen" hatte, waren die Zeitmessungen nach der dynamischen Taktänderung für die Tonne, das das Programm ja vom falschen Basistakt ausging. Dieser Fehler ist übrigens nicht Intel anzulasten. Der TSC war nur für Low-Level-Performancemessungen zur Codeoptimierung gedacht. Dass viele Programmierer das Ding auf einmal zur normalen Zeitmessung benutzen, hatte Intel nicht geplant.
Inzwischen hat Intel nachgegeben und bei den neuen Cores das Verhalten des TSC geändert. Wenn ein Prozessor in den Speed-Step-Modus geht, taktet er zwar runter, der TSC läuft aber mit der Normalfrequenz weiter. Damit ist der TSC zwar für die Codeoptimierung unbrauchbar (weil man keine echten Takte mehr zählen kann), die Zeitmessung wird aber nicht mehr verhunzt. Das gilt aber nur für Speedstep! Wenn man live am FSB dreht, ändert sich der TSC-Takt natürlich mit dem Prozessortakt.
Richtig lustig wird es, wenn mehrere Kerne im Prozessor sind. Jeder Kern hat seinen eigenen TSC und wenn die Kerne auch noch wegen irgendwelcher Stromspartechniken unterschiedlich takten, haben die TSCs auch unterschiedliche Werte. Wenn ein Programm jetzt den TSC abfragt, bekommt es den Wert von dem Kern, auf dem es gerade läuft. Da Windows laufende Programme aber beliebig zwischen den Kernen hin- und herschieben kann, "springen" die ausgelesenen TSC-Werte und laufen scheinbar sogar rückwärts. Das haben natürlich viele Programme nicht vertragen, weshalb es von AMD auch eine Software gibt, die die TSCs synchronisiert. (Ja, das ist der berühmte AMD-Dualcore-Fix.)
Bei Intel kann das übrigens auch passieren. Wenn man Extreme-Quadcores per Multiplikator übertaktet, läuft bei 2 Kernen der TSC u.U. noch mit der Originalfrequenz. Das ist ein Fehler im BIOS und lässt sich mit einem BIOS-Update beheben.
Okay, zurück zum Thema... "GetTickCount()" ist also zu langsam und beim TSC kann man sich nicht sicher sein, ob er konstant läuft. Also hat MS in Windows den High Performance Counter (HPC) eingebaut. Das Ding funzt eigentlich genauso wie "GetTickCount()" und wird mit "QueryPerformanceCounter" abgefragt. Allerdings steht hier die Frequenz nicht fest. Windows sucht sich beim Start die schnellste konstante Zeitquelle raus und verwendet sie als HPC-Grundtakt. Mit "QueryPerformanceFrequency" kann man die benutzte Frequenz abfragen.
Wenn Windows einen alten Pentium oder einen neuen Core mit oben erwähntem konstanten TSC findet, dann nimmt es den TSC (und damit den Prozessortakt) als Zeitgrundlage für den HPC. Wenn der Verdacht besteht, dass der TSC variiert, dann wird meisstens eine Zeitbasis von ca. 3,5 MHz (der ACPI-Timer) benutzt. Auch hier rechnet niemand damit, dass jemand im laufenden Betrieb am FSB dreht und damit den TSC-Takt verändert. Es geht nur um Cool'n'Quiet, SpeedStep, etc...
So, genug der grauen Theorie, hier etwas Praxis:
Ich hab mal eine Timerklasse (Teil eines größeren Programmes, welches eine genaue Zeitmessung benötigt) geschreiben. Um die oben erwähnten Effekte in der Realität auszutesten (einiges war mir damals noch unbekannt) hab ich schnell ein q'n'dirty-Testprogramm zusammengepanscht. Wundert Euch daher nicht über die komische Oberfläche und Startposition.
Kann man hier runterladen: http://85.214.26.220/timercheck.exe
(Keine Angst, iss kein Virus...)
Screenshot: http://85.214.26.220/tcheck.jpg
Taktfrequenz Prozessor -> eigentlich falsch, hier wird der aktuelle Takt vom TSC angezeigt (Den echten CPU-Takt gibts z.B. mit CPUz.) Mit den CPU-Häkchen kann man festlegen, auf welchen Kernen das Programm laufen soll. (Um evtl. Unterschiede in den TSC-Frequenzen zu finden)
Taktfrequenz HPC -> der von Windows angegebene Takt für den HPC
Wenn hier fast der gleiche Wert steht, wie bei "Taktfrequenz Prozessor", dann dient der TSC als HPC-Grundlage.
Mit "HPC benutzt" kann man die Verwendung des HPC im Testprogramm ausschalten. Dann wird immer "GetTickCount()" verwendet.
Mit "Prozessorlast" kann man die CPU etwas rödeln lassen, um die Wirkung von SpeedStep und Co. zu sehen.
Alle, die den "mehr FPS bei weniger Takt"-Effekt haben, tun bitte folgendes:
- Windows mit "hochgetaktetem" Prozessor hochfahren
- Timercheck starten, HPC einschalten und Testtimer laufenlassen
- jetzt mit euren Tools den FSB runtertakten
Wenn HPC und TSC-Takt die gleichen Werte hatten, werdet ihr vermutlich folgende Beobachtung machen:
- der TSC-Takt wird kleiner
- der HPC-Takt bleibt gleich (weil der Wert nur einmal von Windows ermittelt wird)
- die Timerklasse wird gegenüber dem Windows-Timer langsamer (Ich gehe mal davon aus, dass der Windows-Timer konstant bleibt. Da ich nicht weiss, wo eure Übertaktungssoftware dran rumdreht, könnte ich mich aber auch irren. Dann würde sogar der Windows-Timer langsamer laufen und ihr müsstet mit der Stoppuhr nachprüfen.)
Wenn dies der Fall ist, dann laufen jetzt alle Programme, die den HPC benutzen langsamer, bzw. messen kleinere Zeiten.
Wenn ein Programm den TSC benutzt hängt es davon ab, wann es seinen "Basistakt" gemessen hat. Wenn ihr den FSB vorher einstellt, ist alles OK. Wenn ihr danach dran rumdreht, kommt wieder Müll raus...
Beim "dynamischen Übertakten" kommt also schnell Murks bei Zeitmessungen raus. Man kann aber Korrekturrechnen:
Snipermike hat von 3,6 GHz auf 3,2 GHz runtergedreht. Es wurde also mit 3,2 GHz Takt gemessen, aber mit 3,6 GHz gerechnet. Gemessene Zeiten müssen also mit 3,6 GHZ multipliziert werden um die tatsächlichen Taktzyklen zu ermitteln. Dann muss man durch den echten Takt, also 3,2 GHz, teilen.
Da FPS=1/Zeit gilt:
echte FPS= (gemessene FPS * 3,2)/3,6
Dann sollte eigentlich der echte Wert rauskommen. Da durch den veränderten Timer aber das ganze Spiel anders läuft, kann es auch wirkliche Abweichungen bei den FPS geben.
Puh, das war jetzt viel "high tech shit", aber die Moral von der Geschicht ist:
Nicht bei laufendem Windows am Takt rumschrauben. Das gibt nur Probleme...
Beeindruckend. Hab sicher nicht alles verstanden, aber trotzdem danke.
Eines würde mich aber noch interessieren.
Warum hat der 3dMark06 da weniger Probleme und gibt korrekt mehr fps bei höher getakteter CPU raus? Nutzt der 3dMark eine andere Möglichkeit der Zeitmessung?
Grüße
FatBaron
Weil der 3DMark06 vor jedem benchen das System scannt.Blendet immer vorher ein Fenster ein ,scanne System.Zitat:
Zitat von FatBaron
Danke für die Info.Gibt es den eine andere möglichtet sich die genaue Framzahl beim spielen anzeigen zu lassen.Ausser Fraps das geht ja dann wohl nicht.Zitat:
Zitat von Beaker
Bis du sicher das wenn du mehr Frames im Spiel hast ,dadurch das Spiel scheller abläuft? Kann ich mir nämlich nicht vorstellen! Weil wenn das so währe ,könnte mann im Internet nie gegeneinander z.B. Autorennen fahren. Denn dann würde der mit der schnelleren Grafikkarte immer gewinnen.Oder? Ein Zitat.Alle modernen Spiele (also moderner als DOS ) werden nicht mehr durch die Rechenleistung gesteuert (je mehr Rechenleistung desto mehr Frames desto schneller das Spiel), sondern regelmäßig die Berechnung für den nächsten Frame gestartet. Somit sollte kein Spiel mehr zu schnell laufen, egal wie schnell dein Rechner ist.Zitat:
Zitat von FatBaron
*thread entstaub* So, habe Heute eine ulkige Efahrung gemacht...
Habe mir Heute 4 GB Corsair 800 Mhz Speicher gekauft um meine 4 GB Kingston 667 Mhz Speicher auszutauschen.
Wollte gerne meinen Proz übertakten und dazu war der 800er nötig, davon mal ab wollte ich eh gern schnelleren Speicher.
Habe ein E6750 @ 2,66 den ich auf 3,2 getaktet habe. Der Speicher blieb bei 800.
Ergebnis: Weniger FPS als vorher..... Ähm Häähh ? War das Erste was ich gedacht habe.
Dann wurde es auch noch teils instabil (Crysis) indem mein Freund der Anzeigetreiber-Absturz wieder da war....
Ok, als hab dann gleich mal runtergetaktet FSB auf 375 und Speicher auf 750.
Spiel wieder stabil aber immer noch gleich wenig FPS (so ca. 10 FPS weniger als sonst).
Gut, dann hab ich meinen Proz wieder normal getaktet auf 333 FBS mit 2,66 Mhz und den 800er Speicher somit runter auf 667 Mhz und siehe da meine guten alten FPS Werte sind wieder da....
Verkehrte Welt... Naja, muss dann halt für Crysis den Speicher runtertakten. Was solls...
PS: Das Spiel läuft übrigens nicht langsamer bei meinem normal getakteten Proz, sondern nur wenn ich übertaktet habe. Temperaturen alle im grünen Bereich !
Takte die CPU mal RUNTER. Du wirst sehen, dass der bench Dir mehr fps ausspuckt. Verwirrend, aber wahr.
Ingame habe ich beim Übertakten in den Zwischensequenzen auch das Problem, dass der Ton normal läuft, aber das Spiel schneller läuft. Dadurch werden die letzten Sekunden von jedem Satz abgeschnitten. Übertakten außerhalb des BIOS ist somit eigentlich nicht möglich.
Warum das so ist, wurde ja oben schon geklärt.
Grüße
FatBaron
Edit: Ups, habe die letzten Einträge vor meinem nicht mehr gelesen, die Lösung des Problems steht ja schon da und erklärt auch deutlich fundierter wie der Effekt zustande kommt.
Ich glaube ich habe herausgefunden, wie die scheinbare besseren fps zustande kommen. DarkDanger hat ja seine Benchmarkergebnisse mit dem Hinweis geposted, dass die tatsächliche Zeit für den Benchmark nahezu identisch geblieben ist.
Daraus habe ich folgende Schlüse gezogen:
1. der CPU-Takt hatte keinen oder nur einen sehr geringen Einfluss auf das "echte" Benchmarkergebniss (passt zu den aussagen, dass die CPU nie voll ausgelastet wird)
2. die Zeiterfassung während des Benchmarks erfolgt anhand des CPU-Taktes aus dem Bios. Crysis zählt also die Takte mit und errechnet hieraus die vergangene Zeit. Ändert man unter Windows den FSB ermittelt Crysis folglich eine falsche Zeit.
Beispiel: Der CPU-Takt wird von 2400MHz auf 2068MHz reduziert. Crysis geht vom alten Takt aus, wonach nach 2400 Takten eine Sekunde vergangen ist, tatsächlich ist diese Zeit aber bereits nach etwa 2000 Takten verstrichen. Für eine Minute, die der Benchmark ermittelt vergehen also tatsächlich etwa eine Minute und 12 Sekunden.
3. da im Crysis-Benchmark immer eine feste Anzahl von Frames gerendert werden, ermittelt dieser die fps direkt aus der zum Rendern benötigten Zeit, vergeht die "Crysis-Zeit" langsamer als die tatsächliche, ermittelt der Benchmark folglich eine zu geringe Zeit und damit eine zu gute fps-Zahl.
Sollten diese Überlegungen stimmen, so müsste sich eine direkte Abhängigkeit zwischen den ermittelten fps-Zahlen und dem CPU-Takt ergeben, ich habe also mal gerechnet:
CPU: (entspricht lt. meiner Annahme der Crysis-Zeit)
Run 1: 2400 MHz (100,00%)
Run 2: 2068 MHz ( 86,17%)
Run 3: 1878 MHz ( 78,25%)
Low-fps:
Run 1: 12,90 (100,00%)
Run 2: 15,12 (117,21%)
Run 3: 17,87 (128,53%)
Average-fps:
Run 1: 20,97 (100,00%)
Run 2: 24,32 (115,98%)
Run 3: 26,69 (127,28%)
High-fps:
Run 1: 30,86 (100,00%)
Run 2: 33,68 (109,14%)
Run 3: 39,51 (128,03%)
Multipliziert man nun die Pozentzahlen für CPU und fps, so müsste sich lt. meinen Annahmen immer ein Wert nahe 100% ergeben. Kleine Abweichungen wird es natürlich durch einen Resteinfluss des CPU-Taktes, Effekte durch günstige RAM-Teiler und Hintergrundanwendungen geben.
CPU x Low-fps:
Run 1: 100,00%
Run 2: 101,00%
Run 3: 108,40%
CPU x Average-fps:
Run 1: 100,00%
Run 2: 99,93%
Run 3: 99,59%
CPU x High-fps:
Run 1: 100,00%
Run 2: 94,04%
Run 3: 100,18%
q.e.d.
Dies erklärt auch den Effekt, dass Bild und Ton in den Zwischensequenzen nicht Synchron laufen. Die "Bildgeschwindigkeit" wird anhand der "Crysiszeit" ermittelt, die Tonspur ist hingegen eine Audiodatei, die ganz normal abgespielt wird, also in Echtzeit läuft. Übertaktet man ausserhalb des Bios, läuft die "Crysiszeit" zu langsam und damit das Bild zu schnell.
Beispiel: Ich übertakte ausserhalb des Bios von 2400MHz auf 3000MHz. Ein Teil der Sequenz soll eine Sekunde dauern, also spielt Crysis ihn innerhalb von 2400 Takten ab. Durch das Overclocking braucht die CPU für die 2400 Takte aber nur noch 0,8 Sekunden (2400MHz/3000MHz), die Abspielgeschwindigkeit für die Zwischensequenz beträgt 125% (3000MHz/2400MHz) der normalen.
Schöner hätte ich es auch nicht machen können. :-D
Prima.
Jetzt will ich nur noch wissen, wie man das ändern kann. Denn gerade ein Spiel wie Crysis schreit doch geradezu nach Übertakten. Nervig, dass das dann nur im BIOS gehen soll.
Grüße
FatBaron
Ich meine im Crysis-Ordner mal eine Datei gesehen zu haben in der die Systemeigenschaften hinterlegt waren, also GraKa, Anzahl CPUs und Takt etc. Evtl. hilft es ja diese zu ändern, wobei ich fürchte, dass sich Crysis beim Starten wieder die aktuellen Bioseinstellungen zieht.Zitat:
Zitat von FatBaron
Generell ist das Übertakten per Bios sowieso vorzuziehen, da es im allgemeinen zu einer stabileren Lösung führt. Du kannst jua zum Testen unter Windows übertakten und dann die für dich geeigneten Werte im Bios eintragen.
Die von Dir erwähnte Datei könnte man ja schreibschützen.Zitat:
Zitat von s³b!
Wenn ich mich recht erinnere hat XP ein Problem mit einem FSB über 300 und bringt dann diverse Fehlermeldungen. Deswegen ist SetFSB dem Übertakten per BIOS vorzuziehen. Aber ich kann mich irren.
Grüße
FatBaron
Ich kann mein Cpu nicht mehr takten!An was kann es liegen?? Vorher lief der auf 3,4 ghz, und auf einmal kann ich den garnicht mehr takten, er läft jetzt nur noch auf 2,4ghz
über eine Antwort würd ich mich freuen!
MFG Dami
Zitat:
Zitat von Dami
Erstmal herzlich Willkommen^^
Hast du bei dein Mainboard nachgeschaut ob die FSB Zahl korrekt ist?
Oder irgendwelche BIOS Updates gemacht?
Neuer Prozzi drinnen oder RAM?
- Crysis2142
Das bios kann ich garnicht updaten, was ist fsb?Damit kenn ich nicht aus!
das mainboard hab ich http://www.alternate.de/html/product...&l3=Sockel+775
Dami hi, wir haben hier im Harware Forum einen extra overclocking Thread.
(Kann das bitte ein Moderator rüber verschieben, da sonst hier diese Themen ganz durcheinander kommen)