Ein Thread unseres Forums beschäftigt sich mit einem Frameraten-Problem unter SLI. Grob gesagt geht es darum, daß SLI-Gespanne in üblichen Benchmarks bei den dort ermittelten Durchschnitts-Frameraten zwar ihre 50 bis 80 Prozent Mehrperformance erbringen, im realen Spielalltag es aber auftreten kann, daß die Framerate teilweise extrem schwankend ist: Im Durchschnitt werden dann zwar weiterhin (beispielhaft) 30 fps erzeugt, durch die Schwankungen der Framerate fühlen sich diese 30 fps aber eher wie 20 fps an. Im Forums-Thread konnte hierzu durchaus nachgewiesen werden, daß es Fälle gibt, wo eine 30-fps-Framerate dadurch erzeugt wird, daß immer ein langsam erzeugtes Bild (10 fps) einem schnell erzeugtem Bild (50 fps) folgt.

Im Durchschnitt ergibt das immer noch 30 fps, aber im realen Spiel wirkt das klar unruhig. Anscheinend existiert das Problem aber nur auf GeForce8-Karten im SLI-Modus, die GeForce7-Serie sowie auch die Radeon HD 2900 XT unter CrossFire konnten inzwischen ausgeschlossen werden. Und natürlich ist dieser Effekt nur im Bereich von ca. 30 fps wahrnehmbar – wird es weniger, ruckelt es sowieso, wird es mehr, ist es nicht mehr sichtbar, weil zu schnell. Generell ist es wahrscheinlich, daß es sich hierbei um ein reines Treiber-Problem handelt, welches also lösbar ist. Eine mögliche Erklärung, warum dies so passiert, liefert im übrigen dieses Posting: Danach synchronisieren sich die beiden GPUs bei SLI nicht perfekt bzw. es fehlt dem Treiber an einer Einstellung, welche die vielen bei mehreren Grafikchips gleichzeitig erzeugten Bilder besser koordinieren kann.

Bei Phoronix hat man sich sowohl die Performance der Radeon HD 2400 Pro als auch die der Radeon HD 2600 Pro unter Linux angesehen. Beide Karten performen mit dem neuen Linux-Treiber von ATI ziemlich ansprechend, der Vergleich zur GeForce 8500 GT und GeForce 8600 GT geht dabei in etwa so aus, wie auch die Relationen unter Windows aussehen. Allenfalls auffallend ist, daß die Radeon HD 2400 Pro regelmäßig klar hinter der Radeon X1300 Pro zurückliegt – was jetzt aber nicht an Linux hängt, sondern eigentlich nur ausdrückt, wie tief ATI die Radeon HD 2400 Pro im Markt ansiedelt (und dabei war ja auch die Radeon X1300 Pro ihrerseits nur eine LowCost-Lösung).

Wie Hard Tecs 4U in Berufung auf AMD-offizielle Dokumente berichten, besitzt der Speichercontroller der K10-basierenden Prozessoren bereits den Support für DDR3-Speicher. Bisher war zum Thema DDR3 auf AMD-Prozessoren bekannt, daß AMD dies mittels der nächstes Jahr anstehenden 45nm-Prozessoren ermöglichen wird. Dabei dürfte es wohl auch bleiben – man wird dazu halt nur nicht mehr die Prozessoren bzw. das integrierte Speicherinterface umdesignen müssen, sondern das kann der originale K10-Kern schon. Nichts desto trotz wird es bei den Prozessoren eine klare Trennlinie geben: K10-Prozessoren im Sockel AM2+ bieten nur Support für DDR2-Speicher, erst die K10-Prozessoren im Sockel AM3 bieten dann den Support sowohl für DDR2 als auch DDR3.

Der Heise Newsticker berichtet hierzu aber auch gleich von einigen Einschränkungen des K10-Speichercontrollers: So wird DDR3-Speicher derzeit offiziell nur bis DDR3/1333 ermöglicht. Natürlich dürften äquivalent zu den aktuellen AMD-Prozessoren auch höhere Speichertaktraten möglich sein (auch ohne das man deswegen den Prozessor selber übertakten muß), allerdings bedeutet dies auf der anderen Seite, daß Komplett-PCs wohl nicht mit mehr als DDR3/1333 ausgeliefert werden, da sich OEM-Hersteller üblicherweise strikt an die Hersteller-Spezifikationen halten. Gut möglich allerdings, daß AMD bei den 45nm-Prozessoren (wo DDR3 schließlich erstmals bei AMD zum Einsatz kommen soll) den Speichercontroller inzwischen schon wieder überarbeitet hat und dann auch offiziellen Support für DDR3/1600 bieten kann.

