Windows und Dual-Core

[GloomY]

Es gibt ja genügend Postings, die die Probleme beim Einsatz von DualCore unter Windows beschreiben. Laufen tut es meistens schon, aber viele Benutzer klagen z.B. über Ruckeln in Spielen, welches eigentlich nicht sein dürfte.

Das Vorhandensein von mehr als nur einem Prozessor ist ja für Windows nichts Neues, schließlich existieren SMP Systeme schon eine ganze Zeit (Xeon, AthlonMP, Opteron etc.). Seit dem P4 mit SMT identifizieren sich für das Betriebssystem einige Prozessoren selbst bei nur einem physikalisch vorhandenen Prozessor als zwei solcher. Alles also ein alter Hut, welcher anscheinend Dank SMP-Unterstützung seit WinNT und SMT-Unterstützung seit WinXP eigentlich funktionieren sollte, oder?
Trotzdem hat Windows Probleme, wenn man einige Anwendungen nicht explizit auf eine CPU bindet.

Anscheinend ist es ein Windows-Problem, denn solche Klagen sind (mir) weder von Linux, *BSD oder anderen x86-basierten Betriebssystemen bekannt, welche DualCore unterstützen. Eigentlich sollte sich ja ein DualCore-Prozessor von einem SMP-Prozessor aus Betriebssystemsicht nicht wirklich unterscheiden, denn es hat sich ja nur der physische Ort der Prozessorkerne verlagert. SMP-Unterstützung sollte damit automatisch DualCore-Unterstützung implizieren, insofern ist es eigentlich blödsinnig, von DualCore-Unterstützung an sich zu reden.

Wo liegt also das Problem? Ich spekuliere bisher mal auf den Windows-Scheduler, habe dazu aber keinerlei Indizien. Die Hardware betrachtend kann ich nicht wirklich einen Grund ausmachen:
Da sich das Problem mit dem Zuweisen von einer Anwendung an einen physikalischen Prozessor lösen lässt, schränkt die Ursachenforschung schon mal etwas ein. Ein ständiger Wechsel der Ausführung des Programms von Core1 zu Core2 und wieder zurück ist natürlich auch mit einer ständigen Hin- und Herschieben der Daten in den Caches begründet. Auf Grund der verwendeten Cachekohärenz-Protokolle (MESI bei Intel, MOESI bei AMD) wird da immer wieder Invalidiert und upgedatet, was natürlich eine gewisse Verzögerung darstellt. Diese ist aber um Größenordnungen kleiner als die für einen Menschen merkbaren Ruckler in Spielen.
Außerdem tritt das ja genau auch auf einem echten SMP-System auf, also was ist da beim DualCore anders?

:confused:

[BlackBirdSR]

Die erste Frage um das problem noch etwas einzugrenzen:

Tritt das Problem auf dem Pentium-D auf?


edit:
normale Abfrage:
CPUID.HTT=1(edx[28])
CPUID.logical_number_of_processors = 2 (ebx[23:16])
Die CPU meldet sich mit 2 logischen Kernen an, nicht mit 2 physikalischen,

Wird also der SMT Scheduler verwendet?

LEGACY_CMP=1 -> kein SMT
d.h nur bei Abfrage nach LEGACY_CMP wird dem Betriebsystem mitgeteilt, dass kein SMT verwendet wird.
Nach Microsoft Angaben fragt WindowsXP nach diesem Wert.
Also wird trotzdem der SMP Scheduler verwendet.

http://www.google.de/url?sa=t&ct=res&cd=16&url=http%3A//download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWSS05002_WinHEC05.ppt&ei=l3EfQ8GmGpnUwgGUoJW-Cw

Hatte gehofft hier was zu finden. War aber leider nichts :(

[Coda]

Ich glaube nicht, dass es was mit dem Scheduler zu tun hat sondern:

a) C'n'Q funktioniert mit DualCore nicht zuverlässig. Wo da das Problem liegt weiß ich nicht, auf jedenfall taktet sich die CPU nicht zuverlässig hoch
b) Spiele die RDTSC zur Zeitmessung verwenden: Da der Timestamp auf den beiden Cores anders ist gibt das auf jedenfall Probleme.

[GloomY]

Die erste Frage um das problem noch etwas einzugrenzen:

Tritt das Problem auf dem Pentium-D auf?Laut Tombman betrifft das auch den Pentium-D (klick (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3423489#post3423489)).
Ob man sich auf diese Aussage nun verlassen kann, weiss ich nicht...
edit:
normale Abfrage:
CPUID.HTT=1(edx[28])
CPUID.logical_number_of_processors = 2 (ebx[23:16])
Die CPU meldet sich mit 2 logischen Kernen an, nicht mit 2 physikalischen,

Wird also der SMT Scheduler verwendet?

LEGACY_CMP=1 -> kein SMT
d.h nur bei Abfrage nach LEGACY_CMP wird dem Betriebsystem mitgeteilt, dass kein SMT verwendet wird.
Nach Microsoft Angaben fragt WindowsXP nach diesem Wert.
Also wird trotzdem der SMP Scheduler verwendet.

http://www.google.de/url?sa=t&ct=res&cd=16&url=http%3A//download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWSS05002_WinHEC05.ppt&ei=l3EfQ8GmGpnUwgGUoJW-Cw

Hatte gehofft hier was zu finden. War aber leider nichts :(Ich hab' hier leider gerade kein OpenOffice geschweige denn PowerPoint installiert... :(
Ich glaube nicht, dass es was mit dem Scheduler zu tun hat sondern:

a) C'n'Q funktioniert mit DualCore nicht zuverlässig. Wo da das Problem liegt weiß ich nicht, auf jedenfall taktet sich die CPU nicht zuverlässig hochTreten diese Stotterprobleme denn nur in Verbindung mit C'n'Q auf? Das wäre mir neu.
b) Spiele die RDTSC zur Zeitmessung verwenden: Da der Timestamp auf den beiden Cores anders ist gibt das auf jedenfall Probleme.Bist du sicher, dass dieser unterschiedlich ist? Schon mal konkret mit einem Programm nachgeprüft? ;)

[Coda]

Bist du sicher, dass dieser unterschiedlich ist? Schon mal konkret mit einem Programm nachgeprüft? Anders kann ich mir z.B. die CPU-Frequenz-Anzeige von CS:Source nicht erklären: 35423Ghz oder sowas X-D

Aber ich werd das gleich mal abchecken :)

[Demirug]

Ja, der RDTSC Wert wird nicht zwischen den Kernen syncronisiert.

Deswegen soll man ja auch den Timer über Windows auslesen und zudem noch regelmässig die Timerfrequenz abfragen weil sich diese wegen C'n'Q dynamisch verändern kann.

Wenn man doch unbeding RDTSC braucht muß man die Anwendung fest auf einen Kern binden.

[Coda]

Wollte es gerade auch bestätigen...

#include <iostream>

int main(int argc,char *argv[])
{
__int64 timestamp,last_timestamp = 0;

for(;;) {
__asm {
rdtsc
mov DWORD PTR[timestamp+4], edx
mov DWORD PTR[timestamp], eax
}

std::cout << timestamp;
if(timestamp < last_timestamp) std::cout << " <- error";
std::cout << std::endl;

last_timestamp = timestamp;
}
}Bringt in regelmäßigen Abständen den Error :)

[GloomY]

In wie fern verlassen sich die Spiele auf den TSC? Gibt das nicht auch bei SMP Systemen Probleme?

Hat sonst noch irgend jemand eine Idee? :)

[mirp]

Laut Tombman betrifft das auch den Pentium-D (klick (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3423489#post3423489)).
Ob man sich auf diese Aussage nun verlassen kann, weiss ich nicht...Das war nur eine Vermutung. Nach dem Motto, wenn das hier so ist, muss es da auch so sein.
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=3423597#post3423597

Treten diese Stotterprobleme denn nur in Verbindung mit C'n'Q auf? Das wäre mir neu.Das sind zwei verschiedene Probleme. Das C'n'Q-Stottern ist nicht so stark. Ich würde es eher als leichtes Ruckeln bezeichnen.

Bei mir lasse ich C'n'Q aber meist sowieso deaktiviert, da mir ansonsten die Kiste zu alllen möglichen Gelegenheiten abschmiert. Wobei ich bisher nur C'n'Q eindeutig als Gemeinsamkeit entdeckt habe. Denn wenn ich es deaktiviere hört der Spuk auf.


Vor kurzem habe ich bemerkt, dass mich Futuremark einige Ergebnisse nicht veröffentlichen lässt (3DMark 2001 SE). C'n'Q war deaktiviert.

This project can not be published due to detected CPU speed variation.

The checkbox is not visible if a problem was detected in the benchmark project. Possible reasons for this are many, but most are due to an unknown component in your system, or inconsistensies during your benchmark run. If you feel you should be able to publish your project, please visit our support pages.


Bei UT2004 spinnt die FPS-Anzeige etwas (stat fps). Generell zeigt die untere Zeile (avg?) einen zu niedrigen Wert. Egal ob ich die ganze Zeit mit 100+ fps rumrenne, wird hier nur 10-20 fps angezeigt. Außerdem gibt es noch den Fall, dass beiden Zeilen dauerhaft einen zehnstelligen Wert ausgeben.


Mal abgesehen von C'n'Q, sind Probleme von Programmen mit dem Dual-Core eher die Ausnahme. Auch wenn man durch die Berichte im Forum einen anderen Eindruck erhält.

[Coda]

In wie fern verlassen sich die Spiele auf den TSC?Hm zur Zeitmessung schon einige. UT99 macht da selbst mit C'n'Q schon Probleme.
Gibt das nicht auch bei SMP Systemen Probleme?Bisher hat Spieleentwickler Dualcore reichlich wenig gekratzt. Warum auch, der Markt ist ja wahrscheinlich noch kleiner als der derjenigen die Linux haben ;)

[mbee]

Das Windows-Timer-Problem sollte doch eigentlich mit dem "/usepmptimer"-Switch in der boot.ini erledigt sein oder liege ich da falsch? Wenn ich diesen Switch entferne kommt es nämlich bei vielen Anwendungen (z.B. Source-Engine-Spielen) zu ziemlichen Rucklern.

UT2004 habe ich leider nicht mehr auf der Kiste, aber alle anderen Spiele/Anwendungen (Source-Enginge, Doom3, BF2, F.E.A.R.-Demo, etc.) machen bei mir (A64 X2) nur mit C&Q Probleme und laufen mit Desktop-Energieschema einwandfrei. Leider gehört zu den C&Q-Problemkindern auch der Setpoint-Treiber von Logitech: Die Mausbeschleunigung verringert sich und die Maus ruckelt leicht, selbst auf dem Desktop.

[Coda]

Das Windows-Timer-Problem sollte doch eigentlich mit dem "/usepmptimer"-Switch in der boot.ini erledigt sein oder liege ich da falsch?Da liegst du falsch. Wenn die Spiele direkt RDTSC benützen per Assembler hilft alles nix außer die Threadaffinität zu ändern.

[mbee]

Merci! Aber ratsam ist dieser Eintrag bei SMP/Multicore-Systemen doch generell?
AFAIK wird dann für den Timer der Chipsatz und nicht die CPU benutzt.

[Coda]

Merci! Aber ratsam ist dieser Eintrag bei SMP/Multicore-Systemen doch generell?Eigentlich wird RDTSC nicht von der Win32 API benützt, deshalb ist mir der Eintrag etwas schleierhaft. Einen anderen Timer haben die CPUs auch nicht.

[mbee]

Bei mir zeigt er wie bereits geschrieben ziemlich gravierende Auswirkungen:
Besonders Source-Engine basierte Spiele reagieren auf ein Fehlen des Eintrags mit einem zyklischen und ziemlichen Starken Auf und Ab der Framerate bzw. Ablaufgeschwindigkeit (da hilft dann nur die Zuweisung zu einem Core). Ist der Eintrag vorhanden, läuft es ohne die Zuweisung zr einem Core ohne Probleme. Das selbe Spiel bei anderen Anwendungen bzw. Games.

[Coda]

Anscheinend benützt Windows doch tatsächlich RDTSC für QueryPerformanceCounter ohne /usepmtimer. Das tut schon ein bischen weh fast...

[mbee]

Das war der AMD-Prozessor-Treiber (falls Du den installiert hast) ;)
Kannst ihn testweise ja mal rausschmeißen: Bei mir ist es definitiv so, dass der beschriebene Effekt dann z.B. bei CS:Source auftritt, wenn der Thread nicht an einen Core gebunden wird.

