MS wollte wohl vom Einsatz des Nehalems mit Windows 2k8 R2 abraten

[Avalox]

Andreas Stiller schreibt in den aktuellen Prozessorgeflüster interessantes von hinter den Kulissen seitens Intel und MS.

"Diesen Bug hat Intel erst im September in den Specification Updates unter AAK119 (Xeon 5500), AAM123 (Xeon 3500), AAO89 (Xeon 3400), AAJ121 (Core i7-900) und AAN87 (Core i7-800, Core i5) spezifiziert. Und obwohl Microsoft frühzeitig auf den Einsatz des APIC-Timers in der neuen Server-Edition hingewiesen haben dürfte, findet man auch in den jüngsten Specification Updates vom November noch den abwiegelnden Passus: „Intel hat den Fehler bei keiner kommerziell erhältlichen Software beobachtet.“ Unter Fehlernummer 975 530 beschreibt nun Microsoft das Desaster, liefert (auf E-Mail-Anfrage) einen nicht genauer beschriebenen Hotfix und schlägt ansonsten als nicht wirklich ernst zu nehmende Lösung das Abschalten der Stromsparzustände C3 und C6 vor – damit wäre aber auch die Turbo-Boost-Funktion der Nehalems totgelegt. Und schlimmer noch, in einer der Redaktion vorliegenden, nicht veröffentlichten Rohfassung des Fehlerberichts war ursprünglich sogar ein Passus enthalten, der als „preferred solution“ brüsk empfahl, die betroffenen Prozessoren nicht zu verwenden. Starker Tobak: Microsoft rät vom Einsatz der Nehalem-Prozessoren in Servern ab – da ist Intel auf die Barrikaden gegangen und konnte das gerade noch in letzter Sekunde verhindern."

Von Andreas Stiller c't 25/09, S.19 Prozessorgeflüster

http://www.heise.de/ct/artikel/Prozessorgefluester-862083.html

[Gast]

Und worum genau wird jetzt so ein Terz gemacht?
So lang es weiterhin bei "Intel hat den Fehler bei keiner kommerziell erhältlichen Software beobachtet" bleibt, ist ja alles in Ordnung. ;)

Diese Passage klingt ganz anders:
Hat doch Microsoft beim integrierten Hypervisor von Windows Server 2008 R2 mutig auf eine Timer-Funktion zurückgegriffen, die die Redmonder bei früheren Prozessoren selbst als unzuverlässig eingestuft hatten: den Timer des Advanced Programmable Interrupt Controller (APIC).

[Avalox]

Und worum genau wird jetzt so ein Terz gemacht?



Knacktus ist schon mal, dass die Nehalem Systeme kein C3 und C6 und auch den Turbo Boost nicht verwenden sollen. Die Energieeffizienz ist dann auch hin.

Schon ein sehr knackiger Fehler im Nehalem. Hat Intel wohl einige Register gezogen um zu verhindern, dass MS das Papier mit der Empfehlung ganz auf den Nehalem zu verzichten so nicht heraus bringt und "nur" empfiehlt auf C3 und C6 zu verzichten.

[Gast]

Aber warum soll das gemacht werden, wenn das bisher nicht reproduziert werden konnte?

Wenn ich den ersten und dann den mittleren Absatz lese, so lese ich da nur heraus, das Microsoft wagemutig auf etwas setzte, was in der Vergangenheit schonmal Probleme machte und rät von seiner eigenen Software (oder Intel) ab um das "Problem" zu lösen.

Die viel interessantere Frage ist doch, wie relevant ist das überhaupt in der Praxis! In der Theorie kannst du jeden PC in die Tonne kloppen, nicht einmal dein Arbeitsspeicher arbeitet einwandfrei.

[Avalox]

Aber warum soll das gemacht werden, wenn das bisher nicht reproduziert werden konnte?


Natürlich kann es mit einer Software reproduziert werden. Es ist nur noch nicht von Intel bei kommerzieller Software, welche man auf dem Markt kaufen kann, gezielt als Problemverursacher identifiziert worden. Da steht natürlich der Wert dieser Aussage etwas in der Luft. Wie genau ist denn hingesehen worden fragt man sich dabei automatisch?

MS hat es jedenfalls als Problemursache erkannt und deshalb den entsprechenden Hinweis gegeben.


Jetzt musst du dir mal ein großen Unternehmen vorstellen, welches gerade eine SAP R/3 rechnet und die W2k8 Server pfeifen ab.
Da wird niemand Administratives auch nur in Diskussionen kommen wollen, nur weil er ein klare Benutzungsanshinweis von MS nicht beachtet hat.

Dieser Fehler ist schon beeindruckend.

[Gast]

Ich lese aus dem Artikel nichts von "abstürzen" heraus.
Wenn ich es mir recht überlege, steht in dem Artikel gar nichts zu den Auswirkungen. Was passiert denn, wenn überhaupt etwas passiert?

Wäre das Problem ein großes, so hätten es schon auffallen müssen, da die Systeme bereits verkauft wurden.
Desweiteren gibts da noch einen wichtigen Punkt, den ich gerne hinzufügen möchte: Diese Daten und Fehlerblätter sind nicht immer die aktuellsten.

[Avalox]

Ich lese aus dem Artikel nichts von "abstürzen" heraus.
Wenn ich es mir recht überlege, steht in dem Artikel gar nichts zu den Auswirkungen. Was passiert denn, wenn überhaupt etwas passiert?


Nicht gelesen?

"Beim Nehalem sind es aber dummerweise zuweilen derer zu viele, sodass der Hypervisor strauchelt und mit „Clock_Watchdog_Timeout“ stehen bleibt."

Bedeutet.

"The specified processor is not processing interrupts. Typically, this occurs when the processor is nonresponsive or is deadlocked."


Hier noch die MS Fehlermeldung.

http://support.microsoft.com/kb/975530

[Coda]

So wie ich das lese ist das ganze auch nur mit Virtualisierung überhaupt relevant.

Edit: Im Errata-Sheet steht dass das ganze als "No Fix" geführt wird, und es sowieso sehr komisch ist, dass in C6 vom APIC-Timer Interrupts erwartet werden, der dort eigentlich gar nicht läuft.

Das ganze sollte eindeutig von Microsoft gepatcht werden und wird es wohl auch werden.

Appropos kann ich an dem Bug nichts besonders "knackiges" erkennen. Solche Fehler haben moderne Prozessoren zu Hauf.

[Gast]

Nicht gelesen?

Hier steht Aussage gegen Aussage.

Der eine beschreibt etwas, was auftreten könnte, der andere sagt, das lässt sich nicht einfach reproduzieren.

Ob es ein Problem ist, stellt sich erst heraus, wenn es wirkliche Probleme gibt und von wirklichen Problemen wie "Haben tausende Daten verloren, weil xy passiert ist" steht da widerum nichts. In anderen Worten: Es kann auch sein, das der schwarze Peter mal wieder hin und hergeschoben wird. Wenn Microsoft es wusste, hätten sie ja auch darauf reagieren können oder anders: Wenn Microsoft es vorher anders gemacht hat, wieso machen sie es jetzt so?

[Avalox]

Hier steht Aussage gegen Aussage.


Überhaupt nicht.

MS sagt mit Ihrer Software haben die o.g. Intel Prozessoren folgendes Problem deshalb muss dieses und jenes Feature der CPU abgeschaltet werden, um überhaupt einen ordnungsgemäßen und stabilen Betrieb zu erzielen.

Intel schreibt "„Intel hat den Fehler bei keiner kommerziell erhältlichen Software beobachtet.“

Diese Aussage steht überhaupt nicht gegen die von MS. Da Intel weder alle kommerzielle Software überhaupt beobachtet haben kann und MS dort einen direkten Fehler gefunden hat. Heißt es nur, bisher ist Intel der Fehler nicht in der Auswirkung aufgefallen und ist damit schlicht nur eine Rechtfertigung dafür, nicht früher auf den Fehler hingewiesen oder Absorge getragen zu haben.

[_DrillSarge]I[]

bei amd hätte man schwupps den l3-cache abgeschaltet...ups....

;D

[Coda]

MS sagt mit Ihrer Software haben die o.g. Intel Prozessoren folgendes Problem deshalb muss dieses und jenes Feature der CPU abgeschaltet werden, um überhaupt einen ordnungsgemäßen und stabilen Betrieb zu erzielen.
Nein, sie sollten den Hypervisor patchen um das Problem zu umgehen und nicht rumheulen.

Jeder Kernel ist voll mit Workarounds solcher Errata. Das bekommt ihr nur nicht mit. Problematisch wird es erst, wenn es sich mit Software nicht umgehen lässt, bzw. dies nicht vor dem Release getan wird, oder jemand meint er müsse es einfach gar nicht fixen.

Der K10-TLB-Bug wurde im Linux-Kernel auch gefixt, nur Microsoft kann da nicht kurzfristig reagieren, da sie Änderungen am Kernel grundsätzlich (und verständlicherweise) nur mit Service Packs vornehmen.

[Gast]

Heißt es nur, bisher ist Intel der Fehler nicht in der Auswirkung aufgefallen und ist damit schlicht nur eine Rechtfertigung dafür, nicht früher auf den Fehler hingewiesen oder Absorge getragen zu haben.

Das liest du aber falsch. Der Verursacher ist kaum auszumachen. Im Artikel steh, das Microsoft sich *vorherigen* Problemen bewusst gewesen ist und trotzdem darauf gesetzt hat.

Außerdem gibt es noch ein dickes Fragezeichen: Wenn Microsoft angeblich so genau weiß wann und wie das passiert, dann hätten sie Intel genau diese Testkombination mitteilen können und in wenigen Tagen wäre das ganze aufgeklärt. Da braucht es dann nicht einmal "alle" Software, sondern nur die, bei dem sie das ganze beobachtet haben...

[Botcruscher]

Problem beheben und gut. Ist doch egal wer schuld hat.

[Avalox]

Problem beheben und gut. Ist doch egal wer schuld hat.


Na mal sehen. Zur Zeit hat der Fehler im Intel Nehalem ja eine gehörige Auswirkung auf die Verwendbarkeit des Prozessors.

Schuld hin oder her. Die Situation durch den CPU Fehler dürfte den Kunden nicht gefallen.

[Exxtreme]

*g*

Danke für die Info. Da bei uns nächstes Jahr neue Server mit Win2k8 anstehen wird es wohl ein Phenom oder Opteron werden. :D

[JaDz]

Was genau macht nun der Hotfix von MS? Wird ein alternativer Timer genutzt?

[Avalox]

Was genau macht nun der Hotfix von MS? Wird ein alternativer Timer genutzt?

Das schreibt MS nicht. Könnten auch gut durch den Fix die Reg Schlüssel, wie im MS KB Text erwähnt gesetzt werden und C3 und C6 ausgeschaltet werden.

[ein anderer Gast]

Diese ganzen Prozessorgimmicks haben doch noch nie zuverlässig funktioniert.
Gimmick ist ein lustiges oder sonst attraktives Werbegeschenk (auch: Give-away) von geringem materiellen Wert
(..)
Das soll vor allem Kinder ansprechen.

http://de.wikipedia.org/wiki/Gimmick
....und militante Klimaschützer. - Denn sie wissen nicht, was sie tun.

Nehmen wir nur mal den Core2 ... ich kenne niemanden, der freiwillig C1E laufen läßt. Irgendwas funktioniert immer nichtmehr wie vorher, wenn der PC wieder hochfahren soll.

