• Hallo Gast!
    Noch bis zum 20.07. kannst Du an unserer Umfrage zum Hersteller des Jahres teilnehmen! Als Gewinn verlosen wir unter allen Teilnehmern dieses Mal eine Grafikkarte Eurer Wahl für bis zu 1.000 EUR - über eine Teilnahme würden wir uns sehr freuen!

[Sammelthread] Netburst Evolution - Pentium IV/M 478/479 & Xeon 603/604 Stammtisch

Ich dachte immer der Prescott hätte im Gesamten eine deutlich schlechtere IPC als der Northwood. Das der Cache wegen der langen Pipeline so reinhaut und das ausgleicht hatte ich nicht erwartet. In meinen Augen deshalb etwas überraschend das Ergebnis.

Der Northwood sollte ja unter 4ghz dicht machen und der Prescott weiter Takten. Sind vielleicht 266x15 1:1 möglich? Das wären 4ghz und ordentlich Bandbreite am RAM.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich dachte immer der Prescott hätte im Gesamten eine deutlich schlechtere IPC als der Northwood.

Eigentlich hat er das auch. Es wurde ja damals nicht umsonst in den meisten Reviews getitelt, dass der Prescott eher ein Rückschritt war und die Launch Reviews zeigen das meist auch mit einem sehr durchwachsenen Ergebnis.

Siehe z.B. sowas:

oder das:

In anderen Portalen ist das Bild ähnlich. Es ist ein bisschen Rangelei darum wer mal ein paar % vorne liegt und wer ein paar % zurück liegt. Für mehr als die doppelte Anzahl Transistoren – wo natürlich die meisten auf den Cache fallen – einem Shrink und weiteren Architekturverbesserungen zusammen mit dem damals deutlich höheren Stromverbrauch ist das tatsächlich eher dürftig was Intel da geliefert hat und kann aus meiner Sicht eher als "Feldtest" der Architektur gesehen werden um auf 775 mit höherem Takt wenigstens etwas Abstand aufzubauen zum 478er Lineup.

Was ich mir aber vorstellen könnte: der Prescott hat ja diverse Verbesserungen erfahren, die die FSB Bandbreite besser ausnutzen sollen. z.B. wurden ja die Write Combining Buffer von 6 auf 8 erhöht und die Store Buffer sind auch von 24 auf 32 gestiegen. Hyperthreading hat die doppelte Menge an Outstanding Loads bekommen von 4 auf 8 um dort die Effizienz zu steigern. Das zusammen mit den Buffererhöhungen, was den FSB effizienter ausnutzen sollte könnte natürlich hier im Testszenario dazu führen, dass der Prescott mit seinen Architekturverbesserungen vom erhöhten FSB etwas profitiert, mehr als es damals in den Tests mit Default FSB der Fall war.

Dass der FSB bei den P4 schon zu Northwood Zeiten massiven Einfluss hatte, ist ja bekannt. Ein 2,4C mit 12x250 performt deutlich besser als ein 3,0C default @ 15x200. Da reden wir mal eben über zweistellige Zuwachsraten in der Gesamtperformance.

Und was halt auch auffällt ist, dass der Prescott mit steigendem Takt den Abstand nicht gleichmäßig ändert. Wenn man den 3,4GHz Test oben liest, sieht man z.B. in den 3D Mark Scores bei 2,8C vs. 2,8E noch einen Unterschied von etwa 230 Punkten zu Gunsten des Northwoods, bei 3,4C vs. 3,4E sind es nur noch 135 Punkte Unterschied. In den Rendering Tests z.B. sieht es ähnlich aus, der Abstand klafft höher bei den niedrigeren Taktraten.

Vielleicht reicht das dann hier schon um die "Effizienz" des Prescotts zu seinen Gunsten zu kippen durch die Kombination mit FSB und doppeltem Cache.


Wenn ich mal die Zeit über habe, mache ich mir mal die Mühe und lasse die alle mal gegeneinander antreten, auch mit ihren verschiedenen Steppings und teste dann auch mal wie stark sich FSB Anhebungen im Vergleich der beiden Kerne auswirken. Habe alle CPUs und Steppings hier, von den frühen Northwoods, die Extreme Edition und auch alle Prescott Steppings bis zum G1.

