Microsoft rät von Nehalem ab

mariahellwig

Grand Admiral Special
Mitglied seit
28.08.2008
Beiträge
2.084
Renomée
27
Standort
Bielefeld
http://www.heise.de/ct/artikel/Prozessorgefluester-862083.html

Andreas Stiller berichtet, daß es da gewisse Spannungen zwischen Intel und Microsoft gegeben hat. Während Intel beschwichtigt(wie immer), scheint das für den Server 2008 R2 ein größeres Problem zu sein.

Kann das Problem jemand einschätzen? Stehe gerade vor dieser Entscheidung.
 
Erstaunlich wann Artikel von Einzelnen erst gelesen werden: "Praechtiegs Prozessorgeflüster zu Krieg und Frieden" (22.11.2009)

und über "Hypervisor strauchelt und mit Clock Watchdog Timeout" ... das ist ja gar nicht gut für den Nehalem mit seinem APIC-Timer und seinen Interrupts ...

und wenn die Hypervisor vom Windows Server 2008 R2 damit strauchelt und virtualisierte Umgebungen einfrieren ... hat AMD womöglich ein unverhofftes "Camp for free" bei ServerVirtualsierungen bekommen - Jedenfalls bei Windows Server 2008 R2-Server. Da hat der Betreiber die Wahl zum Bugfixing zwischen Turbo Boost, oder Virtualisierung, ob das Intel so beabsichtigt hatte? Ob da wirklich die Zusammenarbeit zwischen Intel und Microsoft gut abgestimmt war? ...
MFG Bobo(04.12.2009)
 
Zuletzt bearbeitet:
Ich denke dieser Absatz klingt besser, und bringt es auf den Punkt. Alternativ kann man dies CPU-Features abstellen, einen AMD kaufen oder besser "Windows als Server BS in die Tonne kloppen"

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).
 
Die Allianz MS-Chipzilla bröckelt! Oder wir werden Zeugen eines perfiden Theaterstückes, um von drohenden Kartell-Observationen abzulenken. Wie A. Stiller allerdings an eine so brisante Rohfassung kommen konnte, ist mir rätselhaft, vielleicht sollte man es wieder einführen, Verräter instantan ihrer gerechten Strafe zukommen zu lassen.

Jedenfalls scheinen Betriebssysteme wie NetBSD und diverse LinSux-Derivate keine Probleme mit deren HyperVisor/Dom0 zu haben, wenn sie auf einem XEON mit Bloomfield- Gainstown- oder Lynnfield-Kern werkeln.
Und wieder einmal lehne ich mich entspannt zurück und erfreue mich unserer 'Microsoft-freien Serverzone'.
 
@Drohne
Abwarten. Würde mich nicht wundern wenn da noch mehr auftaucht. Ich habe noch Oracles Häme in den Ohren als bei Microsoft's SQL-Server einige Sicherheitslücken bekannt wurden. Larry Ellison tönte wie immer herum und verpasste der Oracle-DB den Begriff unbreakable. Bis kurze Zeit später bekannt wurde, daß die Produkte von Larry Ellison alles andere als unbreakable waren.

War klar das es Microsofts Schuld ist wenn Intel's Timerfunktionen nicht richtig funktionieren. Warum nutzen die so etwas bei der Entwicklung auch...

Diese Heiligsprechung Intels nervt nur noch.
 
@mariahellwig:
Wir Intel heilig gesprochen? Mir erscheint es nicht so. MS hat riskanterweise in einer Release eines Betriebssystemes Funktionen eingesetzt, die von Intel als probelamtisch deklariert wurden. Da sage ich nur: selber schuld.
 
Moment mal. Aus dem Artikel geht hervor, daß Intel dies erst im September getan hat. Also zu einem Zeitpunkt als Windows 2008 schon längst produziert wurde. Man hat den Fehler nachgeschoben. Ich sehe die Schuld hier bei Intel. Aus Entwicklersicht kann man da Microsoft keinen Vorwurf machen-
 