[Coda]

Ja hab ich. Siehe Edit...

Da sieht man aber mal wieder wie wenig man sich bisher um SMP gekümmert hat. Naja, vielleicht bekommen wir dann mal endlich einen zuverlässigen Timer im Chipsatz, weil der bisherige hat schon wieder Probleme auf manchen Boards *seufz*

[GloomY]

Hmm, der allgemeine Tenor ist also, dass es Timingsprobleme sind, die durch das Auslesen des TSC und Scheduling-Wechsel auf eine andere CPU verursacht werden?
Da sieht man aber mal wieder wie wenig man sich bisher um SMP gekümmert hat. Naja, vielleicht bekommen wir dann mal endlich einen zuverlässigen Timer im Chipsatz, weil der bisherige hat schon wieder Probleme auf manchen Boards *seufz*Dazu stellt sich dann die Frage, ob dieser Timer dann genau genug ist. Immerhin laufen die Chipsätze meist nicht mit dem vollem CPU-Takt.

Die Verzögerung vom Abschicken der Anfrage zum Auslesen des Chipsatz-Timers bis zum Eintreffen der Antwort bei der CPU könnte auch eine Rolle spielen. Braucht man z.B. eine Genauigkeit im zwei- oder dreistelligen CPU-Takt-Bereich, kann diese Verzögerung das Ergebnis durchaus nennenswert beeinflussen.

Vielleicht wäre es auch eine gute Idee, dem Programm die Möglichkeit einzuräumen, per API des OS sich selbst auf eine CPU zu binden. :confused:

[Coda]

Dazu stellt sich dann die Frage, ob dieser Timer dann genau genug ist. Immerhin laufen die Chipsätze meist nicht mit dem vollem CPU-Takt.~3.5Mhz. Das sollte für jede Zeitmessung ausreichen im Normalfall.

Hmm, der allgemeine Tenor ist also, dass es Timingsprobleme sind, die durch das Auslesen des TSC und Scheduling-Wechsel auf eine andere CPU verursacht werden?Imho: Ja. Was anderes kann eigentlich gar nicht schief gehen beim Task-Wechsel zwischen den CPUs.

Die Verzögerung vom Abschicken der Anfrage zum Auslesen des Chipsatz-Timers bis zum Eintreffen der Antwort bei der CPU könnte auch eine Rolle spielen. Braucht man z.B. eine Genauigkeit im zwei- oder dreistelligen CPU-Takt-Bereich, kann diese Verzögerung das Ergebnis durchaus nennenswert beeinflussen.Äh, wozu bräuchte man das? Da fällt mir nur profiling ein und dazu lässt sich der Thread ja auch auf eine CPU festnageln.

Das würde übrigens nicht nur eine nennenswerte Beeinflussung sein, sondern eine um ein paar hundert Cycles ;)

Vielleicht wäre es auch eine gute Idee, dem Programm die Möglichkeit einzuräumen, per API des OS sich selbst auf eine CPU zu binden.Natürlich ist das eine gute Idee. Viel besser wäre allerdings QPC zu benützen und das Windows nicht zu doof wäre dafür nicht RDTSC zu benützen im SMP-Fall.

[Plutos]

Anders kann ich mir z.B. die CPU-Frequenz-Anzeige von CS:Source nicht erklären: 35423Ghz oder sowas X-D

Aber ich werd das gleich mal abchecken :)

Ach, jetzt wo du es sagst: das ist bei Everest auch so.

[Coda]

Ich will ja nichts sagen, aber ich finde Everest und Sandra ziemlich beschissen.
Die Programme machen nichts weiter als die Win APIs abzufragen und sind dann bei den wenig HW-nahen Sachen zu blöd es richtig auszulesen.

Ich hatte z.B. mal ein Programm namens Dr. Hardware, das zwar nicht so "poppig" gestaltet ist, dafür aber wirklich an die HW rangeht um Infos zu bekommen.

[mirp]

Das Windows-Timer-Problem sollte doch eigentlich mit dem "/usepmptimer"-Switch in der boot.ini erledigt sein oder liege ich da falsch? Wenn ich diesen Switch entferne kommt es nämlich bei vielen Anwendungen (z.B. Source-Engine-Spielen) zu ziemlichen Rucklern.

UT2004 habe ich leider nicht mehr auf der Kiste, aber alle anderen Spiele/Anwendungen (Source-Enginge, Doom3, BF2, F.E.A.R.-Demo, etc.) machen bei mir (A64 X2) nur mit C&Q Probleme und laufen mit Desktop-Energieschema einwandfrei. Leider gehört zu den C&Q-Problemkindern auch der Setpoint-Treiber von Logitech: Die Mausbeschleunigung verringert sich und die Maus ruckelt leicht, selbst auf dem Desktop.Hast du ein Spiel, welche auf der Unreal-Engine vor UT2004 basiert? Bis einschließlich UT2003 stottern diese auch mit dem "/usepmptimer"-Switch. Nur eine Begrenzung auf eine CPU hilft.

[mbee]

Nein. Das mit der alten Unreal-Engine hatte Coda ja schon erwähnt.
Was mich wundert, ist, das Falcon AF keine Probleme macht (im Grund ist die Engine ja uralt) und sogar richtig von Dualcore zur profitieren scheint (bislang das einzige Spiel bei mir, bei dem das der Fall ist).

[mirp]

Coda bezog sich aber auf C'n'Q und nicht auf den Dual-Core. Oder sehe ich das falsch?

[mbee]

Siehst Du richtig, das hatte ich dann falsch in Erinnerung. K.A., was das bei bei der alten UT-Engine sein könnte dann.

[GloomY]

~3.5Mhz. Das sollte für jede Zeitmessung ausreichen im Normalfall.Für Assembler-Programmierung ist oftmals eine taktgenaue Auflösung wünschenswert. Wie sonst soll man denn bei den heutigen superskalaren Prozessoren mit spekulativer Ausführung außerhalb der Programmreihenfolge und mit einer nicht voraussagbaren Speicherlatenz (Caches) ohne Timestamp-Counter feststellen, ob Programmcode A nun schneller oder langsamer als Codestück B ist?

Klar, für den Rest reichen 3,5 MHz wahrscheinlich aus :)

Äh, wozu bräuchte man das? Da fällt mir nur profiling ein und dazu lässt sich der Thread ja auch auf eine CPU festnageln.Ja, auch wieder wahr... :)
Das würde übrigens nicht nur eine nennenswerte Beeinflussung sein, sondern eine um ein paar hundert Cycles ;)Gerade bei den kommenden Mobil-Dual-Prozessoren, bei denen sich die einzelnen Kerne unabhängig voneinander heruntertakten können, wäre ich mir nicht so sicher, dass die beiden Timestamp-Counter nicht doch eine wesentlich größere Differenz aufweisen können.
Natürlich ist das eine gute Idee. Viel besser wäre allerdings QPC zu benützen und das Windows nicht zu doof wäre dafür nicht RDTSC zu benützen im SMP-Fall.QueryPerformanceCounter? Laut Dokumentation (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/queryperformancecounter.asp) sollte Windows dafür orgen, dass das auch im Fall von Multiprozessorsystemen funktioniert. Man könnte hier fast schon von einem Versäumnis oder von Schuld reden, wenn Windows das selbst nicht hinbekommt, was es laut Dokumentation machen sollte...

edit: Ach ja, Dr. Hardware =) Das gab's schon zu DOS-Zeiten, obwohl später auch noch eine Windows-Version (Dr. Hardware 2000?) herauskam. Das war auf jeden Fall ein geniales Programm :)

[JK_MoTs]

(...)
edit: Ach ja, Dr. Hardware =) Das gab's schon zu DOS-Zeiten, obwohl später auch noch eine Windows-Version (Dr. Hardware 2000?) herauskam. Das war auf jeden Fall ein geniales Programm :)Hey, Dr. Hardware gibbet doch immernoch ---> http://www.drhardware.de/pghgload.htm :)

[Gipsel]

Vielleicht wäre es auch eine gute Idee, dem Programm die Möglichkeit einzuräumen, per API des OS sich selbst auf eine CPU zu binden. :confused:
Das geht doch wunderbar per "SetThreadAffinityMask" unter Windows, oder? Damit kann ein Programm auch dafür sorgen, das es immer den gleichen TSC der gleichen CPU ausliest.
Viel besser wäre allerdings QPC zu benützen und das Windows nicht zu doof wäre dafür nicht RDTSC zu benützen im SMP-Fall.
Es ist ja sogar noch viel schlimmer! Windows benutzt bei Uni-Prozessorsystemen für QueryPerformanceCounter den Zeitgeber fürs Powermanagement (diese 3.58MHz) und NUR im SMP-Fall (oder SMT) den TSC. Das ist ja die eigentliche Idiotie. Und dokumentiert ist das auch nirgendwo so richtig. Man findet aber die Bemerkung, das QueryPerformanceFrequency immer den gleichen Wert zurückgibt (konstanter Wert). Das bedeutet, daß bei Veränderungen des Taktes Zeitmessungen mit QPC (aber nur bei SMP/SMT) einfach falsch sind, Windows selbst seine empfohlene Funktion für genaue Zeitmessungen aushebelt. Wirklich clever! Ich frage mich schon eine ganze Weile, wieso das mit den letzten ServicePacks nie behoben wurde.

Gipsel

[mbee]

Das bedeutet, daß bei Veränderungen des Taktes Zeitmessungen mit QPC (aber nur bei SMP/SMT) einfach falsch sind, Windows selbst seine empfohlene Funktion für genaue Zeitmessungen aushebelt. Wirklich clever! Ich frage mich schon eine ganze Weile, wieso das mit den letzten ServicePacks nie behoben wurde.

Gipsel

Ist das dann auch die Erklärung für die momentanen Probleme mit C&Q und X2-CPUs (bei mir verringert sich z.B. beim Heruntertakten der CPU im C&Q-Betrieb auch die Mausbeschleunigung des Maustreibers von Logitech) oder liege ich da völlig daneben?

[DjDino]

Wahnsinn was ihr hier draufhapt mit dem fachsimpeln.
Aber ich bin irgendwie verwirrt,
Praxis : Wenn jetzt also ein Spiel unnatürlich zu schnell läuft oder ruckelt, muss dann jetzt der "/usepmptimer"-Switch entfernt werden oder nur ein Core zugewiesen werden ? Und helfen beide Methoden bei Rucklern oder zu schnellem Gameplay oder muss je nach dem ob es nur ruckelt oder aber nur zu schnell läuft explizit NUR einer der beiden Methoden verwendet werden ?