Für irgendwas müssen die knapp 360 Pentium 4 CPUs ja gut sein :d
 
Ich dachte immer der Prescott hätte im Gesamten eine deutlich schlechtere IPC als der Northwood. Das der Cache wegen der langen Pipeline so reinhaut und das ausgleicht hatte ich nicht erwartet. In meinen Augen deshalb etwas überraschend das Ergebnis.
Die IPC war bei Release nur knapp schlechter (ca. 1-3%). Das Problem ist eher, man hat eine feinere Fertigungsstruktur, größeren Cache und eine neuen Aufbau des Kerns bekommen. Die Leistung war aber selten schneller als der alte Kern. Dazu kommt noch, dass die Prescotts am Anfang horrend mehr verbraucht haben. Mit den neueren updates kamen auch minimale Anpassungen. Vielleicht hat das auch etwas geholfen?
Man darf auch nicht vergessen, dass der Prescott SSE3 kann, was der NW nicht kann. Keine Ahnung in wie Weit das eine Rolle mitspielt. Jedenfalls war ich auch bei den Benchmarks überrascht.
Die Geschwindigkeit wird auch eine Rolle spielen. Das sieht man in den Spiele Test bei Computerbase. Da hat der Northwood bei 2,8GHz 3% Vorsprung und bei 3,2Ghz nur noch 1%. Ich gehe davon aus, dass die höhere Frequenz die schlechtere Latenz der längeren Pipeline etwas ausgleicht.
Gegen den EE haben beide CPUs keine Chance. :coolblue:

Der Northwood sollte ja unter 4ghz dicht machen und der Prescott weiter Takten. Sind vielleicht 266x15 1:1 möglich? Das wären 4ghz und ordentlich Bandbreite am RAM.
Nur wenige Northwoods werden die 4GHz erreichen. Auch nicht alle Prescotts werden das schaffen. Aber ja bei 266MHz und 4GHz geht dann schon was. :d
 
Ich besitze immer noch einen P4 3.4EE Gallatin SL7CH. Ich müsste auch noch eine ES-Version davon haben.
Die Cache-Menge ist sehr entscheidend für seine Leistung – es erinnert mich stark an das Cache-Dumping der Dothan-Sonoma-Prozessoren
 
Ich besitze immer noch einen P4 3.4EE Gallatin SL7CH. Ich müsste auch noch eine ES-Version davon haben.
Die Cache-Menge ist sehr entscheidend für seine Leistung – es erinnert mich stark an das Cache-Dumping der Dothan-Sonoma-Prozessoren
3,4EE als ES hab ich auch noch - der konnte/kann auch was - war aber gruselig vom Watt-verbrauch :)

Die Gallatin waren ja Xeon MP [Die panik-Intel-Brechstange war geboren^^] - mit dem L3 Cache - konnte seine Vorteile haben - aber hatte auch schwere Nachteile.
Wie war das noch ?! 36-Stufen vom L3 bis zum CPU-Core ?!
Das was man beim Core 2 Duo dann ja auf 18 runtergebrochen hatte - diese ewige lange "pipeline", die beim MP nochma n stück länger war.
 
Ich habe gestern die Microcodes bei dem MSI 865PE NEO2 aktualisiert. Ich musste das manuel machen, weil die amibcp tools mit dem BIOS seltsamerweise nicht laufen.
Nach dem Update fiel mir auf, dass die aktuelle Revision, bzw. die aktuelle Version des Microcodes auch in AIDA angezeigt wird (nicht nur AIDA). Somit kann jeder prüfen, ob man da was machen muss / kann.
F2x IDs sollten, soweit ich es verstanden habe die Northwood CPUs sein, F3x und F4x dann die Prescotts.

Was mir auch aufgefallen ist, ich denke die Vcore ist nach dem Update niedriger. Es sieht für mich so aus, dass die load line angepasst wurde und mehr vdroop da ist. Gemessen habe ich das nicht.