Wollte ich auch gerade schreiben:

(...)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(...)
Die Situation (lt. Artikel):
• Microsoft hat diese Funktion bereits bei älteren Prozessoren als unzuverlässig eingestuft!
• Aus dem Artikel geht nicht hervor, ob sich Microsoft bezüglich der Fähigkeiten bei Intel informiert hat.
• Microsoft implementiert diese Funktion, obgleich sie bei älteren Prozessoren genau diese als unzuverlässig eingestuft haben.

Betrachten wir die Angelegenheit doch mal nüchtern und sachlich: Wer hat hier einen Fehler gemacht?


PS: Perfides Intel-Bashing ist unattraktiv, anstössig und nervtötend.
 
Stimmt, habe nur halb hingelesen ... MS als Serverproduzent ist eh bei mir 'relativ weit weg'. Aber so, wie sich die Situation gestellt, hat Intel einen ordentlichen Bock geschossen. Die Frage ist, wenn erst im Septemer ein entsprechendes Erratum eingeflochten wurde, ob nicht tatsächlich Intel diesen Fehler erst im Septmeber als 'problematisch' eingestuft hat.

Ich werde mich mal auf den Mailinglisten der BSD Entwickler schlau machen, was dieser Bug nun wirklich für einen Hypervisor, der auf den APIC Timer setzt, bei Bloomfield und Gainstown bedeutet ...
 
@ShiningDragon

Microsoft hätte es wissen können, aber nicht wissen müssen.

Intel hingegen hätte das Problem eher untersuchen müssen, da es bereits in der Vergangenheit Probleme damit gab. Wenn dieser Bug in der Liste fehlt, obwohl Probleme in der Vergangenheit bekannt waren, kann als Entwickler davon ausgehen, daß dieses Problem behoben wurde. Ich finde du machst es dir etwas einfach mir dumpfes Intel-Bashing vorzuwerfen.
 
Ich finde du machst es dir etwas einfach mir dumpfes Intel-Bashing vorzuwerfen.
Nein, einfach mache ich es mir nicht. Immerhin habe ich mir die Mühe gemacht, andere Beiträge von Dir vorab durchzulesen.

Aber gut, laß uns darauf nicht verbeissen.

Microsoft kann nicht einfach auf gut Glück Funktionen implementieren, die sie selber bei Vorgängerprozessoren als unzuverlässig eingestuft haben. Das hat m.E. nicht viel mit Professionalität zu tun.

Ich mag Microsoft, ja. Auch Intel mag ich leiden, ja. Aber ich werte für mich nur die mir bekannten Informationen aus und anhand dieser bin ich der Meinung, das Microsoft einen Fehler gemacht hat.

Letztlich bin ich froh, das mich die Problematik nicht betrifft. ;D
 
Andere Frage: Darf man als Software-Entwickler nicht auch irgendwann mal erwarten dass HW-Bugs ausgemerzt bzw. funktionen der Prozzis verbessert werden, statt immer nur an der Performance-schraube zu drehen?
d.h. ist die unzuverlässigkeit einer Funktion in einer Prozessorgeneration unmittelba ein indiz dafür dass sich daran auch bei einer neuen Generation nichts änder,t die ja angeblich "der größte Sprung bei Intel seit XX jahren" gewesen sein soll?
 
Darf man als Software-Entwickler nicht auch irgendwann mal erwarten dass HW-Bugs ausgemerzt bzw. funktionen der Prozzis verbessert werden, statt immer nur an der Performance-schraube zu drehen?
Gegenfrage: Würdest Du als Programmierer "auf's Blaue hinaus" programmieren? Wenn ich ein Betriebssystem generiere, dann muß ich mich doch mit den Plattformen auseinandersetzen und kann nicht einfach Funktionen integrieren, die nicht funktionieren.
Notfalls muß ich als Entwickler halt bestimmte Hardwareprodukte ausgrenzen, oder drosseln (lief sowas Ähnliches damals nicht auch beim K10 @ L3 ab?).