[DjDino]

Scheint so das Microsoft hier nun etwas behoben hat : Microsoft Hotfix verbessert Dual-Core Performance (http://www.hardwareluxx.de/story.php?id=2957)

Wird das auch die Perfomance,Ruckel-Probleme in Spielen beheben ?

[mbee]

Gibt's dazu schon einen Link?
Ich habe offengestanden keine Lust jetzt für den Telefonsupport zu blechen und die ganzen Fragen schon wieder zu beantworten (der kostenfreie ist aufgebraucht) und bis zum SP3 ist's ja noch ne Weile hin ;)

[mbee]

Wahnsinn was ihr hier draufhapt mit dem fachsimpeln.
Aber ich bin irgendwie verwirrt,
Praxis : Wenn jetzt also ein Spiel unnatürlich zu schnell läuft oder ruckelt, muss dann jetzt der "/usepmptimer"-Switch entfernt werden oder nur ein Core zugewiesen werden ? Und helfen beide Methoden bei Rucklern oder zu schnellem Gameplay oder muss je nach dem ob es nur ruckelt oder aber nur zu schnell läuft explizit NUR einer der beiden Methoden verwendet werden ?

Ich würde den Switch niemals entfernen (es hat auch seinen Grund das dieser z.B. vom AMD-Prozessortreiber oder XP selbst bei der Installation gesetzt wird)!
Vorausgesetzt der Timer des Chipsatzes läuft vernünftig, machen damit die wenigsten Anwendungen Probleme. Falls es welche gibt, zuerst C&Q deaktivieren (das man eh erst mit diesem Switch "halbwegs vernünftig" verwenden kann) bzw. das Energieschema auf Desktop stellen und falls das nichts hilft, den Prozeß einem Core zuweisen (bei mir bei keiner Anwendung nötig bislang).
Ohne den Switch macht C&Q noch mehr Probleme und die Zuweisung zu einem Core ist bei noch mehr Anwendungen erforderlich.

[Coda]

Es ist ja sogar noch viel schlimmer! Windows benutzt bei Uni-Prozessorsystemen für QueryPerformanceCounter den Zeitgeber fürs Powermanagement (diese 3.58MHz) und NUR im SMP-Fall (oder SMT) den TSC.Das riecht aber verdammt nach Bug, weil es absolut keinen Sinn macht.

[mbee]

Scheint so das Microsoft hier nun etwas behoben hat : Microsoft Hotfix verbessert Dual-Core Performance (http://www.hardwareluxx.de/story.php?id=2957)

Wird das auch die Perfomance,Ruckel-Probleme in Spielen beheben ?

Zumindest scheint es die Probleme mit C&Q beim X2 zu beheben. Mit Dualcore und dem "/usepmtimer"-Switch habe ich bislang (ohne C&Q) bei keiner Anwendung hier Probleme.

[Coda]

Zumindest scheint es die Probleme mit C&Q beim X2 zu beheben. Mit Dualcore und dem "/usepmtimer"-Switch habe ich bislang (ohne C&Q) bei keiner Anwendung hier Probleme.Die die direkt RDTSC benützen kommen trotzdem draus, z.B. das SS2-Demo.

Nach nem Post in Seriously-Forum glauben die nämlich, dass /usepmtimer was an RDTSC ändert. Auf meine PM hat er allerdings noch nicht geantwortet.

[DjDino]

Danke

Der Admin "don" dort sucht nach einem Patch-Link : http://www.hardwareluxx.de/story.php?id=2957#3 (siehe Posting3) - leider nichts geworden bis jetzt.


Ich habe nur die Registry-Änderung des Patches genug verstanden und online als REG-Datei gestellt : http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3554756&postcount=2 Allerdings erfordert diese REG auch zusätzlich die anderen Änderungen wie es scheint weil dort steht : "After you install the hotfix that is described in this article, follow these steps" - also weis ich nicht ob das alleine etwas bringt.

[mbee]

Danke

Der Admin "don" dort sucht nach einem Patch-Link : http://www.hardwareluxx.de/story.php?id=2957#3 (siehe Posting3) - leider nichts geworden bis jetzt.


Ich habe nur die Registry-Änderung des Patches genug verstanden und online als REG-Datei gestellt : http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3554756&postcount=2 Allerdings erfordert diese REG auch zusätzlich die anderen Änderungen wie es scheint weil dort steht : "After you install the hotfix that is described in this article, follow these steps" - also weis ich nicht ob das alleine etwas bringt.

Glaube ich auch nicht, da die Einstellungen wohl erst nach den ausgetauschten Kernel-Dateien greifen werden.

[mbee]

Die die direkt RDTSC benützen kommen trotzdem draus, z.B. das SS2-Demo.

Nach nem Post in Seriously-Forum glauben die nämlich, dass /usepmtimer was an RDTSC ändert. Auf meine PM hat er allerdings noch nicht geantwortet.

Stimmt, hatte ich vergessen da mittlerweile deinstalliert (funzte bei mir auch erst nach Zuweisung zu einem Core).

[Coda]

Danke

Der Admin "don" dort sucht nach einem Patch-Link : http://www.hardwareluxx.de/story.php?id=2957#3 (siehe Posting3) - leider nichts geworden bis jetzt.


Ich habe nur die Registry-Änderung des Patches genug verstanden und online als REG-Datei gestellt : http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3554756&postcount=2 Allerdings erfordert diese REG auch zusätzlich die anderen Änderungen wie es scheint weil dort steht : "After you install the hotfix that is described in this article, follow these steps" - also weis ich nicht ob das alleine etwas bringt.Was hilft ist das Utility "runfirst". Das legt die Thread-Affinität nach dem Start auf eine CPU.

[DjDino]

Was hilft ist das Utility "runfirst". Das legt die Thread-Affinität nach dem Start auf eine CPU.
Ist das ndaselbe wie wenn ich das mit der Prozess-Core-Zuweisung im Taskmanager mache, da werden doch auch alle Threads des Prozesses auf einen Core gelegt oder nicht ?

[Coda]

Ja, aber das kann man in einen Link einfügen und hat dann keine Arbeit jedesmal.

[DjDino]

http://www.activeplus.com/us/freeware/runfirst/
Ist natürlich bequemer,danke.

Ich hoffe jemand erbarmt sich noch und ruft mei MS wegen dem Patch an und ist Willens ihn online zu stellen.

[Coda]

Ich hoffe jemand erbarmt sich noch und ruft mei MS wegen dem Patch an und ist Willens ihn online zu stellen.Das ist kein Fehler von Microsoft, sondern von den Spieleentwicklern. Unter Linux hätte man z.B. exakt das selbe Problem.

Das einzige was MS machen könnte wäre per Hotfix den /usepmtimer auf SMP Systemen setzen.

[DjDino]

Heist das, das demnach komplett auszuschliesen ist das solche Probleme mit anderen Anwendungen (auser Games) auftretten ?

[Coda]

Nein, nur brauchen andere Anwendungen normal keine genaue Zeitmessung.

[DjDino]

Warum genau macht die RDTSC-Zeitmessung da Probleme ?

[DjDino]

Das KB896256 Hotfix ist hier in einem privaten Updatepack enthalten : http://www.whatcounter.com/dlcount.php?id=RyanVM&url=files/RVMUpdatePack1.3.1.cab
"KB896256 - A Windows XP SP2-based computer that has multiple processors exhibits decreased performance or unexpected behavior"

Download : http://www.whatcounter.com/dlcount.php?id=RyanVM&url=files/RVMUpdatePack1.3.1.cab Ist in der CAB.

[Coda]

Weil die 2. CPU erst später aktiviert wird und damit einen anderen Timestamp hat. Das OS verschiebt die Apps aber bei Taskswitches öfter mal auf einen anderen Core und dann ist der Timestamp anders.

Der TSC ist ein Prozessor-internes Register, da hat das OS keinen Einfluss drauf.

[DjDino]

Sorry, der Download funktioniert nur über die Webseite.

http://ryanvm.msfn.org/updatepack.html -> ganz runterscrollen zu "Downloads" -> Post-SP2 Update Pack 1.3.1.

Leider weis ich nicht wie weiter jetzt...

[Gipsel]

Das riecht aber verdammt nach Bug, weil es absolut keinen Sinn macht.
Ist aber scheinbar wirklich Design von MS. In dem Support-Artikel zu dem Hotfix steht:
Correct TSC Synchronization
[..]On computers that have multiple processors, the TSC is typically the operating system hardware timer that backs calls to the kernel KeQueryPerformanceCounter function. When TSC does not increment monotonically, system components that use the kernel KeQueryPerformanceCounter function may not work correctly. Microsoft has addressed this problem by making it possible for the ACPI Power Management Timer to be used as the platform hardware that supports the kernel KeQueryPerformanceCounter function.
Wirklich super wie die sich anpreisen ein Problem mittels des "/usepmtimer" gelöst zu haben, was sie selber erst durch die Nutzung des TSCs beim SMP-HAL herbeigeführt haben. Der Uni-Processor-HAL nutzt ja wie schon erwähnt standardmäßig den PM-Timer.

Gipsel

[Coda]

Ist aber scheinbar wirklich Design von MSMicrosoft verkauft so manches als "Design" *hust* ;)

[Legende]

Wahrscheinlich passt das jetzt nicht zum Thema, aber was macht eigentlich "/NoExecute=OptIn" in der boot.ini ?

[mbee]

Die Aktivierung des NX-Features (und zwar nur für Systemprozesse) des A64.

[(del)]

Sorry, der Download funktioniert nur über die Webseite.

http://ryanvm.msfn.org/updatepack.html -> ganz runterscrollen zu "Downloads" -> Post-SP2 Update Pack 1.3.1.

Leider weis ich nicht wie weiter jetzt...
Leute es wird wohl kein Prob für euch sein die Exe zu besorgen oder? Ich zähle auf euch in-insider :wink:

[mbee]

http://www.xp-sp2-updatepack.de.vu/
Sind zwar 50 MB (auch noch einige andere Hotfixes), aber er ist darunter und kann auch einzeln installiert werden.
EDIT: Und es funzt! Mit C&Q volle Punktzahl bei Aquamark und CS:Source VST (was zuvor nie der Fall war) und der Setpoint-Treiber von Logitech verringert mit C&Q auch nicht mehr die Mausempfindlichkeit :up:

[DjDino]

http://www.xp-sp2-updatepack.de.vu/
Sind zwar 50 MB (auch noch einige andere Hotfixes), aber er ist darunter und kann auch einzeln installiert werden.
EDIT: Und es funzt! Mit C&Q volle Punktzahl bei Aquamark
Thanks for the Link.Kann ich bestätigen, selber Score wie ohne C&Q.

[mirp]

Ich muss noch ein wenig testen. Aber bisher lautet mein Fazit: Das Update behebt bei mir alle Dual-Core Probleme, nicht nur den Leistungsverlust unter C'n'Q. Selbst Anwendungen denen man nur eine CPU zur Verfügung stellen durfte, laufen jetzt auch mit beiden. Die Erkennung der Taktfrequenz scheint nun auch besser zu funktionieren.

[mbee]

Jetzt fehlt nur noch ein Fix für XP64, aber ich befürchte, dass es hier keinen Hotfix geben wird bzw. MS sich bis zum nächsten SP Zeit lässt.

[tenchimuyo987]

geht das Update auch mit dem SP1?

[MegaManX4]

http://www.xp-sp2-updatepack.de.vu/
Sind zwar 50 MB (auch noch einige andere Hotfixes), aber er ist darunter und kann auch einzeln installiert werden.
EDIT: Und es funzt! Mit C&Q volle Punktzahl bei Aquamark und CS:Source VST (was zuvor nie der Fall war) und der Setpoint-Treiber von Logitech verringert mit C&Q auch nicht mehr die Mausempfindlichkeit :up:

Super! Das Update Pack hat mir mal eben meine 32bit Installation zerschossen. Taskleiste ist nur noch ein weißer Streifen, Icons sind weg.

Klasse, jetzt darf ich erstmal neuinstallieren. Als arbeitender Mensch hat man sonst ja auch nix anderes am Wochenende zu tun!
Jetzt darf ich alles neu aufsetzen, denn wenn ich nur XP32 drüberbügel zerschießt mir das garantiert meine XP64 Bootkonfig.
Ich bin vielleicht geladen. Wäre ich mal lieber bei den Updatepacks von winhelpline geblieben.

[(del)]

http://www.xp-sp2-updatepack.de.vu/
Sind zwar 50 MB (auch noch einige andere Hotfixes), aber er ist darunter und kann auch einzeln installiert werden.
EDIT: Und es funzt! Mit C&Q volle Punktzahl bei Aquamark und CS:Source VST (was zuvor nie der Fall war) und der Setpoint-Treiber von Logitech verringert mit C&Q auch nicht mehr die Mausempfindlichkeit :up:
Kriegt das wirklich keiner da raus? :frown:

[(del)]

Super! Das Update Pack hat mir mal eben meine 32bit Installation zerschossen. Taskleiste ist nur noch ein weißer Streifen, Icons sind weg.

Klasse, jetzt darf ich erstmal neuinstallieren. Als arbeitender Mensch hat man sonst ja auch nix anderes am Wochenende zu tun!
Wie wäre es so mitten in der Woche mit einem Image? :rolleyes:

[MegaManX4]

Wie wäre es so mitten in der Woche mit einem Image? :rolleyes:

Bringt nix. Wer weiß was ich in einem halben Jahr für ein Mobo habe? Images bringen nur was, wenn die Syskonfig mehr oder minder gleich bleibt. Kann ich aber berufsbedingt nicht garantieren.

[Benny12345]

http://www.xp-sp2-updatepack.de.vu/
Sind zwar 50 MB (auch noch einige andere Hotfixes), aber er ist darunter und kann auch einzeln installiert werden.
EDIT: Und es funzt! Mit C&Q volle Punktzahl bei Aquamark und CS:Source VST (was zuvor nie der Fall war) und der Setpoint-Treiber von Logitech verringert mit C&Q auch nicht mehr die Mausempfindlichkeit :up:

Wie kann ich den einzeln installen ??

[Benny12345]

Ok habs installiert...

Aber auf der MS-Homepage ist von:

Halmacpi.dll
Ntkrnlmp.exe
Ntkrpamp.exe

die Rede....

Bei mir hat er aber:

Hal.dll
Ntkrnlpa.exe
Ntoskrnl.exe

installiert (waren auch schon vorher drauf)

Ist da etwas falschgelaufen ???

Sind das nicht die Dateien für Singlecore-CPUs ????


Jetzt bin ich richtig verwirrt....

[Coda]

Also irgendwie funktioniert bei mir nach dem Hotfix gar kein C'n'Q mehr.

EDIT: Ok, musste nochmal den Prozessortreiber installieren. Jetzt scheint's zu gehen.

Der Fix synchronisiert die TSC übrigens wirklich beinahe. Aber eben nur beinahe, es können immer noch Probleme auftreten.

[DjDino]

Wie kann ich den einzeln installen ??
Die KB896256 darin verwenden.
geht das Update auch mit dem SP1?
Nein, ist nur für das SP2.
"Die Informationen in diesem Artikel beziehen sich auf:
• Microsoft Windows XP Professional SP2
• Microsoft Windows XP Home Edition SP2" steht da :
http://support.microsoft.com/?id=896256

[Benny12345]

Ok habs installiert...

Aber auf der MS-Homepage ist von:

Halmacpi.dll
Ntkrnlmp.exe
Ntkrpamp.exe

die Rede....

Bei mir hat er aber:

Hal.dll
Ntkrnlpa.exe
Ntoskrnl.exe

installiert (waren auch schon vorher drauf)

Ist da etwas falschgelaufen ???

Sind das nicht die Dateien für Singlecore-CPUs ????


Jetzt bin ich richtig verwirrt....


Dualcore-User schaut mal bitte nach ob das normal ist....


MfG Benny

[mirp]

Wie kann ich den einzeln installen ??Mit UpdatePack-Files\update\winupdate.exe lassen sich die Updates einzeln auswählen.

Ok habs installiert...

Aber auf der MS-Homepage ist von:

Halmacpi.dll
Ntkrnlmp.exe
Ntkrpamp.exe

die Rede....

Bei mir hat er aber:

Hal.dll
Ntkrnlpa.exe
Ntoskrnl.exe

installiert (waren auch schon vorher drauf)

Ist da etwas falschgelaufen ???

Sind das nicht die Dateien für Singlecore-CPUs ????


Jetzt bin ich richtig verwirrt....Die Dateien liegen unter WINDOWS\Driver Cache\i386.

[DjDino]

Ok habs installiert...

Aber auf der MS-Homepage ist von:

Halmacpi.dll
Ntkrnlmp.exe
Ntkrpamp.exe

die Rede....

Bei mir hat er aber:

Hal.dll
Ntkrnlpa.exe
Ntoskrnl.exe

installiert (waren auch schon vorher drauf)

http://support.microsoft.com/kb/309283/de#XSLTH3136121122120121120120
Halmacpi.dll = ACPI-Multiprozessor-PC
Hal.dll = Standard-PC (ohne ACPI)

Sehr seltsam, denn ohne ACPI geht ja normal kein Multiprozessing und ohne ACPI geht auch kein APIC (=nur noch PIC-Modus mit nur 16 IRQs)
Schau mal ob du eh noch 24 mögliche IRQs hast.

[DjDino]

@Benny12345
Ist bei mir (X2-CPU) nach dem Update genauso wie bei dir (HAL.DLL und das andere), weis aber nicht ob es vorher anders war.

[(del)]

Bringt nix. Wer weiß was ich in einem halben Jahr für ein Mobo habe? Images bringen nur was, wenn die Syskonfig mehr oder minder gleich bleibt. Kann ich aber berufsbedingt nicht garantieren.
Wer weiß aber was nach einem Update passiert? ;)