Screenshot 2025-07-02 230702.png
 
Ich habe gestern die Microcodes bei dem MSI 865PE NEO2 aktualisiert.

Magst du mal einen Einblick geben, was sich in den Microcodes so alles verbirgt, bzw. kannst du da reinschauen im Detail?

Und blöde Frage, aber das sind jetzt Microcodes die aktueller sind als die des letzten BIOS, welches MSI für das Board veröffentlicht hat?
 
Magst du mal einen Einblick geben, was sich in den Microcodes so alles verbirgt, bzw. kannst du da reinschauen im Detail?
Ich habe dazu keine brauchbaren Infos gefunden. Nur soweit, dass man da einiges patchen kann. Ob man damit die Loadline ändern kann? Gute Frage wäre auch ob das was mit Intels VRD10 Spezifikation mit beeinflusst.
Was ich sagen kann, die Microcodes der Prescotts sind deutlich größer als die von den Northwoods. Das sieht man in der Spalte size.


Und blöde Frage, aber das sind jetzt Microcodes die aktueller sind als die des letzten BIOS, welches MSI für das Board veröffentlicht hat?
Das letzte offizielle BIOS ist aus 2004. Danach kamen noch Microcodes updates. Ich verstehe nicht, warum MSI da nichts gemacht hat. Ob das Absicht war? Ich teste nochmal den Northwood.
Performance ist zumindest nicht langsamer mit dem Update.
 
was sich in den Microcodes so alles verbirgt, bzw. kannst du da reinschauen im Detail?
Das ist einfach ein Haufen Bytes, die irgendwie von der CPU verwurstet werden. Was Intel genau tut kann man nicht sehen. Der Microcode ist kein Assembler oder sowas…

Ich hab irgendwo die Source von Award 6PG rumliegen, da ist auch der Microcode im (mehr oder weniger) Klartext drin. Damit kann man echt nichts anfangen…
 
Finde den Wissensaustausch hier gerade mega genial! :)

War ja selbst immer auf dem Stand hängen geblieben, dass der Prescott bei gliechem Takt dem Northwood nicht gefährlich wird. Aber denke auch, dass diverse Updates des Microcodes da über die Zeit
Abhilfe geschaffen hat!

Leider scheint das Thema damals keiner mehr verfolgt zu haben, weil es dann relativ zeitnah eh andere CPUs gab, die weitaus schneller waren?
 
Das ist einfach ein Haufen Bytes, die irgendwie von der CPU verwurstet werden. Was Intel genau tut kann man nicht sehen. Der Microcode ist kein Assembler oder sowas…
Achso danke. Ich habe die Frage nicht präzise beantwortet. 😅

War ja selbst immer auf dem Stand hängen geblieben, dass der Prescott bei gliechem Takt dem Northwood nicht gefährlich wird. Aber denke auch, dass diverse Updates des Microcodes da über die Zeit
Abhilfe geschaffen hat!
das denke ich auch! Der Prescott ist trotzdem ineffektiv verglichen mit dem Northwood. Wäre ein E0 / G1 von Anfang da gewesen, würde das auch etwas anders ausehen.

Finde den Wissensaustausch hier gerade mega genial! :)
Ich auch. Im Netz findet man nicht viel an Infos. Vieles muss man selbst erarbeiten. :shake:
Spaß macht es trotzdem. :bigok:

--------------------
Die Spannung beim Northwood ist gleich geblieben. Peformance auch.

edit.
Was seltsam ist. Das MSI board schaltet den patziellen PAT oberhalb von 200MHz beim Prescott ein und beim Northwood nicht. Geil. Das kann man zum Glück per tool aktivieren. Bringt weniger Leistung als volles PAT. [865PE nur unter 200MHz]

--------------------

Hier wie man die CPUID und die Version findet.

screen103.jpg
 
Du hattest mal erwähnt, dass es eventuell auch an SSE3 liegen könnte?

Bin mir gerade nicht ganz sicher, aber ich glaube es gab Benchmarks bei denen man diverse Instruktion ein- bzw. ausschalten konnte.
 
