[Sammelthread] AMD K7 - Sockel A (462)
- Ersteller ItsFun
- Erstellt am
Wenn ich das Datenblatt zum System Bus richtig verstehe, dann hat AMD den Bus grundsätzlich in Steuer bzw. Adress- und Datenleitungen getrennt. Die Datenleitungen sind bidirektional zwischen Cpu und NB, während die Adressleitungen nur in je eine Richtung liegen (ein Satz Leitungen für NB->Cpu und ein Satz für Cpu->NB). Zusätzlich gibts für alles eine CLK Leitung, auf der der Referenztakt mit übertragen wird. Damit gibt es SDATA (bidirektionale Daten) und SADDIN (Adresse "rein") sowie SADDOUT (Adresse "raus"). Soweit ist alles klar, denke ich.
Die Delays brauchen Cpu und NB nun, damit nicht sofort wenn eine Datenübertragung angemeldet wird diese auch startet, sondern es gibt immer eine gewisse Verzögerung. Und das sowohl auf der sendenden als auch empfangenden Seite. Die Cpu meldet also eine Übertragung an, wartet und schickt Daten los. Die NB empfängt die Anmeldung der Übertragung, wartet und nimmt dann die Daten entgegen. Das gibts natürlich nicht nur für den einfachen Fall "read", sondern für alle möglichen Befehle und Übertragungen auf dem Bus. Daher sollten die ganzen Delays kommen...
Das erklärt dann auch, warum manche Delays in Sysclock ("FSB") Zyklen angegeben sind und manche vom Multi der Cpu (und damit vom Cpu Takt) beeinflusst. Letzteres ist vermutlich dann der Fall, wenn die Cpu eine bestimmte Anzahl an Zyklen wartet, bevor die Daten raus gehen oder angenommen wird, das neue Daten angekommen sind.
Anders kann ich mir das nicht erklären... Aber wie zum Henker lädt Nvidia dann die Romsips und manipuliert an den FSB Timings rum?! Die müssen dann zwangsläufig ne Logik in der NB haben, die das regelt. Anders gehts ja nicht oder ich hab einen massiven Denkfehler. Oder man manipuliert tatsächlich "nur" die Timings in der NB und nicht in der Cpu.
Die Delays brauchen Cpu und NB nun, damit nicht sofort wenn eine Datenübertragung angemeldet wird diese auch startet, sondern es gibt immer eine gewisse Verzögerung. Und das sowohl auf der sendenden als auch empfangenden Seite. Die Cpu meldet also eine Übertragung an, wartet und schickt Daten los. Die NB empfängt die Anmeldung der Übertragung, wartet und nimmt dann die Daten entgegen. Das gibts natürlich nicht nur für den einfachen Fall "read", sondern für alle möglichen Befehle und Übertragungen auf dem Bus. Daher sollten die ganzen Delays kommen...
Das erklärt dann auch, warum manche Delays in Sysclock ("FSB") Zyklen angegeben sind und manche vom Multi der Cpu (und damit vom Cpu Takt) beeinflusst. Letzteres ist vermutlich dann der Fall, wenn die Cpu eine bestimmte Anzahl an Zyklen wartet, bevor die Daten raus gehen oder angenommen wird, das neue Daten angekommen sind.
Um nochmal auf den SIP Kram zurückzukommen (Bus Spec, S.140ff):404Kein Plan von. Klingt aber plausibel .
Sprich die NB schickt den
CONNECT Befehl (oder ists ein Pin?!) an die Cpu und feuert dann die 32bit SIP hinterher. Das heisst aber auch, das die ganzen Delays in diesem Moment schon in die Cpu geladen wurden. Die Romsips sollten aber vieeel später im Bootvorgang erst gelesen werden nämlich beim einladen der entsprechenden Abschnitte des Bios in den Cache der Cpu, weil der Ram noch nicht initialisiert sein sollte.Anders kann ich mir das nicht erklären... Aber wie zum Henker lädt Nvidia dann die Romsips und manipuliert an den FSB Timings rum?! Die müssen dann zwangsläufig ne Logik in der NB haben, die das regelt. Anders gehts ja nicht oder ich hab einen massiven Denkfehler. Oder man manipuliert tatsächlich "nur" die Timings in der NB und nicht in der Cpu.
digitalbath
Mr. Oldschool-Bios
@Tzk
Die einzelnen Signale werden zum Glück am Angang kurz erklärt.
Die Frage für mich ist, der Nvidia Chip kann das eigentlich nicht. Wie machen die das?
Die einzelnen Signale werden zum Glück am Angang kurz erklärt.
Ich denke mal, dass die Delays auch dazu da sind, damit die Datenübertragung auch zur richtigen Zeit startet? Systemtakt --> CPU Takt ?
Ja, genau das meine ich.
Sich ändernde sip timings wäre an sich nicht ungewöhnlich beim XP-M auf dem SIS und AMD Chipsatz haben sich diese Delays ja auch im laufenden Betrieb geändert. Je nach Multi halt.
Die Frage für mich ist, der Nvidia Chip kann das eigentlich nicht. Wie machen die das?
TAGG
Experte
- Mitglied seit
- 17.01.2022
- Beiträge
- 163
Nen Kleines Update von mir 
Hab mit den Palominos angefangen, vorne die guten, dahinter die rejects:
Das ASUS board ist super zuverlässig bis jetzt null Probleme, macht deutlich mehr spaß als das abit früher, wenn ein Chip am ASUS 00ed is er tot und es ist nicht eine 50/50 Chance obs der Chip is oder das Bord was spontan die Motivation zu POSTen verloren hat...
Für die die interessiert hab ich mein binning excel angehängt.
Hab mit den Palominos angefangen, vorne die guten, dahinter die rejects:
Das ASUS board ist super zuverlässig bis jetzt null Probleme, macht deutlich mehr spaß als das abit früher, wenn ein Chip am ASUS 00ed is er tot und es ist nicht eine 50/50 Chance obs der Chip is oder das Bord was spontan die Motivation zu POSTen verloren hat...
Für die die interessiert hab ich mein binning excel angehängt.
@TAGG
Das sieht doch nach einem super Start aus. Ich habe auch noch einen Haufen Tbred A und Palomino rumfliegen, aber noch ungetestet... Tbred B und Barton sind einfach interessanter
Das Asus ist ein super Board, falls du dafür ein Modbios brauchst/willst schau mal auf die Biosbude. Zum Binnen und bei niedrigem FSB ist das vermutlich nicht so relevant, trotz fehlendem L12 Mod... Leider hat es eine OVP im L6917B, die bei etwas über 2V (laut Datasheet zwischen 2,0-2,25V und typ. 2.1V) greift. Deshalb hat das Abit NF7 mit 2.2V für Thunderbird und Palos etwas mehr Spielraum. Wenn du am Board rumlöten willst, dann kann man sowohl die Cpu über das 12V Rail versorgen als auch die Vcore Schritte des 6917B anpassen.
Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.
Und noch der Link zum Modbios:
biosbude.de
@digitalbath
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.
Das sieht doch nach einem super Start aus. Ich habe auch noch einen Haufen Tbred A und Palomino rumfliegen, aber noch ungetestet... Tbred B und Barton sind einfach interessanter
Das Asus ist ein super Board, falls du dafür ein Modbios brauchst/willst schau mal auf die Biosbude. Zum Binnen und bei niedrigem FSB ist das vermutlich nicht so relevant, trotz fehlendem L12 Mod... Leider hat es eine OVP im L6917B, die bei etwas über 2V (laut Datasheet zwischen 2,0-2,25V und typ. 2.1V) greift. Deshalb hat das Abit NF7 mit 2.2V für Thunderbird und Palos etwas mehr Spielraum. Wenn du am Board rumlöten willst, dann kann man sowohl die Cpu über das 12V Rail versorgen als auch die Vcore Schritte des 6917B anpassen.
Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.
High Current DC-DC: 12VIN - 3.3 (or 5V) OUT - 35A
Figure 27 shows the device in a high current server power supply application.
Adding an external resistor divider after the remote sense buffer gives the possibility to increase the regulated voltage. Considering for example a divider by two (two equal resistors) the DAC range is doubled from 2.200V to 3.700V with 50mV binary steps. The external resistor divider must be designed in order to give negligible effects to the remote buffer gain, this means that the resistors value must be much lower than the remote buffer input resistance (20kΩ).
Und noch der Link zum Modbios:
Biosbude.de - your resource for bios mods and tools
Biosbude.de - your resource for bios mods and tools
biosbude.de
@digitalbath
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.
TAGG
Experte
- Mitglied seit
- 17.01.2022
- Beiträge
- 163
@TAGG
Das sieht doch nach einem super Start aus. Ich habe auch noch einen Haufen Tbred A und Palomino rumfliegen, aber noch ungetestet... Tbred B und Barton sind einfach interessanter
Das Asus ist ein super Board, falls du dafür ein Modbios brauchst/willst schau mal auf die Biosbude. Zum Binnen und bei niedrigem FSB ist das vermutlich nicht so relevant, trotz fehlendem L12 Mod... Leider hat es eine OVP im L6917B, die bei etwas über 2V (laut Datasheet zwischen 2,0-2,25V und typ. 2.1V) greift. Deshalb hat das Abit NF7 mit 2.2V für Thunderbird und Palos etwas mehr Spielraum. Wenn du am Board rumlöten willst, dann kann man sowohl die Cpu über das 12V Rail versorgen als auch die Vcore Schritte des 6917B anpassen.
Zitat aus dem Datenblatt S.30, R19 und R20 bilden einen Spannungsteiler im Feedback Loop von VoutCORE zu Vsen. Aber Achtung, dieser Teiler erweitert nicht nur die Vcore Range, sondern vergrößert auch die Schritte. Nimmt man einen 1:1 Teiler (effektiv doppelte Vcore), dann sind die Schritte nicht mehr 25mV, sondern 50mV. Ich habe den Mod selbst noch nicht gemacht, weil ich eh nur bei Ambient Temps benche und Bartons nicht mehr als 1.95V sehen sollten.
Und noch der Link zum Modbios:
Biosbude.de - your resource for bios mods and tools
Biosbude.de - your resource for bios mods and tools
@digitalbath
Ich hab gerade nochmal durch das Datenblatt gestöbert und ST schlägt für 12V Vin 3x MBZ 1800uF 16V eingangsseitig vor, wenn die Cpu über 12V laufen soll. Und 6x MBZ 2200uF 6.3V sekundärseitig. Also (fast) das was Asus am A7N8X auch verbaut hat.
Wusste garned dass tbred 2 Versionen hat, muss direkt mal durch die chips gehen und die jeweiligen A versionen bei den relevanten SKUs entfernen
Am ASUS ist schon ein ED mod BIOS von digitalbath drauf, zwar nicht dass aktuellste aber es funktioniert.
OVP müsste mann eigentlich auch easy aushebeln indem mann R7 überbrückt wenn ich mir dass so anschaue? <--- Ist Blödsinn, funktioniert nicht und kann boards killen, die variante von Tzk mit dem 2ten Spannungsteiler geht aber!
L12 mod ist der FID mod für hohe niedere multis, oder? Weil den hat mein board, genauso wie 12V mod
Meine input filtering caps sind ein kleines bissl undersized, have 3x 330uF polys am input und 4x1500uF+1200uF am output und dann 3x330uF + 2x470uF SP-Caps hinter der CPU um die Sparmaßnahmen auszugleichen, SP-CAPs limitieren halt bei der Vcore ein bissl, sind nur 2,5V rated, aber für palominos @2,2-2,3 wirds reichen.
Zuletzt bearbeitet:
Ne. Athlon XP hat wie z.B. Core 2 Duo auch Straps (FSB Timings), die je nach originalem FSB der Cpu geladen werden. Nutzt du ein normales Bios, dann lässt sich deshalb bei einer FSB133 Cpu der FSB nicht so weit hochtakten wie bei einer 166er oder 200er. Meist hat man bei 183 oder 193Mhz FSB eine harte FSB Wand. Das kann man entweder mit einer Drahtbrücke im Sockel beheben oder man nutzt ein Bios welches für alle FSB die gleichen Timings anlegt. Das was den Standard FSB der Cpu festlegt sind die goldenen L12 Brücken auf der Oberseite der Cpu ("FSB Auto Detection"), deshalb heisst der Mod auch L12 Mod bzw. wenn im Bios, dann Soft L12 Mod. Das ED Bios sollte den bereits drin haben.
Den Multi der Palominos sollte man eigentlich mit Silberleitlack ändern können. Wenn du ein gutes Exemplar hast lohnt das zum Benchen eventuell. Ich hab allerdings keine Ahnung wie viel FSB die Teile machen. Bei den Palo hast du ja sicher selbst schon gemerkt das die besseren Cpus alle AGOIA bzw. AROIA sind...
Wenn das Stepping auf A endet ist es ein Tbred A, wenn auf B, dann Tbred B. Also AIUHB ist ein B, AIUGA ist ein A. AIUHB und JIUHB sollten die besten Tbred B Steppings sein, Produktionswoche anfang bis mitte 2003. Ich erinnere mich, das die 1800+ JIUHB 0308 XPMW und 0322 XPMW sehr gute Steppings waren.
Und was deine Caps angeht, 2.5V ist echt arg knapp, gerade bei >2V Vcore. Ich hab Nichicon Polys mit 4V 2700uF verlötet. Und eingangsseitig 2x 3700uF 16V Panasonic FR. Alternativ sollten auch 3x 2200uF 16V gehen. Cap Liste: https://www.hardwareluxx.de/communi...xx-bastelthread.1224414/page-42#post-27655085
Zuletzt bearbeitet:
digitalbath
Mr. Oldschool-Bios
Danke für die Info. Auf der 12V Seite habe ich zur Zeit 3x Pana FR 1500µF drauf. Ist nicht optimal, funktioniert aber. Wenn ich Caps wieder bestelle, kommen da auch solid Caps drauf, wie beim ASRock.
Ich möchte hier ergänzen, dass das alle NF2 boards mit AWARD BIOS den Fall haben. Beim ASRock K7NF2-RAID (AMI BIOS) werden die "FSB-straps" nicht nach CPU, sondern am anligendem FSB Takt und Jumper am board gewählt.
Beim AWARD BIOS könnte man auch noch nachforschen, ob man diese Wahl nach CPU irgendwie umgehen kann. Z.B. die FSB Information in den romsips so einstellen, dass vielleicht auch der aktuell angelegte FSB Takt gewählt wird.
die OVP aushebeln wäre klasse!
Sag Bescheid, wenn du was brauchst. Ich nutze z.B. gerne das 619XT BIOS und bei hohem FSB Takt den romsip preset "custom3".
---------------------
Bin grade bei den letzten Tests für Teil2. Alle timings mit xx6x wie 2161habe ich nicht zum laufen bekommen.
Ergebnisse kommen in den nächsten Tagen.
TAGG
Experte
- Mitglied seit
- 17.01.2022
- Beiträge
- 163
Ah, in meien Kreisen nennt mann dass BSEL mod
Werd ich machen, BIOS hat's laut readme aber eh softwareseitig drinnen.Gut zu wissen, machts einfacher, auch wenn ich alle anderen B chips trotzdem binnen werde denk ich...
Die SP-Caps können dass normalerweise ab, verwende die erfolgreich am Mem-VRM von meinen Rampage Extremes, da bekommens auch 2,1-2,2V ab, mein input-filter ist aber wirklich ein bisschen undersized, normalerweise würde ich da 3x1000uF polys nehmen, aber die sind grade aus, also müssen die FETs ein bisschen leiden, dem Netzteil sollte dass 100% egal sein
Werde ich heute noch probieren denk ich, schaut easy aus, mache dann ein update
Cool, dann werde ich mal 619XT probieren, hab derzeit eins drauf was du vor einer Weile auf Hwbot gepostet hast...
Zuletzt bearbeitet:
Jop, die TBred B streuen mitunter ziemlich. Ich würde ebenfalls alle binnen. Als Datenpunkt: mein 2700+ braucht für 2400Mhz 1.825V sowie für 2500 1.95V und ist ein 0316 RPKW. Die Cpu ist ganz gut, aber alles andere als ein Golden Sample. Die richtig guten Samples sollten für 2400MHz 1.65V oder weniger brauchen.
Zuletzt bearbeitet:
digitalbath
Mr. Oldschool-Bios
guck mal in die BIOSBUDE (Signatur Tzk) rein, da sind alle aktuellen Versionen drin. B2A ist die neuere Version, ansonsten wäre bei A6 das preset "Winbond#1" das gleiche wie "custom3".
Ich habe mich gerade mit einem ASRock K7VT4A+ mit VIA KT400A Chipsatz beschäftigt.
Das Board ist sehr problemlos und hat sogar einige OC-Einstellungen:
CPU: 50 - 248 MHz
CPU-Spannung: +5% / +10%
RAM-Teiler: 133 MHz / 166 MHz / 200 MHz
CL-Timings: 2T / 2,5T / 3T
RAM-Spannung: Low/High
Nicht schlecht. Ich probier gerade mit einem XP3000+ Barton, was mit Luftkühlung so geht.
Das Board ist sehr problemlos und hat sogar einige OC-Einstellungen:
CPU: 50 - 248 MHz
CPU-Spannung: +5% / +10%
RAM-Teiler: 133 MHz / 166 MHz / 200 MHz
CL-Timings: 2T / 2,5T / 3T
RAM-Spannung: Low/High
Nicht schlecht. Ich probier gerade mit einem XP3000+ Barton, was mit Luftkühlung so geht.
Sparksnl
Enthusiast
My best Tb did more before degrading. Top bin should boot on water:
2400 1,650v
2500 1,700v
2600 1,800v
2700 1,975v
2400 1,650v
2500 1,700v
2600 1,800v
2700 1,975v
digitalbath
Mr. Oldschool-Bios
Hallo Zusammen!
hier ist der 2. Teil meiner SIP Tests. Den 1. Teil kann man hier finden: #6.954
In diesem Test möchte ich genauer in die Multi - Timings (Teil der romsips) eingehen.
Nochmal zur Einleitung; ein Timing zu einem Multi sieht in etwa (im BIOS) so aus:
@Tzk hatte die Idee (#6.961) die ersten Bytes der multi-timings gegeneinsander zu testen um die Auswirkungen besser beurteilen zu können. Ziel ist es die einzelnen Bits besser beurteilen zu können.
Tzk hatte auch eine Übersicht der möglichen Timings bei Byte 1+2 erstellt:
Da ich nicht alle Werte testen konne, habe ich mir überlegt, ob ich zu den bisher getesten Werte auch unterschiedliche Werte bei byte 5+6 mit teste.
Als Testbasis habe ich die gleiche Hardware mit den gleichen Einstellungen genutzt:
Für die romsips im ersten Teil habe ich die Standard 200Mhz von Nvidia.
Die Testergebnisse:
Ein paar kritische Worte vorab. Die SuperPI Werte sind diesmal nicht so beständig wie das letzte mal. Ein paar Ergebnisse fallen da aus dem Muster. Quake3 timedemo dagegen passt super und ist recht reproduzierbar.
Wie ich schon ein paar Posts vorher erwähnt habe, habe ich einige timings nicht zum laufen bekommen. Das sind alle, die eine 6 an dritter Stelle haben --> XX6X. Ich habe jeweils mehrere Verschiedene Anpassungen probiert und keins davon hat funktioniert.
Wie man auch an der Tabelle sieht, unterscheiden sich die Werte bei der Spalte byte 7+8. Das liegt daran, dass die einzelnen timings bei byte 1+2 auch unterschiedliche Werte bei byte 7+8 erfordern.
AIDA
SuperPI 1M
Quake3 A timedemo
FSB OC
Meine Auswertung:
Zur Auswertung der eingangs geplanten Tests.
Nvidia nutzt hauptsächlich die Timings: 2141, 6941 und D940. Andere timings wie 2149, 2161, 2169, D968 kommen dagegen seltener vor. Während die Timings mit xx6x überhaupt nicht funktionierten, liefen die timings 2149 und D968 problemlos. Vorteile konnte ich daraus nicht erkennen. Im Gegenteil diese Timings limitieren sogar im OC.
Die normalen Timings 2141, 6941 und D940 funktionieren dagegen problemlos. Ich hatte keine Probleme beim Anpassen dieser Timings in den restlichen Test. Die eingestellten timings bei byte 7+8 funktionierten auf Anhieb.
Anhand der Ergebnisse kann ich keine eindeutige Schlüsse auf die Aufteilung der Bits bei byte 1+2 ziehen. Vielleicht noch, dass der eine Bit [0110] bei xx6x vs. xx4x einen negativen Unterschied bewirkt.
Bei den Tests hat 6941 die schnellsten Ergebnisse erziehlt, gefolgt von 2141 und D940.
Im Vergleich der bytes 5+6 kann man sehen, dass die Unterschiede in den Ergebnissen bei byte 1+2 gleich bleiben. Bytes 5+6 sind auch für den OC FSB Takt verantwortlich. 00ED und 00E4 sind von der Performance her ebenbürtig und vom OC auch gleich. 00EB ist bei der Performance schlechter, bringt aber höheren OC Takt. Bei 00DB ist das maximum erreicht was schlechterer Performance und max OC angeht. Die Kombination aus 6941 und 00DB könnte man vielleicht noch als Kompromis ansehen. Viel schlechter als 6941+00EB ist es nicht (Quake3) und es bringt besseres OC. Diese Kombination ist auch in etwa ähnlich schnell wie D940+ED.
Aus Interesse habe ich noch die 00DD getestet. Ich war überrascht, dass die Unterschiede zu 00ED recht gering ausgefallen sind. Bringt ansonsten keinen Vorteil.
Einen Test zu byte 7+8 tweaks wäre interessant. (Teil 3?)
------------------------
@stunned_guy
wirst du das board in OC testen? Genung Hardware hast du ja da.
hier ist der 2. Teil meiner SIP Tests. Den 1. Teil kann man hier finden: #6.954
In diesem Test möchte ich genauer in die Multi - Timings (Teil der romsips) eingehen.
Nochmal zur Einleitung; ein Timing zu einem Multi sieht in etwa (im BIOS) so aus:
Byte 1+2 | Byte 3+4 | Byte 5+6 | Byte 7+8 |
|---|---|---|---|
69 41 | 20 00 | 00 E4 | 15 18 |
@Tzk hatte die Idee (#6.961) die ersten Bytes der multi-timings gegeneinsander zu testen um die Auswirkungen besser beurteilen zu können. Ziel ist es die einzelnen Bits besser beurteilen zu können.
Tzk hatte auch eine Übersicht der möglichen Timings bei Byte 1+2 erstellt:
Die habe ich als Basis für meine weiteren Tests genutzt. Die anderen Werte sollten soweit wie möglich gleich sein.
Da ich nicht alle Werte testen konne, habe ich mir überlegt, ob ich zu den bisher getesten Werte auch unterschiedliche Werte bei byte 5+6 mit teste.
Als Testbasis habe ich die gleiche Hardware mit den gleichen Einstellungen genutzt:
Ergänzt habe ich das um eine Testreihe mit dem Quake3 Arena timedemo. Getestet wurde das immer mit drei Durchläufen.
Für die romsips im ersten Teil habe ich die Standard 200Mhz von Nvidia.
Die Testergebnisse:
# | sip byte 1+2 | sip byte 5+6 | sip byte 7+8 | test FSB | SuperPI 1M | Quake3 A | AIDA read | AIDA write | AIDA copy | AIDA latency | max FSB OC |
|---|---|---|---|---|---|---|---|---|---|---|---|
1 | 6941 | 00E4 | 1518 | 200 MHz | 54,234 s | 282,6 | 2993 MB/s | 3127 MB/s | 2915 MB/s | 93,4 ns | 221 MHz |
2 | 2141 | 00E4 | 1618 | 200 MHz | 54,781 s | 280,3 | 2887 MB/s | 2793 MB/s | 2768 MB/s | 93,2 ns | 221 MHz |
3 | 2149 | 00E4 | 1618 | 200 MHz | 54,703 s | 279,8 | 2888 MB/s | 2792 MB/s | 2759 MB/s | 93,4 ns | 216 MHz |
4 | D940 | 00E4 | 1618 | 200 MHz | 54,578 s | 277,9 | 2935 MB/s | 2792 MB/s | 2794 MB/s | 101,8 ns | 221 MHz |
5 | D948 | 00E4 | 1618 | 200 MHz | 54,859 s | 277,9 | 2935 MB/s | 2791 MB/s | 2796 MB/s | 101,8 ns | 217 MHz |
6 | 6941 | 00ED | 1518 | 200 MHz | 54,250 s | 282,5 | 2990 MB/s | 3130 MB/s | 2905 MB/s | 93,5 ns | 221 MHz |
7 | 2141 | 00ED | 1618 | 200 MHz | 54,406 s | 280,1 | 2885 MB/s | 2792 MB/s | 2769 MB/s | 93,2 ns | 221 MHz |
8 | D940 | 00ED | 1618 | 200 MHz | 54,516 s | 277,9 | 2939 MB/s | 2791 MB/s | 2812 MB/s | 101,9 ns | 221 MHz |
9 | 6941 | 00EB | 1518 | 200 MHz | 54,422 s | 278,0 | 2937 MB/s | 2793 MB/s | 2796 MB/s | 101,8 ns | 233 MHz |
10 | 2141 | 00EB | 1618 | 200 MHz | 54,656 s | 275,8 | 2833 MB/s | 2791 MB/s | 2694 MB/s | 102,5 ns | 233 MHz |
11 | D940 | 00EB | 1618 | 200 MHz | 54,828 s | 273,6 | 2896 MB/s | 2791 MB/s | 2721 MB/s | 103,3 ns | 233 MHz |
12 | 6941 | 00DB | 1618 | 200 MHz | 54,860 s | 277,9 | 2940 MB/s | 2792 MB/s | 2812 MB/s | 101,9 ns | 258 MHz |
13 | 2141 | 00DB | 1718 | 200 MHz | 54,718 s | 275,7 | 2831 MB/s | 2789 MB/s | 2694 MB/s | 102,5 ns | 258 MHz |
14 | D940 | 00DB | 1718 | 200 MHz | 54,875 s | 273,9 | 2900 MB/s | 2781 MB/s | 2728 MB/s | 103,4 ns | 258 MHz |
15 | 6941 | 00DD | 1618 | 200 MHz | 54,547 s | 282,1 | 2991 MB/s | 3128 MB/s | 2913 MB/s | 93,4 ns | 221 MHz |
16 | 2141 | 00DD | 1718 | 200 MHz | 54,703 s | 280,1 | 2886 MB/s | 2791 MB/s | 2763 MB/s | 93,3 ns | 221 MHz |
17 | D940 | 00DD | 1718 | 200 MHz | 54,593 s | 278,0 | 2937 MB/s | 2792 MB/s | 2794 MB/s | 101,8 ns | 221 MHz |
Ein paar kritische Worte vorab. Die SuperPI Werte sind diesmal nicht so beständig wie das letzte mal. Ein paar Ergebnisse fallen da aus dem Muster. Quake3 timedemo dagegen passt super und ist recht reproduzierbar.
Wie ich schon ein paar Posts vorher erwähnt habe, habe ich einige timings nicht zum laufen bekommen. Das sind alle, die eine 6 an dritter Stelle haben --> XX6X. Ich habe jeweils mehrere Verschiedene Anpassungen probiert und keins davon hat funktioniert.
Wie man auch an der Tabelle sieht, unterscheiden sich die Werte bei der Spalte byte 7+8. Das liegt daran, dass die einzelnen timings bei byte 1+2 auch unterschiedliche Werte bei byte 7+8 erfordern.
AIDA
SuperPI 1M
Quake3 A timedemo
FSB OC
Meine Auswertung:
Zur Auswertung der eingangs geplanten Tests.
Nvidia nutzt hauptsächlich die Timings: 2141, 6941 und D940. Andere timings wie 2149, 2161, 2169, D968 kommen dagegen seltener vor. Während die Timings mit xx6x überhaupt nicht funktionierten, liefen die timings 2149 und D968 problemlos. Vorteile konnte ich daraus nicht erkennen. Im Gegenteil diese Timings limitieren sogar im OC.
Die normalen Timings 2141, 6941 und D940 funktionieren dagegen problemlos. Ich hatte keine Probleme beim Anpassen dieser Timings in den restlichen Test. Die eingestellten timings bei byte 7+8 funktionierten auf Anhieb.
Anhand der Ergebnisse kann ich keine eindeutige Schlüsse auf die Aufteilung der Bits bei byte 1+2 ziehen. Vielleicht noch, dass der eine Bit [0110] bei xx6x vs. xx4x einen negativen Unterschied bewirkt.
Bei den Tests hat 6941 die schnellsten Ergebnisse erziehlt, gefolgt von 2141 und D940.
Im Vergleich der bytes 5+6 kann man sehen, dass die Unterschiede in den Ergebnissen bei byte 1+2 gleich bleiben. Bytes 5+6 sind auch für den OC FSB Takt verantwortlich. 00ED und 00E4 sind von der Performance her ebenbürtig und vom OC auch gleich. 00EB ist bei der Performance schlechter, bringt aber höheren OC Takt. Bei 00DB ist das maximum erreicht was schlechterer Performance und max OC angeht. Die Kombination aus 6941 und 00DB könnte man vielleicht noch als Kompromis ansehen. Viel schlechter als 6941+00EB ist es nicht (Quake3) und es bringt besseres OC. Diese Kombination ist auch in etwa ähnlich schnell wie D940+ED.
Aus Interesse habe ich noch die 00DD getestet. Ich war überrascht, dass die Unterschiede zu 00ED recht gering ausgefallen sind. Bringt ansonsten keinen Vorteil.
Einen Test zu byte 7+8 tweaks wäre interessant. (Teil 3?)
------------------------
@stunned_guy
wirst du das board in OC testen? Genung Hardware hast du ja da.
TAGG
Experte
- Mitglied seit
- 17.01.2022
- Beiträge
- 163
Update, die Variante mit R7 funktioniert so nicht und ist möglicherweise für den tod meines Boards verantwortlich, die Variante von @Tzk
mit dem 2ten Spannungsteiler funktioniert, entweder nur ein Widerstand parallel zu R20 für >2,2V oder ein 100Ohm Potentiometer zwischen VoutCore --> Fbr --> GND (mittlerer Pin auf Fbr), damit kann mann dan Vcore auch senken.
Zuletzt bearbeitet:
Nein, das ist schon wieder Beiseite gelegt. Kommt demnächst in den Verschenkethread mit anderen Boards.
Uff. Das ist ja alles andere als eindeutig... Was ich aus diesem Test mitnehme ist die Tatsache, das 6941 00ED 1518 mit Abstand die schnellste Kombination ist. Das müsste gleichzeitig genau das Settings sein, was in den ganzen Modbiosen als Interface ON hinterlegt ist, während 2141 00ED 1618 für Interface OFF genommen wird. Was mir noch auffällt ist, das bei den 6941er Romsips teilweise der Copy Wert in AIDA durch die Decke geht. 3120mb/s bei 200Mhz ist sehr nah am theoretischen Durchsatz von 3200mb/s, die der FSB hergibt. Da müssen die Timings einfach extrem scharf sein.
Byte 7 und 8 sind auch noch interessant, dort wissen wir ja glücklicherweise welches Setting für was verantwortlich ist. Dort ist Byte 8 mit 18h allerdings schon maximal scharf gestellt und Byte 7 hängt am Cpu Takt. Sprich da spielt dann (auch) der getestete Multi mit rein. Wobei ich mir bei diesen zwei Byten nicht sicher bin obs hauptsächlich um die Stabilität oder um die Performance geht.
Was mich etwas wundert ist die schlechte Übertaktbarkeit. Geht das Board auf dem du getestet hast nicht so gut oder hast du bewusst die Vdd so knapp gewählt, das das Board auf jeden Falls vor der FSB Wall (263) instabil wird?
Danke fürs Testen, auch wenn es wenig erkenntnisreich war.
Zuletzt bearbeitet:
digitalbath
Mr. Oldschool-Bios
@TAGG
Vielen Dank fürs ermittlen.
Ansonsten ist der Unterschied zwischen 6941 (Interface on) und 2141 (Interface off) nicht sooo groß. Ich vermute, dass die anderen sip-timings recht ähnlich sind.
Ich möchte auch herausfinden, warum die normalen Nvidia sips bei ~220MHz aufhören.
Das board selber macht bis 1,60V / 255MHz bei 6941-ED timings mit; 1,775V für 264MHz.
Tests mit verschiedenen Spannungen kann ich noch machen.
edit. Man muss ja bedenken, dass die 258Mhz aus dem Test oben mit den originalen Nvidia sip erreicht wurden. Keine optimierten mod sips.
Vielen Dank fürs ermittlen.
Ich vermute, dass die 6941 timings den 4-BT/SYSCLK Modus aktivieren und so mehr Daten schieben. Bei 2141 würde ich den 2-BT/SYSCLK Modus vermuten.
Ansonsten ist der Unterschied zwischen 6941 (Interface on) und 2141 (Interface off) nicht sooo groß. Ich vermute, dass die anderen sip-timings recht ähnlich sind.
Code:
sip | in bits
===========================
6941 | 0110 1001 0100 0001
2141 | 0010 0001 0100 0001Das könnte man austesten. Ich könnte mir aber vorstellen, dass es bei höherem FSB Takt Auswirkungen haben könnte. Da werden die Bussignale immer schneller und vielleicht werden da kleine Anpassungen benötigt?
Ich habe bewusst die Standard Vdd gewählt. Eine höhere Vdd Spannung würde nur die Grenzen verschieben und ich weiß dann nicht, was von der Spannung abhängt und was von den timings. Ich könnte alleine durch das Senken der offset 68h Werte alle OC Ergebnisse nach oben verschieben.
Ich möchte auch herausfinden, warum die normalen Nvidia sips bei ~220MHz aufhören.
Das board selber macht bis 1,60V / 255MHz bei 6941-ED timings mit; 1,775V für 264MHz.
Tests mit verschiedenen Spannungen kann ich noch machen.
edit. Man muss ja bedenken, dass die 258Mhz aus dem Test oben mit den originalen Nvidia sip erreicht wurden. Keine optimierten mod sips.
Zuletzt bearbeitet:
Das rückt die 258Mhz ins rechte Licht. Originale Sips, 1.6V Vdd und sonst nichts weiter ist sehr stark. Die Vermutung mit 4CLK/2CLK teile ich. Denke da bist du auf einer guten Spur.
Da stellt sich die Frage, ob die Lockerung von SYSDCOUT und SYSDCIN uns Möglichkeiten verschafft den FSB zu erhöhen. Also z.B. statt 1518 dann 2621 oder gar 2722. Hattest du in der Richtung schon was probiert?
EDIT:
Und auch noch ganz interessant von S.53 aus der Bus Spec:
Guter Punkt. Die Frage wird sein, ob eine gewisse Zeit vergangen sein muss oder ob der Chipsatz eine bestimmte Zahl an Zyklen braucht, bis andere Dinge passieren dürfen. SYSDCOUT, SYSDCIN und WRDATA beziehen sich alle auf den Cpu Takt. In der AMD Bus Spec steht folgendes auf Seite 46:
Wenn ich das richtig verstehe, dann sendet die NB immer erst ein Signal das Daten gelesen/geschrieben werden, dann folgt der Delay und anschließend werden die Daten über den Bus geschoben. Der Delay gibt der Gegenstelle Zeit, damit die Daten auch wirklich korrekt übermittelt werden. Die NB nutzt anscheinend den Delay, aber in Abhängigkeit von Cpu Zyklen. Die Frage ist nun, ob der Cpu es egal ist das bei 2,5ghz die Zyklen deutlich kürzer sind als bei z.B. 2ghz. Es sollte einen Unterschied machen ob das System bei 250x10, 200x12.5 oder 200x10 läuft. Ich habe FSB Tests bisher immer bei niedrigen Multis gemacht, eventuell laufen wir dort mit den Romsips ja aus einem bestimmten Fenster raus, weshalb die Wand bei 263MHz entsteht.
Da stellt sich die Frage, ob die Lockerung von SYSDCOUT und SYSDCIN uns Möglichkeiten verschafft den FSB zu erhöhen. Also z.B. statt 1518 dann 2621 oder gar 2722. Hattest du in der Richtung schon was probiert?
EDIT:
Und auch noch ganz interessant von S.53 aus der Bus Spec:
Daraus lese ich, das der Chipsatz dem Prozessor vorgibt, wann er überhaupt berechtigt ist Daten über den Bus zu schicken. Das heisst im Umkehrschluss aber auch, das die NB die ganzen Delays verwalten muss, die die Effizienz des FSB bestimmen. Damit sollte klar sein, warum die Romsips so einen starken Einfluss auf alles haben.
Zuletzt bearbeitet:
digitalbath
Mr. Oldschool-Bios
Vor allem was mich wundert, dass alleine durch das Anpassen der byte5+6 timings auf 00DB man schon besseren FSB Takt erreichen kann.
Macht sinn, wobei NB_SysDcOutDly die Angabe in System Takten ist und SysDcDelay in CPU Takten angegeben werden. SysDcDelay ist scheinbar von NB_SysDcOutDly abhängig, da darin die Zeitverlängerung mit enthalten ist und dann mit einem bestimmten CPU Tekt abschließt. ---> 7 Takte + SysDcDelay.
Würde dann ja bedeuten, wenn wir die NB_SysDcOutDly verlängern, müssten wir auch evtl. die SysDcDelay mit verlängern. Kostet auch evtl. Performance?
Tests mit hohem Multi + FSB Takt ist immer so eine Sache. Bei 2,5Ghz (z.B. 10x250Mhz) ist das nocht kein Problem; darüber hinaus wird es eklig.
Ne. Bisher war meine Beobachtung so, dass SYSDCIN (1518) abhängig davon ist wie byte1+2 asusieht. Sprich: schnelle Werte wie 6941 brauchen 1 Wert niedriger wie 2141 und D940. Wenn bei byte 5+6 eine 00DX steht, brauchen alle sips einen um 1 höheren Wert.
Mit SysDcOutDly habe ich nie experementiert. Bin mir auch nicht sicher, ob das was bringt.
Die anderen Delays wie WRDATA, WR2RD, RD2WR würden mich interessieren.
Die CPU als Sklave.
Die ganzen delays sind etwas unübersichtlich. Immerhin kann man durch das Lesen des datasheets einen kleinen Einblick bekommen. Was mich interessieren würde, wann die RESET commands ausgeführt werden und welchen Einfluss die haben. Bei Gelegenheit ein wenig mehr einlesen in die Materie.Eventuell ergeben sich bei den ganzen Delays ja tatsächlich Abhängigkeiten wie z.B. beim Ram. Tras, Trc und Trfc sind auch abhängig von Tcl, Trp und Trcd... Mit ist das bei hohem FSB aufgefallen, wo 2-2-2-11 mit Trc/rfc 13/15 laufen, aber 3-4-4-11-13-15 instabil wurden. 3-4-4-8-14-16 oder 3-3-3-8-13-15 dagegen ging wieder. In die andere Richtung, also z.B. 2-2-2-5-11-13 habe ich noch nicht probiert.
Was RESET# angeht, der sollte beim Sytemstart ausgelöst werden und die Cpu sowie die NB zurücksetzt. Schau mal in Tabelle 57 in der Bus Spec, da steht quasi als Ablauf drin was beim Systemstart bzw. einem Reset passiert. Und da steht auch genau drin wie die Nummer mit den SIP und damit auch den Bus Timings, die zur CPU übertragen werden läuft.
Was RESET# angeht, der sollte beim Sytemstart ausgelöst werden und die Cpu sowie die NB zurücksetzt. Schau mal in Tabelle 57 in der Bus Spec, da steht quasi als Ablauf drin was beim Systemstart bzw. einem Reset passiert. Und da steht auch genau drin wie die Nummer mit den SIP und damit auch den Bus Timings, die zur CPU übertragen werden läuft.
digitalbath
Mr. Oldschool-Bios
Das Verhalten habe ich auch festgestellt. Ich vermute mal, dass das mehr durch den ersten Teil der romsips (NB Teil) gesteuert wird?
Ja, das leuchtet mir ein.
Mir geht es mehr darum: (Ich hätte präziser schreiben sollen)
Seite 135
Ist der erste Bit der SIP Übertragung.
Sollte, wenn ich das richtig verstanden habe, mehr mit dem Power Management und Halt Befehlen zu tun haben als mit den delays.
digitalbath
Mr. Oldschool-Bios
Ich habe endlich die SIS - sip register geknackt. 
Das Gute daran ist, dass die zum großen Teil auch zu den Werten vom AMD Chipsatz passen.
Das Gute daran ist, dass die zum großen Teil auch zu den Werten vom AMD Chipsatz passen.
Code:
ASRock K7S8X R3.0 - SIS 746FX chipset
200MHz - 133MHz
F0 to F3 in 32-Bit, moved to sip settings
=======================================================================
multi | EC OC ED OD AD PP DS DL EX PM AC RO DM AM BT| F3 F2 F1 F0 |
=======================================================================
5.0 | 101 100 10 01 00 1 0 0011 0 1 011 00 011 011 0 | B2 48 D6 36 |
5.5 | 101 100 10 01 00 1 0 0100 0 1 011 00 011 011 0 | B2 49 16 36 |
6.0 | 101 100 10 01 00 1 0 0101 0 1 011 00 101 101 0 | B2 49 56 5A |
6.5 | 101 100 10 01 00 1 0 0110 0 1 011 00 101 101 0 | B2 49 96 5A |
7.0 | 110 101 10 01 00 1 0 0000 0 1 100 00 101 101 0 | D6 48 18 5A |
7.5 | 110 101 10 01 00 1 0 0001 0 1 100 00 101 101 0 | D6 48 58 5A |
8.0 | 110 101 10 01 00 1 0 0001 0 1 100 00 101 101 0 | D6 48 58 5A |
8.5 | 110 101 10 01 00 1 0 0010 0 1 011 00 101 101 0 | D6 48 98 5A |
9.0 | 111 110 10 01 00 1 0 0010 0 1 101 00 101 101 0 | FA 48 9A 5A |
9.5 | 111 110 10 01 00 1 0 0011 0 1 101 00 101 101 0 | FA 48 DA 5A |
10.0 | 111 110 10 01 00 1 0 0011 0 1 101 00 101 101 0 | FA 48 DA 5A |
10.5 | 111 110 10 01 00 1 0 0100 0 1 101 00 101 101 0 | FA 49 1A 5A |
11.0 | 110 111 00 01 00 1 0 0100 0 1 110 00 101 101 0 | DC 49 1C 5A |
=======================================================================
multi | F3 | F2 | F1 | F0 | |
=======================================================================
[F3:7]=SysDataEvenClkDly (EC) (clocks) 000=No Delay 001=0.5 RO
[F3:6]=010=1.0 011=1.5 100=2.0
[F3:5]=101=2.5 110=3.0 111=3.5
[F3:4]=SysDataOddClkDly (OC) (clocks) 000=No delay 001=0.5 RO
[F3:3]=010=1.0 011=1.5 100=2.0
[F3:2]=101=2.5 110=3.0 111=3.5
[F3:1]=SysDataEvenDly (ED) (clocks) 00=No delay RO
[F3:0]=01=0.5 10=1.0 11=Reserved
[F2:7]=SysDataOddDly (OD) (clocks) 00=No delay RO
[F2:6]=01=0.5 10=1.0 11=Reserved
[F2:5]=SysAddDly (AD) (clocks) 00=No Delay RO
[F2:4]=01=0.5 10=1.0 11=Reserved
[F2:3]=SysPushPull (PP) Drivers 0=Open drain 1=Push/Pull RO
[F2:2]=DECSysComp (DS) 0=Proc Iface w Alpha logic 1=Not RO
[F2:1]=SysDCDelay -Proc Clock Delay from data RDY until date REC RO
[F2:0]=(same as bit1)
[F1:7]=(same as B9h bit1)
[F1:6]=(same as B9h bit1)
[F1:5]=SysAddWide (EX) 0=enabled 1=disabled RO
[F1:4]=SysAddPage (PM) 0=Cache block interleave 1=Page mode RO
[F1:3]=SysAddClkDly (AC) (clocks) 000=No delay 001=0.5 RO
[F1:2]=010=1.0 011=1.5 100-2.0
[F1:1]=101=2.5 110=3.0 111=3.5
[F1:0]=SysResetClkOffset (RO) 00=Bit-time 0
[F0:7]=01=Bit-time 1 10=Bit-time 2 11=Bit-time 3
[F0:6]=SysDataRecMuxPreload (DM) Value RO
[F0:5]=(same as bit6)
[F0:4]=(same as bit6)
[F0:3]=SysAddRecMuxPreload (AM) Value RO
[F0:2]=(same as bit3)
[F0:1]=(same as bit3)
[F0:0]=BitTimesPerSysClk (BT) 0=2 Xfr/SYSCLK 1=4 Xfr/SYSCLKTolle Arbeit mit den SIS Sips. Und sehr interessant zu sehen das manche Timings exakt bei Multi 7 umspringen und darüber schärfer werden.
Helfen die uns bei Nvidia weiter? Oder eher nicht?
Die Nvidia sips sind echt zum Haare raufen.
Helfen die uns bei Nvidia weiter? Oder eher nicht?
Da hab ich mich unpräzise ausgedrückt. Ich meinte das es bei den Romsips eventuell ebenso Abhängigkeiten untereinander gibt. Beim RAM sind die Timings (wie erwähnt) auch zueinander abhängig. Aber ja, ich tippe der erste Teil der Sips hängt eher mit dem RAM zusammen.
Hmm, guter Einwand. Es gibt ja den Disconnect der CPU als Stromsparmaßnahme oder um den Multi zu wechseln. Danach müsste ein Connect ausgeführt werden und eventuell werden die Sip dann auch erneut übertragen.
Die Nvidia sips sind echt zum Haare raufen.
digitalbath
Mr. Oldschool-Bios
Ich denke schon. Ich müsste mal die Nvidia sips genauso in 16Bit / 32Bit aufschlüsseln wie bei SIS. Vielleicht sieht man Ähnlichkeiten. Die Meisten Werte stimmen bei AMD / SIS 100%ig überein. Unterschiede gibt es bei AM und DM. Da vermute ich, dass die Werte von SIS und Nvidia ähnlich sind.
Problem ist nur, dass die Nvidia SIPs vermutlich einige leere Stellen haben und so alle sip Delays entzerrt sind.
Ich würde AM+DM bei Byte 1+2 vermuten und EC+OC+ED in Byte 5+6. Kann mich auch irren.
Achso jetzt verstehe ich das. Dem stimme ich zu. Es werden vermutlich (zeitliche?) Abhängigkeiten in den Delays geben.
2-2-2-5-11-14 hatte ich mal laufen. Infrared hatte ja noch schärfere timings gehabt.
Wird vermutlich auch so sein. Beim SIS/AMD haben sich die sips auch im laufenden Betrieb die Delays geandert (je nach multi). Es werden demnach also mehrere reset Befehle im Betrieb geben; bzw. regelmäßige resets.
Ich finde, wir schlagen uns ganz gut.
The Sandman
Urgestein
Weiß nicht, ob das was bringt, aber SIS 748 ist irgendwie "lernfähig" und Speicherbenchmarks werden schneller, wenn man sie mehrmals hintereinander ausführt.
Müsste das hier sein? SIS HyperStreaming
Scheint sich doch mehr auf I/O perf zu beziehen. Aber irgendwas zeichnet diesen Chipsatz aus, dass er in RAM-Benches zulegt, sobald er sich Muster "gemerkt" hat...
In diesem Testbericht liest man heraus, dass AMD Probleme beim A64 hatte und diesen schon früher launchen wollte:
overclockers-ru.translate.goog
Besteht hier ein Zusammenhang mit der teilweise hohen übertaktbarkeit vom nF2? Wurde vielleicht doch im stillen Kämmerlein mit FSB 233-MHz herumexperimentiert?
Müsste das hier sein? SIS HyperStreaming
Scheint sich doch mehr auf I/O perf zu beziehen. Aber irgendwas zeichnet diesen Chipsatz aus, dass er in RAM-Benches zulegt, sobald er sich Muster "gemerkt" hat...
In diesem Testbericht liest man heraus, dass AMD Probleme beim A64 hatte und diesen schon früher launchen wollte:
Overclockers.ru: Тестирование Athlon 3200+ (Barton) и Abit NF7 rev. 2.0 на 400MHz FSB
Тестирование Athlon 3200+ (Barton) и Abit NF7 rev. 2.0 на 400MHz FSB
Zuletzt bearbeitet:
Aus der JEDEC DDR spec, S.72 bzw Diagramm 52:
Denke das ist für die Ram timings ganz interessant...
Tras = Trcd + Tcl
Trc = Tras + Trp oder Trcd + Tcl + Trp
Also entsprechend für uns (2-2-2-11-13-15):
Tras(min) = 2+2 = 4
Trc(min) = 11 + 2 oder 2+2+2
Also muss entweder Trc auf 13, wenn Tras 11 ist oder wir können sowohl Tras als auch Trc niedriger wählen. Zu Trfc hab ich spontan noch nichts gefunden. Das erklärt aber auch warum 3-4-4-11-13-15 nicht gut läuft, 3-4-4-8-13-15 aber schon. Außerdem müsste damit auch 2-2-2-5-7-12 machbar sein, was Infrared auch genutzt hat.
In der PDF finden sich übrigens auch typische Latenzen für Trc (55ns) und Trfc (70ns). Bei DDR400 sind das 11 bzw. 14 Zyklen.
Denke das ist für die Ram timings ganz interessant...
Tras = Trcd + Tcl
Trc = Tras + Trp oder Trcd + Tcl + Trp
Also entsprechend für uns (2-2-2-11-13-15):
Tras(min) = 2+2 = 4
Trc(min) = 11 + 2 oder 2+2+2
Also muss entweder Trc auf 13, wenn Tras 11 ist oder wir können sowohl Tras als auch Trc niedriger wählen. Zu Trfc hab ich spontan noch nichts gefunden. Das erklärt aber auch warum 3-4-4-11-13-15 nicht gut läuft, 3-4-4-8-13-15 aber schon. Außerdem müsste damit auch 2-2-2-5-7-12 machbar sein, was Infrared auch genutzt hat.
In der PDF finden sich übrigens auch typische Latenzen für Trc (55ns) und Trfc (70ns). Bei DDR400 sind das 11 bzw. 14 Zyklen.
Wenn ich das richtig gesehen habe gibts dafür spezielle Zyklen, nämlich HALT und STOP GRANT bzw. STOP GRANT DISCONNECT. Mit denen kann die cpu quasi schlafen gelegt werden. Anschliesend wird wieder der connect Zyklus durchlaufen, aber ohne Reset.
Zuletzt bearbeitet:
digitalbath
Mr. Oldschool-Bios
Oha, das hört sich interessant an. Der SIS Chipsatz ist an sich nicht schlecht; krankte wohl daran, dass der keinen Dual Channel hat und der Support / Optimierungen durch die Boardhersteller eher mau war.
Selbst mit tweaks war wohl die 3D Performance schlechter als beim NF2.
Könnte ich mir auch vorstellen. Als Plan B sozusagen.
Top!
Ist auch in den datasheets bei Hynix angegeben.
Hmm, mal ne ganz andere Frage. Wenn ihr Q3A Timedemo bencht, welche Timedemo nehmt ihr da? Welche GPU? Wie schließt ihr ein GPU Limit aus? Ich habe noch nie Q3A gebencht oder gezockt (ja, wirklich! )... Ein paar Worte dazu wären top. Oder hat Q3A einen Softwarerenderer?
)... Ein paar Worte dazu wären top. Oder hat Q3A einen Softwarerenderer?
Zuletzt bearbeitet:
