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.
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 von Tünnüf
Hab noch nie was von dir gehört.
Weiß einer wie das bei einem Takt von Einkernern aussieht?
A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.
Hallo Du "Entdecker".
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.
Geändert von noxon (03.11.2007 um 10:52 Uhr)
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...)
Geändert von Gauss (02.11.2007 um 16:09 Uhr)
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.
Grüße
FatBaron
Ich habe einen Athlon64 4000+ @ 2860MHz
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.
Hier mal etwas langweilige Theorie...
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.
Zitieren