Du hattest mal erwähnt, dass es eventuell auch an SSE3 liegen könnte?

Bin mir gerade nicht ganz sicher, aber ich glaube es gab Benchmarks bei denen man diverse Instruktion ein- bzw. ausschalten konnte.
Könnte man austesten. Ich habe grade ein anderes Problem. Das System startet nicht mehr. 😅 Ich gehe davon aus, dass was nicht passt.
Vorbei erst einmal mit der ausprobiererei. :shake:

edit.
geht wieder. Das BIOS hat das komplette System tot gelegt. Konnte ich auch nur mit Batterie ziehen lösen. :fresse:

edit2.
der Northwood scheint recht gut zu gehen. 4GHz wären vermutlich auch noch drin. Will hier aber nicht die Brechstange rausholen. Da müsste ich Richtung 1,7v gehen

3D2001-NW@15x255-6800@400x378.jpg
 
Zuletzt bearbeitet:
4GHz wären vermutlich auch noch drin.

Kann sein, muss aber nicht. Die Netburst CPUs waren ja dafür bekannt hin und wieder einfach mal in eine Wand zu rennen, die sich auch mit exzessiver Spannung nicht wirklich durchbrechen lässt.

Ich habe einen SL6WK 3,0GHz D1 hier liegen, der ein gutes Beispiel dafür ist.

15x250 = 3750 MHz @ default Vcore prime stable
15x255 = 3825 MHz @ 1,68V prime stable
15x260 = 3900 MHz @ 1,70V prime stable
15x266 = 3990 MHz @ 1,728V prime stable
15x267 = 4005 MHz @ 1,75V / 1,775V / 1,8V / 1,825V... alles ausprobiert bis 1,85V... keine Chance, nichtmal ein Screenshot ist drin.


Bei den letzten 15 MHz um die 4GHz zu knacken nässt er sich komplett ein und will keinen Schritt weiter.

Genau dieses Verhalten ist bei den P4 immer mal wieder zu beobachten. Du denkst erst "och, das geht mit moderaten Erhöhungen ja ganz gut vorwärts" und plötzlich... 1-2 MHz mehr im FSB und du kriegst das Ding um keinen Preis zum laufen. Mit extremer Kälte vielleicht möglich, aber mit konventioneller Luft- oder Wasserkühlung keine Chance.

Da sind die Chips manchmal etwas anders drauf, wo du einfach immer mehr Spannung rein füttern kannst und du erkennst irgendwo Tendenzen dass er zumindest etwas stabiler ist als vorher oder plötzlich zumindest 8M schafft oder so, aber nicht bei manchen P4s. Knallharte Wand.
 
Ein kleiner Ausschnitt, damit man sich vorstellen kann wie so ein Microcode Update ausschaut. Das ist natürlich nur der Start und nicht alles... Ich habe das noch nicht in Ghidra (Disassembler) geworfen, glaube aber nicht, dass das Code ist. Intel wird den Microcode vermutlich während der Initialisierung in der Cpu oder im Chipsatz parsen und dann entsprechend laden.

Nur so am Rande: Ich glaube nicht, dass der Microcode die IPC signifikant steigern kann. Normalerweise wird der eher genutzt um Workarounds für Bugs zu basteln oder undefiniertes Verhalten zu umschiffen.

1751603899297.png
 
Kann sein, muss aber nicht. Die Netburst CPUs waren ja dafür bekannt hin und wieder einfach mal in eine Wand zu rennen, die sich auch mit exzessiver Spannung nicht wirklich durchbrechen lässt.
Hast recht, ist bei einem Kurztest auch so, nur einiges vorher wie bei deiner. 😅
Ich weiß aber nicht, ob das board hier grätscht oder die CPU. Denke eher letzteres.
Dieses Verhalten ist für mich ungewöhnlich. Bin eher AMD CPUs gewöhnt, wo die Taktwand eher fließend ist.


