AMD kündigt Verbesserungen am Timestamp-Counter an

Wie kürzlich bekannt wurde, will AMD bei seinen zukünftigen Prozessoren das Zeitmanagement verbessern. Dies geht aus einem Thema der Usenet-Gruppe "comp.unix.solaris" hervor, in der AMD- und Sun-Mitarbeiter über Probleme sprachen, die vom Timestamp-Conter TPC der Prozessorkerne und dem Powermanagment (Performance-State P und Power-State C1) hervorgerufen werden können.

Der Time Stamp Counter (TSC) dient zur internen Zeitmessung und existiert sowohl bei CPUs von Intel als auch von AMD.

Die Probleme die der Time Stamp Counter hervorruft, können das Thread-Handling der Betriebsysteme stören und somit eine unnötige Verlangsamung hervorrufen. Ein Faktor ist der sogenannte TSC-Drift. Der Timestamp-Counter-Drift tritt auf, wenn die Timestamp-Counter der Prozessorkerne nicht synchron laufen. Dies ist allerdings kein "neuer" Fehler, denn schon früher waren Dual-Prozessorsysteme von diesem Symptom betroffen. Da sich die Leistung der Prozessoren jedoch enorm gesteigert hat, fällt dieses Problem erst jetzt richtig auf.

Ein Hauptgrund für das Eintreten des TSC-Drift ist das Throttling des Mainboardchipsatzes. Durch ein solches "Drosseln" des Chipsatzes kann es vorkommen, dass ein Prozessorkern asynchron zum anderen arbeitet.

Unter Unix / Linux existiert die möglichkeit einen solchen TSC-Drift zu vermeiden, denn mit der Bootoption "notsc" oder "clock=pmtmr" wird der Timestamp-Counter umgangen. Aktuelle Unix / Linux Versionen umgehen jedoch automatisch dieses Problem und eine Eingabe dieser Bootoption ist nicht nötig.
Auch unter den Microsoft Betriebssystemen Windows XP SP2, Windows XP 64-Bit und Windows Server 2003 SP1 ist es möglich, durch eine Bootoption dieses Problem zu umgehen. Dies funktioniert jedoch nur bei Single-Prozessor Dual-Core System. Die Boot-Option hierfür lautet "/usepmtimer".

AMDs Fellow Rich Brunner kündigte bei dieser Diskussion jedoch an, dass AMD den Timestamp-Counter für zukünftige Prozessoren umgestalten will.

<b>Links zum Thema:</b><ul><li><a href="http://groups.google.de/group/comp.unix.solaris/browse_frm/thread/4de2600596862002" target="B">TSC and Power Management Events on AMD Processors</a></li><li><a href="http://www.heise.de/newsticker/meldung/65802" target="b">heise.de</a></li></ul>

Irgendwie beschleicht mich das Gefühl zu Recht auf der Sockel A Plattform geblieben zu sein:
XP64, AMD-X2, PCIe-Kartenangebot (bis auf Grakas) und Multicore unterstützende Programme - all das liegt nocht ein wenig im (teuren) Argen. Ein Wechsel zur M2 Zeit könnte wesentlich ausgereiftere Umgebungen erwarten lassen. Das soll kein Vorwurf sein, daß AMD irgend etwas falsch gemacht hätte - nur eine kleine Reflexion aus Anwendersicht. Subjektiv, versteht sich.

Allfred schrieb:

Irgendwie beschleicht mich das Gefühl zu Recht auf der Sockel A Plattform geblieben zu sein:

Zum Vergrößern anklicken....

Das hier angesprochene Problem hat nix mit dem Sockel und den dort verwendeten CPUs zu tun. Das ist einfach nur ein Problem von Mehrprozessorsystemen, kann also beim Sockel A genauso auftreten.

Nee schon klar - ich meine ja nur, daß die Prozessoren mit jedem Steping besser werden und die Zeit eine bessere Software- und Hardware- Unterstützung bringen wird.

Ich glaube ja nicht das es besser wird mit der Zeit. Es kommen doch immer mehr Bugs dazu, oder hast du schon mal fehlerfrei Software gehabt?
Ich habe einen X2 und keine Probleme damit bemerkt. Dank Folding@Home laufen die zwar auch immer auf vollast, aber nun ja.

markus397 schrieb:

Ich glaube ja nicht das es besser wird mit der Zeit. Es kommen doch immer mehr Bugs dazu, oder hast du schon mal fehlerfrei Software gehabt?
Ich habe einen X2 und keine Probleme damit bemerkt. Dank Folding@Home laufen die zwar auch immer auf vollast, aber nun ja.

Zum Vergrößern anklicken....

Wie gesagt der Fehler besteht ja schon... ewig, aber erst jetzt wo die CPUs wirklich schnell werden fällt er ins gewicht!
Bei dir kann genau so eine Abweichung eintreten ... denn du musst ja erstmal dein OS hochfahren oder? Ich denke nicht, dass dein X2 während des Boots voll ausgelastet ist

Letzte Woche noch dasselbe Thema an der Uni gehabt, heute schon im P3D.

Da sagt nochmal einer die Bildung hinkt der aktuellen Entwicklung hinterher

AMD-Hammer schrieb:

Auch unter den Microsoft Betriebssystemen Windows XP SP2, Windows XP 64-Bit und Windows Server 2003 SP1 ist es möglich, durch eine Bootoption dieses Problem zu umgehen. Dies funktioniert jedoch nur bei Single-Prozessor Dual-Core System. Die Boot-Option hierfür lautet "/usepmtimer".

Zum Vergrößern anklicken....

Da schau her, genau den schalter setzt der AMD X2 treiber wenn man ihn denn installiert.

Das hier hatte jetzt aber nichts mit dem Fehler im XP in Verbindung mit X2s zu tun..?

RavenTS schrieb:

Das hier hatte jetzt aber nichts mit dem Fehler im XP in Verbindung mit X2s zu tun..?

Zum Vergrößern anklicken....

Kommt darauf an welchen fehler du meinst. Gibt aber keinen "X2 fehler in XP". Grundsätzlich können alle doppelkern/doppel prozessor systeme die bekannten performance probleme haben, die vorallem bei spielen sichtbar werden. Das ist kein AMD spezifisches problem.

Ob dieser TSC drift auch dafür verantwortlich ist, weiss ich nicht mit sicherheit, nehme ich aber mal an. Ich weiss nur, dass ich den AMD X2 treiber, der eben auch dieses flag in der Boot.ini setzt, von anfang auf einer frischen XP installation drauf hatte und CnQ deaktiviert habe (da ich moderat übertakte) und nie irgendwelche probleme in spielen erkennen konnte - wie auch, die kerne werden nie gedrosselt.

Grundsätzlich steht da ja, dass TSC drift nur auftritt wenn das mainboard stromspar mechanismen anwendet und so die TSC der kerne ggf. nicht mehr synchron laufen. Genau in diese kerbe schlägt ja auch dieser ominöse microsoft hotfix den man nur direkt von MS beziehen kann (oder halt irgendwo sonst inoffiziell runterlädt), da er auch die auswirkungen von CnQ auf performance kritische anwendungen (spiele) abfängt.