Kein Mensch der einen 'wichtigen' Server laufen läßt, würde ein Feature wie den Turbo-Mode des Nehalem ernstlich in Erwägung ziehen. Sollte sich die CPU jemals im Turbo-Mode befinden, zeigt das nur, daß das System hoffnungslos überdimensioniert ist und mit nicht-optimierter Software betrieben wird. Und wenn der Server tatsächlich von C3 (=Deep Sleep) oder C6 (=Reset State) profitieren könnte, dann ist es eben kein 'wichtiger' Server. Das schließt sich gegenseitig aus. Nur ein kompletter Vollidiot würde einen wichtigen Server wie ein mobiles System oder wie ein Netbook mit Atom konfigurieren:
Deep sleep (C3) and Deeper sleep (C4) are terms used in the power management of mobile platforms.
http://www.intel.com/support/processors/sb/CS-028739.htm

C6 ist ein Gimmick für Netbooks mit Intels Atom-Prozessor. Das man solche Features auch in Nehalem integriert hat, ist für mich ein Zeichen, daß man sich den Einsatz von Nehalems in späteren High-End Mobile-Solutions nicht verbauen wollte. Im Ernst: Ich kann mir nicht vorstellen, daß jemand der einen 'wirklichen' Server betreibt, auf diese Technik zurückgreift. Wenn man kein Geld hat die Stromrechnung für einen Server zu stemmen, dann sollte man es gleich bleiben lassen. Da sind ja die monatlichen Provider-Gebühren schon um ein Vielfaches höher.

mfg

PS @ Exxtreme: Das du dich gleich auf Phenom oder Opteron festlegst wegen eines abschaltbaren Features für mobile Solutions, das in dieser Form bei AMD-CPUs nicht mal enthalten ist, zeugt von tiefem Systemverständnis. 'Si tacuisses' usw. usf. ;) - Wenn es um den Anschaffungspreis geht -wenn jemand die Server aussucht- und dann zu AMD greift, würde ich es ja noch verstehen. Aber wenn es um langfristige Energieeffizienz geht. Sorry - da sollte man bei AMD momentan nochmal gut nachrechnen. - Hinterher ist man meistens klüger. Und wenn man sowieso schon am überlegen ist, und C3/C6 tatsächlich ein Thema ist, dann sollte man überlegen, ob ein Quad überhaupt in dieses Szenarium paßt. Vielleicht tuts ja auch schon ein Atom.... und überhaupt: Vielleicht sind die alten Server doch gar nicht so schlecht, wie sie auf dem Papier mittlerweile wirken. ;)

[Avalox]

Im Ernst: Ich kann mir nicht vorstellen, daß jemand der einen 'wirklichen' Server betreibt, auf diese Technik zurückgreift. Wenn man kein Geld hat die Stromrechnung für einen Server zu stemmen, dann sollte man es gleich bleiben lassen. Da sind ja die monatlichen Provider-Gebühren schon um ein Vielfaches höher.



Auch wenn es dich jetzt desillusioniere wird. Aber der Druchschnittsserver ist über 24/7 Betrieb zu 15% ausgelastet.
Das kommt daher, dass ein Server immer für eine Peakleistung konzipiert ist.

Green-IT. Der Prozessorfehler trifft den Intel Server ins Mark. Da natürlich in den Intel Energieverbauchsrechnungen entsprechende Effekte aus Features mit eingerechnet wurden. Dort spielt es keine Rolle, ob AMD eine ähnliche Funktion bietet oder nicht. Es zählt was am Ende bei rauskommt und dieses hat sich grade auf der Intel-Seite im Zusammenspiel mit MS W2k8 R2, also dem aktuellem MS Server, verschlechtert.

Wer zudem damit gerechnet hat, in Schwachlastzeiten die Klimatisierung runter zu fahren, weil die Server kühler betrieben werden, der hat in dieser Konstellation auch noch mit Folgekosten zu rechnen.

Der Fehler von i5, i7, Xeon usw. wird sicherlich schnell gefixt werden. Ist schon ein ziemlicher GAU das ganze.

Andreas Stiller (c't) nennt es Desaster. Hat er Recht mit. Ist nur noch nicht in aller Breite ins Bewusstsein gerutscht.

[Undertaker]

Appropos kann ich an dem Bug nichts besonders "knackiges" erkennen. Solche Fehler haben moderne Prozessoren zu Hauf.

Das ist wohl der Knackpunkt... Mal wieder einer von vielen Errata auf einer langen Liste, praktisch zudem wohl kaum relevant. Wird wohl einfach untergehen... ;)

[Gast]

*g*

Danke für die Info. Da bei uns nächstes Jahr neue Server mit Win2k8 anstehen wird es wohl ein Phenom oder Opteron werden. :D

Wie kommst du zu diesem Schluß?

W2K8 ist nicht betroffen und zeig mir mal ein paar gute Server mit AMD CPUs.

Hint: Im Reallife sind 8 Sockel AMD Server (egal ob HP,IBM,Fujitsu) langsamer als 4 Sockel AMD Server.

mfg

[Lawmachine79]

Tja, was soll man da noch sagen. Durchbrennende Sockel auf Bastelplattformen, verbuggte CPUs. Intel ist ja mittlerweile sowas wie Cyrix Ende der 90er. Dann müssen andere Firmen "überzeugt" werden wie die Rohrmuffen, damit sie dichthalten. Exakt wegen solchem Geschäftsgebahren ist die Firma für mich unkaufbar, von Laptop über Quadcore bis Postville.

[Undertaker]

Na zum Glück gibts bei anderen Firmen keine Fehler... ;)

Kann es sein, dass dieser Thread nur einen ganz bestimmten Zweck verfolgt, der mit der eigentlichen Meldung wenig zu tun hat...? :confused:

[Lawmachine79]

Na zum Glück gibts bei anderen Firmen keine Fehler... ;)

Kann es sein, dass dieser Thread nur einen ganz bestimmten Zweck verfolgt, der mit der eigentlichen Meldung wenig zu tun hat...? :confused:
Für solche Aktionen muss der Finger in die Wunde und es muss fleißig rumgepult werden. Nur wenn solche Aktionen in die Geldbörse gehen, wird es einen Erziehungseffekt geben. Und das derlei Methoden bei Intel ja quasi fester Bestandteil der Unternehmenskultur ist beschäftigt mittlerweile ja auch ganze Heerscharen von Anwälten. Warum sie es trotzdem machen? Weil es sich finzanziell für sie lohnt! Wenn man die Produkte nicht mehr kauft, DANN erst tut es weh. Aber solange Leute die CPUs kaufen und damit die Anwälte bezahlen, die für Intel die Verzögerungsgefechte gegen die Behörden ausfechten, werden diese Geschäftsmethoden auch bleiben. Intels Kriegskasse für Strafzahlungen und Prozesse ist ja voll. Deshalb kann man ja auch genauso weitermachen. Vielleicht schadet es nicht, wenn man mal über den Tellerrand "mein Quad-Core schafft Super-Pi in x sex" blickt.

[Exxtreme]

Wie kommst du zu diesem Schluß?

W2K8 ist nicht betroffen und zeig mir mal ein paar gute Server mit AMD CPUs.

Hint: Im Reallife sind 8 Sockel AMD Server (egal ob HP,IBM,Fujitsu) langsamer als 4 Sockel AMD Server.

mfg
Bei Servern geht es nicht unbedingt um Geschwindigkeit sondern auch um Zuverlässigkeit. Bin gespannt was noch alles verschwiegen wird. Und Win2k8 R2 ist betroffen, lies man den Artikel. Und dritte Aussage kapiere ich nicht. Ein AMD-Server mit 8 Sockeln ist langsamer als ein AMD-Server mit 4 Sockeln? :confused:

[Lord Wotan]

Warum gibt es keine Rückruf Aktion.

Und am was erinnert mich das. Richtig, einst hatte doch AMD mal so einen Komischen CPU Bug. Und Intel hatte doch auch schon mal sowas mit einen Rechenfehler oder? Ließ Intel damals nicht auf Wunsch, die CPU´s austauschen?

[_DrillSarge]I[]

Und Intel hatte doch auch schon mal sowas mit einen Rechenfehler oder? Ließ Intel damals nicht auf Wunsch, die CPU´s austauschen?
naja da war auch die halbe fpu kaputt.
schau mal auf der intel/amd-seite, die cpus sind voll mit kleineren macken.
edit:
http://download.intel.com/design/processor/specupdt/320836.pdf

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322.pdf

[Undertaker]

Für solche Aktionen muss der Finger in die Wunde und es muss fleißig rumgepult werden. Nur wenn solche Aktionen in die Geldbörse gehen, wird es einen Erziehungseffekt geben. Und das derlei Methoden bei Intel ja quasi fester Bestandteil der Unternehmenskultur ist beschäftigt mittlerweile ja auch ganze Heerscharen von Anwälten. Warum sie es trotzdem machen? Weil es sich finzanziell für sie lohnt! Wenn man die Produkte nicht mehr kauft, DANN erst tut es weh. Aber solange Leute die CPUs kaufen und damit die Anwälte bezahlen, die für Intel die Verzögerungsgefechte gegen die Behörden ausfechten, werden diese Geschäftsmethoden auch bleiben. Intels Kriegskasse für Strafzahlungen und Prozesse ist ja voll. Deshalb kann man ja auch genauso weitermachen. Vielleicht schadet es nicht, wenn man mal über den Tellerrand "mein Quad-Core schafft Super-Pi in x sex" blickt.

Du bist gerade ziemlich OT... Wieviele Errata hat ein Phenom II nochmal, um die 40-50? Und wieviele davon sollen erst gar nicht gefixt werden?

Es geht doch bei einem derartigen Fehler nur um die Relevanz, d.h. ob ein praktisches Auftreten zu erwarten ist. Wenn nein, ist so ein Erratum nur ein weiteres auf einer langen und größtenteils recht irrelevanten Liste einer jeden CPU.

[Avalox]

I[;7675958'] die cpus sind voll mit kleineren macken.



Nochmal.
MS war ganz kurz davor, dass MS vor den generellen Einsatz der Intel i5, i7 und der entsprechenden Xeon CPUs abgeraten hat. Dieses ist eine ganz andere Dimension, als solch ein kleiner nebenbei kommentierter Fehler.

Erst die Intervention seitens Intel in letzter Sekunde hat dieses scheinbar verhindert. So ist "nur" heraus gekommen, dass die wichtigen Energiesparfunktionen und der Turbo Boost abgeschaltet werden sollen.

[Gast]

Bei Servern geht es nicht unbedingt um Geschwindigkeit sondern auch um Zuverlässigkeit. Bin gespannt was noch alles verschwiegen wird. Und Win2k8 R2 ist betroffen, lies man den Artikel. Und dritte Aussage kapiere ich nicht. Ein AMD-Server mit 8 Sockeln ist langsamer als ein AMD-Server mit 4 Sockeln? :confused:

1.) W2K8 ist ein anderes OS als W2K8 R2

2.) Nimm dir 2 Server, einmal mit 8 Sockeln und einen mit 4 Sockeln und spiele mal bisschen mit rum (z.B. SQL-DBs, Rechenintensive Simulationssoftware) und du wirst erkennen, das das 8 Sockel System so viel mit synchronisation und Speicherzugriffen über mehrere CPUs beschäftigt ist, das ein 4 Sockel System schneller wäre. Dies ist auch der Grund, warum viele 8 Sockel AMD Server ersatzlos gestrichen wurden.

3.) Wer Zuverlässigkeit will, schaltet dieses Stromsparzeug eh ab, da es viele Software gibt (z.B. Hypervirtualisieren), die durch die versch. Taktraten aus dem Tritt kommt.