Niemals nicht darf man eine Software, die so nahe an der Hardware operiert und diese zugänglich macht, auf Vermutungen oder Spekulationen hin entwickeln. Das ist und bleibt unprofessionell.

Stelle Dir vor, Creative würde nun für seine Soundkarten Treiber herausbringen, die einen "PowerModus" oder "Energiesparmodus" ansprechen, der gar nicht oder nur teilweise funktioniert...
 
Die Aussage "MS rät von Nehalem ab" lässt mir noch immer keine Ruhe!
Das ist schon eine gewaltige Aussage, seitens MS, wenn die so getroffen wurde, das gabs so in der Vergangenheit noch nicht, oder?
Die beiden müssen sich dafür doch heftig in die Wolle gekriegt haben, oder?*lol*
Während sich AMD und Intel jetzt ganz lieb haben, gab es zwischen Intel und Microsoft wohl mal wieder richtig Zoff hinter den Kulissen.
 
Zuletzt bearbeitet:
Die Aussage "MS rät von Nehalem ab" lässt mir noch immer keine Ruhe!
Gerüchte... da wird munter spekuliert. Nirgendwo gab es einen Beweis für eine solche angeblich getätigte Aussage.

Programmierer werden sich sicherlich geärgert haben und untereinander vielleicht gemotzt (hey, wenn wir arbeiten und etwas läuft nicht, dann lästern wir auch).

Aber solange ich nirgends eine offiziell dokumentierte und von Microsoft bestätigte Aussage zu der obigen Äusserung lese, bleibt das ein Gerücht, eine Mutmaßung, eine Fantasie oder Theorie.
 
Ich will die Entwickler bei Microsoft nicht übermäßig in Schutz nehmen. Man hätte da bei Intel auf Grund der schlechten Erfahrungen nachfragen können. Man hätte das Problem erahnen können.

Aber, die eigentliche Schuld trifft hier Intel. Es ist ein Intel-Produkt welches hier patzt. Intel hat dann verdammt nochmal die Pflicht darauf hinzuweisen. Das Problem war Intel nicht unbekannt. Nur weil es bisher angeblich bei keinem Produkt zu Problemen gekommen ist, hält man Informationen zurück. Das ist doch die übliche Salamitaktik.
 
Das ist doch die übliche Salamitaktik.
...die wir in gleichem Maße (wenn nicht schlimmer) von AMD kennen.
...die wir in gleichem Maße (wenn nicht schlimmer) von NVIDIA kennen.

Ich kenne nicht viele Hersteller, die aktiv mit Errata werben gehen. Natürlich ist es shice wenn ein Produkt "Defizite" (um es mal freundlich auszudrücken) aufweist. Da wurden Fehler auf mehreren Seiten gemacht.

Dennoch kann ich Deiner Meinung nicht zustimmen, das Intel auf Microsoft hätte zugehen müssen. Als Entwickler sollte man zu den Hardwareherstellern gehen. Ich frage mich sowieso, warum Microsoft diese Funktion implementiert, wenn es vorher noch nie funktioniert haben soll?

Wie wird nun eigentlich in diesem Bereich weiter verfahren? Werden die Prozessoren kastriert ausgeliefert? Wird das Errata beseitigt? Programmiert Microsoft einen workaround? Deaktiviert Microsoft dieses Feature gänzlich?
 
Wozu gibt es eignetlich spezifikationen von Features?
Entweder ich behaupte "Mein Produkt xyz kann das, erfüllt also spezifikation blah blah blah", dann bin ich aber in der Pflicht das auch so abzuliefern,
oder ich lasse es sein, dann kann ich mir aber auch nicht die unterstützung auf die fahnen schreiben... ?
Die frage ist also, muss ich als entwickler es nötig haben ständig in software workarounds für "schräge" HW zu implementieren oder eine dokumentierte Funktion nicht nutzen nur weil die Hersteller es nicht gebacken kriegen!?
Und da regt sich noch einer auf dass die SW ständig "hinterherhinkt" wenn man immer mit Funktionen arbeiten muss die 15 Jahre alt sind und seit 20 Generationen stabil nur um halbwegs sicher zu sein dass alles zufriedenstellend funktioniert!?