Ein kleiner Ausschnitt, damit man sich vorstellen kann wie so ein Microcode Update ausschaut. Das ist natürlich nur der Start und nicht alles... Ich habe das noch nicht in Ghidra (Disassembler) geworfen, glaube aber nicht, dass das Code ist. Intel wird den Microcode vermutlich während der Initialisierung in der Cpu oder im Chipsatz parsen und dann entsprechend laden.

Nur so am Rande: Ich glaube nicht, dass der Microcode die IPC signifikant steigern kann. Normalerweise wird der eher genutzt um Workarounds für Bugs zu basteln oder undefiniertes Verhalten zu umschiffen.
Danke für die Info. Hier der CPUID ist der Checksum. Gut zu wissen. Wobei ich den Code der Microcodes nicht anfassen werde. Ich kopiere die mir in Blöcken zurecht, fertig. Nur das Microcode Modul im BIOS braucht einen Checksum, sonst meckert das BIOS.
Bei dem AMI BIOS von meinem board liegt der Microcode unkomprimiert im Hauptbios. So konnte ich ohne tools die Microcodes tauschen. Nur der Checksum musste gemacht werden. :)

Ich denke auch nicht, dass die IPC groß geändert werden kann. Dennoch habe ich das Gefühl, dass das board mit dem Update besser taktet. Ich kann mich auch täuschen...
 
Das kann sein. Im Microcode kann ja auch irgendwas an Parametern für den FSB (quasi Sips) mitgegeben werden, was den FSB positiv beeinflusst. Oder intern in der CPU wird etwas umgebogen.
 
Ich weiß aber nicht, ob das board hier grätscht oder die CPU. Denke eher letzteres.

Bei den FSB Regionen wo du mit der CPU bist dürfte das Board noch keinen Stress empfinden. Die meisten Low-Performer Boards bekommen so etwa ab FSB270-275 langsam Dicke Backen, aber da wärst du schon im über 4GHz Bereich.

In meinem Falle kann ich das Board zumindest ausschließen, mit dem Board (IC7M3) habe ich schon ne Menge 2,4C / 2,6C CPUs auf FSB300+ selektiert, das ist im Bereich um 270 MHz noch völlig gelangweilt :d

Dieses Verhalten ist für mich ungewöhnlich. Bin eher AMD CPUs gewöhnt, wo die Taktwand eher fließend ist.

Ich würde sagen so grob 15% der CPUs die ich bisher durchgetestet habe, betrifft dieses Phänomen.
Die anderen skalieren weiter, mal mehr mal weniger gut, wobei natürlich zum Ende das Verhältnis von Spannung und Gain im Takt immer schlechter wird, aber es bewirkt da wenigstens noch was, im Gegensatz zu den Hardwall Kandidaten, die einfach kategorisch aussteigen.

Ich denke auch nicht, dass die IPC groß geändert werden kann. Dennoch habe ich das Gefühl, dass das board mit dem Update besser taktet. Ich kann mich auch täuschen...

Hm ich weiß nicht? Wenn man sich anschaut, welchen Impact die Microcode Updates tlw. auf die Performance der CPU hatten als die Spectre / Meltdown Problematik aufkam (Leistungseinbußen tlw. bis 10% je nach Workload) und wie Intel Performanceprobleme aktuell auch mit der Core 200 Serie versucht mit Microcode zu fixen (wenn ich das richtig mitbekommen habe?), denke ich schon, dass da in gewisser Weise Einfluss genommen werden kann, zumindest um bestimmte Effekte abzuschwächen. Klar, man kann keine Designfehler komplett ausmerzen, wie man ja an den eben genannten Beispielen gesehen hat, wo auch noch OS Updates zusätzlich nötig wurden, aber zumindest Detailverbesserungen halte ich hier nicht für ausgeschlossen oder was meint ihr?

Damals war das mit Sicherheit alles noch "einfacher" gehalten und die Möglichkeiten sicher begrenzter, aber ganz ausschließen würde ich das auch nicht. Vielleicht setze ich mir das zusätzlich auf die Liste, wenn ich die CPUs alle mal gegeneinander stelle, dass ich auch einfach mal den Vergleich mache mit First-Release Bios / Mid-Life-Bios und Last-Release Bios um zu schauen ob es dort unterschiede gab für manche Steppings / CPU Varianten.
 