-> Das umtakten funktioniert nicht richtig, da entweder die Hostinstanz (HYper-V) die Auslastung nicht kennt oder im Fall von VMware der entsprechende Support fehlt.

mfg

[Exxtreme]

1.) W2K8 ist ein anderes OS als W2K8 R2
OK, mein Fehler.
2.) Nimm dir 2 Server, einmal mit 8 Sockeln und einen mit 4 Sockeln und spiele mal bisschen mit rum (z.B. SQL-DBs, Rechenintensive Simulationssoftware) und du wirst erkennen, das das 8 Sockel System so viel mit synchronisation und Speicherzugriffen über mehrere CPUs beschäftigt ist, das ein 4 Sockel System schneller wäre. Dies ist auch der Grund, warum viele 8 Sockel AMD Server ersatzlos gestrichen wurden.
Dazu habe ich keine Quelle gefunden, die das belegt. Ich kann mir zwar durchaus vorstellen, daß man derartige Szenarien konstruieren kann. Die Einstellung der 8-CPU-Server kann aber ganz andere Gründe haben.
3.) Wer Zuverlässigkeit will, schaltet dieses Stromsparzeug eh ab, da es viele Software gibt (z.B. Hypervirtualisieren), die durch die versch. Taktraten aus dem Tritt kommt.

-> Das umtakten funktioniert nicht richtig, da entweder die Hostinstanz (HYper-V) die Auslastung nicht kennt oder im Fall von VMware der entsprechende Support fehlt.

mfg
Gibt genug Software, die auf Taktänderungen nicht empfindlich reagiert. Und da macht Stromsparen durchaus viel Sinn da es bares Geld spart. Ein SQL-Server muss nicht mit voller Leistung laufen wenn in der Firma nach dem Feierabend niemand mehr arbeitet.

[Triskaine]

Ich zitiere aus dem AMD Errata Guide:


400. APIC Timer Interrupt Does Not Occur in Processor C-States:

Description:

An APIC timer interrupt that becomes pending in low-power states C1e or C3 will not cause the processor to enter the C0 state even if the interrupt is enabled by Timer Local Vector Table Entry[Mask], APIC320[16]). APIC timer functionality is otherwise unaffected.

Potential Effect on System:

System hang may occur provided that the operating system has not configured another interrupt source.
APIC timer interrupts may be delayed or, when the APIC timer is configured in rollover mode (APIC320[17]), the APIC timer may roll over multiple times in the low-power state with only one interrupt presented after the processor resumes.
The standard use of the APIC timer does not make this effect significant.

Suggested Workaround:

Operating system software should enable another source of timer interrupts, such as the High Precision Event Timer, before it enters the C1 state by executing the HALT instruction and C1e is enabled through Interrupt Pending and CMP-Halt Register[C1eOnCmpHalt or SmiOnCmpHalt]
(MSRC001_0055[28:27] are not 00b).
For purposes of determining if C1e is enabled, the operating system should not sample MSRC001_0055 until after ACPI has been enabled. Operating system software should enable another source of timer interrupts, such as the High Precision Event Timer, when the processor enters the C3 state.
It is possible for the system to implement a hardware fix to C1e mode on some processor revisions
and some packages. This is indicated by OSVW[1] and no workaround is necessary when
OSVW_Length >= 2 and OSVW[1] is zero. An operating system workaround for C3 mode is always
necessary, regardless of the setting of OSVW[1].

Fix Planned:

C1e state: Yes
C3 state: No


AMD Prozessoren der 10h Architektur im C3 und D0 Stepping haben insgesamt 32 dokumentierte Errata, davon 14 für die keine Behebung geplant ist.

[Coda]

I[;7675958']naja da war auch die halbe fpu kaputt.
Quatsch. Der ROM der für Berechnungen genutzt wurde falsch synthetisiert was dazu führte dass unter ganz bestimmten Bedingungen eine Division nach ziemlich vielen Stellen falsche Ergebnisse liefert.

Für den Endanwender war das eigentlich piep egal.

[_DrillSarge]I[]

Quatsch. Der ROM der für Berechnungen genutzt wurde falsch synthetisiert was dazu führte dass unter ganz bestimmten Bedingungen eine Division nach ziemlich vielen Stellen falsche Ergebnisse liefert.
von mir aus :rolleyes:


Für den Endanwender war das eigentlich piep egal.
"You mean 2.00000000 + 2.000000000 doesn't equal 3.999998456?" ;D
kommt drauf an was man macht. fdiv war ja nicht der einzige, mehr oder minder schlimme, fehler. f0 (;D) lässt grüßen.

4195835/3145727=1,33382. pentium -> 1,33374

[Coda]

F0 war ja noch viel uninteressanter für Enduser. Das ist maximal auf Servern ein Problem gewesen. Damals war x86 dort aber noch nicht sehr vertreten.

I[;7676247']kommt drauf an was man macht.
Solang man nicht irgendwelche numerischen Simulationen gebraucht hat war es egal.

Das ganze wurde ziemlich hochgekocht.

[Lawmachine79]

Du bist gerade ziemlich OT... Wieviele Errata hat ein Phenom II nochmal, um die 40-50? Und wieviele davon sollen erst gar nicht gefixt werden?

Es geht doch bei einem derartigen Fehler nur um die Relevanz, d.h. ob ein praktisches Auftreten zu erwarten ist. Wenn nein, ist so ein Erratum nur ein weiteres auf einer langen und größtenteils recht irrelevanten Liste einer jeden CPU.
Natürlich hat jede CPU diese Errata. Der Punkt ist aber a) wie relevant sind sie und b) wie gehe ich damit um? Und die von Intel eingeschlagene Vorgehensweise, die Thema dieses Threads ist, ist mal wieder unter aller Sau.

[Gast]

Das ist aber Quatsch, warmachine.
Schließlich sagt Intel, das der Fehler bei keiner kommerziellen Software auftritt. Und da stellt sich dann wirklich die Frage nach der Relevanz.
Wenn etwas nicht auftritt, ist es dann in der Praxis noch relevant oder wichtig?

Vorallem sollten wir eines nicht vergessen: Wer kennt sich besser mit seinen eigenen Prozessoren aus? Intel oder Microsoft? Ihr tut ja gerade so, als würde Microsoft alles besser wissen, sogar wie andere ihre Prozessoren zu bauen haben. :hammer:

[Exxtreme]

Das ist aber Quatsch, warmachine.
Schließlich sagt Intel, das der Fehler bei keiner kommerziellen Software auftritt.
Windows 2k8 R2 ist keine kommerzielle Software?

[Gast]

Ein Punkt den ich noch hinzufügen möchte: Wenn ein Fehler relevant ist, so würde Intel ihn schnellsten beheben.
Dafür braucht es nicht Microsoft. Denn sobald auch nur ein Großkunde Fehler meldet, fällt das alles auf Intels-Ruf zurück und das geht zu lasten des eigenen Geschäfts.
Intel tut also gut daran, Probleme nicht zu verschweigen, denn wenn sie es tun würden, müssten sie in Zukunft nicht nur die Prozessoren austauschen, sondern auch noch Schadensatz in Millionen oder Milliardenhöhe leisten. Da wäre es weitaus billiger sofort zu reagieren...

Und wie schon gesagt, eine CPU ist nicht "fehlerfrei", genau wie DRAM-Fehler immer mal wieder vorkommen, sogar in Servern. Gab letztens erst eine Studie dazu...

Windows 2k8 R2 ist keine kommerzielle Software?

Da hast du dir selbst ins Bein geschossen: Intel hat es doch gerade bei kommerzieller Software getestet und konnte es dennoch nicht bestätigen.
Glaubst du das Intel das Betriebssystem nicht getestet hat, war es doch genau das was Microsoft bemängelt hat? :crazy:

Wenn Ich ein Problem in der Form "unter Windows Server xy" gibts dieses und jenes Problem an den Prozessorbauer melde, meinst du dann nicht auch, das dieser genau diesen Sachverhalt *zuerst* überprüfen wird?
Wo steht, das Intel es NICHT nachvollzogen hat? Zeig mir die Stelle!

[Undertaker]

Natürlich hat jede CPU diese Errata. Der Punkt ist aber a) wie relevant sind sie und b) wie gehe ich damit um? Und die von Intel eingeschlagene Vorgehensweise, die Thema dieses Threads ist, ist mal wieder unter aller Sau.

Wenn ich das Posting von Triskaine in diesem Zusammenhang sehe, kann ich hier keine Intel-spezifische Besonderheit erkennen. Du? Wäre der Fehler kritisch - was er laut Intel nicht ist - gäbe es eine Rückrufaktion o.ä., siehe das Posting des Gastes über mir.

[Gast]

@Exxtreme
Das eine schließt das andere nicht aus.

Intel hat den Fehler bei keiner kommerziell erhältlichen Software beobachtet.

Darunter könnte das Betriebssystem sein, denn ohne dieses hätten sie es kaum testen können, da es ja gerade im Zusammenhang mit diesem auftreten soll.. denk dir den Rest, falls du so weit denken magst. ;)

Viel interessanter ist doch aber diese Passage:

Hat doch Microsoft beim integrierten Hypervisor von Windows Server 2008 R2 mutig auf eine Timer-Funktion zurückgegriffen, die die Redmonder bei früheren Prozessoren selbst als unzuverlässig eingestuft hatten: den Timer des Advanced Programmable Interrupt Controller (APIC).

Mir stellt sich da vielmehr die Frage warum Microsoft etwas tut, von dem klar gewesen ist, das es schonmal Probleme bereitete. Wieso dreht sich das Thema hier nicht darum? Denn sie hätten es offensichtlich vermeiden können, sollte das nicht oberste Priorität haben?

[Lawmachine79]

Ein Punkt den ich noch hinzufügen möchte: Wenn ein Fehler relevant ist, so würde Intel ihn schnellsten beheben.
Dafür braucht es nicht Microsoft. Denn sobald auch nur ein Großkunde Fehler meldet, fällt das alles auf Intels-Ruf zurück und das geht zu lasten des eigenen Geschäfts.
Intel tut also gut daran, Probleme nicht zu verschweigen, denn wenn sie es tun würden, müssten sie in Zukunft nicht nur die Prozessoren austauschen, sondern auch noch Schadensatz in Millionen oder Milliardenhöhe leisten. Da wäre es weitaus billiger sofort zu reagieren...


Das ist eine Abwägungsfrage im Zuge des Risikomanagements. Man kann darauf spekulieren, daß nie ein Großkunde negativ davon betroffen sein wird. Also eine rein stochastische Frage. Startet man hingegen einen Rückruf leidet Intels Ruf so oder so. Startet man keinen, leidet er nur vielleicht, dafür aber stärker.
Wenn ich das Posting von Triskaine in diesem Zusammenhang sehe, kann ich hier keine Intel-spezifische Besonderheit erkennen. Du? Wäre der Fehler kritisch - was er laut Intel nicht ist - gäbe es eine Rückrufaktion o.ä., siehe das Posting des Gastes über mir.
Intel ist nicht geeignet um zu beurteilen, ob ein Fehler von Intel kritisch ist oder nicht. Sonst könnte ich ja meine eigene Steuererklärung prüfen und die Auszahlung veranlassen.

[Gast]

Intel ist nicht geeignet um zu beurteilen, ob ein Fehler von Intel kritisch ist oder nicht. Sonst könnte ich ja meine eigene Steuererklärung prüfen und die Auszahlung veranlassen.

Intel ist dazu geeignet zu beurteilen, ob Intel Prozessoren einen Fehler haben, den Intel verursacht hat.

