XP Vorsicht vor AMD Dual-Core Optimizer mit SATA-Raid

Hallo liebe Leser,

an dieser Stelle möchte ich eine eindringliche Warnung davor aussprechen, den AMD Dual-Core Optimizer zusammen mit einem SATA-Raid System zu betreiben.

Der AMD-Dual Core Optimizer synchronisiert die Time Stamp Counter (TSC) MSRs bei AMDs Dual-Core Prozessoren. Bei einigen Spielen kommt es ohne diese Software zu Rucklern oder Abstürzen. So weit so gut. Bei meinen Kunden setze ich den Optimizer seit Mitte des Jahres ein, ebenso wie bei mir selbst. Bisher keine Probleme.

Ein Kunde äußerte vor ein paar Wochen den Wunsch nach einem Raid-0 System bestehend aus einem ULi M1697 Mainboard und einem AMD Athlon 64 X2 5000+. Ein paar Tage nach der Auslieferung meldete sich der Anwender, sein System könne nicht mehr booten. Nach eingehender Untersuchung stellte sich heraus, dass das Dateisystem total zerstört war. chkdsk meldete über 150 Fehler von verwaisten Daten über falsche Indizes und und und. Zuerst dachte ich an eine defekte Platte (bei einem Raid-0 ja besonders tragisch) oder einen defekten RAM. Doch die Platten waren ebenso in Ordnung wie die RAMs. Ich installierte sicherheitshalber einen neueren SATA-Raid Treiber, deaktivierte das schnelle Herunterfahren und schickte den Kunden wieder fort.

Nur einen Tag später stand er wieder auf der Matte, wieder mit defektem Dateisystem. Wieder war es so, dass er am Abend den PC ganz normal herunterfuhr, am nächsten Morgen jedoch konnte er nicht mehr booten. Ich fing schon an an der Integrität des ULi Raid-Controllers des ASRock AM2XLI-eSATA2 zu zweifeln, bis ich in einer Hand voll Threads über den Erdball verteilt auf ähnliche Probleme stieß. Jedes Mal betraf es Anwender, die einen AMD Dual-Core Prozessor einsetzten. Da klingelten bei mir plötzlich die Alarmglocken, zumal ich nur ein paar Tage vorher bereits ein ULi-SATA-Raid System verkauft hatte - dort allerdings mit einem 3800+ Single-Core Prozessor - und dieser User hat überhaupt keine Probleme.

Ich bestellte den Kunden also noch einmal her, wieder reparierten wir das Dateisystem mit chkdsk, dieses Mal jedoch entsorgte ich zusätzlich dazu aber auch noch den AMD Dual-Core Optimizer. Naja, was soll ich sagen. Das ist nun zwei Wochen her und seitdem ist das Problem wie weggeblasen.

Bei Licht betrachtet scheint es sich um ein Kompatibilitätsproblem zwischen dem ULi-SATA-Raid Treiber und dem AMD Dual-Core Optimizer irgendwo während der Synchronisationsphase zu handeln, denn der Fall stellt sich wie folgt dar:

1. Dual-Core Prozessor + Optimizer + ULi-Chipsatz + SATA-HDD (Microsoft Treiber) => OK
2. Dual-Core Prozessor + Optimizer + ULi-Chipsatz + SATA-Raid (ULi Treiber) => Datensalat
3. Dual-Core Prozessor + ohne Optimizer + ULi-Chipsatz + SATA-Raid (ULi Treiber) => OK
4. Dual-Core Prozessor + Optimizer + nForce4-Chipsatz + SATA-Raid (NVIDIA Treiber) => OK
5. Single-Core Prozessor + ULi-Chipsatz + SATA-Raid (ULi Treiber) => OK

Insbesondere die Tatsache, dass ein Dual-Core System bei einem weiteren Kunden zusammen mit dem Optimizer und einem SATA-Raid an einem NVIDIA-Controller ohne Probleme arbeitet (oder besser "arbeitete", denn sicherheitshalber hab ich den Optimizer nun auch dort deinstalliert), zeigt, dass das Problem nicht grundsätzlich existiert. Mit dem Standard Microsoft-Treiber ohne Raid-Funktion tritt das Problem sowieso nicht auf. Mit einem ATI- oder VIA-Board konnte ich die Szene leider noch nicht nachstellen, kann also auch keine Angaben machen, ob es das Problem zusammen mit SATA-Raid dort gibt oder nicht.

Dummerweise ist das zu allem Überfluß wieder ein Problem, das nicht so einfach zu reproduzieren ist. Auch bei System 2 hat der User den Rechner zig mal rauf und runter gefahren bzw. über Stunden eingesetzt, ohne dass das Problem aufgetreten ist. Aber irgendwann war's dann soweit.

