News-Archiv Februar 2000
News-Index
- Benchmark-Charts aktualisiert
- GeForce mit 64 MB RAM
- Intel & AMD Price-cut
- Registry Tweaker
- Quake 3 Patches 1.16h bis 1.16n
- 3DCenter sucht Mitarbeiter!
- Savage 2000 mit/ohne T&L
- 32 Bit, 32 Bit !
- UT Benchmarking (2)
- Willamette im Oktober
- KX133-Reviews
- neue Downloads
- UT Benchmarking (1)
- Performancebremse i820
- zwei Bitboys-Interviews
Benchmark-Charts aktualisiert
28. Februar 2000 / von Leonidas
Es wurde wieder Zeit, die Benchmark-Charts zu aktualisieren - ergo haben wir genau dies getan und die inzwischen eingeflogenen 65 neuen Resultate (Vielen Dank an alle Mitwirkenden!) eingearbeitet. Besonders angetan hat Euch alles was mit Quake 2 und Quake 3 zusammenhängt, die entsprechenden Charts wurden einigermaßen durchgeschüttelt. Auch Unreal Tournament konnte schon einige Ergebnisse abfangen.
Was mir im besonderen auffiel: Zum einen bringt das Overclocken von GeForce-Grafikkarten eine ganze Menge - man kann damit durchaus eine kleinere CPU wettmachen. Die GeForce setzt hier den höheren Takt auch ziemlich gut in Mehrleistung um. Zum anderen: Bei einem Athlon sollte man ganz genau auf die richtige Grafikkarte achten falls man Höchstleistungen anstrebt. Mit einer 3Dfx-Grafikkarte läuft der Athlon jedenfalls wesentlich besser als mit anderen Grafikkarten - selbst die GeForce ist unter einem Athlon kein Abräumer. Für Athlon-Besitzer werden die kommenden Voodoo4/5-Karten sicher hochinteressant werden ...
GeForce mit 64 MB RAM
22. Februar 2000 / von Leonidas
DELL wird in einer der nächsten DELL-PC-Serien (wer hat was von sofort gesagt? - es ist eine Ankündigung!) eine GeForce-Grafikkarte mit 64 MB DDR-RAM verbauen. Passend dazu hat Sharky Extreme einen Packen Benchmarks anzubieten. Die Benchmarks kommen dabei getreu der alten Regel trau nie einer Statistik die Du nicht selbst gefälscht hast direkt von DELL, die Jungs von Sharky haben die Karte selber nie zu Gesicht bekommen.
Grundsätzlich gesehen bringen diese zusätzlichen 32 MB nur in Quake 3 etwas. Andere aktuelle Spiele werden davon kaum bis überhaupt nicht profitieren, die Unterschiede in 3DMark2000 sind wie der Tester selber - von theroretischer Natur. Zurück zu Quake 3 - dort suggeriert die DELL-GeForce eine 3,56 mal höhere Leistung unter 1024*768 @ 32 Bit im Quaver-Demo (wurde von Reverend The Pulpid zum Vergleichszweck 32- und 64-MB-Grafikkarten aufgenommen, Download). Allerdings wurde von DELL mit DDR-RAM gegen konventionelles SDR-RAM getestet - nicht sehr professionell.
Unabhängig davon möchte ich auf den entscheidenen Punkt hinweisen: Dieser Effekt tritt ausschließlich auf, wenn man unter 32 Bit Texturen-Tiefe (texture quality) die höchste Texturen-Einstellung (texture details) wählt. Was natürlich DELL für den Test auch getan hat, obwohl keine Hardwarereview-Site bisher mit der höchsten Texturen-Einstellung testet (das "HighQuality"-Setting nutzt nur die zweithöchste) und auch wir diese für unsere Benchmark-Regeln nicht empfehlen.
Der Grund sind die einfach enormen Texturen-Anforderungen vieler Quake3-Maps. In der höchsten Textureneinstellung bei 32 Bit Texturen-Tiefe verbrauchen z.B. Q3DM9 oder Q3Tourney3 lockere 30 MB Texturen, was zuzüglich ca. 10 MB Speicherbedarf für das Bild selber nicht mehr in den Speicher einer 32-MB-Grafikkarte passen würde. Logischerweise geht eine 32-MB-Grafikkarte ohne AGP-Texturing (unter OpenGL unterstützen das nur die Savage4 und die Savage2000 von S3) - konfrontiert mit einer Speichermenge von 40 MB (und mehr) am Krückstock. Deswegen auch der deutliche Unterschied zur 64-MB-Grafikkarte von DELL. Das ist wie wenn man mit einer Voodoo1 ein Spiel startet, welches eine Mindestanforderung einer Grafikkarte mit 4 MB Texturen-RAM hat (die Voodoo1 hatte 2 MB Texturen-RAM) - die eigentliche Leistung der Grafikkarte oder des Gesamtsystems wird irrelevant, da die Karte immer nur am Texturen-Nachladen ist.
Stellt man nun eine niedrigere Textureneinstellung ein oder aber setzt die Texturen-Tiefe auf 16 Bit wird dieser von DELL gemessene Unterschied im Prinzip verschwinden. Dann werden wieder "nur" ca. 8 MB bzw. 17 MB Texturen benutzt (wieder zuzüglich der 10 MB Speicherbedarf für das Bild selber), welches eine 32-MB-Grafikkarte ohne Probleme bewältigen kann. Die 64-MB-Grafikkarte kann und wird hier nicht schneller sein, es ist schließlich nur mehr Speicher. Schon beim gängigen "HighQuality"-Setting wird der Unterschied wieder in den Bereich weniger Prozente fallen. Insofern ist die DELL-GeForce mit ihren 64 MB RAM nicht schneller sondern sind einfach nur die Benchmark-Bedingungen clever gewählt ...
Ich glaube, hier ist es sinnvoller die eigenen Quake3-Einstellungen in einem der vorgenannten Punkte herunterzusetzen anstatt sich jetzt unbedingt eine 64-MB-GeForce an Land zu ziehen. Der visuelle Unterschied zwischen 16- und 32-Bit-Texturen (in der höchsten Texturen-Einstellung) ist doch vernachlässigbar gering. Im Prinzip besteht keine Notwendigkeit eine 64-MB-GeForce zu nehmen, Vorteile bei anderen Spielen als Quake 3 sind momentan nicht vorhanden und eine größere Zukunftsfähigkeit durch die zusätzlichen 32 MB sind auf dem ständig etwas neues erfindenden Grafikkartenmarkt eine blanke Illusion.
Spekulation: Verschiedentlich war davon zu hören, daß die DELL-Karte in echten 0.18 micron gefertigt werden würde (die bisherigen GeForce´s sind in 0.22 micron) - das würde eine wesentlich bessere Übertaktfähigkeit bedeuten. Weniger spekulativ ist, daß DELL wegen des Strombedarfs durch die zusätzlichen 32 MB erst noch auf die passenden Mainboards warten muß (die Spannungsregler müssen´s verkraften können). Hier würde auch der Haken zu suchen sein bei frei verkäuflichen 64-MB-GeForce´s - viele momentane Boards werden wohl bei einem AGP-Strombedarf von geschätzten über 10 Ampere einfach nur kapitulieren. Diese möglichen Inkompatiblitäten wird die Zukunft zeigen.
Kleine Geschichte am Rande: DELL hätte noch viel stärker bei Benutzung unseres Annihilator-Demo "auftrumpfen können". Dort erreicht bei den von DELL benutzen Einstellungen jede 32-MB-GeForce unabhängig der CPU maximal nur 5 Bilder pro Sekunde. Mit der 64-MB-Grafikkarte könnten das bei bei einem 800 MHz Athlon so ca. 30 fps sein - also locker das sechsfache. Das Annihilator-Demo ist in diesem Punkt - obwohl nicht einmal so beabsichtigt - sogar besser geeignet als das Quaver-Demo, weil die verwendete Texturenmenge viel konstanter hoch ist.
Nachtrag vom 5. März ...
Laut dem Support von nVidia können auch TNT/TNT2/GeForce-Karten das AGP-Texturing. Dank an Thomas Eßer für die
Information. Ändert erst einmal nichts an obigen Aussagen zur 64-MB-GeForce.
Nachtrag vom 28. März ...
64-MB- vs. 32-MB-GeForce ... der Titel sagt alles.
Intel & AMD Price-cut
21. Februar 2000 / von Leonidas
Ursprünglich wollte Intel schon am 25. die Preiskeule herausholen, nun aber wird man aber genau wie AMD am 28. Februar den Käuferscharen wieder neue (Preis-)Anreize geben, unbedingt auf die eigenen Produkte zu setzen:
| Type |
neuer Preis |
Preissenkung |
| Pentium III 550 | $ 193 | 20 % |
| Athlon 600 | $ 195 | 33 % |
| Athlon 650 | $ 225 | 42 % |
| Pentium III 600 | $ 241 | 23 % |
| Athlon 700 | $ 265 | 49 % |
| Pentium III 650 | $ 316 | 25 % |
| Pentium III 667 | $ 337 | 25 % |
| Athlon 750 | $ 360 | 48 % |
| Pentium III 700 | $ 417 | 26 % |
| Pentium III 733 | $ 455 | 23 % |
| Pentium III 750 | $ 530 | 29 % |
| Athlon 800 | $ 535 | 37 % |
| Pentium III 800 | $ 647 | 24 % |
| Athlon 850 | $ 750 | neu |
| Pentium III 833 | $ 765 | neu |
| Pentium III 866 | $ 776 | neu |
OEM-Preise bei 1000-Stück-Abnahme, aktueller Dollar-Kurs: 1 $ = 1,98 DM
Was fällt auf? AMD sägt nach der Januar-Preissenkung nun auch noch den 550er Athlon ab, während Intel den 500er Pentium III auslaufen läßt. Achtung! Wer den sehr gut übertaktbaren Pentium III E (Coppermine) mit 550 MHz ordern will, sollte sich nicht länger als bis April Zeit geben. Dann wird auch dieser Typ aus der Intel-Linie herausfallen. Bis zu diesem Zeitpunkt sollte dann auch klar sein, was Intel mit den neuen Celerons mit Coppermine-Kern vor hat und ob diese eine Alternative darstellen können.
Zum anderen ist es schon erstaunlich zu sehen mit welcher Härte AMD an der Preisspirale dreht. Mit im Schnitt um die 40 Prozent Preissenkung werden alle Intel-Preise geradezu deklassiert. AMD rückt eindeutig die Typen bis 750 MHz in den bezahlbaren Bereich, dieser reicht bei Intel nur bis zum 667er. Weiterer AMD-Vorteil: Im Gegensatz zu Intel schreibt man die 800-MHz-CPUs nicht nur in die Preisliste, sondern kann sie dann auch liefern.
Registry Tweaker
20. Februar 2000 / von Leonidas
Unser Download-Bereich hat einen neue Bereicherung erfahren durch Satanic Surfer´s Registry Tweaker. Zugegebenermaßen geistert das Programm schon seit einigen Tagen durchs Netz, aber die bei uns liegende Version 0.99c sollte noch niemand haben, diese ist mir von Satanic Surfer persönlich gesandt wurden (Gruß und Dank an dieser Stelle).
Worum geht es überhaupt? Der Registry Tweaker ist ein Tweak-Programm für Grafikkarten mit nVidia´s TNT/TNT2/GeForce-Chipsätzen. Alle vorhandenen Möglichkeiten zeigt dieser Screenshot (46 kB).
Die wichtigsten Einstellungen sind die Möglichkeiten, den AGP-Modus selber zu bestimmen und das SideBandAdressing einzuschalten. Mittels "Hardware-Optionen aktivieren" kann man im übrigen die Overclocking-Menüs in den Referenztreibern freischalten (mittels der weiter untenstehenden Spezial-Option auch für die Treiber ab Version 3.76). Der Funktionsumfang entspricht somit weitesgehend dem Programm "AGP Wizard" von Creative - mit dem entscheidenen Unterschied, daß es eben nicht auf Grafikkarten mit Creative-BIOS beschränkt ist ...
Bedingung für die Lauffähigkeit sind entweder installierte Referenztreiber von nVidia oder aber Treiber vom Kartenhersteller, die direkt auf den Referenztreibern basieren (sollte in 99 % der Fälle gegeben sein). Im Fall des Falles einer Einstellung welche zum Absturz des Rechners beim Hochfahren führt: Im abgesicherten Modus starten - die Tweaks werden damit automatisch nicht geladen - und dann hat man die Gelegenheit die eigenen Einstellungen wieder rückgängig zu machen.
Quake 3 Patches 1.16h bis 1.16n
19. Februar 2000 / von Leonidas
Der BETA-Patch 1.16h ist draussen und hier ist eine Liste mit Download-Möglichkeiten für die Win32-Version (2,9 MB). Dieser Patch benötigt keinen der vorherigen Patches.
Als wichtigste User-seitige Änderungen wurde die Auto-Download-Möglichkeit (bekannt aus Quake 2) eingebaut. Diese steht allerdings automatisch auf "ON", wer die nicht mag sollte sie also sofort ausschalten. Die Einstellung findet sich unter Setup/Game Options. Die kompletten Änderungen stehen im ReadMe (es ist gleich das vom Patch 1.16n).
Dringend zu obigen 1.16h-Patch wird das Security-Patch 1.16i empfohlen (den Patch 1.16h vorher einspielen!), da es ein kleines Sicherheitsproblem der 1.16h-Version bezüglich der Sichtbarkeit des eigenen CD-Keys in LANs gibt. Hier eine Liste mit Download-Möglichkeiten (0,4 MB).
Schneller oder langsamer wird Quake III Arena durch das Update nicht (bei mir 0,4 % schneller). Was man als Nutzer der Speed-Optimierungen für Win32 beachten sollte: Die .dlls kommen ab sofort in das "baseq3"-Verzeichnis. Damit greifen MODs automatisch nicht mehr auf diese zurück und die lästige Umschalterei kann entfallen.
Die Server im Internet laufen momentan noch mehrheitlich unter der 1.15er-Version (Win32) bzw. der 1.11er-Version (Linux). Anderseits - wenn alle Server relativ schnell umgestellt werden kann man wieder auf Linux-Servern spielen (welche ungefähr die Hälfte aller Quake3-Server stellen), da die Updates für die Linux- und Mac-Versionen ebenfalls in Version 1.16 verfügbar sind. Zumindestens einige wenige 1.16er Server gibt es jetzt schon - z.B. die gXp-Server.
Nachtrag vom 20. Februar ...
Mit der 1.16er kann ich plötzlich auch zu 1.11er-Servern connecten. Ging vorher irgendwie nicht.
Eine positive Nebenerscheinung.
Nachtrag vom 22. Februar ...
IdSoftware hat nachgelegt und den Beta-Patch 1.16j veröffentlicht. Der Patch 1.16h muß vorher installiert sein, der
Patch 1.16i wird nicht mehr benötigt.
Nachtrag vom 7. März ...
Mit dem 1.16m-Patch (4,7 MB) erledigen sich obige Patches und es wird nur noch dieser benötigt.
Eine neue CTF-Map ist neu mit dabei.
Nachtrag vom 13. März ...
Eine Lösung des Problems der Warnfensterchen bei Benutzung der
Speed-Up-DLLs gibt es in
dieser News.
Nachtrag vom 19. März ...
Wir streichen das Wort Beta - idSoftware hat das finale Point Release 1.16n veröffentlicht.
Es enthält keine grundlegende Änderungen außer das die Skins der idSoftware-Macher mit dabei sind und der
Download
so auf 7,9 MB angewachsen ist. Das lokal liegende ReadMe
ist ebenfalls auf dem aktuellen Stand 1.16n.
Nachtrag vom 16. April ...
Den Patch sollte inzwischen jeder haben, das ehemals lokal liegende ReadMe flog demzufolge runter vom Server.
3DCenter sucht Mitarbeiter!
17. Februar 2000 / von Leonidas
Das 3DCenter ist seit Ende 1999 mit "echtem" Angebot im Netz vertreten, nun stößt das derzeitige Team des 3DCenters an seine Grenzen. Daher suchen wir fähige Mitarbeiter! Interesse?
Hier erklärt sich auch, warum wir nicht immer so aktuell sein können wie das andere sind. Da wir keine reine News-Site sind, sondern zusätzlich noch unsere Benchmark-Anleitungen und die Benchmark-Charts am laufen halten wollen und wir den mittlerweile großen Download-Bereich ebenfalls dauernd pflegen müssen ergibt sich nicht immer genügend Zeit für die News. Diese Situation behindert natürlich auch den weiteren Ausbau der Site, welchen wir aber im eigentlichen voranbringen wollten - denn Ideen sind genügend vorhanden.
Savage 2000 mit/ohne T&L
13. Februar 2000 / von Leonidas
Es ist zwar schon wieder ein paar Tage her, aber ich komme erst jetzt dazu, ein bißchen was zum Thema zu schreiben.
Auf Thresh´s FiringSquad gibt es einen Direktvergleich von Diamond´s Viper II mit S3´s Savage2000-Chip gegen nVidia´s GeForce-Chip mit normalem SDR-RAM. Da momentan nichts gegen eine GeForce mit DDR-RAM ankommt (ATi verabschiedete sich kürzlich aus diesem Rennen) und beide Karten auch preismäßig relativ zusammenliegen ist dieser Vergleich der interessanteste, welchen man derzeit anstellen kann.
Aber unabhängig von diesem Vergleich, welcher erwartungsgemäß irgendwo unentschieden ausgeht, ist sicher am meisten interessant, daß die FiringSquad die Viper II mit und ohne T&L (Geometriebeschleunigung) getestet hat. Denn momentan senkt das T&L der Viper II die Frameraten in Quake 3! Damit wird auch klar, warum S3 das T&L bisher noch nicht in den Treibern aktiviert hat ... Den Werten mit dem Intro von Unreal Tournament würde ich nicht allzuviel Beachtung schenken, das Intro ist nun mal nicht das Spiel und außerdem funktioniert T&L eh nicht in UT.
Das größte Problem wird offensichtlich, wenn man sich die Werte beim Treemark-Benchmark ansieht, welcher ohne T&L nicht anständig absolvierbar ist. Dort funktioniert das T&L der Viper II, wenn auch auf niedrigerem Niveau als das der GeForce! Und wenn es zumindestens technologisch funktioniert aber rein praktisch in Anwendungen (Spielen) noch nicht heißt das, daß S3/Diamond wohl noch ein schweres Stück Arbeit in die T&L-Treiber der Diamond Viper II investieren muß, um diese wirklich lauffähig zu bekommen. Die Sprüche seitens S3´s bezüglich des fehlenden T&Ls in Richtung "minimaler Hardware-Defekt welcher in einem der nächsten Treibern behoben wird" fallen wohl somit doch eher unter die übliche Marketing-Vertuschungstaktik.
Anderer Punkt: Unter einem Pentium III 600 MHz verliert die Viper II mit T&L im Schnitt ca. 30 Prozent an Performance in Quake 3 in HighQuality, in den Fastest- und Normal-Settings ist dagegen kaum ein Unterschied zu sehen (also dort wo die GraKa relativ wenig leisten muß). Bei einem Celeron A 300 MHz ist fast unabhängig der Settings kaum ein Unterschied zwischen mit und ohne T&L zu sehen - hier muß die Grafikkarte auch weniger Leistung bringen weil sie eh durch die CPU ausgebremst wird.
Aber heißt das dann im Endeffekt: Stellt man der Viper II eine große CPU zur Verfügung stellt und animiert sie damit zu größeren Leistungen wird dann das bord-eigene T&L schwächer performen als die reine CPU-Leistung ohne T&L ?!
Letzteres würde ganz sicher nicht dem Grundgedanken von T&L entsprechen. Jedenfalls wird das Thema S3 und T&L langsam aber sicher zur unendlichen Geschichte. Rückschau: S3´s T&L-Trouble (26.11.) und S2K immer noch ohne T&L (18.1.). Wir beobachten es weiter ...
32 Bit, 32 Bit !
13. Februar 2000 / von Leonidas
Lang versprochen und endlich fertiggestellt sind nun die 32-Bit-Benchmark-Charts. Es sind mittlerweile genügend Ergebnisse da gewesen (83 um genau zu sein), damit sich die Sache lohnte.
Die 16-Bit-Tabellen haben wir nicht geupdatet, trotz der vielen in den letzten zwei Wochen eingetroffenen Ergebnisse (Danke!) - dafür war einfach die Zeit nicht mehr da. Das wird aber nächstes Wochenende - denke ich - nachgeholt.
UT Benchmarking (2)
8. Februar 2000 / von Leonidas
Die anderen News zum selben Thema: Teil 1 (6. Februar) und Teil 3 (20. Mai).
Zwei aufgekommenen Fragen zum Benchmarking von Unreal Tournament will ich noch nachgehen (Achtung, wird ziemlich technisch jetzt):
Warum nicht wie bei Unreal die Vorspann-Sequenz zum Benchmarken?
Sicher - das wäre viel einfacher gewesen und die Frage, ob denn die Timedemos nach zukünftigen Patches noch funktionieren werden läßt sich damit auch umgehen. Und außerdem wird diese Methode sogar von einigen Review-Sites angewandt. Warum also nicht? Nun, was bei Unreal richtig war muß bei Unreal Tournament nicht mehr automatisch als richtig gelten. Denn ein Benchmark sollte also im Zweifelsfall schon das Spiel selber repräsentieren können.
In Unreal ist die FlyBy-Sequenz als Benchmark kein Problem. Sie repräsentiert Unreal recht gut, denn Unreal wird dominiert von leistungsfressenden Außenwelten und daß zeigt das Intro sehr gut. Das die realen Gegner fehlen ist bei diesem Benchmark verschmerzbar, schließlich tauchen diese in Unreal selten massiert auf. Die zusätzliche Belastung durch Gegner-Darstellung und -Einwirkung sollte weit unter der durch die opulent designten Level erzeugten Belastung liegen.
In Unreal Tournament liegt die Sachlage geradezu Welten anders. Denn obwohl UT noch aufwendigere Level als Unreal vorzuweisen hat, ist es nunmal ein reines Multiplayer-Spiel, egal ob on- oder offline. Was die Frameraten in UT heruntertreibt sind Gegner, am besten viele Gegner und die daraus entstehenden Massenkämpfe und Dauerschlachten. Hier kann das Intro von UT überhaupt nicht punkten. Mal ganz abgesehen davon das es eh Texturen und Außenszenen verwendet, die später im Spiel nie wieder auftauchen, gibt es im ganzen Intro keine Gegner in Aktion zu erleben und schon gar kein regelrechtes Gefecht. Der Vorspann von UT repräsentiert nicht das echte Spiel und ist damit herzlich ungeeignet zum Benchmarken diesselben.
Warum keinen Parameter "?timebased" beim Benchmark-Kommando?
Zur Erklärung: Dieser Parameter wird auf einigen Sites im Internet empfohlen. Bei
Verwendung sieht die Startzeile des Timedemos wie folgt aus:
demoplay utbench?timebased
Der Parameter bewirkt, das ein Demo zeitbasierend abgespielt wird. Bei einem UT-Demo werden bei der Aufnahme sowohl die Anzahl der gerenderten Frames als auch die benötigte Zeit gespeichert. Im Normalfall (ohne Parameter) wird ein Demo framebasierend abgespielt, d.h. jedes aufgezeichnete Frame wird hintereinander dargestellt, egal wieviel Zeit das kostet. Beim zeitbasierenden Ablauf wird die zur Aufzeichnung benötigte Zeit zugrundegelegt und das Demo in dieser Zeit durchgejagt, egal ob dann Frames ausgelassen werden müssen. Der Unterschied macht sich nur bemerkbar wenn man ein Demo unter 400*300 (hohe Aufnahme-Frameraten) aufnimmt und unter 1024*768 (niedrige Abspiel-Frameraten) abspielt - beim framebasierenden Ablauf wird dann wesentlich mehr Zeit benötigt und beim zeitbasierenden werden dann wesentlich weniger Frames dargestellt. Von der Theorie her sollten beide Formen auf die selbe Endframerate kommen.
Abweichend davon gilt festzustellen, daß rein praktisch gesehen die mit dem vorgenannten Parameter erreichten Frames per Secound (fps) des UTBench-Demo ca. 4-5 fps höher liegen als beim Befehl ohne diesen Parameter. Und das es mich fast einen ganzen Tag gekostet hat festzustellen, woran das nun genau liegt. Denn grundsätzlich gesehen lässt sich nichts gegen höhere Frameraten einwenden ...
Anderseits liegt in diesem Parameter irgendein Bug drin (möglicherweise nur in Version 4.05b). Das UTbench-Demo startet bei Benutzung des Parameters nicht wie gewöhnlich mit dem ersten Frame (Flak Cannon einsammeln), sondern ungefähr erst beim ersten Teleporter. Noch viel besser: Bei jedem neuen Durchlauf ist der Startpunkt bei Benutzung des Parameters jedesmal ein bißchen anders! Einmal kurz vor dem Teleporter, einmal schon zwei Sekunden danach - jeder einzelne Demodurchlauf hat einen etwas anderen Startpunkt.
Interessant ist der Punkt, daß dieser Effekt jeweils unter OpenGL, Direct3D und Glide auftritt (wahrscheinlich auch unter MeTaL, kann ich nicht nachprüfen), und es kommt dabei bei jedem Renderer zu einer unterschiedlich langen "Verschluckungszeit"! Das heißt, Leute die Direct3D testen haben eine andere Demolänge als Leute die unter OpenGL testen (und bei einer Demolänge von nur zwei Minuten sind fünf Sekunden Unterschied schon ziemlich viel). Noch interessanter: Beim Software-Renderer ist dieser Bug nicht vorhanden, dort wird das komplette Demo abgespielt!
Im genauen fehlen beim UTbench-Demo bei Benutzung des Parameters die ersten 10 bis 15 Sekunden. Viel besser wird es, wenn ich die eigens zu diesem Zweck aufgenommenen Test-Demos durchjage - die Spanne reicht von 7 Prozent bis zu gigantischen 23 Prozent, die jeweils vom Anfang des Demos fehlen. Muß ich weiterreden? Unabhängig davon wie der Parameter mal gedacht wurden war - das Teile eines Demos verschluckt werden ist sicher nicht geplant gewesen, und das disqualifiziert den "?timebased"-Parameter komplett.
Nebenbei habe ich auch noch herausgefunden, warum mit diesem Parameter das UTbench-Demo "schneller" wird. Die verschluckten Anfangssequenzen sind im Vergleich zu den restlichen Sequenzen doch langsamer als diese und drücken - wenn sie gezeigt werden - den Durchschnitt. Wenn sie nicht gezeigt werden, muß logischerweise die Durchschnitts-fps des Timedemos steigen. Man kann dies gut feststellen wenn man ein Demo mit schnellem Anfang und langsamen Ende aufnimmt. Durch das Wegschneiden des schnellen Anfangs beim Durchlauf mit Parameter sollte ein niedrigerer Durchschnitts-Wert entstehen als beim Durchlauf ohne Parameter - und genauso passiert es auch. Alternativ kann man das UTbench-Demo mit dem von diesem Parameter-Bug freien Software-Renderer in beiden Varianten durchlaufen lassen - die Ergebnisse sollten sind gleich sein und sind es auch.
Deshalb bitte ich diesen Parameter bei Benchmarks für uns nicht einzusetzen - und ich empfehle auch anderen WebSites, dies für die eigenen Reviews nicht zu tun. Dieser Parameter erzeugt zum jetzigen Zeitpunkt einen jedesmal anderen Anfang des Demos und ist damit für ernsthafte Vergleiche nicht geeignet. Die höhere Framerate resultiert nur aus der verschluckten langsamen Anfangssequenz des UTbench-Demos, bei anderen Demos kann das anders aussehen.
Nachtrag vom 24. April ...
Ich stelle eben fest, daß mit dem 4.13er Patch die Sache wieder anders aussieht. Insofern werde
ich mir die ganze Thematik nochmals ausführlich zu Gemüte führen, um die neue Situation entsprechend
zu berücksichtigen.
Nachtrag vom 20. Mai ...
Vorgenannte neue Situation hat sich mit dem
Beta-Patch 4.19 auch schon wieder erledigt.
Willamette im Oktober
7. Februar 2000 / von Leonidas
Unabhängig von der im Februar stattfindenden Präsentation des Pentium III - Nachfolgers mit Codename Willamette (Pentium IV ?) behauptet The Register, daß der Verkaufsstart auf den 1. Oktober 2000 fallen soll, also ganze sieben Monate später. Für so abwegig halte ich dies gar nicht mal, der Pentium III wurde ja auch schon ein halbes Jahr vor Auslieferung vorgestellt.
Intel´s Willamette wird eine angeblich komplett neue 32-Bit-Architektur enthalten - die grundsätzliche Architektur des Coppermines stammt schließlich noch vom 1995er Pentium Pro. Mit einer Starttaktfrequenz von 1 GHz wird Intel wieder massiv in den Kampf gegen AMD´s Athlon einsteigen können, wobei diese wahrscheinlich genau zu diesem Zeitpunkt die ersten Modelle der aufgebohrten Athlon-Variante "Thunderbird" ausliefern werden können.
Wieviel von dieser "ganz neuen Architektur" Marketing-Blabla ist, wird abzuwarten sein. Denn ob sich angesichts der voranschreitenden 64-Bit-Projekte von Intel (Merced, McKinley) und AMD (K8 - Sleegehammer) jetzt noch ganz neue 32-Bit-Architekturen lohnen, ist eher zu bezweifeln. Sicher dauert der Umstieg theoretisch Jahre, aber der momentan harte Konkurrenz-Kampf zwischen Intel und AMD wird diese Entwicklung - im Gegensatz zur Umstellung 16-Bit- zu 32-Bit-CPUs - doch stark forcieren. Insofern ist meiner Meinung nach eher eine stark veränderte Coppermine-Architektur zu erwarten, der Sprung wird vergleichbar sein mit dem Sprung vom Pentium zum Pentium II (welcher meiner Meinung nach bis auf die stärkere FPU-Einheit und den Cache on Board kein großer war - Intels Sprünge vom 386 zum 486 und vom 486 zum Pentium waren da wesentlich größer).
Zumindestens werden wir wieder mal mit neuen CPU-Erweiterungen "beschenkt", inoffiziell WPNI (Willamette Processor New Instructions) genannt. Soviel zum Thema, das ISSE des Pentium III wäre der alleinige Seligmacher. Was WPNI exakt schneller machen wird - keinen Schimmer. Aber die Marketing-Abteilung von Intel wird sich schon was einfallen lassen ...
Unabhängig davon bleiben Willamette & Thunderbird eine Sache für das tiefe zweite Halbjahr. Momentan geht die Konzentration in Richtung der kommenden Celerons mit Coppermine-Kern, während AMD jederzeit mit höheren Athlon-Taktfrequenzen kontern wird (und diese dann auch liefern kann), sobald Intel zu nahe kommt.
KX133-Reviews
7. Februar 2000 / von Leonidas
Innerhalb der letzten Tage sind nicht nur erste Mainboards mit VIA´s KX133 in Deutschland aufgetaucht, sondern es gibt auch eine Menge Reviews zum neuen Athlon-Chipsatz:
Letztere ist eine japanische Site. Das wichtigeste kann man aber auch so lesen und die Site ist ansonsten sehr tiefgehend gestaltet was die Benchmarks angeht.
Grundsätzlich sieht es ganz so aus als ob VIA diesmal einen Chipsatz hinbekommen hat, welcher den Referenz-Chipsätzen leistungsmäßig in nichts nachsteht (was nicht immer so war - VIA "glänzte" in der Vergangenheit regelmäßig mit Chips, die auch in der Leistung billig waren). Technisch aktuell ist er ja auf jeden Fall und preismäßig soll er auch günstiger sein, was dem Preis der kompletten Motherboard-CPU-Kombination gut tun sollte.
Passend dazu der Hinweis auf diese Site, auf welcher alle aktuell verfügbaren Golden Finger Devices für den Athlon umfassend vorgestellt werden, mit Bild, verfügbaren Reviews, technischen Daten und Preis.
neue Downloads
7. Februar 2000 / von Leonidas
Wir haben ein paar neue, hoffentlich für Euch interessante Downloads auf die Site gebracht:
- MSI BUSRacing Stellt im laufenden Betrieb den FSB von MSI-Mainboards ein.
- WCPUID Exakte Informationen über alle Taktfrequenzen des Rechners und alle CPU-, Cache- und AGP-Features.
- WCPUL2 Einstellung der L2-Cache-Latency von Pentium II und Celeron A.
- Creative Unified Glide-Wrapper für alle Grafikkarten von Creative mit S3- oder nVidia-Chip.
- WickedGL Beschleunigt OpenGL-Spiele bei 3Dfx-Grafikkarten.
- S3 MiniGL Beschleunigt OpenGL-Spiele bei S3-Grafikkarten.
- Savage2000 MeTaL MeTaL-Treiber für die Savage2000 in UT.
- G400 TurboGL Beschleunigt OpenGL-Spiele bei G400-Grafikkarten.
- MGATweak Tweaker für G200 und G400.
- Timedemo für Unreal Tournament: UTbench
- DirectX 7.0a deutsch Update Das reine Update von 7.0 deutsch auf 7.0a deutsch.
- DirectX 6.0 deutsch
- DirectX 6.0 Control Panel
- DirectX 5.2 deutsch Wird nach einer De-Installation von DirectX benötigt!
- DirectX 5.2 Control Panel
Gleichfalls haben wir alle bisherigen zum Download angebotenen Programme auf neue Versionen kontrolliert und diese gegebenenfalls aktualisiert.
UT Benchmarking (1)
Die anderen News zum selben Thema: Teil 2 (8. Februar) und Teil 3 (20. Mai).
6. Februar 2000 / von Leonidas
Nachdem wir es schon lange angekündigt hatten, habe ich heute nun die Sektion zum Benchmarken von Unreal Tournament fertiggestellt. Bei dieser Gelegenheit ist gleich die komplette Selbst benchmarken!-Sektion dem aktuellen Stand der Dinge angepasst wurden - ich habe versucht, hier und da Dinge zu vereinfachen oder exakter zu beschreiben.
Um bei Unreal Tournament zu bleiben, als Timedemo habe ich das UTBench-Demo ausgewählt, es wird mittlerweile von den meisten Hardwarereview-Sites verwendet. Andere Möglichkeiten wären das Wicked400-Demo von Reverend The Pulpid oder das sharkbit.dem von Sharky Extreme (letzteres wollte man aber seitens Sharky nicht herausgeben) gewesen. Beide Demos sind aber noch schlimmer CPU-beanspruchend als das ausgewählte UTBench-Demo und ich glaube damit noch weniger geeignet als dieses.
Denn leider ist Unreal Tournament unglaublich CPU-limitiert, selbst beim UTbench-Demo sind kaum fps-Unterschiede zwischen den verschiedenen Auflösungen sichtbar. Selbst das Herunterschrauben der Grafikoptionen bringt so gut wie nichts! Deshalb sollte niemand über Frameraten im Bereich um die 20 fps erschrocken sein - Unreal Tournament ist eben ein typischen Epic-Game auch was die Hardware-Anforderungen angeht.
Nachtrag vom selben Tag ...
Fällt mir gerade so spontan ein: Wenn man die Anfangssequenz von UT ausschalten
will, sollte man in der "UnrealTournament.ini" (im System-Verzeichnis von
UT) die folgende Zeile "LocalMap=CityIntro.unr" in die Zeile
"LocalMap=UT-Logo-Map.unr" umändern.
Performancebremse i820
3. Februar 2000 / von Leonidas
AnandTech hat wieder mal zugeschlagen und präsentiert in diesem Artikel ein extrem umfangreiches i820-Chipsatz-Review. Zur Erinnerung: Der i820 ist der von Intel zur Unterstützung der Coppermine-CPU konzipierte Chipsatz. Der wesentliche neue Punkt war der Einsatz der neuen RAMBUS-Speichertechnologie, welche in der Planungsphase eine extreme Erhöhung der zur Verfügung stehenden Bandbreite versprach. Intel bekam jedoch das komplizierte Timing der RAMBUS-Speicher nie in den Griff und mußte im letzten Herbst den i820 wenige Tage vor der weltweiten Einführung wieder zurücknehmen.
Da sich die Lösung dieser Probleme in die Länge zog und auch die Speicherpreise für die RAMBUS-Module nicht fallen wollten (momentan beim 4fachen von normalen SD-RAM) konnte Intel gar nichts anderes tun, als die eigentlich exklusiv für RAMBUS designten i820-Chipsätze auch für normales SD-RAM umzuarbeiten. Jetzt schickt man nun eine neue Revision des Chipsatzes ins Gefecht, welcher über die Möglichkeit verfügt mit beiden Speicherarten umzugehen. Die technischen Details lest Ihr bei AnandTech.
Natürlich hat AnandTech auch entsprechende Benchmarks vorzuweisen. Neben einigen für uns uninteressanten Appikations-Benchmarks kommen auch ein paar Spiele zum Einsatz. Zu meinem großen Leidwesen sind die von AnandTech erzeugten Ergebnisstabellen aber extrem chaotisch geordnet. Es wurden verschieden hoch getaktete Coppermines auf verschiedenen Chipsätzen getestet und dann nach Höhe der Ergebnisse in eine einzige Tabelle geworfen. Leider ist es damit fast unmöglich, den exakten Vergleich der Chipsätze gegeneinander anzutreten, da alle CPUs total durcheinander sind. Und der entscheidende Punkt, warum ich mich überhaupt für dieses Thema interessiere, ist natürlich die Frage nach der Leistung die mit den SD-RAM-i820´s gegenüber den bisherigen Chipsätzen zu erreichen ist.
Aus diesem Grund habe ich es mir erlaubt, die Werte von AnandTech hier noch mal aufzubereiten und in eine Form zu bringen, die den Vergleich der Chipsätze ermöglicht. Ich beschränke mich dabei auf die beiden wesentlichsten Benchmarks (den Rest lest Ihr, wie schon erwähnt, bei AnandTech selber) und liefere auch nicht die exakten Frameraten (da diese für einen solchen Vergleich unrelevant sind), sondern setzte die Ergebnisse in Relation zu einandern.
Als Grundlage (100 %) dienten dabei die Benchmarks mit VIA´s Pentium III - Chipsatz Apollo Pro 133A, da die Werte mit Intels BX-Chipsatz leider unvollständig sind. Was nicht weiter wild ist, der Apollo Pro ist grundsolide, technisch aktuell und leistungsmäßig ungefähr auf BX-Niveau bzw. verschmerzbar niedriger als dieser einzuordnen.
Zuerst ein in den Settings relativ realitätsfremder Test: Quake III Arena, demo001, 640*480 @ 16 Bit, "Normal" Settings, direkter Vergleich zum VIA-Chipsatz Apollo Pro 133A mit SD-RAM.
| CPU und FSB |
i440BX/SDRAM |
i820/SDRAM |
i820/RAMBUS |
| Coppermine 500 100 MHz FSB |
+ 4,2 % | - 7,6 % | + 5,1 % |
| Coppermine 550 100 MHz FSB |
+ 3,8 % | - 7,1 % | + 7,2 % |
| Coppermine 667 133 MHz FSB |
- 11,0 % | + 5,6 % | |
| Coppermine 733 133 MHz FSB |
- 14,1 % | + 2,8 % | |
| Coppermine 750 150 MHz FSB |
- 13,4 % | + 0,1 % | |
| Coppermine 825 150 MHz FSB |
- 13,0 % | + 0,5 % |
Aufgrund des "Normal"-Settings bei der gewählten niedrigen Auflösung ist dieser Test stark theoretisch, jedoch immer noch aussagekräftiger als die üblichen Applikations-Benchmarks. Zumindestens treten hier die Unterschiede der einzelnen Lösungen stärker zu tage. Gut zu sehen die geradezu durchgehende Schwäche des i820 bei Benutzung von SD-RAM. Aber auch die RAMBUS-Variante kann sich nicht wesentlich besser gegenüber den wenigen BX-Tests positionieren.
Ein wesentlich realitätsnaherer Test: Unreal Tournament, UTBench, 1024*768 @ 32 Bit, direkter Vergleich zum VIA-Chipsatz Apollo Pro 133A mit SD-RAM.
| CPU und FSB |
i440BX/SDRAM |
i820/SDRAM |
i820/RAMBUS |
| Coppermine 500 100 MHz FSB |
+ 2,9 % | + 2,9 % | + 23,0 % |
| Coppermine 550 100 MHz FSB |
+ 3,4 % | + 1,1 % | + 23,9 % |
| Coppermine 667 133 MHz FSB |
- 6,7 % | + 11,7 % | |
| Coppermine 733 133 MHz FSB |
- 6,5 % | + 10,8 % | |
| Coppermine 750 150 MHz FSB |
- 5,7 % | + 8,4 % | |
| Coppermine 825 150 MHz FSB |
- 5,0 % | + 7,9 % |
Dieser Test ist der aussagekräftigste von allen, da es sich sowohl um eine gebräuchliche Auflösung als auch um keinen Grafikkarten-limitierten Benchmark handelt. Aufgrund dieser Realitätsnähe erlauben diese Testergebnisse auch Rückschlüsse auf die Auswirkungen nicht nur in Benchmarks, sondern auch im normalen Gamer-Alltag. Hier kann sich die i820-RAMBUS-Variante stärker positionieren und auch die i820-SDRAM-Variante schneidet nicht ganz so desaströs ab wie bei Quake 3 unter 640*480. Grundsätzlich gesehen kann aber auch hier der i820 mit SD-RAM nicht überzeugen.
Fazit: Und wieder eine schwere Schlappe für den i820-Chipsatz. Die Ergebnisse mit RAMBUS sind gut, aber bei den exorbitanten Kosten dieses Speichers disqualifiziert sich diese Lösung selbst für Leute mit großem Geldbeutel sofort - eine bessere CPU/Grafikkarte bringt da mehr. Die Ergebnisse mit SD-RAM sind einfach nur niederschmetternd. Selbst gegen den VIA-Chipsatz sieht man nicht gut aus, gegen den "alten" BX-Chipsatz kann man überhaupt nicht punkten. Ich denke bei einem vollständigen Vergleich gegen den BX-Chipsatz wäre das Ergebnis noch schlechter für Intels i820. Deshalb: So lange sich keine besseren Ergebnisse in späteren Reviews einstellen sollte man einen weiten Bogen um jegliche i820-Mainboards machen.
zwei Bitboys-Interviews
1. Febraur 2000 / von Leonidas
Leider schon wieder das Thema Glaze3D und Bitboys. Letztere gaben jetzt Thresh´s FiringSquad und AnandTech je ein Interview. Viel neues gab es nicht, auch wenn die Ausführungen doch weit über die lächerlichen Presseerklärungen von vor ein paar Tagen hinausgehen.
Ok, zumindestens zu den Veröffentlichungsterminen präsentierte man etwas konkreteres. Im 2. Quartal ... angeblich diesen Jahres ;-)) ... will man erste Samples des Chips der Öffentlichkeit präsentieren und im 3. Quartal mit der Massenproduktion beginnen. Ergo wird der Glaze3D bei Einhaltung des Zeitplans ein Chip für den heißen Herbst 2000 werden und geht damit in Konkurrenz zu nVidia´s NV-20 und zu den ersten T&L-Chips von ATi und Matrox.
Interessant ist im übrigen die Aussage, daß es auch Varianten mit 18 MB eDRAM (zuzüglich 32 MB normalen SD-RAM) geben wird. Erst mit dieser RAM-Bestückung kann der Glaze3D in den Auflösungen über 1024*768 @ 32 Bit die gewaltige Bandbreite des eDRAMs komplett ausspielen - mit 9 MB eDRAM müsste er in diesen hohen Auflösungen auf das langsame SD-RAM ausweichen und der Vorteil wäre dahin.
Zugeben mußten die Bitboys allerdings, daß sie momentan noch kein Stück Silizium vorzuweisen haben. Die Amis haben dafür einen schönen Begriff: Vaporware - frei übersetzt: Eine Sache, die real noch gar nicht existiert. Und ganz unabhängig davon gilt unsere ältere Aussage: "Wir wollen da jemanden sehen, der ein Stück Chip in den Händen hält - dann reden wir über die zu erwartende Performance."