[Benny12345]

http://support.microsoft.com/kb/309283/de#XSLTH3136121122120121120120
Halmacpi.dll = ACPI-Multiprozessor-PC
Hal.dll = Standard-PC (ohne ACPI)

Sehr seltsam, denn ohne ACPI geht ja normal kein Multiprozessing und ohne ACPI geht auch kein APIC (=nur noch PIC-Modus mit nur 16 IRQs)
Schau mal ob du eh noch 24 mögliche IRQs hast.

Schau dir mal dieses Bild an: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=3558034&postcount=67

Da steht ACPI-Multiprozessor aber trotzdem verwendets die hal.dll

IRQs sinds 24

Hab vor 3 tagen WinXP neu draufgemacht....

Kanns daran liegen dass ich C&Q ausgeschaltet hab (schon immer) ??

[DjDino]

Vielleicht wurde die halmacpi.dll aus irgendwelchen Kompatibilitätsgründen in hal.dll unbenannt, ist also aber in Wahrheit doch eine halmacpi.dll.

Such mal die halamacpi.dll,mach einen Mausrechtsklick drauf->"Version" und schau was dort oben bei "Beschreibung" oder unten bei "Produktbeschreibung" in der Liste steht.

[mbee]

Super! Das Update Pack hat mir mal eben meine 32bit Installation zerschossen. Taskleiste ist nur noch ein weißer Streifen, Icons sind weg.

Klasse, jetzt darf ich erstmal neuinstallieren. Als arbeitender Mensch hat man sonst ja auch nix anderes am Wochenende zu tun!
Jetzt darf ich alles neu aufsetzen, denn wenn ich nur XP32 drüberbügel zerschießt mir das garantiert meine XP64 Bootkonfig.
Ich bin vielleicht geladen. Wäre ich mal lieber bei den Updatepacks von winhelpline geblieben.


Das ist natürlich ärgerlich. Das Paket ist auch nicht dazu gedacht, mal alles einfach draufzuknallen (falls Du das getan hast): Es ist eine Hotfix-Sammlung und diese sind weitaus nicht so geprüft wie die öffentlichen Patches bzw. sollten nur im Bedarfsfall einzeln installiert werden (was auch dabei steht). Ich habe nur den Dual-Core-Hotfix installiert (ohne Nebenwirkungen).
Kein System-Restore-Point vorhanden?

@Benny12345: Das scheint so schon in Ordnung zu sein, ist bei mir auch so und die Dateien haben trotzdem das richtige Datum bzw. die richtige Versionsnummer. Ggf. werden diese wirklich bei der Installation umbenannt (im Driver-Cache-Ordner wurden diese mit den bei MS genannten Bezeichnungen angelegt).

[Gast]

Also was bei der Dateibeschreibung deiner hal.dll so steht : (Beispiel : http://members.chello.at/djdino/temp/dateieigenschaften.png )

[Benny12345]

LOOL

Da steht wirklich halmacpi.dll....

Bei den beiden Kernel-EXEs genau dasselbe...

Dann bin ich ja beruhigt....

MfG Benny

[Benny12345]

Der Fix synchronisiert die TSC übrigens wirklich beinahe. Aber eben nur beinahe, es können immer noch Probleme auftreten.

Wieso beinahe ? Wie hast du das festgestellt ??

Bei mir ist z. B. der FPS-Counter in UT2004 immernoch fehlerhaft und wenn ich ne Seite anping und dann die ping.exe auf ne andere CPU leg werden die pings unrealistisch kurz (2ms statt 14 wie normalerweise)....

Werd mal den PCMark05 testen. Der ging auch nur wenn man /usepmtimer in die boot.ini gekloppt hat...

MfG Benny

[Coda]

Wieso beinahe ? Wie hast du das festgestellt ??Eigenes simples Testprogram

Bei mir ist z. B. der FPS-Counter in UT2004 immernoch fehlerhaft und wenn ich ne Seite anping und dann die ping.exe auf ne andere CPU leg werden die pings unrealistisch kurz (2ms statt 14 wie normalerweise)....Ja, eben nur beinahe. Aber es ist besser als vorher ;)

[mbee]

Werd mal den PCMark05 testen. Der ging auch nur wenn man /usepmtimer in die boot.ini gekloppt hat...

MfG Benny

Du solltest /usepmtimer ja auch drinlassen (auch mit dem Hotfix) bzw. reinsetzen, falls es nicht in der boot.ini steht. Das ist dafür kein Ersatz.

[Benny12345]

Oh kacke.

PCMark05 geht immernoch ned.

Also kein Ersatz für /usepmtimer

Schade wars....

[Benny12345]

Du solltest /usepmtimer ja auch drinlassen (auch mit dem Hotfix) bzw. reinsetzen, falls es nicht in der boot.ini steht. Das ist dafür kein Ersatz.

Mit /usepmtimer hab ich aber manchmal unrealistisch hohe CPU-Frequenzen in CS:S um die 13000 MHz....

[mbee]