Daher erst einmal meine allgemeine Warnung: dem AMD Dual-Core Optimizer an einem SATA-Raid System mit einer gehörigen Portion Skepsis gegenüber treten, wenn einem seine Daten lieb sind. Die Datenfehler mit dem ULi-SATA-Raid-Treiber sind womöglich nur ein Problem von vielen und womöglich sucht man Tage/Wochen vergeblich nach der Ursache, tauscht RAMs, Platten, CPU, etc. dabei liegt das Problem bei einem kleinen Stück Software

Nachtrag: Details zu den Testsystemen
System ULi: AMD Athlon 64 X2 5000+, ASRock AM2XLI-eSATA2 BIOS 1.30, 2x Seagate Barracuda 7200.10 SATA2 250 GB ST3250620AS 16 MB Cache, ULi Raid-Treiber 1.0.5.8 und 1.0.5.9, WinXP Pro SP2
System NVIDIA: AMD Athlon 64 X2 5000+, ASRock ALiveNF6G-DVI BIOS 1.60, 2x Seagate Barracuda 7200.10 SATA2 250 GB ST3250620AS 16 MB Cache, NVIDIA Raid-Treiber v6.77, WinXP Home SP2

Na wunderbar...

Ich wollte eigentlich schon längst die seit Monaten verstaubende Platte als Mirror integrieren und logischerweise auf den integr. Contr. meines Dual SATAII zurückgreifen.

Auf den Dualcore Optimizer kann ich jedoch nicht verzichten.

Eine Idee, ob das Problem nur bei RAID0 besteht hast Du sicherlich auch nicht, oder?

Nero24 schrieb:

dabei liegt das Problem bei einem kleinen Stück Software

Zum Vergrößern anklicken....

hier möchte ich auch mal etwas "Kritik" an AMD loswerden...
wieso schaffen sie es nicht, eine CPU zu bauen wo man all ihre Feature brauchbar einsetzen kann? Wieso sind CPU "Treiber" notwendig die wie nun gesehen richtig Probleme machen kann

Die frage ist, ob das problem bzgl der des TSC bei AMD zu suchen ist. Bei Linux benötigt man ja anscheinend keine derartigen hilf smittel...

Riddler82 schrieb:

Die frage ist, ob das problem bzgl der des TSC bei AMD zu suchen ist.

Zum Vergrößern anklicken....

Bei Intel laufen die Pentium D und Core Duo Prozessoren unter Windows auch ohne Zusatzsoftware wunderbar. Sogar mit Enhanced SpeedStep. Dabei sollte AMD einen ebenso guten Draht zu Microsoft haben. Nicht umsonst nennt sich das "i386" Gegenstück bei Windows XP 64 Bit Edition Installations CD auch "AMD64". Insofern ist es verwunderlich, dass Windows XP nicht auch alle benötigten Treibern von Haus aus für AMD Prozessoren mitbringt. Dass dies an Microsoft liegt, kann ich mir eigentlich nicht vorstellen. Ich denke es ist eher die Zusammenarbeit seitens AMD gehindert. Intel hat in dieser Hinsicht einfach eine offenere Art, wenn man sich ihre FTP Server anschaut und sieht was dort an Massen für Dokumentationen und Programmen liegt. Dort könnte man Wochen zubringen.

Ich will den Thread jetzt hier nicht zutexten, aber wie ist das mit dem Patch den Microsoft gebracht hat? der ist doch nicht nur für AMDs gedacht gewesen, oder?
Desweiteren hat zumindest WindowsXP die Speedstep Treiber/Funktionen wohl schon integriert (bei NT4 und 2000 muss man afaik extra welche installieren), während das bei CnQ ja bekanntlich nicht der Fall ist.
Die Integration scheint mir als zumindest noch bei XP 32bit für Intel-CPUs ein bisschen besser zu sein.

Wie gesagt, Unter Linux sind mir solche mätzchen, die den Einsatz den DC-Optimizers nötig machen, auf anhieb nicht geläufig, deshalb kann ich das Problem (und auch die Notwendigkeit für solche Zusatztreiber) so ohne weiteres nicht nur AMD zuschieben.
Wer denn nun wirklich schuld ist... da hilft nur Abwarten und auf seine Daten achtgeben.