Ich bezweifle, das du eine Ausbildung zum Steuerberater gemacht hast, Intel besitzt tausende, wenn nicht noch mehr Experten auf dem Gebiet.
Ich stelle mir da vielmehr die Frage, woher Microsoft das Wissen nimmt, wieviel Ahnung haben die denn von Prozessorenbau?

[Black-Scorpion]

Und wie viel hast du davon?
Es muss sich doch so langsam überall herumgesprochen haben das bei Intel aus Prinzip erstmal alle Schuld sind nur sie nicht.
Und nun überlegen wir warum es nur die Nehalem betrifft und die anderen CPUs nicht.
Aber Intel macht ja keine Fehler.

[Undertaker]

Intel ist nicht geeignet um zu beurteilen, ob ein Fehler von Intel kritisch ist oder nicht. Sonst könnte ich ja meine eigene Steuererklärung prüfen und die Auszahlung veranlassen.

Natürlich ist Intel dazu geeignet, die wirtschaftlichen Folgen einer überflüssigen oder versäumten Rückrufaktion kann nur der Hersteller selbst abwägen. Warum wurde der P3 1,13GHz wohl zurückgerufen?

[Lawmachine79]

Natürlich ist Intel dazu geeignet, die wirtschaftlichen Folgen einer überflüssigen oder versäumten Rückrufaktion kann nur der Hersteller selbst abwägen. Warum wurde der P3 1,13GHz wohl zurückgerufen?
Weil man dort im Zuge der Abwägung zu dem Schluß gekommen ist, daß die Eintrittswahrscheinlichkeit so hoch ist, daß mit ziemlicher Sicherheit davon ausgegangen werden muss, daß der zu erwartende Schaden eintritt (wir erinnern uns: Risiko=Eintrittswahrscheinlichkeit x zu erwartender Schaden). Bei den Nehalembugs pokert man halt, weil man die Eintrittswahrscheinlichkeit geringer einschätzt. Microsoft aber ist für sein Produkt zu dem Schluß gekommen, das Risiko anders zu bewerten und wollte eine Empfehlung aussprechen (für sein Produkt), die unter dem Druck Intels nicht ausgesprochen wurde.

[Coda]

Warum wurde der P3 1,13GHz wohl zurückgerufen?
Weil der Chip nicht stabil war. Das hier ist etwas anderes. Es treten ja keine zufälligen Fehler auf. Auch bringt rückrufen nicht viel wenn in er Errata-Liste "No Fix" vermerkt ist ;)

Der APIC-Timer gehört übrigens zur Northbridge, nicht zur CPU selbst.

Im übrigen glaube ich immer noch, dass das ganze relativ einfach in Software zu fixen wäre, das Problem ist nur, dass Microsoft offenbar nicht genügend validiert hat. Intel hat den Bug ja dokumentiert, wohl schon bevor 2008 R2 auf dem Markt war.

[Gast]

@Black-Scorpion
Möchtest du sagen, das Microsoft ein besseres Unternehmen ist? Dann müsste ich laut lachen.
Dreck am Stecken haben sie alle und vertuschen tun sie es auch, wie oft hab ich schon Meldungen von Sicherheitslücken gelesen, die nicht öffentlich gemacht wurden? Egal ... das die EU und andere gegen Intel oder Microsoft vorgeht, sollten wir nicht vergessen.

Solche Großunternehmen tun alles, um ihren Ruf zu wahren. Wenn ein Problem auftritt, das mehrere Ursachen haben kann, ist es natürlich ein leichtes, die Schuld auf andere zu schieben, ohne den eigenen Fehler konkret zu benennen.

Ich bin mir sogar ziemlich sicher, das in den Testlaboren sogar kritische Fehler gefunden werden, nur gelangt sowas nicht an die Öffentlichkeit, weil es vor Auslieferung behoben wird. Als Mitarbeiter plaudert man Geschäftsgeheimnisse sowieso nicht aus, wenn man nicht ruiniert werden möchte.

[Undertaker]

Weil der Chip nicht stabil war. Das hier ist etwas anderes. Es treten ja keine zufälligen Fehler auf. Auch bringt rückrufen nicht viel wenn in er Errata-Liste "No Fix" vermerkt ist ;)

Der APIC-Timer gehört übrigens zur Northbridge, nicht zur CPU selbst.

Genau das meinte ich ja damit. ;) Dort war der Fehler so kritisch, dass er nicht nur gefixt werden musste, sondern auch ein Rückruf folgte. Das ist hier wohl nicht der Fall.

[Undertaker]

Weil man dort im Zuge der Abwägung zu dem Schluß gekommen ist, daß die Eintrittswahrscheinlichkeit so hoch ist, daß mit ziemlicher Sicherheit davon ausgegangen werden muss, daß der zu erwartende Schaden eintritt (wir erinnern uns: Risiko=Eintrittswahrscheinlichkeit x zu erwartender Schaden). Bei den Nehalembugs pokert man halt, weil man die Eintrittswahrscheinlichkeit geringer einschätzt.

Exakt, nur das das kein "Poker", sondern eine durchaus verlässliche Einschätzung von Intels Ingenieuren sein dürfte - die den Fehler für praktisch nicht relevant halten ("commercial software"). Übrigens genau der gleiche Punkt wie bei jedem Erratum. Jetzt ist die Frage, was unterscheidet dieses von anderen, z.B: dem von Triskaine geposteten bei Phenom II CPUs? Beide sind offensichtlich nicht so relevant, dass akuter Handlungsbedarf besteht. Und das sagt alles. :)

[Coda]

Intel wird ihn nichtmal fixen.

Es sind auch schon viel zu viel Prozessoren auf dem Markt und der Fehler viel zu lang bekannt, als das Microsoft die Schuld in Richtung Intel schieben sollte.

Die Bugs sind zwar ärgerlich, aber als jemand der Systemsoftware schreibt sollte man sich die Fehlerlisten von AMD und Intel schon genau anschauen. Es ist ja auch nicht so, als wären Fehler in der APIC-Implementierung eine Seltenheit. Das ganze ist offenbar relativ komplex im Zusammenspiel mit den Taktwechseln und dem restlichen System.

[Lawmachine79]

Exakt, nur das das kein "Poker", sondern eine durchaus verlässliche Einschätzung von Intels Ingenieuren sein dürfte - die den Fehler für praktisch nicht relevant halten ("commercial software"). Übrigens genau der gleiche Punkt wie bei jedem Erratum. Jetzt ist die Frage, was unterscheidet dieses von anderen, z.B: dem von Triskaine geposteten bei Phenom II CPUs? Beide sind offensichtlich nicht so relevant, dass akuter Handlungsbedarf besteht. Und das sagt alles. :)
Nein, hier ist eben der Unterschied, das Microsoft zu einer wesentlich anderen Beurteilung gekommen ist und sie diese Beurteilung auf Druck von Intels ändern mussten. Wenn kein Handlungsbedarf bestünde, hätte man Microsoft ja einfach machen lassen können und das Ganze argumentativ aus eigener Sicht gegendarstellen.
Intel wird ihn nichtmal fixen.


Ist ja auch nicht mehr notwendig, nachdem Microsoft die Empfehlung geändert hat, ist der Handlungsdruck dafür ja weg.

[Undertaker]

Nein, hier ist eben der Unterschied, das Microsoft zu einer wesentlich anderen Beurteilung gekommen ist und sie diese Beurteilung auf Druck von Intels ändern mussten. Wenn kein Handlungsbedarf bestünde, hätte man Microsoft ja einfach machen lassen können und das Ganze argumentativ aus eigener Sicht gegendarstellen.

Sagt Microsoft nicht selbst, das der Fehler auch mehrere ältere CPUs betrifft? Und wenn Coda meint, dass Intel nichteinmal einen Fix plant, was gibts da noch zu diskutieren? Auch Microsoft berichtet nicht von konkreten Problemen, sondern warnt nur davor - wenn diese laut CPU-Hersteller nicht auftreten können, ist das Erratum nicht bedeutsamer als die vielen anderen, die es noch so gibt.


Ist ja auch nicht mehr notwendig, nachdem Microsoft die Empfehlung geändert hat, ist der Handlungsdruck dafür ja weg.

Der Handlungsdruck entsteht nicht daraus was Microsoft sagt, sondern aus der Relevanz des Problems. Alles andere sind Verschwörungstheorien.

[Avalox]

Sagt Microsoft nicht selbst, das der Fehler auch mehrere ältere CPUs betrifft?


Die älteste CPU welche dort erwähnt wird ist der Core i7.
Danach folgen die entsprechenden Xeon Gegenstücke und der Core i5.


Auch Microsoft berichtet nicht von konkreten Problemen

Natürlich sind diese konkret, reproduzierbar und zudem sehr praxisnah. Steht doch alles in der MS KB.

[Exxtreme]

Exakt, nur das das kein "Poker", sondern eine durchaus verlässliche Einschätzung von Intels Ingenieuren sein dürfte
Ich denke, daß MS eine bessere Einschätzung bezüglich des Win2k8 R2 abgeben kann als Intel.

[Coda]

Ist ja auch nicht mehr notwendig, nachdem Microsoft die Empfehlung geändert hat, ist der Handlungsdruck dafür ja weg.
*facepalm*

Die Errata-Liste gibt es schon viel länger als das MS-Key-Bulletin.

[Lawmachine79]

*facepalm*

Die Errata-Liste gibt es schon viel länger als das MS-Key-Bulletin.
Das ist mir bekannt. Aber nur weil in der Errataliste steht, daß kein Fix geplant ist, heisst das nicht, daß man nicht hätte umplanen müssen. Drehe man es wie man will, hätte das in dem Dokument gestanden, hätte Intel IRGENDWAS tun müssen. Und wenn kein Fix geplant ist, heisst das nicht, daß "wir tun nichts" eine Option ist, wenn das in dem Microsoftdokument steht. Das hätte nämlich einige Aufmerksamkeit auf sich gezogen. Das öffentliche Echo wäre vernichtender gewesen als nach dem "Pentium"-Bug. Da ist es dann völlig wurscht, wie lange es welche Liste und welches Bulletin gab.

Der Handlungsdruck entsteht nicht daraus was Microsoft sagt, sondern aus der Relevanz des Problems.
Handlungsdruck entsteht heutzutage aus öffentlichem Druck und der Angst vor Einnahmeverlusten (die wiederum durch öffentlichen Druck noch mehr Rechtfertigung erfährt). Die Essenz ist doch: "Microsoft rät vom Einsatz von Premiumprozessoren der Premiummarke in der Premiumpreisklasse in seinem Serverbetriebssystem ab". Genauso hätte es sinngemäß in der Fachpresse gelautet.

Wieso übt Intel den Druck auf MS aus, "wenn das alles gar nicht so schlimm ist".

[Gast]

Dazu habe ich keine Quelle gefunden, die das belegt. Ich kann mir zwar durchaus vorstellen, daß man derartige Szenarien konstruieren kann. Die Einstellung der 8-CPU-Server kann aber ganz andere Gründe haben.

Ich habe mehrere derartigen Server gesehen (z.B. HP DL 785) und nach den Performance Problemen wurden die zurück genommen. Unter der Hand erfährt man einiges mehr, aber nattürlich nichts offizielles ...

[Coda]

Das ist mir bekannt. Aber nur weil in der Errataliste steht, daß kein Fix geplant ist, heisst das nicht, daß man nicht hätte umplanen müssen. Drehe man es wie man will, hätte das in dem Dokument gestanden, hätte Intel IRGENDWAS tun müssen. Und wenn kein Fix geplant ist, heisst das nicht, daß "wir tun nichts" eine Option ist, wenn das in dem Microsoftdokument steht. Das hätte nämlich einige Aufmerksamkeit auf sich gezogen. Das öffentliche Echo wäre vernichtender gewesen als nach dem "Pentium"-Bug. Da ist es dann völlig wurscht, wie lange es welche Liste und welches Bulletin gab.
Der Punkt ist, dass du meinst Intel müsse irgendwas fixen. Da bin ich ganz anderer Meinung.