Hm ich weiß nicht? Wenn man sich anschaut, welchen Impact die Microcode Updates tlw. auf die Performance der CPU hatten als die Spectre / Meltdown Problematik aufkam (Leistungseinbußen tlw. bis 10% je nach Workload) und wie Intel Performanceprobleme aktuell auch mit der Core 200 Serie versucht mit Microcode zu fixen (wenn ich das richtig mitbekommen habe?), denke ich schon, dass da in gewisser Weise Einfluss genommen werden kann, zumindest um bestimmte Effekte abzuschwächen. Klar, man kann keine Designfehler komplett ausmerzen, wie man ja an den eben genannten Beispielen gesehen hat, wo auch noch OS Updates zusätzlich nötig wurden, aber zumindest Detailverbesserungen halte ich hier nicht für ausgeschlossen oder was meint ihr?

Damals war das mit Sicherheit alles noch "einfacher" gehalten und die Möglichkeiten sicher begrenzter, aber ganz ausschließen würde ich das auch nicht. Vielleicht setze ich mir das zusätzlich auf die Liste, wenn ich die CPUs alle mal gegeneinander stelle, dass ich auch einfach mal den Vergleich mache mit First-Release Bios / Mid-Life-Bios und Last-Release Bios um zu schauen ob es dort unterschiede gab für manche Steppings / CPU Varianten.
Also ich denke schon, dass die Möglichkeiten mit einem Microcode groß sind (siehe aktuelle CPUs). Ich denke mal es ist eine Art der Firmware für die CPU wo man auch Befehle und mathematische Prozesse anpassen kann. Prescott CPUs haben, soweit ich gelesen habe, interne Monitoring Fähigkeiten. Das wäre was man mittels Microcodes anpassen könnte. CPU MSR Werte? Ich habe keine Ahnung. :)

Ich denke aber nicht, dass sich bei den P4 CPUs performance technisch viel mit den Microcodes geändert hat. Intel wird schon versucht haben bei jeder Microcode Version das maximale heraus zu holen. Ich kann mich auch irren und lasse mich gerne überraschen. So ein Microcode Vergleich wäre interessant. Ich hätte ehrlich gesagt nicht die Muße dazu. Die verschiedenen Microcodes anzupassen, da könnte ich aber helfen. :)
Generell auch wenn du ein BIOS brauchst wo man die Microcodes abklappern muss.
 
Kann sein, muss aber nicht. Die Netburst CPUs waren ja dafür bekannt hin und wieder einfach mal in eine Wand zu rennen, die sich auch mit exzessiver Spannung nicht wirklich durchbrechen lässt.
+1.
Ich habe zwei SL6WKs (EE Rejects mit 30 Caps von unten), wo man denkt, die gehen ziemlich gut. 3,6-3,8GHz ohne Spannungserhöhung.
Nur - Spannung hilft rein gar nichts. Die gehen mit VID bis in die Wall und kein MHz weiter. Mit den 3,8+ kannst du da schon sehr zufrieden sein @digitalbath :)

Ein D0 Prescott SL7E5 von mir kann das auch. 4GHz@1,375V, aber bei 4,1 (255-258 FSB) hat er ne harte FSB Wall. Da würde Kälte helfen, aber wem hilft Kälte. ^^
 
Ich habe zwei SL6WKs (EE Rejects mit 30 Caps von unten),

Das ist kein EE reject ;) Das ist ein SL793 reject. Das ist der einzige SL6WK der mit 30 caps bestückt war.

Ausschuss der nicht gut genug war für die 3,4 GHz Kontrolle ODER Überproduktion, die runter gelabelt wurde, aber das war eher später der Fall, die frühen Samples waren eher einfach durchgefallen.