Das Problem liegt nicht an AMD, sondern an unsauber geschriebener Software in Verbindung mit Cool'n Quit.
Seit den 586ern bzw. 686ern haben die CPUs einen TSC, der zählt genau mit wieviele Takte die CPU seit dem Anschalten abgearbeitet hat (ist ein 64bit Register). Normalerweise ist das eine prima Zeitquelle, denn das ist der genaueste Zähler den es im Rechner gibt.
Problematisch ist es aber wenn die CPU ihre Taktrate ändert, weil der TSC dann auch unterschiedlich schnell läuft. Üblicherweise guckt man bei Programmstart 1mal wie schnell das Ding läuft (also wie hoch die CPU taktet, man wartet zB. 0.5sek ab, wofür man die Real Time Clock benutzen kann, und guckt um wieviel sich der TSC geändert hat), danach benutzt man den Wert einfach. Wenn die CPU ihren Takt ändert, läuft das Programm/Spiel dann auch entsprechend mit einer anderen Geschwindigkeit.

Das nächste Problem betrifft SMP Systeme. Denn da laufen die TSCs üblicherweise nicht synchron, wenn die CPUs auch noch sowas wie Cool'n Quit können, können die TSCs garnicht mehr synchron laufen. Wenn das OS dann das Prog von einer CPU auf die andere schiebt, ändert sicht auf einmal der Wert vom TSC, und dann kommt die ganze Zeitmessung durcheinander.

Desswegen dürfte man den TSC eigentlich garnet benutzen, aber vielerorts wurde er nunmal benutzt. Das gab schon beim Transmeta Efficeon Probleme, desswegen hat sich Transmeta irgendwann dazu entschieden den TSC unabhängig vom realen CPU Takt laufen zu lassen.
Also bedankt euch bei sowas nicht bei AMD, sondern bei den Spieleherstellern. Warum es bei ULI nun RAIDs zerschießt weis ich auch nicht. Man kann den TSC zur Zeitmessung sicher auch in einem Treiber benutzen, aber sinnvoll ist es nicht. Eigentlich sollten man den TSC garnimmer benutzen.

@Riddler

Gibt's den überhaupt für Linux? Afaik nicht, hab auch noch nie daran gedacht sowas zu benutzen (hab 'nen X2). Auf den TSC dürfen unter Linux afaik eh nur priviligierte Programme zugreifen, sprich man braucht root-rechte.

i_hasser schrieb:

@Riddler

Gibt's den überhaupt für Linux? Afaik nicht, hab auch noch nie daran gedacht sowas zu benutzen (hab 'nen X2). Auf den TSC dürfen unter Linux afaik eh nur priviligierte Programme zugreifen, sprich man braucht root-rechte.

Zum Vergrößern anklicken....

Mir ist nichts bekannt das es sowas für Linux gäbe oder überhaupt nötig wäre. Eben deshalb habe ich den Fehler von vorherein nicht bei AMD gesehen.

warum macht dann das Intel SpeedStep nicht die selben Probleme bei gleicher Software?

Könnte daran liegen das Intel sein Speedstep im Mobile bereich schon vor AMD gebracht hat und die Software bei Intel CPUs anders abfragt ist aber ne wilde Vermutung. Hatte ich weiter oben ja schon angeschnitten, mit den in WinXP schon integrierten Speedstep Funktionen.

Ich bin ja kein Programmierer.

Das weis ich auch nicht. Könnte sein, dass der TSC bei SpeedStep immer mit der selben Geschwindigkeit läuft (was eigentlich gegen die Spezifikation vom TSC verstößt), oder dass win den TSC bei intel CPUs automatisch abgleicht, oder Anfragen einfach per Exception abfängt und in Software ausführt (wenn man user Programmen die Privilegien für den TSC entzieht bekommt man quasi immer eine Nachricht wenn jemand versucht drauf zuzugreifen, der Treiben könnte dann den erwarteten Wert errechnen und den zurückgeben).

Ist aber alles nur Spekulation. Ich könnt mal ein kleines Prog schreiben, das die Geschwindigkeit des TSC anzeigt. Dann müsste sich noch ein Intelianer finden, der das mal austestet.

i_hasser schrieb:

Ist aber alles nur Spekulation. Ich könnt mal ein kleines Prog schreiben, das die Geschwindigkeit des TSC anzeigt. Dann müsste sich noch ein Intelianer finden, der das mal austestet.

Zum Vergrößern anklicken....

na dann her damitm, wobei kann die Desktop CPU das auch?
hab mich da noch nicht drum gekümmert, jedenfalls läuft die Geschwindigkeit konstant.

Hat zufällig jemand cygwin oder linux am Laufen? Das würde die Sache deutlich vereinfachen, sonst muss ich erst mingw installieren.