Diese Anzeige ist IMO im Gegensatz zu den Vorteilen doch ziemlich wurst oder? ;)
Zumindest bei mir macht diese Einstellung deutlich weniger Probleme und sie wird auch vom AMD-Treiber oder bei einer Neuinstallation von XP so vorgenommen.

[Benny12345]

Diese Anzeige ist IMO im Gegensatz zu den Vorteilen doch ziemlich wurst oder? ;)
Zumindest bei mir macht diese Einstellung deutlich weniger Probleme und sie wird auch vom AMD-Treiber oder bei einer Neuinstallation von XP so vorgenommen.

Bei der Neuinstallation wird sie NICHT vorgenommen. (Zumindest bei mir nicht)

Aber das mit dem /usepmtimer funzt jetzt:

UT2004 fps sind korrekt angezeigt.(Ging vorher trotz /usepmtimer nicht)

Bei CS:S schwankts nur noch zwischen 2,3 und 2,5GHz (bis jetzt...)

ScienceMark 2.0 zeigt bei beiden CPUs die gleiche Taktfrequenz und nicht 2394 und 18000 oder so......

Also schonmal Danke für den Tipp...

[Coda]

UT2004 fps sind korrekt angezeigt.(Ging vorher trotz /usepmtimer nicht)pmtimer wirkt sich nur auf QPC aus, RDTSC kann davon nicht beeinflusst werden.

Ganz richtig ist es aber immer noch nicht, weil es eben immer noch kleine Abweichungen gibt.

[Benny12345]

pmtimer wirkt sich nur auf QPC aus, RDTSC kann davon nicht beeinflusst werden.

Ganz richtig ist es aber immer noch nicht, weil es eben immer noch kleine Abweichungen gibt.

Hmm hab jetzt ne halbe Stund UT2004 gezockt un es wurden net n einziges Mal (hab die ganze Zeit oben ins Eck geschaut ;)) falsche FPS angezeigt...

Resüme:

Ohne Hotfix, /usepmtimer, Runfirst FPS falsch
Nur mit mit Runfirst FPS OK
Nur mit /usepmtimer FPS falsch
Nur mit Hotfix FPS falsch
Mit Hotfix und /usepmtimer FPS OK

MfG Benny

[Gipsel]

Ganz richtig ist es aber immer noch nicht, weil es eben immer noch kleine Abweichungen gibt.
Die sind aber meiner Ansicht nach ok. Die Programmierer sollten schon selbst dafür sorgen, daß sie bei Benutzung des TSCs immer die gleiche CPU ansprechen (ist ja im Prinzip ganz einfach). Das sie jetzt mit dem Hotfix von Windows schon (fast) synchronisiert werden, bügelt da schon einen Teil der Unterlassungen der Programmierer aus.
Wirklich wichtig ist aber, daß man überhaupt eine verläßliche Zeitmessung hat. QPC ist ja ohne den /usepmtimer switch für die Tonne.

[Benny12345]

Hmm hab jetzt ne halbe Stund UT2004 gezockt un es wurden net n einziges Mal (hab die ganze Zeit oben ins Eck geschaut ;)) falsche FPS angezeigt...

Resüme:

Ohne Hotfix, /usepmtimer, Runfirst FPS falsch
Nur mit mit Runfirst FPS OK
Nur mit /usepmtimer FPS falsch
Nur mit Hotfix FPS falsch
Mit Hotfix und /usepmtimer FPS OK

MfG Benny


OK

Kommando zurück.

Eben hats wieder komische fps angezeigt und bei Sciencemark sind die Frequenzen wieder deutlich verschieden.....

Oh verdammt, hab mich schon gefreut endlich das Problem los zu sein.... :(

EDIT: Seltsam. Wenn ich neustarte gehts wieder alles.
Kann das sein das der Timer nach ner Weile "ausm Takt" kommt....??

[Benny12345]

OK

Kommando zurück.

Eben hats wieder komische fps angezeigt und bei Sciencemark sind die Frequenzen wieder deutlich verschieden.....

Oh verdammt, hab mich schon gefreut endlich das Problem los zu sein.... :(

EDIT: Seltsam. Wenn ich neustarte gehts wieder alles.
Kann das sein das der Timer nach ner Weile "ausm Takt" kommt....??


Scheint wirklich langsam ausm Takt zu kommen weil ich bei ScienceMark 2.0 sehr schön sehen kann wie der Frequenzunterschied der CPUs immer grösser wird (statt beide 2400 haben sie dann 2400 und 2408 und nach ner Weile dann 2392 und 2414 usw.).....

Reboot und alles ist wieder in Ordnung (für ne kurze Zeit :()

Alles seeeehr seltsam......

[Benny12345]

So jetzt hat die eine CPU in Sciencemark schon 2438MHz Tendenz steigend....

Wie kann sowas möglich sein. Verändert sich der Mainboard-Timer mit der Zeit ???

[Coda]

Die sind aber meiner Ansicht nach ok. Die Programmierer sollten schon selbst dafür sorgen, daß sie bei Benutzung des TSCs immer die gleiche CPU ansprechen (ist ja im Prinzip ganz einfach). Das sie jetzt mit dem Hotfix von Windows schon (fast) synchronisiert werden, bügelt da schon einen Teil der Unterlassungen der Programmierer aus.
Wirklich wichtig ist aber, daß man überhaupt eine verläßliche Zeitmessung hat. QPC ist ja ohne den /usepmtimer switch für die Tonne.Natürlich ist es ok. Normal sollte man gar kein rdtsc im Code verwenden.

[Benny12345]

So jetzt hat die eine CPU in Sciencemark schon 2438MHz Tendenz steigend....

Wie kann sowas möglich sein. Verändert sich der Mainboard-Timer mit der Zeit ???

Hmm das Ganze tritt auch OHNE /usepmtimer auf....

Direkt nachm Reboot geht alles wunderbar aber nach ner Zeit stimmen dann dir Frequenzen im Sciencemark nimmer und bei UT2004 spackt der FPS-Counter ab.


@Coda: Kannst du mir mal dein Testproggie schicken ?


MfG Benny

[Muh-sagt-die-Kuh]

Sehr seltsam, denn ohne ACPI geht ja normal kein Multiprozessing und ohne ACPI geht auch kein APIC (=nur noch PIC-Modus mit nur 16 IRQs)
Schau mal ob du eh noch 24 mögliche IRQs hast.Seltsam ist das nicht, das ist Standard Windows-Verhalten: Die aktive HAL und der aktive Kernel finden sich immer als HAL.DLL und NTOSKRNL.EXE im System32 Verzeichnis.

SMP geht übrigens auch ohne ACPI => HALMPS.DLL

[Coda]

@Coda: Kannst du mir mal dein Testproggie schicken ?Das ist nur ein Konsolenprogram, dass in einer Schleife den TSC ausließt und wenn der Wert niedriger ist als der Letzte "<- Error" dahinterschreibt, Das darf nämlich normal nicht passieren.

Willst du das wirklich haben? ;)

[DjDino]

Seltsam ist das nicht, das ist Standard Windows-Verhalten: Die aktive HAL und der aktive Kernel finden sich immer als HAL.DLL und NTOSKRNL.EXE im System32 Verzeichnis.

SMP geht übrigens auch ohne ACPI => HALMPS.DLL
Ah so ist das, verleitet also nur zu der falschen Deutung.
Für SMP ist im Grunde nur APIC zwingend Vorrausetzung (damit Systeme mit mehreren CPUs diese Prozessoren untereinander kommunizieren können benötigen diese jeweils das lokal APIC)
Normal läuft WinXP ohne ACPI (Standart-PC) dadurch immer auch ohne APIC, deswegen meine Argumentation.MPS-Multiprozessor-PC (HALMPS.DLL) ist da eben die einzige Ausnahme, findet aber für Normaluser kaum sinnvollen Einsatz ohne ACPI und deren Vorteile.

[Benny12345]

Das ist nur ein Konsolenprogram, dass in einer Schleife den TSC ausließt und wenn der Wert niedriger ist als der Letzte "<- Error" dahinterschreibt, Das darf nämlich normal nicht passieren.

Willst du das wirklich haben? ;)

Ne brauchs doch ned ;)

Also nach längerem Test muss ich sagen dass das Hotfix leider NIX bringt.

Alle Games die Probleme machen haben diese auch nach dem Hotfix noch, egal ob mit /usepmtimer oder ohne (UT2004, CS:S, Farcry.....)

Der einzige Unterschied ist, dass der Fehler nach nen Neustart erst mal weg ist, sich dann aber die Taktfrequenz langsam zu "verstellen" scheint. Irgendwie bleibt sie nicht konstant was für mich echt n Rätsel ist....

Hätte gute Lust meine Prozzi zu verkaufen und dafür nen FX57 reinzustecken bis AMD die Probleme mit ner neuen Revision in den Griff bekommt....

Echt zum kotzen so langsam........

[(del)]

Thanks for the Link.Kann ich bestätigen, selber Score wie ohne C&Q.
Leute ich krieg ne Krise :frown: Der Link funzt nicht. Und die andere Adresse aus den Threads hier ist auch "down". Wo kriegt man das Ding nun her? :usad:

[GloomY]

Hätte gute Lust meine Prozzi zu verkaufen und dafür nen FX57 reinzustecken bis AMD die Probleme mit ner neuen Revision in den Griff bekommt....

Echt zum kotzen so langsam........Das sind Software-Problem. Das hat nichts mit der Hardware zu tun. Diese funktioniert einwandfrei.

Im Übrigen musst du nicht für jede Kleinigkeit umbedingt einen Post schinden. Qualität statt Quantität!

[mirp]

Die englische Version des Patches, die in diversen Foren herumgeistert, ist übrigens neuer (29.09.2005, 5.1.2600.2765). Allerdings funktioniert sie eben nicht mit einem deutschen Windows.

[Hesky]

Also wie heisst jetzt der DC Hotfix genau ? Will nämlich nur den installieren. Kein bock mein System zu zerschiesen.

[mbee]

Der deutsche Hotfix zum KB-Artikel mit der Nummer 896256, also KB896256. Stand hier im Thread allerdings auch schon mal...

[Coda]

Hätte gute Lust meine Prozzi zu verkaufen und dafür nen FX57 reinzustecken bis AMD die Probleme mit ner neuen Revision in den Griff bekommt...Ich sage es jetzt nochmal in aller Deutlichkeit: Das ist KEIN Problem von AMD!

Das ganze wird mit jeder SMP-Maschine so sein, sei es jetzt ein Dual-Opteron, Dual-Xeon, Pentium D oder Athlon 64 X2. Daran werden auch tausend Revisionen nichts ändern können.

Die Schuld liegt bei den Spieleentwicklern, die falsche Methoden zur Zeitmessung verwenden.

[zeckensack]

Die sind aber meiner Ansicht nach ok. Die Programmierer sollten schon selbst dafür sorgen, daß sie bei Benutzung des TSCs immer die gleiche CPU ansprechen (ist ja im Prinzip ganz einfach). Das sie jetzt mit dem Hotfix von Windows schon (fast) synchronisiert werden, bügelt da schon einen Teil der Unterlassungen der Programmierer aus.
Wirklich wichtig ist aber, daß man überhaupt eine verläßliche Zeitmessung hat. QPC ist ja ohne den /usepmtimer switch für die Tonne.Verstehe ich das richtig dass dieser Hotfix nur die TSCs synchronisiert und nicht dafür sorgt dass QPC wie auf Uniprozessorsystemen funktioniert? Sind die denn noch ganz klar in der Birne?

Mei ...

Btw, semi-OT, von wegen Timing-Problemen durch Cool'n'Quiet:
Timing-Probleme durch SpeedStep (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=250468)