Wie auch immer... IMHO ligt hier ein gewaltiger Fehler im gesamten System... undzwar völlig unabhängig vom konkreten Fall hier.

Können opterons das eigentlich besser was Microsoft hier bemängelt?

grüßchen
ich
 
... Wie wird nun eigentlich in diesem Bereich weiter verfahren? Werden die Prozessoren kastriert ausgeliefert? Wird das Errata beseitigt? Programmiert Microsoft einen workaround? Deaktiviert Microsoft dieses Feature gänzlich?
Das hat doch der Artikel "Prozessorgeflüster" klar und deutlich beschrieben.

Vorerst hat der Windows 2008 SR2-Nutzer sich zu entscheiden zwischen einem Low-Power-Betrieb mit Turbo-Modus ODER einem Virtualisiertem System, die die Hardwarebeschleunigung dafür nutzt.

Der Bug müsst demnach auch Windows 7 Business und Ultimate betreffen. Das ist ja das gleiche Grundgerüst dahinter.

MFG Bobo(2009)
 
Die Timer sind echt eine hässliche Sache auf x86.

Ein zuverlässiger, schneller und genauer Timer hätte schon durchaus Vorteile. Der APIC-Timer geht schon in die richtige Richtung, wenn er noch alle Eigenschaften erfüllen würde, wäre es recht schön.

Der APIC-Timer hat die Vorteile, dass er eine hohe Taktfrequenz besitzt (jedoch vom FSB abhängig, d. h. variabel) und von der Zugriffszeit sehr schnell (auf der CPU) ist und sich Interrupts mit diesem Timer generieren lassen.

Probleme gibt es halt, da der Timer auf der CPU sitzt und sich anscheinend durch Frequenzänderungen beeinflussen lässt und damit nicht genau ist. Für relative Zeitmessungen ist das weniger ein Problem (Ereignis A vor Ereignis B, wenn alle APIC-Timer auf den CPU-Cores synchron laufen) aber für absolute Zeitmessungen ist das ein größeres Problem.

Die Implementierung des APIC-Timers unterscheidet sich außerdem noch auf den unterschiedlichen CPU-Architekturen.

Auch AMD hatte Probleme mit asynchronen APIC-Timern auf den Multi Core CPUs. Erst nach einem Patch konnte dieses Problem behoben werden. Probleme gabs wenn Anwendungen von einem Core auf einen anderen "gewandert" sind.

Letztendlich ist das Problem, dass der APIC Timer wohl nicht genau spezifiziert ist und es bei der Implementierung zu viele Freiheiten gibt.

Es wäre schon längst Zeit eine Überarbeitung der Timer-Architekturen durchzuführen und für die Zukunft nur noch einen Timer anzubieten. Um die Komptibiltät zu wahren, müsste man die Schnittstellen für die "alte Timer-Hardware" emulieren.

Diese Ziele haben bei den Hardware-Herstellern wohl geringere Prioritäten, was zählt ist der Gewinn und mit sowas macht man wohl kein Geld oder nur bei Nischenanwendungen wie Echtzeitsystemen basierend auf x86.
 
Zuletzt bearbeitet:
@ CapJo

Hab mich schon immer gewundert warum mein MB ein HPET hat.

Hat das auch mit dem APIC-Timer zu tun?
Scheinbar ist der noch ganricht nötig zur Zeit (HPET), evt. gäbe es hier ja potential. *noahnung*

MfG
 
Zuletzt bearbeitet:
Der HPET ist ein externer Timer auf dem Mainboard und hat einen eigenen Taktgeber (Quartz). Leider ist der Takt nicht genau spezifiziert.