i_hasser schrieb:

Das Problem liegt nicht an AMD, sondern an unsauber geschriebener Software in Verbindung mit Cool'n Quit.
Seit den 586ern bzw. 686ern haben die CPUs einen TSC, der zählt genau mit wieviele Takte die CPU seit dem Anschalten abgearbeitet hat (ist ein 64bit Register). Normalerweise ist das eine prima Zeitquelle, denn das ist der genaueste Zähler den es im Rechner gibt.
Problematisch ist es aber wenn die CPU ihre Taktrate ändert, weil der TSC dann auch unterschiedlich schnell läuft. Üblicherweise guckt man bei Programmstart 1mal wie schnell das Ding läuft (also wie hoch die CPU taktet, man wartet zB. 0.5sek ab, wofür man die Real Time Clock benutzen kann, und guckt um wieviel sich der TSC geändert hat), danach benutzt man den Wert einfach. Wenn die CPU ihren Takt ändert, läuft das Programm/Spiel dann auch entsprechend mit einer anderen Geschwindigkeit.

Das nächste Problem betrifft SMP Systeme. Denn da laufen die TSCs üblicherweise nicht synchron, wenn die CPUs auch noch sowas wie Cool'n Quit können, können die TSCs garnicht mehr synchron laufen. Wenn das OS dann das Prog von einer CPU auf die andere schiebt, ändert sicht auf einmal der Wert vom TSC, und dann kommt die ganze Zeitmessung durcheinander.

Desswegen dürfte man den TSC eigentlich garnet benutzen, aber vielerorts wurde er nunmal benutzt. Das gab schon beim Transmeta Efficeon Probleme, desswegen hat sich Transmeta irgendwann dazu entschieden den TSC unabhängig vom realen CPU Takt laufen zu lassen.
Also bedankt euch bei sowas nicht bei AMD, sondern bei den Spieleherstellern. Warum es bei ULI nun RAIDs zerschießt weis ich auch nicht. Man kann den TSC zur Zeitmessung sicher auch in einem Treiber benutzen, aber sinnvoll ist es nicht. Eigentlich sollten man den TSC garnimmer benutzen.

@Riddler

Gibt's den überhaupt für Linux? Afaik nicht, hab auch noch nie daran gedacht sowas zu benutzen (hab 'nen X2). Auf den TSC dürfen unter Linux afaik eh nur priviligierte Programme zugreifen, sprich man braucht root-rechte.

Zum Vergrößern anklicken....

Demnach ist also höchstwahrscheinlich der Uli Treiber der Verursacher und das Problem wird unabhängig von der Art des RAIDs sein udn ich sollte meine 2. Platte besser nicht als Raidmirror betreiben. Richtig?

Also es liegt mit nahezu 100%iger Wahrscheinlichkeit am ULi Treiber. Ob das Raidabhängig ist weis ich nicht, müsste man einfach ausprobieren.
Wär vorstellbar, dass die eine Wartefunktion für irgendwelche Portzugriffe brauchen (bei PATA HDDs im PIO Mode muss man zB. alle xyz µs einen Port lesen, könnte sein, dass es bei irgendwelchen Verwaltungssachen bei SATA ähnlich ist). Man müsste mal gucken, ob das auch ohne Raid mit den ULI Treibern passiert.

Btw. er compiliert grad mingw, kann noch ein bisschen dauern.

Scheint also Tatsächlich diese unglückliche Kombo aus ULi-Treiber, DC-Optimizer und RAID zu sein.
Habe 2 Platten am ULi 1575 dran im SATA (nonRAID)-mode und den DC-Opt. auf x64 installiert.
Bisher gehts bei mir (ca. 6 Monate altes System). Die einzigen Daten die abhanden kamen waren meine G³ savegames die ich besoffen irgendwo hingeschoben habe... (Den Ordner hab ich dann irgendwann aus Unwissenheit gelöscht )



bye Hübie

So, hab mal schnell was zusammen gezimmert. Das Prog wartet immer eine Sekunde und gibt dann die Differenz vom TSC aus. Bei einem Testlauf sah das zB. so aus:

2006e6
2006e6
2006e6
2006e6
1942e6
2006e6
2006e6
2006e6
2069e6
2006e6
2006e6

Die 2006 sind die 2000MHz mit denen die Cores laufen, bei den 1942e6 Ticks hab ich den Task mal auf CPU #1 geschoben, bei den 2069 wieder auf CPU #0. Cool'n Quit hab ich nicht laufen, wie man sieht laufen die TSCs trotzdem nicht synchron.