EE rejects wären die SL6Z3 bis SL6Z5 mit M0 Kern. Das wiederum ist ein ganz anderes Kapitel, da die echt besonders sind, nur manchmal halt der L3 Cache defekt war, weshalb die deaktiviert trotzdem verwendet wurden. Kommen ausschließlich aus Costa Rica wie alle EE CPUs und gehen idR überdurchschnittlich gut, weshalb die SL6Z* recht begehrt sind. So begehrt, dass ich die letzten direkt als ganzen Tray aus Israel importiert habe um sie zu retten :fresse:
 
Ich habe zwei SL6WKs (EE Rejects mit 30 Caps von unten), wo man denkt, die gehen ziemlich gut. 3,6-3,8GHz ohne Spannungserhöhung.
Nur - Spannung hilft rein gar nichts. Die gehen mit VID bis in die Wall und kein MHz weiter. Mit den 3,8+ kannst du da schon sehr zufrieden sein
Ich muss mich korrigieren. Meiner hört so gegen 3,9GHz auf. Genau habe ich das nicht mehr getestet. 3,75GHz gehen mit knappe 1,62V. Ich denke das ist okay.

Das ist kein EE reject ;) Das ist ein SL793 reject. Das ist der einzige SL6WK der mit 30 caps bestückt war.

Ausschuss der nicht gut genug war für die 3,4 GHz Kontrolle ODER Überproduktion, die runter gelabelt wurde, aber das war eher später der Fall, die frühen Samples waren eher einfach durchgefallen.
Meiner ist ein SL6WU aus Malaysia. Ebenfalls einer mit 30 Käfer auf der Rückseite. Hergestellt 2003 / KW49.

EE rejects wären die SL6Z3 bis SL6Z5 mit M0 Kern. Das wiederum ist ein ganz anderes Kapitel, da die echt besonders sind, nur manchmal halt der L3 Cache defekt war, weshalb die deaktiviert trotzdem verwendet wurden. Kommen ausschließlich aus Costa Rica wie alle EE CPUs und gehen idR überdurchschnittlich gut, weshalb die SL6Z* recht begehrt sind. So begehrt, dass ich die letzten direkt als ganzen Tray aus Israel importiert habe um sie zu retten :fresse:
:fresse: Ich will nicht wissen, was sowas kostet. Geil! :)


-------------------------------

Ein letzer Vergleich, danach lasse ich die Kiste in Ruhe und nerve euch auch nicht. :d
Diesmal bei 15x250MHz - 3750MHz

Northwood D1 [15x250, 1,625V] / 2,5-3-3-8 / PAT / GF6800@ 400x378Prescott E0 [15x250, 1,4V] / 2,5-3-3-8 / PAT / GF6800@ 400x378
3DMark 2001SE2132121680
3DMark 2003 [CPU]10404 [CPU - 950]10234 [CPU - 962]
Aquamark3 [GFX | CPU]57083 [GFX - 7761 | CPU - 10786 ]58016 [GFX - 7743 | CPU - 11570]
Unreal Gold203,17fps216,34fps
Unreal Tournament 2003161,07fps168,77fps
Serious Sam 2 [low fps]252,1fps [low - 138,2fps]253,3fps [low - 134,9fps]
AIDA Memory test [read | write | copy | latency][ 6534MB/s | 5301MB/s | 5198MB/s | 79,6ns][ 7592MB/s | 5314MB/s | 6083MB/s | 73,0ns]
 
Zuletzt bearbeitet:
Meiner ist ein SL6WU aus Malaysia. Ebenfalls einer mit 30 Käfer auf der Rückseite.

Jep den SL6WU gibt’s auch noch, ist aber auch ein D1 Kern. Das sind SL792 rejects die ab ca. Mitte 2003 die volle Käferbestückung trugen, vermutlich in Vorbereitung auf die SL793 Einführung.

:fresse: Ich will nicht wissen, was sowas kostet. Geil! :)

Das waren rund 20 Stück, da kann man das schon machen. Gerade die SL6Z3 und SL6Z4 die dabei waren, bekommt man sonst eher selten und die eignen sich wunderbar für FSB300+ Spielereien. Eine Graupe war dabei die keine 3800 MHz mitgemacht hat, die anderen marschieren ohne Probleme in den 4 GHz Bereich.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh