[Sammelthread] AMD K7 - Sockel A (462)

[bschicht86]

Ist bei den 1.04 BIOS Versionen auch das Problem mit Interface Auswahl?

Keine Ahnung, was du damit meinst.

 

[digitalbath]

Die NF2 AWARD BIOSe haben ja die Auswahl bei der CPU Interface ---> aggressive / optimal. Bei den bisherigen A7N8X BIOS Versionen hat ASUS aus aggressive optimal gemacht. Ich bin mir nicht sicher, aber irgendwas haben die da auch was deaktiviert. Man konnte jedenfalls nicht alles einstellen. Ich sehe es mir später an.

 

[Tzk]

Man konnte jedenfalls nicht alles einstellen.

Eigentlich schon. Es muss nur der Punkt System Performance auf user defined stehen, dann ist alles freigeschaltet.

Es ist ja ein A7N8X Deluxe 1.04 (Frisst das auch BIOS'se vom v.2.00?)

Nein, wird nicht mit den 2.00er Biosen booten. Und dann sollte dort eins der letzten offiziellen Biose geflasht werden und es sollte dann (wegen fehlendem L12 Mod) unbedingt eine FSB 200 Cpu verwendet werden, wie der XP3200+ DKV4E. In der Kombination sollte das Board gerade so 200MHz packen, vielleicht auch 210. Mit einer 133er oder 166er Cpu wirst du bei ~183Mhz bzw. ~193Mhz scheitern weil die Romsips zu scharf sind.

 

[digitalbath]

Eigentlich schon. Es muss nur der Punkt System Performance auf user defined stehen, dann ist alles freigeschaltet.

Ich habe nachgesehen. Bei dem 1.04er BIOS war alles wie es soll. Bei dem BIOS A7N8X-E ist die Interface Option grau "show only" und die aggressive option in "optimal" umbenannt und deaktiviert.

das meinte ich.

@bschicht86
Ich habe eine Version mit normalen sips gemacht und eine mit den mod sips. Probier es aus und schau mal, ob alles läuft. Ich habe im BIOS etwas umstrukturiert. Ich hoffe, dass alles so ist wie es soll. Dann könnte ich verschiedene sips noch erstellen. Die zusätzlichen RAM Optionen habe ich nicht rein gemoddet. Ich denke mal, dass die hier nicht so wichtig sind. Wenn doch, kann ich das noch nachträglich machen.

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

Interessant bei diesem BIOS sind die originalen sips. Die habe ich so noch nirgendwo gesehen. Ähneln zwar der Nvidia Vorgabe, aber im Detail gibt es Änderungen. 200MHz sips sind bei Interface aggressive und optimal gleich

Spoiler: sip

65D0 162B 0200 0310 0303 0303 0C0C 0C0C
0040 6900 FF7E 04E0 5605 6655 3003 0743
0000 0088 1F3F 6200 0000 0000 86A8 1000
0D0F AA00 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F40 0000 0000 0008 0000 0000 0000 0000
2141 2400 00E4 1618 2141 2500 00E4 1618
2141 2500 00E4 1618 2141 2600 00E4 1618
2141 2300 00E4 2720 2141 2400 00E4 2720
2141 2500 00E4 2618 2141 2600 00E4 2618
2141 2000 00E4 1618 2141 2100 00E4 1618
2141 2100 00E4 1618 2141 2200 00E4 1618
2141 2200 00E4 1618 2141 2300 00E4 1618
2141 2300 00E4 1618 2141 2400 00E4 1618

65D0 162B 0200 0310 0303 0303 0C10 1010
0040 6900 FF7E 04E0 5605 6655 3003 0743
0000 0088 1F3F 6200 0000 0000 86A8 1000
0D0F AA00 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F00 0000 0000 0008 0000 0000 0000 0000
6941 2400 00ED 1510 6941 2500 00ED 1510
6941 2500 00ED 1510 6941 2600 00ED 1510
2141 2300 00ED 2720 2141 2400 00ED 2720
6941 2500 00ED 2618 2141 2600 00ED 2618
2141 2000 00ED 1618 2141 2100 00ED 1618
6941 2100 00ED 1618 2141 2200 00ED 1618
2141 2200 00ED 1618 2141 2300 00ED 1618
6941 2300 00ED 1510 6941 2400 00ED 1510

65D0 162B 0200 0310 0303 0303 0C10 1414
0040 6900 757E 04E0 5605 6655 3003 0743
0000 0077 1F3F 6200 0000 0000 86A8 1000
0D0C DD00 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F40 0000 0000 0008 0000 0000 0000 0000
D940 2400 00DB 1719 D940 2500 00DB 1719
D940 2500 00DB 1719 D940 2600 00DB 1719
D940 2300 00DB 2821 D940 2400 00DB 2821
D940 2500 00DB 2821 D940 2600 00DB 2821
D940 2000 00DB 1821 D940 2100 00DB 1821
D940 2100 00DB 1821 D940 2200 00DB 1821
D940 2400 02EB 1619 D940 2300 00DB 1719
D940 2300 00DB 1719 D940 2400 00DB 1719

65D0 162B 0200 0310 0303 0303 0C10 1414
0040 6900 757E 04E0 5605 6655 3003 0743
0000 0077 1F3F 6200 0000 0000 86A8 1000
0D0C DD00 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F00 0000 0000 0008 0000 0000 0000 0000
2141 2400 00E4 1618 2141 2500 00E4 1618
2141 2500 00E4 1618 2141 2600 00E4 1618
2141 2300 00E4 2720 2141 2400 00E4 2720
2141 2500 00E4 2618 2141 2600 00E4 2618
2141 2000 00E4 1618 2141 2100 00E4 1618
2141 2100 00E4 1618 2141 2200 00E4 1618
2141 2200 00E4 1618 2141 2300 00E4 1618
2141 2300 00E4 1618 2141 2400 00E4 1618

65D0 162B 0200 0310 0303 0303 0C10 0000
0000 6100 8E7E A4EA 0600 0000 3003 0743
0000 0000 1F3F 6200 0000 0000 86A8 1000
0D00 CCCC 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F00 0000 0000 0008 0000 0000 0000 0000
D948 2400 00DB 1719 D948 2500 00DB 1719
D948 2500 00DB 1719 D948 2600 00DB 1719
D948 2300 00DB 2821 D948 2400 00DB 2821
D948 2500 00DB 2821 D948 2600 00DB 2821
D948 2000 00DB 1821 D948 2100 00DB 1821
D948 2100 00DB 1821 D948 2200 00DB 1821
D948 2200 00DB 1819 D948 2300 00DB 1719
D948 2300 00DB 1719 D948 2400 00DB 1719

65D0 162B 0200 0310 0303 0303 0C10 0000
0000 6100 8E7E A4EA 0600 0000 3003 0743
0000 0000 1F3F 6200 0000 0000 86A8 1000
0D00 CCCC 0000 0000 0000 0000 FFFF FFFF
FFFF FFFF 0000 0000 0000 0000 0000 0000
0380 804B 0400 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0F00 0000 0000 0008 0000 0000 0000 0000
D948 2400 00DB 1719 D948 2500 00DB 1719
D948 2500 00DB 1719 D948 2600 00DB 1719
D948 2300 00DB 2821 D948 2400 00DB 2821
D948 2500 00DB 2821 D948 2600 00DB 2821
D948 2000 00DB 1821 D948 2100 00DB 1821
D948 2100 00DB 1821 D948 2200 00DB 1821
D948 2200 00DB 1819 D948 2300 00DB 1719
D948 2300 00DB 1719 D948 2400 00DB 1719

 

[Tzk]

Bei dem BIOS A7N8X-E ist die Interface Option grau "show only" und die aggressive option in "optimal" umbenannt und deaktiviert.

Ach krass... Das ist mir noch nie so aufgefallen. Allerdings nutze ich beim -E Deluxe eigentlich immer die 1013 als Basis. Eventuell hat Asus da in der 1011 rumgemurkst und das später in der 1012 und 1013 wieder entfernt?

----

Was das 1.04er Bios angeht, dazu findet sich bei CB folgendes:

NVIDIA has a BIOS that cleans up a lot of the "noise" and would allow some older boards to hit 400FSB. However, it is still up to the board maker if they are going to use that BIOS and validate their board for official 400FSB support. NVIDIA feels that the board makers will vary on their response to this. Aggressive companies such as ABIT will release the BIOS and state you can overclock on most of them and support it on others. More conservative companies - like Asus - will probably use the BIOS for stability, but will only certify the newest boards to support 400FSB officially or unofficially.

Und genau dieses Update ist beim v1.04 wohl mit Bios 1008 passiert:

Version 1008
2004/06/18 374.88 KBytes

A7N8X Deluxe BIOS 1008 for PCB revision 1.04, and 1.06 only.
* Add boot option to select boot from SCSI or SATA.
* Update FSB400 romsip table.

 

[digitalbath]

Ach krass... Das ist mir noch nie so aufgefallen. Allerdings nutze ich beim -E Deluxe eigentlich immer die 1013 als Basis. Eventuell hat Asus da in der 1011 rumgemurkst und das später in der 1012 und 1013 wieder entfernt?

Aus dem Gedächnis heraus müsste das Deluxe 2.00 BIOS das auch haben. Bin mir da aber nicht sicher.

Was das 1.04er Bios angeht, dazu findet sich bei CB folgendes:

Danke! Die Info macht sinn!
Jedenfalls sind die Sips für 166MHz und 200Mhz interessant. Werde die mal austesten. Vielleicht bekommt man da was raus. Die 200Mhz sips sind meiner Meinung nach weniger aggressiv als die normalen von Nvidia.


aus dem CB link

Demnach ist es den Programmieren bei nVidia (denn nVidia programmiert aus Gründen der Geheimhaltung alle Bios für nForce 2 Platinen in Eigenregie) gelungen, sog. 'Rauschen' auf nForce 2 Platinen zu minimieren, sprich die Signale sauberer zu halten.

Oha. Das würde erklären warum so wenige datasheets durchgesickert sind. Ich gehe jede Wette ein, dass die Hersteller nicht alle Infos hatten.

 

[Tzk]

Im letzten offiziellen Deluxe v2.0 Bios (aber gemoddet) kann ich das Interface wählen und die Einstellung funktioniert auch. Ob ich das wieder freischalten musste… gute Frage.

 

[The Sandman]

...eine Mikrowelle aus der Küche konnte schon ein Störfaktor sein...
Frequenzen usw. Rauschen... ;O

 

[bschicht86]

NF7 2.0 RA890314045013343 v0.51
SPP 0310 A1
MCP 0305 A3

 

[bschicht86]

Zu dem obigen NF7: Gibt es vom Produktionszeitraum irgendwas, wo man sagen könnte, das Aufbehalten lohne sich? Weil auch meine Sockel A-Abteilung ist schon mehr als voll.

 

[The Sandman]

easy: fight me

 

[Tzk]

Tendenziell eher neuere Boards als das gezeigte. Allerdings gibt es immer Ausnahmen. Wenn du die Graupen aussortieren willst, dann nehme einen Bioschip mit Modbios und boote jedes Board bei 230, dann 240 und zuletzt 250Mhz mit Hynix RAM. Alle die das nicht schaffen sortierst du direkt aus. Den Rest kann man dann mit 32M antreten.

Als Vorauswahl kannst du alles rauswerfen was einen Metalldeckel hat. Das ist quasi die alte NB ohne FSB 400.

Über wie viele Boards reden wir denn?

 

[WMDK]

"Überflüssige" NF7(-S) bitte immer zu mir, ich gebe jedem NF7 ein Zuhause

 

[bschicht86]

So eine blöde Zicke, dieses NF2. Erst ordentlich gereinigt und dann testen wollen. memtest im Dual-Channel lief, bis der erste Fehler kam. Dachte noch, RAM hinüber und hab die Kiste aus gemacht. Danach startet das Board nur noch mit einem Kanal - der einzelne Kanal wollte keinen RAM mehr fressen. Nach ein paar Tests (und einem ModBIOS) später nahm er gar keinen RAM mehr an.

Ich legs erstmal in die Schrottkiste und probier es in ein paar Wochen nochmal.

 

[digitalbath]

Hast du mal einen anderen Multi probiert? Manchmal passen manche Multis nicht. Die sips aus dem A7N8X 1.04 habe ich bei mir bei Multi 9 nicht zum laufen bekommen. Die neueren für die "Ultra 400" gingen dagegen mit Multi 9 (teilweise auch nur mit Anpassungen).

Das board hat kein bock mehr? Oder hat mein mod BIOS es zerlegt?

 

[bschicht86]

Ich hatte einen 2500+ dabei, den ich auf Multi 11 gelassen hatte. Channel 2 hat vor dem ModBIOS aufgegeben, danach hatte ich dein ModBIOS drauf um zu schauen, obs besser wird. Wurde es nicht, nach einer halben Runde memtest waren beide Kanäle "fort".

 

[digitalbath]

Okay, Multi 11 ist eigentlich weniger kritisch. Multis 10 - 8 sind kritischer.
Mod BIOS hat funktioniert? Waren alle menus okay? Wenn ja, kann man das BIOS in die BIOSBUDE hochladen.

 

[stunned_guy]

MSI K7N2 Delta-L Board 10

Northbridge: 0446 A1 SPP Ultra400



Southbridge: 0445 A4 MCP



SN: K0412914179

 

[digitalbath]

Moin zusammen! Holt euch einen Kaffee, es gibt wieder Text.
Der Anlass zu diesem Post waren eigentlich die romsips aus dem A7N8X 1.04 BIOS. Ich wollte diese mit den sips aus den neueren "Ultra400" BIOSen vergleichen. Soviel verrate ich schon vorab, dass ich die sips aus dem 1.04 BIOS nicht zum laufen bekommen habe. Ich hätte zwar einen anderen Multi wählen können, dann wären die vorherigen Test umsonst gewesen.
Nichtdestotrotz verrät der restlichte Test auch einiges.

Das Testsetup:

board: K7NF2-RAID
CPU:   XP-M 2400+ @ Multi 9.0
RAM:   2x 256MB Hynix BT-D43 @2,5-4-4-8-13-16-3-4-4-4-3-4-5
Vdd:   1,60V board Standard
Vdimm: 2,7V

Mit dem Setup sollte das board stressfrei bis 255MHz (32M) mitmachen. Ich denke bei den Nvidia sips geht die Puste schon weit vorher aus.
Max. FSB Test wurden mit min. einem Lauf SuperPi 4M (32M dauert mir hier zu lange) getestet.

Die Testergebnisse:

​

#​	FSB speed​	Interface​	test FSB​	SuperPI 1M​	AIDA read​	AIDA write​	AIDA copy​	AIDA latency​	max FSB OC​
1​	133 MHz​	optimal​	200 MHz​	54,422 s​	2884 MB/s​	2793 MB/s​	2763 MB/s​	93,2 ns​	217 MHz​
2​	133 MHz​	aggressive​	200 MHz​	54,093 s​	2989 MB/s​	3130 MB/s​	2914 MB/s​	93,4 ns​	216 MHz​
3​	166 MHz​	optimal​	200 MHz​	55,094 s​	2897 MB/s​	2784 MB/s​	2727 MB/s​	103,5 ns​	218 MHz​
4​	166 MHz​	aggressive​	200 MHz​	54,375 s​	2887 MB/s​	2792 MB/s​	2763 MB/s​	93,4 ns​	248 MHz​
5​	200 MHz​	optimal​	200 MHz​	55,469 s​	2898 MB/s​	2792 MB/s​	2712 MB/s​	103,3 ns​	258 MHz​
6​	200 MHz​	aggressive​	200 MHz​	54,406 s​	2884 MB/s​	2792 MB/s​	2770 MB/s​	93,2 ns​	223 MHz​

Ein paar kritische Worte zum Test. Ich habe eingangs mich für Multi 9.0 entschieden, damit ich notfalls auch bis max FSB bei dieser CPU tackten kann. Leider sind die CPU-Multis 8-10 nicht stressfrei. Manche passen einfach nicht zu den sip-timings. So musste ich auch bei den normalen NVidia sips anpassen, damit das board überhaupt mit 200Mhz startet. Ein Beispiel: Bei 200MHz (optimal) musste ich den Wert für SYSDCIN Delay von 8 auf 7 stellen, dann startete das board stressfrei. [SYSDCIN zu verstellen, damit ein Multi funktioniert ist ein guter Trick ]
Die eingangs geplanten Tests der A7N8X 1.04 sips musste ich streichen. Ich habe diese sips selbst mit Anpassungen nicht zum laufen bekommen. Entweder startete das board gar nicht, das System bootete und bleib beim Win booten hängen oder hängte sich beim Desktop auf. Ich habe das nach längerem probieren sein lassen. Die "low noise" sips der "Ultra 400" boards sind da pflegeleichter.

Meine Auswertung:
Zur kurzen Erklärung zu den sips allgemein:

Die sips bestehen ja aus zwei Teilen. Dem ersten Teil, der für alle Multis gilt, und dem zweiten Teil, der für die einzelnen Multis eigene Timings hat. Der erste Teil betrifft meiner Meinung nach eher den MC Teil; der zweite Teil die CPU-FSB-Datenströme.
Bis dato war meine Meinung, dass die Übertaktbarkeit des front-side-busses hauptsächlich von dem ersten Teil der sips abhängt. Durch anpassen der Werte im ersten Teil (PCI register b0d0f0 68h und 6Bh) konnte ich bisher einen hohen FSB Takt erreichen. Unabhängig der Multi timings im zweiten Teil der sips. Die Multi timings dagegen entscheiden die Geschwigkeit des Systems (Daten-Durchsatz + Zugriffszeit?). Das ist letzendlich auch der Unterschied zwischen Interface Aggressive und Optimal. Hierbei werden nur andere Multi-timings gesetzt. Der erste Teil der sips ist meist bei optimal und aggressive gleich und unterscheiden sich nur bei den FSB Geschwindigkeiten.

Die Ergebnisse der 133MHz sips sind kaum überraschend. Es ist ja allgemein bekannt, dass es die schnellsten sind. Dass man damit auch nicht übertakten kann ist klar.
Alle anderen Test sind dagegen schon interessant.
Bei den 166MHz Tests finde ich schon erstaunlich wie groß der Unterschied zwischen optimal und aggressive ist. Ich hatte schon geahnt, dass die 166MHz Tests besser abschneiden werden, da der 68h Wert im ersten Teil der 166MHz sips auf 00 gestellt wurde , und somit den niedrigsten Wert hat. Im Vergleich dazu hat 133Mhz hier den Höchsten Wert mit FF. Ich kann wohl nicht erklären warum aggressive hier gut taktet und optimal nicht. Da der Unterschied zwischen den beiden nur die Multi timings sind, sollte es daran liegen.
Die Überraschung hatte ich bei den 200MHz Tests. Hier hatte ich keinen hohen FSB Takt erwartet, denn der register 68h Wert liegt hier auch auf einem recht hohen Wert (AD). Trotzdem hat das board einen hohen Takt bei Interface optimal erreichen können. Er war sogar höher, als bei meinen mod sips. Über Geschwindigkeit brauchen wir wohl hier nicht reden, da hier die langsamsten Multi - Timings eingesetzt wurden. Bei Aggressive war der OC Takt wieder auf dem erwarteten Niveau. Auch hier enscheiden die Multi-timings mit über das OC Verhalten. Ich nehme mal an, dass der Datendurchsatz auch einen Anteil am OC hat.

mein Fazit:
Zusammenfassen würde ich den Test, dass bei den sips die Multi-Timings und somit der Datendurchsatz auch einen Einfluss auf OC hat. Bisher habe ich bei den mod sips immer die schnellsten Multi-timings aus den 133MHz Aggressive sips benutzt. Vielleicht limitiert das auch unseren max OC? Es sind weitere Test nötig, damit man vielleicht einen guten Kompromis zwischen OC und Durchsatz erreichen kann. z.B. mit den 166Mhz aggressive timings?

Was den Nvidia sips angeht, ich frage mich noch immer, warum sie die sips bei den "Ultra400" boards geändert haben. Bei den Generationen vorher (NF1, NF2-166MHz) sahen die sips anders aus. Die Erklärung "noise" kann ich hier schlecht einordnen. Für mich sieht es so aus, dass Nvidia versucht hat die Kompabilität anzupassen, ohne Rücksicht auf OC. Wu hat bei seinen Entwicklungen zu den "DFI Beta-BIOS" Versionen schrittweise die vorherigen NF2-166MHz sips genutz um sie zu perfektionieren.

 

[Tzk]

Sehr interessant, das sich zwischen den optimal/aggressive Tabellen so extreme Unterschiede ergeben. 200Mhz optimal ist ja schnarchlangsam, taktet dafür aber gut. Das wird wohl die Variante für Stabilität sein. Während 166 opt. ebenso langsam ist, aber zusätzlich schlecht taktet (WTF?). Das 166 aggr. so gut geht hätte ich dagegen nicht erwartet, genau das hat Oskar bei DFI wohl auch entdeckt und deshalb diese Romsips als Basis genommen. Die Bandbreite/Latenz der 133 aggr. ist schon extrem gut, das fällt ebenfalls auf.

An der Stelle frage ich mich nun, ob die 200 opt. eventuell als Basis für unsere weiteren Tests in Richtung 263+ geeignet sind?

EDIT:
Ich hab mir gerade nochmal die ÜBersicht zu den letzten 4 Stellen der Multi Tabellen angesehen. Es scheint so, dass nur SYSDCOUT, SYSDCIN und WRDATA DELAY in CPUCLK angegeben sind. WRTORD und RDTOWR nicht?! Wir nutzen derzeit hauptsächlich 1518, vielleicht müssen wir da mal 151D (WRTORD = 2 und RDTOWR = 2) testen? Mit 1518 wären beide 1.

 

[digitalbath]

Sehr interessant, das sich zwischen den optimal/aggressive Tabellen so extreme Unterschiede ergeben. 200Mhz optimal ist ja schnarchlangsam, taktet dafür aber gut. Das wird wohl die Variante für Stabilität sein. Während 166 opt. ebenso langsam ist, aber zusätzlich schlecht taktet (WTF?).

Dass die 166MHz optimal sips schlecht takten könnte an den Multi timings liegen. Die fangen ja mit D961.... an. Alle D9xx timings sind langsam, so wie auch 200Mhz optimal.
So wie ich das sehe, ist der erste byte der multi timings huptsächlich für die Geschwindigkeit und Latenz verantwortlich. Das kann man auch an der PI Grafik erkennen.

Demnach ist 69xx am schnellsten, dann 21xx, dann D9xx. Die Stellen 5+6 (00DB, 00EB, 00ED, 00E4) bewirken aber auch was. Das kann man 166MHz / 200MHz optimal sehen. ---> EB vs DB.
Wenn ich bei D948 auf die schnelleren ED ändere bekomme ich immer noch eine Latenz von 101,9ns und eine PI zeit von ~54,8s.

Warum 166MHz optimal schlecht liefen, keine Ahnung. Ich denke, die D961 timings passen nicht 100%ig.

Das 166 aggr. so gut geht hätte ich dagegen nicht erwartet, genau das hat Oskar bei DFI wohl auch entdeckt und deshalb diese Romsips als Basis genommen. Die Bandbreite/Latenz der 133 aggr. ist schon extrem gut, das fällt ebenfalls auf.

Vorsicht. Wu hat die sips der NF2-166MHz Metallkappen benutzt, nicht der neueren 166MHz aggressive. Erkennbar an den 5en und 6en im ersten Teil der sips.

An der Stelle frage ich mich nun, ob die 200 opt. eventuell als Basis für unsere weiteren Tests in Richtung 263+ geeignet sind?

Testen sollte man das schon, wobei man sagen muss, dass wenn man diese 200MHz optimal sips schneller mach, auch gleichzeitig beim OC einbüßen muss. "Einfache" Merlin EB sips sind min. gleich schnell und übertakten dann besser. Stoff für einen Teil 2.

Ich hab mir gerade nochmal die ÜBersicht zu den letzten 4 Stellen der Multi Tabellen angesehen. Es scheint so, dass nur SYSDCOUT, SYSDCIN und WRDATA DELAY in CPUCLK angegeben sind. WRTORD und RDTOWR nicht?! Wir nutzen derzeit hauptsächlich 1518, vielleicht müssen wir da mal 151D (WRTORD = 2 und RDTOWR = 2) testen? Mit 1518 wären beide 1.

Diese letzten vier Stellen sind vermutlich wichtiger als gedacht. Zur Erinnerrung, ich habe bei 200MHz optimal den SYSDCIN Wert verändert für den Test.
151D ist auch in den NF1 und NF4 sips vorhanden.

 

[Tzk]

Vorsicht. Wu hat die sips der NF2-166MHz Metallkappen benutzt,

Ah, Missverständnis meinerseits. DAS ist allerdings noch interessanter.
----

Was die vier ersten Stellen angeht, die müsste man mit den uns bekannten Werten und mit genug Datenpunkten so auseinanderbasteln können, wie du es mit den letzten vier Stellen getan hast. Folgende Werte habe ich derzeit in einer Exceltabelle stehen, die aus diversen Biosen stammen. Hattest du mal angetestet, ob man die beliebig kombinieren kann? Ich denke auch hier müssen testreihen her, die Stabilität und Performance systematisch durchgehen. So wie es aussieht ist AIDA und 1M dafür ein guter Indikator, heisst es geht schnell

6941
6961
2141
2149
2161
2169
D940
D948
D961
D968

Die andere Sache wäre der Rest der Romsips. Es gibt echt komischen Kram, bei dem es eine gute Frage ist, warum unsere ED55 sips dort nichts stehen haben... Hier mal beispielhaft das "CA02" mitten drin:

6941 2300 00ED 2620  | ED55         FSB200 aggr     5x
D968 A5CA 02DB 1719  | DFI N24LDB24 FSB133 optimal 12.5x

 

[digitalbath]

Hattest du mal angetestet, ob man die beliebig kombinieren kann?

Ja habe ich getestet. Manches geht, das meiste eher nicht. z.B: D948 und D940 kann man tauschen, ersteres ist minimal schneller. D941 war dann nicht möglich. Ansonsten war die Tauschaktionen eher mit einem nicht-boot Ergebnis gekrönt. Kombinationen zu testen ist seeeehr langwierig, bis man eine Kombination gefunden hat. Ich habe es schnell sein gelassen.
Bei schnelleren timings muss man die SYSDCIN Wert nach oben oder unten korrigieren.

Ich denke auch hier müssen testreihen her, die Stabilität und Performance systematisch durchgehen. So wie es aussieht ist AIDA und 1M dafür ein guter Indikator, heisst es geht schnell

das stimmt. Man kann da auch recht schnell ermitteln, was los ist.

Was die vier ersten Stellen angeht, die müsste man mit den uns bekannten Werten und mit genug Datenpunkten so auseinanderbasteln können, wie du es mit den letzten vier Stellen getan hast.

sip   |  in bits
===========================
6941  | 0110 1001 0100 0001
6961  | 0110 1001 0110 0001
2141  | 0010 0001 0100 0001
2149  | 0010 0001 0100 1001
2161  | 0010 0001 0110 0001
2169  | 0010 0001 0110 0001
D940  | 1101 1001 0100 0000
D948  | 1101 1001 0100 1000
D961  | 1101 1001 0110 0001
D968  | 1101 1001 0110 1000

Auf den ersten Blick sehen die Zahlen wild aus. Sieht man diese als bits, sieht das Ganze anders aus. Vergleicht man die sips aus 133MHz agg / opt, so stellt man fest, der Unterschied ist im ersten Byte 69 vs 21

sip   |  in bits
===========================
6941  | 0110 1001 0100 0001  aggressive
2141  | 0010 0001 0100 0001  optimal

Der Unterschied sind lediglich zwei mal die 1 vs. 0. Von den Latenzen her sind beide gleich aber bei aggressive werden mehr Daten transportiert, siehe AIDA Werte.
Ich hätte für die ersten beiden bits das hier vermutet. Vergleiche auch dazu die langsamen D9xx Werte, die mit einer 1 anfangen.

Den Rest hätte ich 32bit -weise in AMD Reihenfolge dahinter gehägt. Ist aber nur eine grobe Theorie.

Die andere Sache wäre der Rest der Romsips. Es gibt echt komischen Kram, bei dem es eine gute Frage ist, warum unsere ED55 sips dort nichts stehen haben... Hier mal beispielhaft das "CA02" mitten drin:

Der Teufel steckt im Detail. Der Unterschied zwischen A [1010] und 2 [0010] ist die 1 vorne. Ansonsten könnte die 0 auch eine Art Auto Wert sein.
Es wird schwer, das zu entschlüsseln.

edit:

6941 2300 00ED 2620 --> 3= SysDcDelay?

 

[Tzk]

Vergleicht man die sips aus 133MHz agg / opt, so stellt man fest, der Unterschied ist im ersten Byte 69 vs 21

Genau das wäre meine Strategie. Wenn wir ausreichend viele Romsips finden, die sich sehr ähnlich sind, dann können wir daraus hoffentlich Gruppen aus Bytes ableiten.

6941 2300 00ED 2620 --> 3= SysDcDelay?

Gut beobachtet, ich schließe mich deiner Vermutung an. Und darüber hinaus könnten die zwei Bits links daneben zum SysDcOutDly gehören. Wir haben in den Romsips entweder 2?h (0010 ????b) oder A?h (1010 ????b). Eventuell gehört das erste Bit dieser Folge noch zu den ersten vier Bytes dazu. Also so:

69              41             23             0000ED2620
01101001 010000010 0100011

69             61             A3             3A02ED1510
01101001 011000011 0100011

Generell scheint AMD einiges an Delays vorgesehen zu haben, damit die Daten passend gelesen werden können. Und das sowohl in der Cpu als auch in der Nb. Und wenn ich das richtig verstehe, dann gibt es Delays, die für das verzögerte Senden von Daten zuständig sind als auch solche, die das verzögerte Empfanden kompensieren. Das alles sollte die Effizienz der Datenübertragung auf dem Bus beeinflussen und damit (auch) die Latenz zum Ram. Dadurch das Sockel A den Flaschenhals immer am FSB hat sehen wir das direkt in AIDA.

An dieser Stelle glaube ich, das man mit einem Logic Analyzer den SIP Bus bei Reset des Systems mitschneiden muss, um das gesichert zu ermitteln. AMD hat in der Bus Specification ja die 32 Bits aufgeschlüsselt, die beim Systemstart übertragen werden müssen.

 

[digitalbath]

Gut beobachtet, ich schließe mich deiner Vermutung an. Und darüber hinaus könnten die zwei Bits links daneben zum SysDcOutDly gehören. Wir haben in den Romsips entweder 2?h (0010 ????b) oder A?h (1010 ????b). Eventuell gehört das erste Bit dieser Folge noch zu den ersten vier Bytes dazu. Also so:

SysDCOut Delay haben wir doch schon auf die 1518 ermittelt, siehe #6.764

Da die Zahlen aus der Tabelle 100% zu den multi tables bei 6941 2300 00ED 2620 passen, würde ich SysDCDelay als fix sehen.
SysDCDelay steht auch in der sip Tabelle.

Die anderen Stellen zu belegen wird aber nicht so einfach. Es sind, so wie ich das sehe, mehr Stellen vorhanden, als ich die belegen kann. Ich denke in den multi tables sind noch andere Werte vorhanden.
Wo ich auch meine Schwierigkeiten habe, ist die Reihenfolge in der die einzelnen Optionen stehen könnten. In den PCI registern stehen die meisten Optionen in 32Bit Ordnung (also 4x 8bit offset zu einem 32bit offset). SIS hat für deren Belegung aber in 8Bit gesetzt. Bei den Nvidia sips sehe ich teilweise eine 16Bit Ordnung. Das macht es für mich schwer da irgendetwas zu erkennen.

Generell scheint AMD einiges an Delays vorgesehen zu haben, damit die Daten passend gelesen werden können. Und das sowohl in der Cpu als auch in der Nb. Und wenn ich das richtig verstehe, dann gibt es Delays, die für das verzögerte Senden von Daten zuständig sind als auch solche, die das verzögerte Empfanden kompensieren. Das alles sollte die Effizienz der Datenübertragung auf dem Bus beeinflussen und damit (auch) die Latenz zum Ram. Dadurch das Sockel A den Flaschenhals immer am FSB hat sehen wir das direkt in AIDA.

Ich blicke ehrlich gesagt bei den ganzen delays nicht durch. Das datasheet ist auch nicht immer schlüssig aufgebaut. Teilweise sind darin noch Multis 3.0-4,5 noch drin, die später dann gestrichen wurden.

An dieser Stelle glaube ich, das man mit einem Logic Analyzer den SIP Bus bei Reset des Systems mitschneiden muss, um das gesichert zu ermitteln. AMD hat in der Bus Specification ja die 32 Bits aufgeschlüsselt, die beim Systemstart übertragen werden müssen.

404 Kein Plan von. Klingt aber plausibel .

 

[Tzk]

Mir gehts ähnlich… bei den ganzen Werten verliere ich hin und wieder den Überblick, siehe Sysdcout Delay. Insbesondere die obere Hälfte der Sips verursacht bei mir immer wieder Kopfschmerzen 🙈 Wird mal Zeit für ein großes Diagramm wo alles aufgedröselt ist. Der in deiner Sig verlinkte Post ist dafür Super geeignet und hilft mir regelmäßig weiter 👍

Was wir dennoch tun können ist die erste Hälfte der Multi Tabellen gegeneinander zu testen, um die Auswirkungen zu ermitteln und daraus ggf Einflüsse auf Bandbreite und Stabilität abzuleiten.

 

[digitalbath]

Insbesondere die obere Hälfte der Sips verursacht bei mir immer wieder Kopfschmerzen 🙈 Wird mal Zeit für ein großes Diagramm wo alles aufgedröselt ist.

Der Vorteil am ersten Teil der sips ist ja, das wir viel von Windows aus testen können. Eine Aufschlüsselung könnte tatsächlich helfen.

Der in deiner Sig verlinkte Post ist dafür Super geeignet und hilft mir regelmäßig weiter 👍

Danke. Ich versuche den sip Post aktuel zu halten, damit man das auch an einem Punkt wieder findet.

Was wir dennoch tun können ist die erste Hälfte der Multi Tabellen gegeneinander zu testen, um die Auswirkungen zu ermitteln und daraus ggf Einflüsse auf Bandbreite und Stabilität abzuleiten.

Wäre ein guter Punkt für einen Teil2 der Tests. Ich schau mal, ob ich das schaffe. Da durch das Tauschen der ersten Hälfte die SYSDC Werte angepasst werden müssen, wird das Ganze etwas dauern. Parallel dazu könnte man die Ergebnisse mit dem ersten Teil auf der Vorseit vergleichen. Bandbreite, Geschwindigkeit, OC....

 

[TAGG]

So, hier mal ein paar von meinen boards:

MSI K7N2 Delta-ISLR SN hab ich keine im beispiel format gefunden..

Northbridge: 0401 A1 SPP Ultra 400

Southbridge: 0402 A4 MCP-T



ASRock K7NF2-RAID
SN: 6BM0X1341525

Northbridge: 0512 A1 SPP Ultra 400

Southbridge: 0503 A3 MCP RAID



ASUS A7N8X Deluxe rev 1.04
SN: 32ZG1E4374

Northbridge: 0303 A3 SPP

Southbridge: 0302 A3 MCP-T



ASUS A7N8X-E Deluxe rev 1.01 Board 1
SN: 45MM1Y4379

Northbridge: 0402 A1 SPP Ultra 400

Southbridge: 0352 A4 MCP-T



ASUS A7N8X-E Deluxe rev 1.01 Board 2
SN: 47MM6L7412

Northbridge: 0415 A1 SPP Ultra 400

Southbridge: 0350 A4 MCP-T



Derzeit noch keine max BCLK scores, aber die kommen wenn ich zeit finde

 

[stunned_guy]

Erster Post und das gleich hier. Das schindet Eindruck
Beim MSI ist die Siereinnummer richtig, erkennt man ja auf dem Aufkleber.

Du bist doch der Kollege von HWBot mit gleichem Nickname, der auch fleißig Ergebnisse postet. Dann hat dieser Sockel A Thread sicherlich dort gute Bekanntschaft und einen guten Ruf erzeugt !

 

[digitalbath]

@TAGG
Willkommen! Bin auf Ergebnisse und die mods gespannt!