[Coda]

Ich kann mir vorstellen, dass es SMP-Chipsätze gibt die Fehler im Chipsatz-HPT haben und MS deshalb nicht einfach überall /usepmtimer aktivieren kann.

[(del)]

Die englische Version des Patches, die in diversen Foren herumgeistert, ist übrigens neuer (29.09.2005, 5.1.2600.2765). Allerdings funktioniert sie eben nicht mit einem deutschen Windows.
Kernel ist doch sprachunabhängig (?) Ist bestimmt nur die bescheuerte Installroutine. Obwohl MS schon zig mal schrieb, daß sich "sprachneutrale"
Patches auf jedem System installieren lassen. Man ey :mad:
Man muß bestimmt wieder in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language
vor dem Install "Default" und "InstallLanguage" auf 0409 ändern und danach vor dem Booten zurück auf 0407.

Aber so oder so scheinen alle Links dazu erstmal down. Den einen haben sie abgeklemmt, der andere jammer weil das gleiche. Streß! :D

[(del)]

Der deutsche Hotfix zum KB-Artikel mit der Nummer 896256, also KB896256. Stand hier im Thread allerdings auch schon mal...
Der Link führt nicht zum Ergebnis ;) Ich sags ja gerne nochmal.

[mbee]

Er hat nach dem Hotfix gefragt, nicht nach nem Link ;)
Die KB-Nummer kann man bei MS dem entsprechenden Mitarbeiter am Telefon angeben und erhält dann den Hotfix. Hätte ich auch gemacht, wenn unser kostenfreier Support nicht aufgebraucht wäre.

[Gast]

Er hat nach dem Hotfix gefragt, nicht nach nem Link ;)
Die KB-Nummer kann man bei MS dem entsprechenden Mitarbeiter am Telefon angeben und erhält dann den Hotfix. Hätte ich auch gemacht, wenn unser kostenfreier Support nicht aufgebraucht wäre.
Die Hotfixes fallen doch nicht unter "Support" -> Kosten (??)

[mbee]

Doch, zumindest AFAIK und Du telefonierst in diesem Fall mit dem Support:
http://support.microsoft.com/gp/kontaktinfo

Falls nicht, spricht natürlich nichts dagegen und falls man seine kostenlosen zwei Anfragen noch nicht aufgebracht hat, schon gar nicht.

[Gipsel]

Verstehe ich das richtig dass dieser Hotfix nur die TSCs synchronisiert und nicht dafür sorgt dass QPC wie auf Uniprozessorsystemen funktioniert? Sind die denn noch ganz klar in der Birne?

Erstens ja, zweitens nein.

Ich habe sehr lange gebraucht, um überhaupt zu kapieren, was MS da für einen Mist gemacht hat.
Zuerst hatte ich bei einigen komischen Benchmarkergebnissen eines P4 mit HT auf einem MSI-Board (die ersten mit so einem Dynamic Overclocking "Feature") auch das Board im Verdacht die Frequenz des PerformanceCounters zu ändern. Auf die Idee, daß RDTSC für QPC im Multi-CPU-HAL benutzt wird, bin ich seeehr lange nicht gekommen (war ja auch nirgendwo dokumentiert).

Die (in meinen Augen unnötige) Synchronisation der TSCs funktioniert sowieso nur begrenzt und spätestens wenn irgendwann die Cores unabhängig voneinander takten ist es sowieso vorbei mit dem Hotfix. Das standardmäßige Setzen des /usepmtimer switches in der boot.ini durch einen Patch ist viel sinnvoller. Man kann ja wohl nicht jedem Nutzer zumuten, das manuell zu machen.

[mirp]

http://support.microsoft.com/?id=896256

Die Seite wurde gerade erneuert. Auf den ersten Blick fallen aber nur die neuen Dateiversionen auf. Es gibt immer noch keine Downloadmöglichkeit. Man muss weiterhin drum betteln.

Article ID : 896256
Last Review : October 10, 2005
Revision : 2.1

[Benny12345]

http://support.microsoft.com/?id=896256

Die Seite wurde gerade erneuert. Auf den ersten Blick fallen aber nur die neuen Dateiversionen auf. Es gibt immer noch keine Downloadmöglichkeit. Man muss weiterhin drum betteln.

Article ID : 896256
Last Review : October 10, 2005
Revision : 2.1

Hab den Patch grad mal "bestellt", soll heut noch per email kommen....

[Benny12345]

So.

Patch is grad gekommen. Hab aber bis jetzt noch keinen Unterschied bemerkt...

MfG Benny

[GloomY]

Ich habe sehr lange gebraucht, um überhaupt zu kapieren, was MS da für einen Mist gemacht hat.Ja, das ist wirklich idiotisch :|
Die (in meinen Augen unnötige) Synchronisation der TSCs [...]Wie funktioniert das eigentlich technisch? Das Auslesen ist ja eine Hardwareangelegenheit, die man nicht mittels Betriebssystem abfangen kann. Oder gibt es einen Befehl, um den TSC umzuprogrammieren? Wird da konkret der Wert des einen TSCs gelesen und dann dem anderen zugewiesen? :conf2:
[...] funktioniert sowieso nur begrenzt und spätestens wenn irgendwann die Cores unabhängig voneinander takten ist es sowieso vorbei mit dem Hotfix.Und das wird imho nicht lange auf sich warten lassen. Beim kommenden Doppelkernprozessor Jonah kann sich AFAIR jeder Kern selbstständig runtertakten. Spätestens also in ein paar Monaten kommt dann das Problem trotz Patch wieder auf die Anwender und Programmierer zu.
Das standardmäßige Setzen des /usepmtimer switches in der boot.ini durch einen Patch ist viel sinnvoller. Man kann ja wohl nicht jedem Nutzer zumuten, das manuell zu machen.Ich denke, dass das im nächsten großen Servicepack enthalten sein muss. Ansonsten hätte sich Windows dann für einen Mehrprozessorbetrieb disqualifiziert. Man kann ja nicht erwarten, dass die Programmierer alle ihre eigene Timing-Routinen mitbringen, weil die vom Betriebssystem bereitgestellten nicht zuverlässig funktionieren... :down:

[Coda]

Ja, das ist wirklich idiotisch :|
Wie funktioniert das eigentlich technisch? Das Auslesen ist ja eine Hardwareangelegenheit, die man nicht mittels Betriebssystem abfangen kann. Oder gibt es einen Befehl, um den TSC umzuprogrammieren? Wird da konkret der Wert des einen TSCs gelesen und dann dem anderen zugewiesen? :conf2:Soweit ich weiß kann man den TSC nur lesen. Ich denke das OS supsendiert solange die eine CPU bis die andere den gleichen Wert erreicht hat o.ä.

Und das wird imho nicht lange auf sich warten lassen. Beim kommenden Doppelkernprozessor Jonah kann sich AFAIR jeder Kern selbstständig runtertakten. Spätestens also in ein paar Monaten kommt dann das Problem trotz Patch wieder auf die Anwender und Programmierer zu.Das Problem lässt sich nicht vom OS beheben.

Ich denke, dass das im nächsten großen Servicepack enthalten sein muss. Ansonsten hätte sich Windows dann für einen Mehrprozessorbetrieb disqualifiziert.Sie sollten /usepmtimer als default nehmen, der Rest ist den App-Programmierern anzurechnen.

Man kann ja nicht erwarten, dass die Programmierer alle ihre eigene Timing-Routinen mitbringen, weil die vom Betriebssystem bereitgestellten nicht zuverlässig funktionieren... :down:Das geht auch gar nicht. Wie willst du denn auf HW-Level zugreifen von außerhalb Ring 0? RDTSC kann übrigens auch als priviledged instruction eingestellt werden, was MS gleich am Anfang machen hätte sollen.

[Gipsel]

Wie funktioniert das eigentlich technisch? Das Auslesen ist ja eine Hardwareangelegenheit, die man nicht mittels Betriebssystem abfangen kann. Oder gibt es einen Befehl, um den TSC umzuprogrammieren? Wird da konkret der Wert des einen TSCs gelesen und dann dem anderen zugewiesen? :conf2:
Der TSC ist auch nur ein prozessorspezifisches MSR, das zusätzlich über RDTSC als unprivilegiertem Befehl gelesen werden kann. Man kann das entsprechende MSR aber auch setzen (mit WRMSR). Soweit ich weiß, kann man aber speziell beim TSC nur die unteren 32Bit setzen, die oberen 32Bit werden ignoriert und dabei auf Null zurückgesetzt. Müßte ich aber sonst nochmal nachlesen. Windows wird also beim Booten einfach die TSCs beider Prozessoren möglichst zeitnah auf Null resetten. Das ist alles, denke ich.
Wenn man doch die vollen 64Bit setzen kann, könnte Windows versuchen die in regelmäßigen Abständen neu zu synchronisieren. Ist aber ziemlich sinnfrei.

Edit:
Habe gerade nochmal nachgeschaut, ab dem Prescott kann man mit WRMSR die vollen 64Bit des TSCs setzen, vorher nur die unteren 32Bit, wobei die oberen auf Null gesetzt werden. Wie es bei AMD aussieht, habe ich keine Ahnung.
Windows wird also nur einen Reset der TSCs durchführen. Was anderes funktioniert ja z.B. auf den Northwoods auch gar nicht.
Register 10H
IA32_TIME_STAMP_COUNTER
Timestamp Count Value
A 64-bit register accessed when referenced as a qword through a RDMSR, WRMSR or RDTSC instruction. Returns the current time stamp count value. All 64 bits are readable. On earlier processors, only the lower 32 bits are writable. On any write to the lower 32 bits, the upper 32 bits are cleared. For processor family 0FH, models 3 and 4: all 64 bits are writable.

[Gast]

Dieser Patch bringt bei Intel Prozessoren die Hyper Threading unterstützen nichts oder?

[(del)]

So.

Patch is grad gekommen
Na ist doch spitze.Und wo bleibt es? :tongue:

[(del)]

Ich denke, dass das im nächsten großen Servicepack enthalten sein muss
In der Beschreibung des Patches steht doch imho, daß man entweder bei MS anbimmelt oder sich bis zum nächster Servicepack (also SP3) gedulden muß.

@Gast
Ebenfalls in der Beschreibung steht es, daß es auch für Intels HT ist.

[Benny12345]

Na ist doch spitze.Und wo bleibt es? :tongue:

Willst haben ??

Kein Problem. Einfach deine E-Mail an mich pm(en) oder

ftp://benny12345.dyndns.org

Username: update
PW: update

MfG Benny

[(del)]

Willst haben ??

Kein Problem

Benny12345 :massa: Benny12345 :massa: Benny12345 :massa: Benny12345 :massa: :tongue:

Ich frag mich nur was die am Kernel so rumfrickeln, daß es von einem einzigen Patch mittlerweile die v3 gibt. Wahnsinn :O

Was merkst Du nicht? Hast Du C&Q schon vorher an gehabt bzw. Probs damit? Du mußt den PAtch ausführen, dann den Regeintrag machen bzw. das von DjDino hier abfeuern. Dann Neustart und dann den AMD64 Treiber von AMD ;) erneut installieren. Nach dem nächsten Neustart sind 99% der Probs die die Leute mit C&Q haben, WEG. Bzw. die Schwierigkeiten die Windows damit hat sind zu 99% nicht mehr so merkbar :mad:

Plus, bei 100% kann man die X2 jetzt auch übertakten ohne Probs mit C&Q zu bekommen. Was bei vielen noch der Fall zu sein scheinte. Also C&Q lief zwar halbwegs, aber wenn man übertaktet hat, spinnte das System merklichER. nun solls weg sein.

[Benny12345]

Benny12345 :massa: Benny12345 :massa: Benny12345 :massa: Benny12345 :massa: :tongue:

Ich frag mich nur was die am Kernel so rumfrickeln, daß es von einem einzigen Patch mittlerweile die v3 gibt. Wahnsinn :O

Was merkst Du nicht? Hast Du C&Q schon vorher an gehabt bzw. Probs damit? Du mußt den PAtch ausführen, dann den Regeintrag machen bzw. das von DjDino hier abfeuern. Dann Neustart und dann den AMD64 Treiber von AMD ;) erneut installieren. Nach dem nächsten Neustart sind 99% der Probs die die Leute mit C&Q haben, WEG. Bzw. die Schwierigkeiten die Windows damit hat sind zu 99% nicht mehr so merkbar :mad:

Plus, bei 100% kann man die X2 jetzt auch übertakten ohne Probs mit C&Q zu bekommen. Was bei vielen noch der Fall zu sein scheinte. Also C&Q lief zwar halbwegs, aber wenn man übertaktet hat, spinnte das System merklichER. nun solls weg sein.

Ich meine nur dass ich keinen Unterschied zum "alten" Hotfix merke. C&Q hab ich schon immer deaktiviert. Hab jetzt nur das neue Hotfix drauf und den /usepmtimer Eintrag sonst nichts, keine AMD-Treiber, kein Reg-Eintrag. Muss sagen die meisten Games laufen tadellos nur eben so Dinge wie UT2004 FPS Counter und Sciencemark spinnen noch rum aber daran lässt sich wohl nix ändern....

MfG Benny

[mbee]

So.

Patch is grad gekommen. Hab aber bis jetzt noch keinen Unterschied bemerkt...

MfG Benny


Ein Unterschied ist wohl, dass man den Registry-Eintrag nicht mehr bzw. nur noch mit "0" zum disablen braucht. Für die Aktivierung ist keiner mehr nötig (die "alte Version" setzte hier den entsprechenden Eintrag mit Wert "1" in der Registry voraus).
EDIT: Hast Du wohl schon selbst heraus gefunden (hatte Dein Posting erst nicht gesehen).

Tausend Dank für das FTP-Hosting :up:

[Benny12345]

Der Unterschied ist wohl, dass man den Registry-Eintrag nicht mehr bzw. nur noch mit "0" zum disablen braucht. Für die Aktivierung ist keiner mehr nötig.

Tausend Dank für das FTP-Hosting :up:

Kein Problem ;)

Hat mich echt gewundert dass die von MS nur meine Email wollten und 2h später war der Patch da bzw. ein Link.

Leider is der FTP etwas lahm weil er hier auf meinem Rechner läuft und es deshalb nur 48Kb/sec sind, aber der Hotfix ist ja zum Glück nicht soo groß...

MfG Benny

[(del)]

Tausend Dank für das FTP-Hosting :up:
Jou. Aber zum Schnorren selbst sind wir uns zu schade he? :biggrin:

Übrigens läuft der Kernel hier auf einer Single Maschine im Vergleich zu .2622 momentan ohne erkennbare oder messbare Nachteile. Und auch ohne Vorteile :wink:

Wie kommt man auf /usepmtimer? Weil im KB hab ich es nicht gesehen? (?) Ohne ist es dann aber nicht wirklich der Bringer oder? Trägt es etwa der AMD-Treiber ein oder muß man das zu Fuß - und auf jeden Fall - erledigen? An so ner Kiste sitzt ich erst am WE dran. Wollte dann alles bestens erledigen.

[Coda]

Dieser Patch bringt bei Intel Prozessoren die Hyper Threading unterstützen nichts oder?Ne, da is der TSC eh immer synchron.

[mirp]

Ne, da is der TSC eh immer synchron.Der Hotfix behebt aber auch andere Probleme. Und die beziehen sich nicht alle auf TSC.

Diese Windowseigenart wäre doch eigentlich eine Erklärung, warum EIST (mit HT) mehr Leistung kostet als C'n'Q. Es gab Situationen in denen trotz Last zu spät wieder hochgetaktet wurde.

http://www.computerbase.de/artikel/hardware/prozessoren/2005/test_intels_pentium_4_600-serie/4/#abschnitt_enhanced_speedstep

Aber ganz sicher bin ich mir nicht, ob das hier auch an Windows liegt. Die Probleme ähneln sich aber.

[DjDino]

@Benny12345

Ja, lade ihn doch bitte mal hoch :)

[DjDino]

ftp://benny12345.dyndns.org

Username: update
PW: update

MfG Benny
Super, Danke.

[DjDino]

Oh kacke.

PCMark05 geht immernoch ned.

Also kein Ersatz für /usepmtimer

Schade wars....
"HDD Test problems when /usepmtimer switch not present in boot.ini is fixed" : Quelle (http://www.hardwareluxx.de/story.php?id=2979)

[Legende]

Kommt dieses "Ruckeln" eigentlich nur auf Rechnern vor, welche C'n'Q aktieviert haben?

[Benny12345]

So.

Der FTP läuft wieder....

[Gipsel]

Leider is der FTP etwas lahm weil er hier auf meinem Rechner läuft und es deshalb nur 48Kb/sec sind
Hier gibt's volle 100MBit: WindowsXP-KB896256-v3-x86-DEU.exe (http://139.30.40.11/WindowsXP-KB896256-v3-x86-DEU.exe)

[mbee]

Jou. Aber zum Schnorren selbst sind wir uns zu schade he? :biggrin:

Ich hätte schon auch "geschnorrt", aber da hatte er den Link schon gepostet.


Wie kommt man auf /usepmtimer? Weil im KB hab ich es nicht gesehen? (?) Ohne ist es dann aber nicht wirklich der Bringer oder? Trägt es etwa der AMD-Treiber ein oder muß man das zu Fuß - und auf jeden Fall - erledigen? An so ner Kiste sitzt ich erst am WE dran. Wollte dann alles bestens erledigen.

Der AMD-Treiber mach diesen Eintrag bei der Installation (als EXE-Datei bzw. das Setup-Programm in diesem Fall), falls er noch nicht in der boot.in vorhanden ist. Bei Installation meiner Slipstream-SP2-CD von XP war der Eintrag übrigens auch bei einer frischen Neuinstallation auf dem X2-System schon vorhanden, genau so wie bei XP64 (auch Neuinstallation).

[DweF]

hallo,

hab ich den artikel richtig verstanden?,
für einen "p4-northwood mit htt" ist dieser hotfix völlig uninteressant.

ist das richtig?

danke im voraus

[(del)]

Kommt dieses "Ruckeln" eigentlich nur auf Rechnern vor, welche C'n'Q aktieviert haben?
Steht das hier im Thread etwa anders?

[Benny12345]

hallo,

hab ich den artikel richtig verstanden?,
für einen "p4-northwood mit htt" ist dieser hotfix völlig uninteressant.

ist das richtig?

danke im voraus

Jo ist relativ uninteressant. Ich weiss halt net was noch für Veränderungen drin sind ausser dem beschriebenen Fix....

MfG Benny

[Benny12345]

Steht das hier im Thread etwa anders?

Ja das tut es. Es tritt auch ohne C&Q auf.

Zumindest bei mir.

MfG Benny

[DweF]

Jo ist relativ uninteressant. Ich weiss halt net was noch für Veränderungen drin sind ausser dem beschriebenen Fix....

MfG Benny
DANKE

mfg

[(del)]

Jo ist relativ uninteressant. Ich weiss halt net was noch für Veränderungen drin sind ausser dem beschriebenen Fix....
In dem KB werden aber explizit Doppel-, DualCore- und Intels HT-Systeme erwähnt.

Ich hab so ein Gefühl in der Harnblase, daß sich da auch was für Speedstep getan hat. Mal sehen, ob sich das jemand diesjahr noch annimmt.

[DjDino]

Unter der vom 10.Oktober aktuallisierten http://support.microsoft.com/kb/896256/en-us steht nirgends das man den AMD-Prozessortreiber nach dem Patch neu (nochmal) installieren soll.Warum soll das dann nötig sein ? Ich mein wäre es so, so würde MS das als OS + Patch-Anbieter doch wohl wissen und hinweisen oder ?

[mbee]

Mußte ich beim neuen und beim alten Hotfix nicht machen. Bei Coda war es glaube ich allerdings beim dem alten Hotfix notwendig.

[(del)]

Mußte ich beim neuen und beim alten Hotfix nicht machen. Bei Coda war es glaube ich allerdings beim dem alten Hotfix notwendig.
Ich würd auch mal sagen, daß es anzuraten wäre.

Dafür kannst Du mal checken, ob man das bei V3 mit dem Regeintrag immernoch braucht. Als Meldung auf der Hauptseite "hier" steht, man bräuchte es.

edit: Ja wie? Den alten mußt du doch gehabt haben bevor Benny den aktuellen ins netz stellte. Hmm... :wink:

[DjDino]

Hm, bei der alten Version stand in dem MS-Link wie man die "state policy behavior" in der REG aktiviert,also :
"How to enable the new performance state policy behavior"

Bei der neuen vom 10.Oktober jetzt steht aber stattdesen wie man es deaktiviert :
"How to disable the new performance state policy behavior":
http://support.microsoft.com/kb/896256/en-us#XSLTH4140121124120121120120

Daraus schliese ich das dieser REG-Eintrag vom neuen V3-Patch jetzt schon automatisch vorgenommen wird...oder nicht ?

[(del)]

Hm, bei der alten Version stand in dem MS-Link wie man die "state policy behavior" in der REG aktiviert,also :
"How to enable the new performance state policy behavior"

Bei der neuen vom 10.Oktober jetzt steht aber stattdesen wie man es deaktiviert [...]

Daraus schliese ich das dieser REG-Eintrag vom neuen V3-Patch jetzt schon automatisch vorgenommen wird...oder nicht ?
Dann ist das in dem v3 Kernel die Standardeinstellung.

[mbee]

Yep, hatte ich hier übrigens schon geschrieben ;)
(Habe den Registry-Eintrag wieder gelöscht ohne negative Auswirkungen).

[(del)]

Yep, hatte ich hier übrigens schon geschrieben ;)
(Habe den Registry-Eintrag wieder gelöscht ohne negative Auswirkungen).
Du hast erstmal imho nur "anscheinend" oder so geschrieben ;) Jetzt müßte man das nur Leo sagen.

[Benny12345]

Hm, bei der alten Version stand in dem MS-Link wie man die "state policy behavior" in der REG aktiviert,also :
"How to enable the new performance state policy behavior"

Bei der neuen vom 10.Oktober jetzt steht aber stattdesen wie man es deaktiviert :
"How to disable the new performance state policy behavior":
http://support.microsoft.com/kb/896256/en-us#XSLTH4140121124120121120120

Daraus schliese ich das dieser REG-Eintrag vom neuen V3-Patch jetzt schon automatisch vorgenommen wird...oder nicht ?

Also hier hat er den besagten Regeintrag nicht automatisch erstellt...

[(del)]

Also hier hat er den besagten Regeintrag nicht automatisch erstellt...
Suchen tut er ihn aber. Um zu gucken, ob 0 drin steht. Sonst verhält es sich als wenn es ihn mit 1 geben würde. Schrieb ich ja, Standardeinstellung des Kernels. Nicht, Standardeinstellung in der Registry ;)