Wenn Microsoft schon im Hypervisor den wirklich schon öfters unzuverlässigen APIC-Timer verwendet, dann sollten sie ihn auch so robust auslegen, dass er mal mit einem falschen Timer-Interrupts leben kann. Der Fix wäre einfach den letzten Status zu prüfen ob der Interrupt nicht schonmal reinkam. Das ist einfach eh eine gute Idee.

Weißt du überhaupt was ein Interrupt ist und was er veranlasst?

Microsoft flennt nur rum, weil sie zu dumm waren das zu bemerken bevor sie 2008 R2 ausgeliefert haben, und jetzt soll Intel der Sündenbock sein?

[Lawmachine79]

Der Punkt ist, dass du meinst Intel müsse irgendwas fixen. Da bin ich ganz anderer Meinung.

Wenn Microsoft schon im Hypervisor den wirklich schon öfters unzuverlässigen APIC-Timer verwendet, dann sollten sie ihn auch so robust auslegen, dass er mal mit einem falschen Timer-Interrupts leben kann. Der Fix wäre einfach den letzten Status zu prüfen ob der Interrupt nicht schonmal reinkam. Das ist einfach eh eine gute Idee.

Weißt du überhaupt was ein Interrupt ist und was er veranlasst?

Microsoft flennt nur rum, weil sie zu dumm waren das zu bemerken bevor sie 2008 R2 ausgeliefert haben, und jetzt soll Intel der Sündenbock sein?
Jaaaa, ich weiß, was ein Scheiß-IRQ ist und bevor Du mich nach E/A-Adressen und DMA-Kanälen fragst, die kenne ich auch noch, damit habe ich mich zu Doszeiten (ich habe meinen ersten PC 1989 im zarten Alter von 10 gebaut) und bis einsch. Windows 98 zur Genüge rumgeschlagen, damals war dieses Systemverständnis ja noch notwendig, um z.B. eine Soundkarte und eine Netzwerkkarte im gleichen PC fehlerfrei zum Laufen zu bringen. Und der APIC brachte unter anderem die Verbesserung, daß es nicht mehr nur 16 sondern 32 IRQ-Leitungen sind, die zur Verfügung stehen. Also, es gibt noch etwas zwischen dem eingefleischten Programmierer/Coder und einem Computerbild-Leser.
Davon abgesehen, MÜSSTE ich aber nicht wissen, was ein IRQ ist, was ein PIC oder ein APIC ist, um zusammenzufassen, daß Microsoft in einem Dokument von Intel-CPUs abraten wollte. In diesem Falle hätte Intel die legitimen Möglichkeiten gehabt, den Fehler, der diesen Rat Microsofts begründete, abzustellen oder mit der Empfehlung zu leben. Man entschied sich aber für keine legitimie sondern für eine nicht legitime Möglichkeit und zwar dafür, Microsoft unter Druck zu setzen, diese Empfehlung zu ändern. Das ist eine völlig einfache Darstellung des Sachverhalts. Mir ist in diesem Zusammenhang egal, ob es um einen APIC geht oder ob Microsoft einen wackeligen Weg gewählt hat, um Timingangelegenheiten nach diversten Schlafzuständen zu regeln. Es geht schlichtweg um Intels Geschäftsgebahren, da kann Microsoft meinentwegen auswürfeln, wie sie das Problem regeln, es ändert dennoch nichts an dem Geschäftsgebahren und an der Art und Weise, wie da gehandelt wird.
Also ich meine mitnichten, daß Intel irgendwas fixen MUSS. Die MÜSSEN gar nix. Vielleicht WOLLEN sie was fixen. Und wenn sie nichts fixen WOLLEN dann MÜSSEN sie damit leben, daß Softwarefirmen diese Dinge, sofern für den reibungslosen Betrieb notwendig, eben dokumentieren. Intel hat die Wahl etwas zu fixen und dafür etwas zu investieren oder es eben nicht zu tun und mit den Folgen zu leben. Die Lösung kann dann aber nicht sein, das andere Unternehmen zu bestimmten Handlungen zu nötigen. Microsoft wird das ja mit Sicherheit nicht durch gutes Zureden wieder entfernt haben.

[Coda]

Jaaaa, ich weiß, was ein Scheiß-IRQ ist
Das hat nur sehr entfernt mit IRQs zu tun.

Man entschied sich aber für keine legitimie sondern für eine nicht legitime Möglichkeit und zwar dafür, Microsoft unter Druck zu setzen, diese Empfehlung zu ändern.
Ich finde das in diesem Fall aber durchaus legitim. Und was von "Druck ausüben" steht auch nirgends im Heise-Artikel. Da kann auch ein ganz normales Gespräch gewesen sein.

[Lawmachine79]

Das hat nur sehr entfernt mit IRQs zu tun ;)
Das ist eine Hauptaufgabe des APICs ;).

Davon abgesehen habe ich denke ich deutlich genug gemacht, daß es nicht technische Unzulänglichkeiten selbst sind, die mir gegen den Strich gehen. Ich streite auch gar nicht ab, daß Du wahrscheinlich über mehr technisches Detailwissen als ich verfügst (oder technisches Wissen allgemein, nicht daß "Detailwissen" als Einschränkung verstanden wird). Mir geht es um was völlig anderes: ein Konzern von der Größe Intels definiert sich eben nicht nur dadurch, daß er "mal 'n paar CPUs baut", sondern eben auch durch sein Auftreten in der Öffentlichkeit. Das habe ich aber in all meinen Posts sehr deutlich gemacht.

[Undertaker]

Die älteste CPU welche dort erwähnt wird ist der Core i7.
Danach folgen die entsprechenden Xeon Gegenstücke und der Core i5.


Nein, ich denke da verstehst du folgenden Satz falsch:

"Hat doch Microsoft beim integrierten Hypervisor von Windows Server 2008 R2 mutig auf eine Timer-Funktion zurückgegriffen, die die Redmonder bei früheren Prozessoren selbst als unzuverlässig eingestuft hatten"

"frühere Prozessoren" kann in diesem Zusammenhang nicht wirklich die diskutierten Nehalem/Lynnfield beinhalten, dann macht die Formulierung wenig Sinn.

Ein Hotfix scheint ja laut c't auch zu existieren, damit liegt der Ball bei MS.

[Coda]

Das ist eine Hauptaufgabe des APICs ;).

Davon abgesehen habe ich denke ich deutlich genug gemacht, daß es nicht technische Unzulänglichkeiten selbst sind, die mir gegen den Strich gehen. Ich streite auch gar nicht ab, daß Du wahrscheinlich über mehr technisches Detailwissen als ich verfügst (oder technisches Wissen allgemein, nicht daß "Detailwissen" als Einschränkung verstanden wird). Mir geht es um was völlig anderes: ein Konzern von der Größe Intels definiert sich eben nicht nur dadurch, daß er "mal 'n paar CPUs baut", sondern eben auch durch sein Auftreten in der Öffentlichkeit. Das habe ich aber in all meinen Posts sehr deutlich gemacht.
Was mir daran nicht passt, ist dass ich Microsoft hier in der Bringpflicht halte und nicht Intel!

Ich stimme ja mit dir überein, dass Intel manchmal ziemlich unsaubere Geschäftspraktiken hat, aber bin diesem Fall haben sie genau richtig gehandelt.

Da wäre wieder ein riesen Trara um nichts gemacht worden in der Presse.

[Exxtreme]

Das ist eine Hauptaufgabe des APICs ;).

Davon abgesehen habe ich denke ich deutlich genug gemacht, daß es nicht technische Unzulänglichkeiten selbst sind, die mir gegen den Strich gehen. Ich streite auch gar nicht ab, daß Du wahrscheinlich über mehr technisches Detailwissen als ich verfügst (oder technisches Wissen allgemein, nicht daß "Detailwissen" als Einschränkung verstanden wird). Mir geht es um was völlig anderes: ein Konzern von der Größe Intels definiert sich eben nicht nur dadurch, daß er "mal 'n paar CPUs baut", sondern eben auch durch sein Auftreten in der Öffentlichkeit. Das habe ich aber in all meinen Posts sehr deutlich gemacht.
Was ich noch viel krasser finde, ist daß MS absolut Intel-hörig ist. Die wagen es scheinbar niemals zu widersprechen. Intel schafft es jedes Mal die unter Druck zu setzen und die geben jedes Mal klein bei.

[Avalox]

"frühere Prozessoren" kann in diesem Zusammenhang nicht wirklich die diskutierten Nehalem/Lynnfield beinhalten, dann macht die Formulierung wenig Sinn.


Nee, nee. Mit diesen früheren CPUs scheint es ja zu funktionieren, mit dem Hinweis von Intel. Vielleicht ist das Handling in Windows 2008 R2 entsprechend robust ausgelegt worden.

Nach dem Meldung von MS und der nun dargelegten Fehlerbeschreibung von Intel, funktioniert es eben gerade ab dem i7 nicht mehr. Die Situation hat sich mit dem i7 verschlechtert, bzw. es kommt erst ab dem i7 zum tatsächlichen Fehlverhalten.




Ein Hotfix scheint ja laut c't auch zu existieren, damit liegt der Ball bei MS.

Dieser wird bestimmt C3 und C6 inkl. Turbo-Boost usw. des Nehalem Kerne einfach im System abschalten. So, dass man die Reg Schlüssel nicht per Hand zu setzen hat.

[Coda]

Was ich noch viel krasser finde, ist daß MS absolut Intel-hörig ist. Die wagen es scheinbar niemals zu widersprechen. Intel schafft es jedes Mal die unter Druck zu setzen und die geben jedes Mal klein bei.
Wo war das denn noch so?

Intel wollte Microsoft z.B. dazu überreden eine andere 64-Bit-Erweiterung für x86 zu unterstützen und Microsoft hat es nicht getan. Nur deshalb unterstützen Intel-Prozessoren heute AMD64.

Dieser wird bestimmt C3 und C6 inkl. Turbo-Boost usw. des Nehalem Kerne einfach im System abschalten. So, dass man die Reg Schlüssel nicht per Hand zu setzen hat.
Glaub ich eher weniger.

Das sind wohl nur ein paar Zeilen Code an den richtigen Stellen um den Fehler zu vermeiden.

[Gast]

Dieser wird bestimmt C3 und C6 inkl. Turbo-Boost usw. des Nehalem Kerne einfach im System abschalten. So, dass man die Reg Schlüssel nicht per Hand zu setzen hat.

Hallo,

macht er nicht, ich habe den schon selbst installiert und es geht nachher immer noch.

mfg

[Avalox]

Hallo,

macht er nicht, ich habe den schon selbst installiert und es geht nachher immer noch.


Na ja, weiss man nicht, ob er cleverer Weise es dynamisch handelt. Eben genau dann C3 und C6 abschaltet, wenn entsprechend der Hypervisor kritisch genutzt wird.

Solange MS nichts dazu schreibt, kann man auch nichts verbindliches sagen.

[Coda]

Eben genau dann C3 und C6 abschaltet, wenn entsprechend der Hypervisor kritisch genutzt wird.
Das wäre viel mehr Aufwand als einfach zu schauen, ob der Interrupt der gerade ankommt nicht falsch ausgelöst wurde.

Und ich würde jetzt mal sagen, dass das auch überhaupt nicht machbar ist einfach im Betrieb C3 und C6 zu deaktivieren.

[Köstlich]

Interessantes Geflüster, pikant dass Microsoft von Nehalem-CPUs abrät. :-)

[HOT]

Das wird aber auch ne politische Dimension haben zwischen M$ und Intel. Da spielen nur wirtschaftliche und politische Beweggründe eine Rolle, wie die damit umgehen. Technisch wird das nicht so schlimm sein.
Übrigens misstrauen Admins von Natur aus sämtlichen taktmodifizierenden und anderen Enegiesparmechanismen ziemlich. Turbomode wird sowieso total ignoriert im Profisegment. C1E und andere Taktmodifiziernde Massnahmen werden ebenfalls nicht angewendet werden. Das ist alles viel zu unsicher und generiert evtl. zusätzliche Arbeit. Es ist einfach wichtig, dass der Prozessor absolut vorhersehbar arbeitet.

[StefanV]

Knacktus ist schon mal, dass die Nehalem Systeme kein C3 und C6 und auch den Turbo Boost nicht verwenden sollen. Die Energieeffizienz ist dann auch hin.

Schon ein sehr knackiger Fehler im Nehalem. Hat Intel wohl einige Register gezogen um zu verhindern, dass MS das Papier mit der Empfehlung ganz auf den Nehalem zu verzichten so nicht heraus bringt und "nur" empfiehlt auf C3 und C6 zu verzichten.
Ja, vorallen wenn du dir dieses Posting (http://www.computerbase.de/forum/showpost.php?p=6942274&postcount=68) anschaust.
Weiter unten sagt ein User, das C3 und C6 auch deaktivert werden mussten, damit das NT aufhört zu singen...

Die Stromsparmechanismen im Nehalem bzw hier in diesem Falle eher Bloomfield, scheinen also nicht so ganz einwandfrei und problemlos zu funktionieren.

[Coda]

Was kann Nehalem für beschissene Spannungswandler irgendwo im System?

Natürlich funktionieren die Stromsparmechanismen so wie sie sollen.

[Ronny145]

Ja, vorallen wenn du dir dieses Posting (http://www.computerbase.de/forum/showpost.php?p=6942274&postcount=68) anschaust.
Weiter unten sagt ein User, das C3 und C6 auch deaktivert werden mussten, damit das NT aufhört zu singen...

Die Stromsparmechanismen im Nehalem bzw hier in diesem Falle eher Bloomfield, scheinen also nicht so ganz einwandfrei und problemlos zu funktionieren.


Auch interessant dabei:



Hab mir nun ein Enermax Modu82+ 525 Watt gekauft und eingebaut...........und man hört direkt am Netzteil eigentlich nur etwas wenn man sich als kleinlich bezeichnen würde^^...

Im Vergleich zu den Cougar Netzteilen ein krasser unterschied !!!.


Hier versucht Compucase den schwarzen Peter den Mainboard Herstellern in die Schuhe zu schieben. Aber wenn einige NTs weniger Probleme haben, ist das auch nur die halbe Wahrheit. Aber so oder so hat das wohl kaum was mit der CPU zu tun, dann eher was mit dem Board. Minderwertige Bauteile oder was auch immer. Den Stromsparmechanismen kann man da nicht die Schuld geben. Im Thread ist außerdem zu lesen das die Probleme teilweise erst nach einem Bios Update auftraten.

[StefanV]

Dann schau dir den Thread noch weiter an, da gibts noch Berichte von anderen Netzteilen, die anfangen zu singen.

@Coda
Nun, immerhin passiert das bei 3 komplett verschiedenen Boards, bei dem einen (Gigabyte) hängt es von der BIOS Version ab, bei den anderen beiden (MSI P55 und ASUS) wohl nicht.
Unschön ist, das auch hier niemand der Sache aufm Grund gehen wird bzw sich das mal genauer anschauen werden wird...

[Coda]

Nun, immerhin passiert das bei 3 komplett verschiedenen Boards.
Fiepen kommt von den Spulen der Spannungswandlung. Vermutlich haben sie alle ähnliche Schaltkreise.

Eine CPU fiept ganz bestimmt nicht :freak:

[StefanV]

Das ist mir schon klar.

Ich dachte hier auch eher an die Intel VRM Spec für die Spannungsregler als an die CPU selber.

[Undertaker]

Inwiefern sollte eine VRM-Spec Spulenfiepen verhindern können? So ein Geräusch entsteht doch ganz simpel durch schwingende Wicklungen, bei entsprechender Vorsorge kann allein durch z.B. Vergießen jegliches Problem vermieden werden.

[Botcruscher]

Das kostet doch aber Geld und wir wissen doch wie schlecht die Gewinnspanne bei Netzteilen ist.:freak:

[puntarenas]

Wo gibt es denn "vergossene Spulen" im Consumerbereich? Weder die kleinen Dinger auf Grafikkarten und Boards, noch die großen Spulen in Netzteilen kommen umwickelt oder vergossen daher. Es wäre wünschenswert, wenn dies nach der "All solid capacitators" Marketingwelle der nächste Trend wäre.

Ich frage mich, wie teuer das sein kann? Es ist doch deprimierend, wenn man für wenige Euro ein "Plastikspray" erhält, mit dem sich das Spuelenfiepen wirksam bekämpfen lässt, so man den an die Spule rankommt. Ich tippe mal frech auf wenige Cent in der Massenfertigung und das kotzt mich dann einfach nur an. Oder gibt es technische Bedenken oder gar Nachteile?

Ob das als Anforderung in die Plattformspezifikationen aufgenommen werden könnte, kann ich nicht beurteilen, aber spezifiziert oder nicht, ich würde mir das als selbstverständlich bei Board- und Netzteilherstellern wünschen.

[Coda]

Das ist mir schon klar.

Ich dachte hier auch eher an die Intel VRM Spec für die Spannungsregler als an die CPU selber.
Ich glaube kaum, dass da drin steht was für einen Spulen-Hersteller man verwenden muss.

Vermutlich ergibt sich bei der Referenzimplementierung aber genau in den States eine Resonanzfrequenz die man hört wenn man billige Spulen einsetzt. Die Mainboard-Hersteller sollte man da aber eher anschwärzen wenn sie wegen sowas Cents sparen.

[Avalox]

Ich dachte hier auch eher an die Intel VRM Spec für die Spannungsregler als an die CPU selber.

Die allergrößte Herausforderung für eine Stromversorgung sind plötzliche Lastwechsel. Die CPU, welche ja durchaus für gigantische Lastwechsel in kürzesten Zeiträumen sorgen kann, ist dort ganz sicher eine Herausforderung für die Stromversorgung und kann durch ihre Funktion die Stromversorgung klar stressen.



Grundsätzlich fände ich die Frage interessant; ob man beim Intel i7 die Stromsparmodi so modulieren kann, dass das Netzteil "Always look on the bride side of life" pfeift?

[Lawmachine79]

Ich glaube kaum, dass da drin steht was für einen Spulen-Hersteller man verwenden muss.

Vermutlich ergibt sich bei der Referenzimplementierung aber genau in den States eine Resonanzfrequenz die man hört wenn man billige Spulen einsetzt. Die Mainboard-Hersteller sollte man da aber eher anschwärzen wenn sie wegen sowas Cents sparen.
Das gilt bei den unverschämten Boardpreisen umso mehr.

[puntarenas]

Intel-Themenabend bei PCGH - Warum pfeifen Netzteile mit P55-Boards? (http://extreme.pcgameshardware.de/1304447-post15.html)

Intel macht es sich da meiner Meinung nach zu einfach, denn egal ob nun Mainboard oder Netzteil, der Branchenriese zeichnet sowohl für die P55-Plattformspezifikationen, als auch für die ATX Power Supply Guide verantwortlich und mir kann keiner erzählen, dass die Ingenieure dort vom Wechselspiel zwischen Boards und Netzteilen erst durch Forenberichte erfahren haben. Dass PC-Hersteller wie Dell in ihren Fertigrechnern Board und Netzteil aufeinander abstimmen, tröstet die Kunden von teuren Boards und Netzteilen aus dem Retailmarkt bestimmt wenig.

Das gilt bei den unverschämten Boardpreisen umso mehr.
Ich muss sagen, die P55-Plattform kommt mir mittlerweile ausgesprochen halbgar vor und Intel bekleckert sich nicht gerade mit Ruhm. Allerdings bin ich auch von den Boardherstellern enttäuscht, entweder verifizieren die ihre Hardware nicht oder sie haben Null Qualitätsanspruch, dann braucht aber auch niemand Boards für >100€ mit Heatpipes auf Chips, die nicht einmal mehr die Nothbridge beinhalten. Alles Moppelkotze! :mad:

[StefanV]

Ich würde hier sogar fast vermuten, das ein paar dickere Kondensatoren zwischen NT und CPU VRM helfen könnten.

[Chrisch]

Was hat das Fiepen einiger Netzteile mit "MS wollte wohl vom Einsatz des Nehalem mit Windows 2k8 R2 abraten" zu tun?

Btw hab ich 3 NTs im Einsatz (Corsair HX1000W, Corsair 400W & Seasonic M12-600W) und das Seasonic ist das einzige welches sich mit einigen Boards nicht verträgt (fiept).

[Lawmachine79]

Was hat das Fiepen einiger Netzteile mit "MS wollte wohl vom Einsatz des Nehalem mit Windows 2k8 R2 abraten" zu tun?


Weil sich langsam ein bestimmtes Gesamtbild ergibt: abfackelnde Sockel, CPU nicht mit handelsüblichen Betriebssystemen einsetzbar, fiepende Motherboards - und die "Wegwerfplatinen" fangen bei 75€, für weniger Geld bekommt man bei anderen Plattformen ein verkapptes Highendboard: http://geizhals.at/deutschland/a430932.html , für ein "ordentliches" P55-Board legt man mindestens 100€ hin. Insgesamt nennt man so etwas eine Bastelplattform - da passt die Empfehlung von Microsoft perfekt ins Bild. Naja, aber immerhin 400+ fps in 640x480...

[Undertaker]

Nun ist endgültig klar, was der Hauptgrund für diesen Thread war und ist...

[Ronny145]

Immerhin hat sich warmachine79 geoutet, also ernst nehmen kann man den nicht. Das sind auch immer wieder die selben, wenns mal wieder was zu bashen gibt. Nur gut das mein 80€ Schrottboard noch kein Fiepen oder sonstige Symptome gezeigt hat.

[puntarenas]

Nur gut das mein 80€ Schrottboard noch kein Fiepen oder sonstige Symptome gezeigt hat.
Ja, gut für dich. Trotzdem kommen diese Kommentare und die zahlreichen Userklagen bestimmt nicht aus dem Nichts:

Statement von Cougar (http://www.computerbase.de/forum/showpost.php?p=6942274&postcount=68)
Statement von Intel (http://extreme.pcgameshardware.de/1304447-post15.html)

Ob es bedauerliche Einzelfälle sind oder sich eine Tendenz zu unschönen Störgeräuschen auf der LGA1156-Plattform abzeichnet, wird man sehen. Die Störgeräusche kommen in dem Fall übrigens nicht vom "Schrottboard", sondern aus dem Netzteil, auch wenn Board und Netzteil hierbei Teamwork leisten.

[Botcruscher]

Dann sei glücklich. Was zu den Gigabyte Boards bezüglich USB hört ist auch alles andere als gut...

[Ronny145]

Ja, gut für dich. Trotzdem kommen diese Kommentare und die zahlreichen Userklagen bestimmt nicht aus dem Nichts:

Statement von Cougar (http://www.computerbase.de/forum/showpost.php?p=6942274&postcount=68)
Statement von Intel (http://extreme.pcgameshardware.de/1304447-post15.html)


Kenne ich alles schon. Nur was soll das Cougar Statement überhaupt zeigen? Das beweist nichts. Man kann das Problem damit umgehen, das ist klar. Compucase versucht die Schuld abzuwälzen, womit sie vielleicht richtig liegen. Ich weiß es nicht. Compucase hatte eine fiependes Netzteil untersucht und in der Firma kein Fiepen festgestellt. Die Argumentation geht nicht auf. Jedes System kann anders reagieren und somit auch das Netzteil. Vielleicht verträgt sich das Netzteil mit den Lastwechseln des Lynnfield nicht.

Bei Gelegenheit schalte ich die Sachen mal aus und lausche am Netzteil, vielleicht höre ich ein Unterschied. Gigabyte und Cougar soll ja die gefährliche Mischung sein.

[Schrotti]

Wieder so ein Panikmache Thread.

Meine Kombination pfeift oder fiept nicht.

[Odal]

Weil sich langsam ein bestimmtes Gesamtbild ergibt: abfackelnde Sockel, CPU nicht mit handelsüblichen Betriebssystemen einsetzbar, fiepende Motherboards - und die "Wegwerfplatinen" fangen bei 75€, für weniger Geld bekommt man bei anderen Plattformen ein verkapptes Highendboard: http://geizhals.at/deutschland/a430932.html , für ein "ordentliches" P55-Board legt man mindestens 100€ hin. Insgesamt nennt man so etwas eine Bastelplattform - da passt die Empfehlung von Microsoft perfekt ins Bild. Naja, aber immerhin 400+ fps in 640x480...

dein "verkapptes Highendboard" hat nichtmal passive Kühlung auf den SpaWas...ob das bei CPUs mit einer TDP von bis zu 140Watt mal gut geht :rolleyes: geschweige denn mehr als einen pcie x16 slot (selbst wenn der nur elektrisch als 4-8x ausgeführt ist)

[Coda]

Ich würde hier sogar fast vermuten, das ein paar dickere Kondensatoren zwischen NT und CPU VRM helfen könnten.
Dazwischen würde der Rechner nicht mehr angehen :tongue:

dein "verkapptes Highendboard" hat nichtmal passive Kühlung auf den SpaWas...ob das bei CPUs mit einer TDP von bis zu 140Watt mal gut geht :rolleyes: geschweige denn mehr als einen pcie x16 slot (selbst wenn der nur elektrisch als 4-8x ausgeführt ist)
Ich zähl da 10 Phasen. Kühlung dürfte damit ziemlich unnötig sein.

[StefanV]

Dazwischen würde der Rechner nicht mehr angehen :tongue:
Natürlich...
Dann halt so:
Vor den Spannungsreglern könnte eine größere Kapazität helfen, die Spannungsregler vom Netzteil zu entkoppeln und so diese Resonanzgeräusche verhindern.
Ich zähl da 10 Phasen. Kühlung dürfte damit ziemlich unnötig sein.
Wären dann wohl 8 (Cores) + 2 (NB) und ja, eine Kühlung ist unnötig, zumal ein Großteil der Energie eh ans PCB abgegeben wird.

[Lawmachine79]

dein "verkapptes Highendboard" hat nichtmal passive Kühlung auf den SpaWas...ob das bei CPUs mit einer TDP von bis zu 140Watt mal gut geht :rolleyes: geschweige denn mehr als einen pcie x16 slot (selbst wenn der nur elektrisch als 4-8x ausgeführt ist)
Es hat eine 10 Phasen-Stromversorgung - das ist High-End, keine Pseudoheatpipes für die Optik

[_DrillSarge]I[]

Es hat eine 10 Phasen-Stromversorgung - das ist High-End,
das sagt erstmal gar nix aus. genauso wie "all solid capacitors". WAS man genau verbaut hat zählt. wobei speziell das board, zu diesem preis, gut ist.
genauso wenig sind dicke heatpipe-kühler ein zeichen von guter qualität.

[Lawmachine79]

I[;7685836']das sagt erstmal gar nix aus. genauso wie "all solid capacitors". WAS man genau verbaut hat zählt. wobei speziell das board, zu diesem preis, gut ist.
genauso wenig sind dicke heatpipe-kühler ein zeichen von guter qualität.
Auf das "All Solid"-Gedöns habe ich mich nicht bezogen - das schmiert ja jeder Hersteller auf seine Kartons. Aber PCB und Stromversorgung findet man in dieser Form sonst nur in 130€+ Boards (Ok, gibt noch einen "Ausreisser" von DFI für 113€).

[Power]

selten so einen bashing thread gelesen - klar SP wieder mal voll am feuern hast du nix anderes zu tun ?


hab hier schon 4 i5-750 kombis am laufen mit OC und ohne OC seit 2 Monaten weder irgendwelches pfeifen noch irgenwelche Teile die abrauchen

und nun zum Threadtitel mir entsteht einfach der eindruck das MS hier deutlich was versäumt hat was umzuschreiben beim 2k8 R2

Nun den Schwarzen Peter auf Intel zu schieben obwohl dieses Problem ja schon lange bekannt ist wird mal wieder als Kreuzzug gegen Intel verwendet

P55 Mainboards die ja angeblich bei 0,9 VCore abgeraucht sein sollen - halte ich immer noch für einen Blödsinn waren wohl eher 1.6 VCore
nur weil jener dies behauptet ? sollte es zu 100% stimmen ?

könnte man im Gegenzug behaupten " ich betreibe mein i5 mit 2.4 VCore und der raucht nicht ab" wer würde dies wohl glauben ?

Hauptsache jeder Dau ohne jedes Grundwissen bastelt sich seinen eignen PC - nichts gegen Hobbyschrauber ich meine nur die Daus

und alle als panikmache" abgerauchten Boards links "entpupen sich als immer wieder die selben - wieviel sind den insgesammt abgeraucht ??


Fakt ist MS hat was bei 2k8 R2 versäummt das aber bisher nicht mal 100% reproduzierbar zu sein scheint

[Odal]

Ich zähl da 10 Phasen. Kühlung dürfte damit ziemlich unnötig sein.

ach nicht schon wieder dieses phasen märchen...als ob es nur einen typ mosfet gibt :rolleyes: und als ob "die phase" ein bauteil ist an der die VerlustLeistung abfällt.....

[Gast]

Ich finde es lustig, wie es hier mal wieder zugeht. :)

IMO ist dieser Fehler mehr als ärgerlich. Strom ist das was neben der Hardware so richtig ins Geld geht und da spreche ich nicht von irgendeiner Serverfarm. Der "Green-IT-Zug" hat mittlerweile volle Fahrt aufgenommen. AMD hatte mit den ersten Opterons nicht zuletzt auch deswegen einen Riesenerfolg und hat Intel Marktanteile abgenommen. Und nicht umsonst wirbt seitdem auch Intel auf seinen bunten Powerpointfolien mit der "Performance-per-Watt".
Ob dieser Fehler die Verbrauchszahlen signifikant beeinflussen kann ist wohl noch nicht abzuschätzen. Sicher ist jedenfalls, dass es sich die Firmen, die mittlerweile doch Recht stark auf Virtualisierung setzen, zweimal überlegen werden welchem CPU-Hersteller sie für die Serverinfrastruktur den Vorzug geben sollen.
Da passt das Verhalten von Intel, diesen Fehler klein zu Reden, sehr gut ins Bild. Der Fehler ist wohl schon einer Erwähnung Wert. ;)

Zu dem Phasen-Fiepen-Gerede: Dieser Fehler ist doch beim Hersteller des Boards bzw. des Netzteils zu suchen und nicht beim CPU-Hersteller. Heutige CPUs verursachen nun mal enorme Lastwechsel. Das muss ein ordentliches 80%+ Netzteil abkönnen. Ein ordentliches Board erst Recht. Ob jetzt der Lastwechsel von der CPU "korrekt" funktioniert ist doch dabei total nebensächlich.

[StefanV]

Zu dem Phasen-Fiepen-Gerede: Dieser Fehler ist doch beim Hersteller des Boards bzw. des Netzteils zu suchen und nicht beim CPU-Hersteller. Heutige CPUs verursachen nun mal enorme Lastwechsel. Das muss ein ordentliches 80%+ Netzteil abkönnen. Ein ordentliches Board erst Recht. Ob jetzt der Lastwechsel von der CPU "korrekt" funktioniert ist doch dabei total nebensächlich.
Naja, hier kann man sich streiten.

Der Punkt ist, das der CPU Hersteller für die Spezifikation der Spannungsregelung verantwortlich ist, der MoBo Hersteller hält sich dann (mehr oder weniger) dran und setzt das um.
Die Frage ist jetzt, ob eine höhere Kapazität auf dem Board dieses Fiepen vermindern kann.

Laut Compucase hilft es (auch hier), die Stromsparmodis zu deaktivieren.

[Gast]

Sagen wir es mal so (vereinfacht): Die Spec für eine CPU sieht eine Minimallast und ein Maximallast. vor. An diesem Min. und Max. müssen sich die Board- und Netzteilhersteller orientieren. Die weiteren Parameter (Dauer und Häufigkeit der Lastwechsel) bestimmen die Anwender und sind somit auch nicht vom CPU-Hersteller vorhersehbar bzw. nicht beeinflussbar. Das einzige was die Hersteller von Boards und Netzteilen machen können ist es typische Anwendungsfälle beim Desing ihrer Produkte zu berücksichtigen. Dem einen gelingt das besser, dem andern schlechter.

[StefanV]

@Gast
Du weißt aber, das Intel auch für die ATX12V Spec (mit) verantwortlich ist? ;)

[Avalox]

Die weiteren Parameter (Dauer und Häufigkeit der Lastwechsel) bestimmen die Anwender und sind somit auch nicht vom CPU-Hersteller vorhersehbar bzw. nicht beeinflussbar. Das einzige was die Hersteller von Boards und Netzteilen machen können ist es typische Anwendungsfälle beim Desing ihrer Produkte zu berücksichtigen. Dem einen gelingt das besser, dem andern schlechter.

Doch, doch. Der CPU Hersteller bestimmt ja gerade mit seinen diversen eingebauten Stromsparmechanismen genau diese Lastwechsel ganz eklatant.

Es ist ja nur eine sehr Consumer vereinfachte Sicht ein Netzteil nach der bereitgestellten Gesamtleistung anzubieten. Die Leistung sagt ja kaum was aus und funktioniert ja nur, weil doch ein paar Standards den Benutzer vor dem totalen Griff ins Klo absichern.

Es müssen in Mikrosekunden gigantische Ströme bereit gestellt werden.
Dass muss ein Netzteil erstmal können. Je schneller eine CPU seine Stromsparmechanismen schalten kann, bzw. je besser diese Stromsparmenachnismen wirken bzw. je größer das Delta der Stromaufnahme liegen kann, je höher sind die letztendlich die Ströme welche in kürzester Zeit dort fließen müssen. Das hängt nicht mal direkt mit einer maximalen Leistungsaufnahme einer CPU zusammen.

Und mal ehrlich wer achtet denn beim Netzteilkauf darauf, ob dieses Netzteil für die Verwendung mit einem Board oder einer speziellen CPU Version vom Hersteller freigegeben ist oder nicht. Aber genau dieses müsste man eigentlich tun.

[Ronny145]

Laut Compucase hilft es (auch hier), die Stromsparmodis zu deaktivieren.


Ja natürlich. Netzteile, die mit den Schwankungen nicht zurechtkommen, wird das sicher helfen. Kann aber auch nicht die Lösung sein. In dem CB Thread hatte der eine user mit dem Cougar ein deutlich lauteres fiepen. Hier sollte man sich die NTs genauer ansehen und Compucase nicht gleich versuchen mit merkwürdigen Begründungen die Schuld auf andere zu schieben. Und scheinbar schieben die Board Hersteller wiederum die Schuld auf die Netzteile. Jeder schiebt die Schuld auf den anderen. :biggrin:

Gerade gefunden, das sagt JZ von Gigabyte.


bei tiefen idle spannungsschwankungen treten hochfrequenzspitzen auf der 12V leitung auf und es gibt netzteile, die das gut abkönnen und einige zirpen ebend mal lauter oder leiser... das ist immer von der CPU (regelbereich+vid) und den bios einstellungen abhängig... das problem gibt es auch schon bei X58er, gerade bei neueren CPUen... ob gbt oder asus oder dfi... die waschen sich alle mit wasser... deswegen wird es bald ein neuen regler 12.0 geben...

http://www.hardwareluxx.de/community/showpost.php?p=13399297&postcount=1315

[Gast]

@Gast
Du weißt aber, das Intel auch für die ATX12V Spec (mit) verantwortlich ist? ;)

Wer hier daran mitwirkt ist doch nebensächlich. Es wird sich darauf geeinigt (auch wenn Intel und AMD dies maßgeblich bestimmen) und jeder muss sich daran halten. Wenn ich mich daran nicht halten kann oder will, muss ich es sein lassen oder ausschließlich Boards für ARM-CPUs bauen.

Eine CPU hat verschiedene Lastzustände. Mit diesen Lastzuständen _muss_ die Hardware die um die CPU herum gebaut wird zurecht kommen. Daran gibt es nichts zu deuteln.

Doch, doch. Der CPU Hersteller bestimmt ja gerade mit seinen diversen eingebauten Stromsparmechanismen genau diese Lastwechsel ganz eklatant.

Das habe ich auch nicht bestritten. Nur wird eben die Dauer und Häufigkeit dieser Lastwechsel direkt durch das Nutzungsverhalten bestimmt bzw. beeinflusst. Manch ein Hersteller sagt sich da halt der Durchschnittsbenutzer setzt keine Anwendungen (Prime o. ä.) ein, die eine CPU an ihre Grenzen bringen und spart eben etwas ein. Ein anderer sagt sich das trifft auf 10% der Nutzungsdauer eines Netzteils zu und legt sein Netzteil darauf aus.
Der Hersteller muss eben sein Board oder Netzteil für eine Fülle von (Dauer-)Lastzuständen konzipieren und das ist nicht einfach!

[Coda]

ach nicht schon wieder dieses phasen märchen...als ob es nur einen typ mosfet gibt :rolleyes: und als ob "die phase" ein bauteil ist an der die VerlustLeistung abfällt.....
Das ist kein Märchen. Und welches Bauteil einer Phase nun wieviel Verlustleistung verursacht ist völlig egal. Fakt nur ist, dass mehr Phasen zu geringerer Verlustleistung führen.

http://www.3dcenter.org/artikel/geheimnis-spannungswandler

Der genau verwendete MOSFET dürfte in dieser Schaltung übrigens nur sehr unwesentlich die Verlustleistung verändern. Genauer gesagt, kann man sehr wohl die Anzahl der Phasen zwischen zwei Boards vergleichen, weil sie sich eigentlich technisch gleich verhalten müssen.

[desert]

ich habe neulich irgendwo gelesen, war das in pcgh? Ist ja auch egal, das microsoft einen patch für amd prozessoren rausgebracht hat, wegen dem apic timer, da er verhindert kann das amd prozessoren in irgendeinen energiesparmodus wechseln können.

Wieso ist kein problem, bei intel aber schon?

[Gast]

Wieso ist kein problem, bei intel aber schon?
Weil Microsoft im einen Fall ohne groß Aufsehen zu machen den eigenen Frickelkern angepasst hat und im anderen Fall die Hardware mit viel Tamtam für fehlerhaft und damit nicht zu gebrauchen erklären wollte.

[Odal]

Das ist kein Märchen. Und welches Bauteil einer Phase nun wieviel Verlustleistung verursacht ist völlig egal. Fakt nur ist, dass mehr Phasen zu geringerer Verlustleistung führen.


schonmal was von prallel geschalteten Mosfets gehört um die Stromlast aufzuteilen? Dazu ist keine zwingende Auslegung als seperate Phase notwendig um die Wahrscheinlichkeit von Mosfetplatzern durch zu hohe Stromaufnahme zu minimieren.


Der genau verwendete MOSFET dürfte in dieser Schaltung übrigens nur sehr unwesentlich die Verlustleistung verändern. Genauer gesagt, kann man sehr wohl die Anzahl der Phasen zwischen zwei Boards vergleichen, weil sie sich eigentlich technisch gleich verhalten müssen.

Es geht doch gar nicht um die Verlustleistung die ein Mosfet verursacht sondern wieviel Verlustleistung an ihm anfallen darf/fällt bis er "platzt".

[StefanV]

ich habe neulich irgendwo gelesen, war das in pcgh? Ist ja auch egal, das microsoft einen patch für amd prozessoren rausgebracht hat, wegen dem apic timer, da er verhindert kann das amd prozessoren in irgendeinen energiesparmodus wechseln können.
Der C1E Patch?
Wieso ist kein problem, bei intel aber schon?
Weil das 'ne ganz andere Baustelle ist!

Hier gibts einen Absturz/Programmfehler, wenn die entsprechenden Energiesparmodis aktiv sind, bei AMD wurde er 'nur' nicht genutzt.

[desert]

Der C1E Patch?

Weil das 'ne ganz andere Baustelle ist!

Hier gibts einen Absturz/Programmfehler, wenn die entsprechenden Energiesparmodis aktiv sind, bei AMD wurde er 'nur' nicht genutzt.

Und? Das zeigt doch aber nur das apic einfach nicht zugebrauchen ist.

Meine Frage daher nochmal, wieso wird hier wieder intel die schuld zugeschustert und nicht microsoft. Die nutzen doch etwas was nicht richtig funktioniert und vorallem ist es schon seit langem bekannt.

[Coda]

schonmal was von prallel geschalteten Mosfets gehört um die Stromlast aufzuteilen? Dazu ist keine zwingende Auslegung als seperate Phase notwendig um die Wahrscheinlichkeit von Mosfetplatzern durch zu hohe Stromaufnahme zu minimieren.
Das Problem sind aber nicht die MOSFETs, sondern die Dioden. Könnte man den Strom auf "mehrere MOSFETs aufteilen" in einer Phase, sähen Spannungsregler anders aus.

Es geht doch gar nicht um die Verlustleistung die ein Mosfet verursacht sondern wieviel Verlustleistung an ihm anfallen darf/fällt bis er "platzt".
Natürlich geht es darum. Wenn du nur eine Phase hättest würdest du ~60W in der Spannungsregelung verbraten bei einer modernen CPU. Mit 8 Phasen, aber <10W - und das verteilt. Da brauchst du nichts mehr aktiv kühlen.

[StefanV]

Nun, es hilft wohl schon, aber Boards mit nur 3 Phasen (+1 für NB) sind idR nicht für 125W ausgelegt, gibt hier zwar Ausnahmen wie dieses MSI (http://geizhals.at/deutschland/a382864.html), die Regel ist aber, das man erst ab 4 Phasen 125W TDP CPU Support hat...

[Coda]

Thank you Captain Obvious. Das man mit drei Phasen aus den oben genannten Gründen keine 125W unterstützt sollte doch klar sein.

[Gast]

Bugreport: Nehalem plus Hyper-V ergibt Bluescreen
http://www.zdnet.de/sicherheits_analysen_bugreport_nehalem_plus_hyper_v_ergibt_bluescreen_story-39001544-41524516-1.htm

[Gast]

Microsoft hatte damals die Einführung eines neuen Timer-Bausteins gefordert, der vollkommen unabhängig von der CPU arbeitet. Damals ging es nicht um Virtualisierung, sondern um Multimedia-Anwendungen.

In dem Dokument heißt es: "Der Advanced Programmable Interrupt Controller (APIC) beinhaltet viele Eigenschaften der Echtzeituhr [des IBM AT aus dem Jahr 1984]. Er wurde entwickelt, um mehrere Prozessoren synchron zu halten. Er verfügt nur über eine niedrige Auflösung, und das Silizium dieser Uhr ist manchmal ziemlich buggy. Entscheidender ist jedoch, dass der Timer in einigen Implementierungen durch das Power-Management angehalten wird, was ihn als zuverlässige Zeitquelle unbrauchbar macht. Er wird daher nur selten verwendet."

Ein Softwareentwicklungsleiter mit ein wenig Erfahrung hätte daraus durchaus schließen können, dass man sich auf Komponenten besser nicht verlassen sollte, bei denen schon öfter "Errata" dokumentiert wurden und die durch neue Power-Management-Methoden, etwa Deep Sleep einzelner Cores oder Turbo-Modi, nicht vorsehbare Nebeneffekte zeigen.

Der von Microsoft und Intel gemeinsam entwickelte High Performance Event Timer (HPET) ist auf jedem modernen PC vorhanden. Da Hyper-V ohnehin nur auf Prozessoren mit Hardwarevirtualisierungsunterstützung läuft, kann man davon ausgehen, dass jeder Rechner, auf dem Hyper-V grundsätzlich lauffähig ist, auch über einen HPET-Baustein verfügt.

Ganz so einfach darf man es sich jedoch nicht machen. Die Verwendung des APIC-Timers, der jeweils lokal auf jedem Core vorhanden ist, hat durchaus Vorteile bei der Virtualisierung. Nutzt man ihn, so muss man sich jedoch über mögliche Konsequenzen im Klaren sein. Die Hypervisor-Hersteller halten Details darüber, wie sie welche Timer-Bausteine verwenden, unter Verschluss. Fakt ist jedoch, dass Konkurrent VMware keine Stabilitätsprobleme beim Einsatz von Nehalem-Prozessoren hat, sei es durch geschickte Umgehung des dokumentierten Bugs oder durch Verwendung anderer Timer-Mechanismen an kritischen Stellen.

MS => FAIL

[Gast]

MS => FAIL

Ist doch nix neues. Wie war das noch mit Windows 95 und AMD K6 CPUs >= 350 MHz?

http://support.microsoft.com/kb/192841

[Ric]

Oder Windows 9x bis 98SE mit Prozessoren schneller als 2,1GHZ

...läuft alles darauf hinaus, das CPUs Aufgaben schneller abarbeiten, als bei der Entwicklung vorhergesehen. - kommt vor

Ich fass den zu, 99,99% auf einem MS-basierten Rechner geschriebenen, Gast - Kommentar mal kurz zusammen:

Relevanz - Null
Tollfaktor - Einhundert

[(del)]

Ist doch nix neues. Wie war das noch mit Windows 95 und AMD K6 CPUs >= 350 MHz?Ja fällt mir jetzt auch auf. Quatschen alle Programmierer halbtot was man darf und was nicht, weil sich dies und jenes in zukünftigen Versionen noch ändern kann, prädigen die einzig wahren Kompatibilitätslehren und intern bauen sie selbst einen Mist nach den anderen.

Naja was solls. Da guckt ja auch keiner nach. Hauptsache die API tuts halt :freak: Wein prädigen und mit Wasser kochen. Ja ja, so kennt man sie.

[Gast]

Z

...läuft alles darauf hinaus, das CPUs Aufgaben schneller abarbeiten, als bei der Entwicklung vorhergesehen. - kommt vor



Bei anständiger Programmierung kommt das eben nicht vor.