Das Problem des HPET ist, dass er nicht überall vorhanden ist und dass er sich zum einen abschalten lässt und zum anderen leider auch nicht wirklich einheitlich ist. Ich hab schon einige Mainboards angetroffen, bei denen der HPET im BIOS per default deaktiviert war. Es gibt ihn auch in verschiedenen ausprägungen was die Anzahl der Bits für den Timer angeht (32 Bit / 64 Bit)..

Zudem ist der Zugriff auf den HPET (Latenz) länger als beim APIC-Timer. Er läuft jedoch unabhängig vom "Systemtakt".

Auf vielen (meisten?) Systemen wird die alte Timer-Hardware verwendet, die nur sinnvoll im periodischen Modus verwendet werden kann, da der Overhead einfach zu groß ist um Individuelle Timer-Interrupts zu erzeugen.

So etwas war im Gespräch um die Akku-Laufzeit von Notebooks zu erhöhen. Im "Normalfall" werden pro Sekunde 100 Timer-Interrupts erzeugt (nötig für das Scheduling, OS, Task-Switches usw.). Wenn der PC "nichts zu tun" hat würde es z. B. reichen nur noch 50 bzw. 10 Interrupts pro sekunde zu erzeugen oder noch besser jeden Interrupt angepasst und variabel zu erzeugen. Damit könnte die CPU über längere Zeiträume in einem stromsparenden Modus versetzt werden. Da sowas auf der alten Timer Hardware nicht möglich ist, bleibt diese Möglichkeit Energie zu sparen versperrt.

Hier noch was zu "Variable Tick Timer" unter Windows CE --- http://blogs.msdn.com/ce_base/archive/2006/09/27/understanding-the-variable-tick-timer.aspx

Man müsste das ähnlich wie bei Direct X machen und bestimmte Hardware-Eigentschaften als Vorgabe machen, die die Hersteller erfüllen müssen um "Windows 7" tauglich zu sein. Genau so wie es bei Direct X, der Fall ist.

Dann könnte man auf eine einheitliche Hardware-Basis aufbauen ... aber leider läuft es ja anders.
 
Zuletzt bearbeitet:
Das kommt dabei heraus wenn die Aktionkurse wichtiger sind als "was gscheits" zu machen, auf gut schwäbisch ausgedrückt.
Das Problem an der ganzen Plattofrm, das sich hier beim Timer-Beispiel sehr schön zeigt ist, dass die ganze Geschichte zu einer Zeit definiert wurde als Stromsparen noch kaum wichtig war (sogar Pentiums waren noch leicht passiv kühlbar), Notebooks ein sauteures Acessoire für Freaks und/oder Businessmen...
Langsam hemmt das Legacy-Zeugs die Entwicklung... vor allem da man anscheinend nur noch mit großen Benchmarkbalken oder Spottpreisen was verkaufen kann, da hat es keien sonderliche Priorität den Entwicklern die Arbeit zu erleichtern... :]

Schau mer mal wie das zukünftig läuft.. aber ich finds immer wieder Toll wenn sich die SW-Branche vorwerfen lassen muss sie wäre ein Bremsklotz, weil sie die HW ja so rasant weiterentwickle etc... ;D

Bin mal gespannt ob polling (und damit ständiges, größtenteils grundloses Aufwecken von millionne Transistoren aus dem sleepstate) in 20 Jahren immernoch der einzig wirklich zuverlässige Weg ist...
Schon lustig, man liest üebrall von "event driven programming"... aber das HW-Äquivalent eines Events, nämlich ein Interrupt ist nur mit hängen und würgen für was scheinbar "einfaches" wie eine Zeitsteuerung zu verwenden.... *lol*
 
Ich schließe mich Ge0rgy an: Was für Auswirkungen hat die ganze Geschichte für Opterons zu bedeuten?
Wurde da auch für Opterons optimiert? Wenn nicht, dann wäre ein neuer kontroverser Werbespruch seitens MS angesagt:

Optimised for Intel Xeon and therefore working better on AMD Opteron
*rofl*
 
Zurück
Oben Unten