[DjDino]

Die Kernelmodifikation macht also diesen Registryeintrag total unötig und irrelevant, verstehe, Danke. Mann, mann...wird das langsam kompliziert hier...

[sloth9]

Um jetzt die allg. Kompliziertheitheit zu perfektionieren:

Wie schaut das Ganze jetzt bei W2k sp4 aus?

[Alge]

Um jetzt die allg. Kompliziertheitheit zu perfektionieren:

Wie schaut das Ganze jetzt bei W2k sp4 aus?

Hi!

Das würde mich jetzt auch interessieren. Und was ist wenn man kein Q&C möchte? -> Einfach nur /usepmtimer in die boot.ini?

Gruss
Alge

[(del)]

Die Kernelmodifikation macht also diesen Registryeintrag total unötig und irrelevant, verstehe, Danke
Jein. Der Regeintrag wird es nun benutzt um "es" abzuschalten und nicht mehr um es einzuschalten.

[DjDino]

Bezüglich DualCore-Perfomance scheint der Patch einiges zu bewirken, beim 3DMark05-CPU-Test gibt es einen kleinen, jedoch reproduzierbaren Abfall (war ebenfalls bei einem 2ten Durchlauf).Die Verluste bei PcMark04 sind schon seltsam, könnten aber auch ein Bug sein weil PCMark04 schon vor dem Patch erst nach mehreren Durchläufen überhaupt zu einem End-Score kam, ansonsten aber wegen einen Multithreaded-Test-Fehler keinen erzeugen konnte.Dieses Problem wurde auch durch den DualCore-Patch nicht behoben.


Getestet wurde mit meinem X2 und dem aktuellen V3-Patch mit im BIOS deaktivierten C&Q und um Messungenauigkeiten möglichst
gering zu halten jeweils nach einem Windows-Neustart ohne laufende Hintergrundprogramme (Autostart-Einträge,etc.).


3dmark05:

Vor Patch :
3DMark Score : 8647
CPU Score : 6740

Nach Patch :
3DMark Score : 8644
CPU Score : 6416

Aquamark 3 (unterstützt Hyperthreading) :

Vor Patch :
GFX : 17685
CPU : 11136
AquamarkScore : 98593

Nach Patch :
GFX : 17688
CPU : 11123
AquamarkScore : 98535

PcMark04-v130 (unterstützt DualCore/Hyperthreading) :

Vor Patch :
Multithreaded Test 1 / File Compression 7.03 MB/s
Multithreaded Test 1 / File Encryption 77.35 MB/s
Multithreaded Test 2 / File Decompression 62.11 MB/s
Multithreaded Test 2 / Image Processing 30.65 MPixels/s
Multithreaded Test 3 / Virus Scanning 5218.5 MB/s
Multithreaded Test 3 / Grammar Check 6.12 KB/s
PCMark04-Score : 7112

Nach Patch :
Multithreaded Test 1 / File Compression 3.79 MB/s
Multithreaded Test 1 / File Encryption 38.45 MB/s
Multithreaded Test 2 / File Decompression 31.1 MB/s
Multithreaded Test 2 / Image Processing 15.31 MPixels/s
Multithreaded Test 3 / Virus Scanning 2869.64 MB/s
Multithreaded Test 3 / Grammar Check 3.79 KB/s
PCMark04-Score : 5024




Kann jemand hier die Leistungsverluste nachvollziehen ?

[(del)]

Vor Patch :
Multithreaded Test 1 / File Compression 7.03 MB/s
Multithreaded Test 1 / File Encryption 77.35 MB/s
Multithreaded Test 2 / File Decompression 62.11 MB/s
Multithreaded Test 2 / Image Processing 30.65 MPixels/s
Multithreaded Test 3 / Virus Scanning 5218.5 MB/s
Multithreaded Test 3 / Grammar Check 6.12 KB/s
PCMark04-Score : 7112

Nach Patch :
Multithreaded Test 1 / File Compression 3.79 MB/s
Multithreaded Test 1 / File Encryption 38.45 MB/s
Multithreaded Test 2 / File Decompression 31.1 MB/s
Multithreaded Test 2 / Image Processing 15.31 MPixels/s
Multithreaded Test 3 / Virus Scanning 2869.64 MB/s
Multithreaded Test 3 / Grammar Check 3.79 KB/s
PCMark04-Score : 5024
Bis auf den Score selbst alle Ergebnisse sogut wie halbiert. hmm...

[DjDino]

PcMark04-v130 (unterstützt DualCore/Hyperthreading) :

Vor Patch :
Multithreaded Test 1 / File Compression 7.03 MB/s
Multithreaded Test 1 / File Encryption 77.35 MB/s
Multithreaded Test 2 / File Decompression 62.11 MB/s
Multithreaded Test 2 / Image Processing 30.65 MPixels/s
Multithreaded Test 3 / Virus Scanning 5218.5 MB/s
Multithreaded Test 3 / Grammar Check 6.12 KB/s
PCMark04-Score : 7112

Nach Patch :
Multithreaded Test 1 / File Compression 3.79 MB/s
Multithreaded Test 1 / File Encryption 38.45 MB/s
Multithreaded Test 2 / File Decompression 31.1 MB/s
Multithreaded Test 2 / Image Processing 15.31 MPixels/s
Multithreaded Test 3 / Virus Scanning 2869.64 MB/s
Multithreaded Test 3 / Grammar Check 3.79 KB/s
PCMark04-Score : 5024


KORREKTUR ! Die Ergebnisse sind doch ein Irrtum b.z.w. wegen irgendeinem einem Kompatibilitäts-Bug bei PcMark04.Nach erneutem hochfahren heute und anschliessendem Test waren die Ergebnisse alle wieder praktisch identisch (PCMark04-Score : 7108) mit jenen vor dem DC-Patch.
Wenn PcMark04 mit einem A64-DualCore so merkwürdig-niedrige Ergebnisse liefert muss es anscheinend neu gestartet werden.

Inzwischen habe ich ausserdem mit dem DulaCore-Tester schlechthin, mit CineBench 2003 (http://www.maxon.net/pages/download/cinebench.html) gebencht auch.Cool&Quiet ist aktiv (weil das MS ja zusammen mit dem Patch empfiehlt damit dieser wirksam ist) :

Vor DC-Patch : 641 CPU-Score
Nach DC-Patch : 640 CPU-Score

Einbussen durch den DC-Patch mit DualCore-Anwendungen sind dann also wohl doch falsch.

Da der DC-Patch eigentlich Perfomanceprobleme mit Single-Threaded-Anwendungen und der Zeitsynchronisation beheben soll hier Werte mit CineBench 2003 mit nur einer genutzen CPU.Es sollen da zwar nur Probleme mit Spielen behoben worden sein doch wollte ich das auch mal mit einer reinen CPU belastenden Anwendung testen :

Vor DC-Patch : 342 CPU-Score
Nach DC-Patch : 344 CPU-Score


Sorry für die Verwirrung die ich hier vielleicht ausgelöst habe vorher.

Der Patch macht also nichts schlechter, wenn dann nur besser :)

[(del)]

Um jetzt die allg. Kompliziertheitheit zu perfektionieren:

Wie schaut das Ganze jetzt bei W2k sp4 aus?
Wie wohl. Bei w2k wollte MS nichtmal brauchbare Unterstützung für HT nachrüsten...

[Coda]

Wieso, DualCore ist echtes SMP, damit dürfte W2K keinerlei Probleme haben.

Das Serious Sam 2 Demo 2 hat übrigens immer noch den gleichen Fehler. Und mit dem Hotfix läuft es jetzt sogar nur noch unter Direct3D ;(

[(del)]

Wieso, DualCore ist echtes SMP, damit dürfte W2K keinerlei Probleme haben
Jein. Ich meine, w2k wird mit CnQ die geichen Probs haben wie XP mit dem SP2 Kernel. Oder nicht?
Es ging drum, daß MS den w2k Kernel wegen HT nicht erneuern wollte, als w2k noch "full supported" war :mad:

[Avalox]

AMD: besseres Prozessor-"Zeitmanagement" in der Zukunft

"...Neu ist in diesem Zusammenhang die Ankündigung von AMD-Fellow Rich Brunner, dass man die TSCs in Zukunft umgestalten will, sodass sie unabhängig von den P- und C1-States und von STPCLK weiterarbeiten. Hierfür bekommt das CPUID-Register 0x8000_0007 (Advandes Powermanagement Information) ein neues Flag: TSCinvariant. "


http://www.heise.de/newsticker/meldung/65802

[Gipsel]

"[..] dass man die TSCs in Zukunft umgestalten will, sodass sie unabhängig von den P- und C1-States und von STPCLK weiterarbeiten."
So auf die Schnelle sehe ich darin nicht wirklich einen Sinn. Der TSC soll Taktzyklen zählen und fertig ist. Wenn man Zeit messen will, soll man dazu irgendeinen hochauflösenden Timer benutzen.
Wieso soll jetzt die Hardware Designfehler in der Software ausbügeln? Das ist doch ein wenig verquer.

[ShadowXX]

So auf die Schnelle sehe ich darin nicht wirklich einen Sinn. Der TSC soll Taktzyklen zählen und fertig ist. Wenn man Zeit messen will, soll man dazu irgendeinen hochauflösenden Timer benutzen.
Wieso soll jetzt die Hardware Designfehler in der Software ausbügeln? Das ist doch ein wenig verquer.

Weil in Vista wahrscheinlich immer noch der gleiche quatsch gemacht wird, wie in XP.....und MS da auch nix dran drehen will.

Also müssen die HW-Hersteller in die Bresche springen......

[Coda]

Uhm, das passiert unter Linux auch. Es liegt daran dass das BIOS den zweiten Core einfach später aktiviert.

Der Designfehler von XP ist, dass QueryPerformanceCounter auf SMP-System defaultmäßig trotzdem den TSC benützt (und sogar nur da). Das tut so weh.

Ich denke unter Vista wird sich das sehr wohl ändern, denn da wird ein funktionierender Chipsatz-Timer als Logo-Vorraussetzung verlangt :)

[ShadowXX]

Der Designfehler von XP ist, dass QueryPerformanceCounter auf SMP-System defaultmäßig trotzdem den TSC benützt (und sogar nur da). Das tut so weh.


Das meinte ich ja mit "quatsch"....


Ich denke unter Vista wird sich das sehr wohl ändern, denn da wird ein funktionierender Chipsatz-Timer als Logo-Vorraussetzung verlangt :)

Ich hab schon Treiber gesehen, die ein MS-WHQL-Logo hatte, die soooooo buggy waren, das man sich fragte, worin der WHQL-Test des Treibers überhaupt bestand.

Auf das Logo von MS gebe ich nun wirklich nix.

Und wenn die CPU-Hersteller anfangen sowas in Ihre CPUs einzubauen, dann habe ich in Richtung MS eher ein flaues Gefühl.

[Coda]

Ich nicht *schulterzuck*

Wir werden sehen.

[Benedikt]

Uhm, das passiert unter Linux auch. Es liegt daran dass das BIOS den zweiten Core einfach später aktiviert.

Der Designfehler von XP ist, dass QueryPerformanceCounter auf SMP-System defaultmäßig trotzdem den TSC benützt (und sogar nur da). Das tut so weh.

Ich denke unter Vista wird sich das sehr wohl ändern, denn da wird ein funktionierender Chipsatz-Timer als Logo-Vorraussetzung verlangt :)
Was meinst du damit, Coda? HPET?
Welche Chipsätze können das eigentlich abseits von Intel?