Gleichfalls gibt es einige Einschränkungen, sofern man die neue Möglichkeit des K10-Kerns, offiziell DDR2/1066 ansteuern zu können, nutzen will. So sind unter DDR2/1066 offiziell wieder nur zwei DualRank (DualSide) Speicher möglich (Erklärung zu Single- und DualRank), zudem kann der Speicher unter diesem Takt dann nur noch mit einer Command Rate von 2T angesteuert werden. Daneben wurde auch die bekannte Einschränkung der K8-Prozessoren beibehalten, daß unter DDR2/800 ebenfalls nur eine Command Rate von 2T möglich ist. Aber auch hier gilt wieder: Alle diese Einschränkungen sind rein offizieller Natur und geben damit eigentlich nur wieder, wie Komplett-Systeme (maximal) aussehen werden. In der Praxis kann und wird mehr möglich sein – was dann aber eben immer von der Klasse der verwendeten Komponenten und natürlich auch ein wenig vom Faktor Glück abhängt.

Einen weiteren Test zur Performance des Level2-Caches bei Intels Core 2 Duo Prozessor gibt es bei Nordic Hardware. Dazu wurden Core 2 Duo Prozessoren mit 2 und 4 MB Level2 Cache sowie ein Pentium E mit Core 2 Duo Kern und 1 MB Level2 Cache zum Test eingeladen und auf gleiche Werte bezüglich Taktfrequenz und FSB-Takt gebracht. Der technische Unterschied zwischen diesen Prozessoren lag dann also nur noch bei der Größe und der Anbindung des Level2-Caches. Bei der Performance zeigten sich eher nur geringe Unterschiede zwischen den verschiedenen Cache-Größen/Anbindungen, auch war keine besondere Tendenz auszumachen, ob der Abstand zwischen 1 und 2 MB größer oder kleiner ist als der Abstand zwischen 2 und 4 MB. Beachtenswert ist allenfalls, daß ausgerechnet die Spiele mit am stärksten auf den Cache-Unterschied reagierten: Hier ermittelten Nordic Hardware jeweils 9 Prozent Performancegewinn beim Sprung von 1 auf 2 MB und beim Sprung von 2 auf 4 MB Level2 Cache.

Shortcuts: Gemäß Hard Tecs 4U könnte es nun doch noch einen Intel-offiziellen X48 Mainboard-Chipsatz geben. Dieser würde als Unterschied zum jetzt in den Markt kommenden X38-Chipsatz den offiziellen Support für DDR3/1600-Speicher anbieten – was die kommenden X38-Mainboards zumindestens im Overclocking-Betrieb aber auch leisten können. Golem berichtet über den Umstand, daß Windows Update in einem speziellen Fall den Benutzer nicht rückfragt, ob dieser ein heruntergeladenes Update installieren will – und zwar bei Updates für Windows Update selber. Das Problem wird hier aber weniger bei der technischen Seite gesehen, sondern eher darin, daß wenn der Benutzer die Option "Nachfragen vor Installation" auswählt, man normalerweise annimmt, daß dies dann eben auch für wirklich alles gilt.

Wie nochmals Golem vermelden, hat Google die AGB seines OnlineOffice-Dienstes "Text & Tabellen" nach wie vor nicht geändert, womit die kürzliche Beteuerung, man wolle die sich in diesen AGB erteilte Nutzungslizenz auf von Benutzern eingestellte Dokumente nicht ausnutzen, eher unter das Stichwort "PR-Maßnahme" fällt (einmal abgesehen davon, daß diese Beteuerung rechtlich sowieso nicht bindend ist). Und letztlich berichtet der Heise Newsticker noch davon, daß sich Akademie.de endlich gegen die Abmahnung der GEZ wehrt und dazu negative Feststellungsklage erhoben hat. Die Meldung wirft auch Licht auf einen speziellen Punkt der GEZ-Abmahnung, wo seitens der GEZ schlicht eine andere Rechtsauffassung von Akademie.de abgemahnt wurde – womit generell ausgedrückt wird, daß in GEZ-Angelegenheiten wohl allein nur die Rechtsauffassung der GEZ bindend sein soll ;).