Ich hab das Ding für win mal in den Anhang gepackt, beendet wird das Ding einfach mit Strg+C.

EDIT: Mist, gibt kein .exe als Anhang... hab's mal hier hinkopiert: www.i-hasser.net/a.exe

i_hasser schrieb:

Hat zufällig jemand cygwin oder linux am Laufen? Das würde die Sache deutlich vereinfachen, sonst muss ich erst mingw installieren.

Zum Vergrößern anklicken....

Hab hier Linux am Laufen, wie kann ich helfen?

Habs mal laufen lassen:

1256e6 <---Start
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1250e6<---Explorer
1249e6
1249e6
1249e6
1250e6<---Ordner geöffnet
1249e6
1250e6<---Unterordner geöffnet
1249e6
1249e6
1249e6
1250e6<---CPU-Z gestartet
2107e6<---nach dem Start von CPU-Z
1249e6
1249e6
1250e6<---gedödel
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6


Cool&Quiet ist aktiv
Hab keinen Kern zugewiesen.


bye Hübie

Huhu,

ich hab die Kombination auch im Einsatz. (X2 4400+, ULi 1697 und SATA2-RAID sowie DualCore-Optimizer) - aber ich habe damit noch nie ähnliche Erfahrung gemacht. Mein System läuft einwandfrei.

Scheint also noch andere Faktoren zu geben, die da mit reinspielen.

Hübie schrieb:

Habs mal laufen lassen:

1256e6 <---Start
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1250e6<---Explorer
1249e6
1249e6
1249e6
1250e6<---Ordner geöffnet
1249e6
1250e6<---Unterordner geöffnet
1249e6
1249e6
1249e6
1250e6<---CPU-Z gestartet
2107e6<---nach dem Start von CPU-Z
1249e6
1249e6
1250e6<---gedödel
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6
1249e6


Cool&Quiet ist aktiv
Hab keinen Kern zugewiesen.


bye Hübie

Zum Vergrößern anklicken....

Bei CPU-Z hat er die CPU offensichtlich hochgetaktet. Wär halt mal interessant, wie das bei den Intelianern aussieht. Kleine Abweichungen in den Werten sind nicht unnormal, weil die Wartefunktion nicht so sehr genau ist.

@MisterSempron

Hast du'n Intel am Laufen?

@

Stonehedge schrieb:

Huhu,

ich hab die Kombination auch im Einsatz. (X2 4400+, ULi 1697 und SATA2-RAID sowie DualCore-Optimizer) - aber ich habe damit noch nie ähnliche Erfahrung gemacht. Mein System läuft einwandfrei.

Scheint also noch andere Faktoren zu geben, die da mit reinspielen.

Zum Vergrößern anklicken....

Hi, welches Mobo hast du denn genau? ich nutze das Epox 9U1697, allerdings mit S-ATA platten ohne aktiver Raid funktion.
Ich werd allerdings zusehen bald zwei zusätzlich platten zu bekommen und diese dann als RAID-0 einrichten.

i_hasser schrieb:

Bei CPU-Z hat er die CPU offensichtlich hochgetaktet. Wär halt mal interessant, wie das bei den Intelianern aussieht. Kleine Abweichungen in den Werten sind nicht unnormal, weil die Wartefunktion nicht so sehr genau ist.

@MisterSempron

Hast du'n Intel am Laufen?

@

Zum Vergrößern anklicken....

Nein, einen Intel hab ich leider nicht am Laufen, hier zu Hause haben alle nur AMD.

Riddler82 schrieb:

Hi, welches Mobo hast du denn genau? ich nutze das Epox 9U1697, allerdings mit S-ATA platten ohne aktiver Raid funktion.
Ich werd allerdings zusehen bald zwei zusätzlich platten zu bekommen und diese dann als RAID-0 einrichten.

Zum Vergrößern anklicken....

Huhu, ich hab ein Asrock SLI32 eSATA 2 Sockel 939

wie gesagt: Problematik hat hier keinen Bestand!

ich habe grds. ziemlich konstant
2128e6

bei Programmstarts und aktivitäten gibt es Abweichungen.

Wenn ich jedoch mit dem Asus AI-Gear Tool auf Powersave stelle,
schwankt alles wesentlich mehr (so alle 5-6 sind anders)
2092e6 sowie 2167e6 sind dabei die Peaks. (CPU weitgehend im IDLE)

wenn ich mit Sandra dabei die CPU benche, kommen Werte wie 3000e6 und viel mehr heraus (bis über 10.000) und das obwohl die kleine Exe in Echtzeit läuft.
Die Sandra Werte sind dabei übrigens auch vollkommen daneben