Aktuelles

[Sammelthread] Sockel-A (462) - AMD Athlon / XP / XP-M / MP

Tzk

Ich Horst
Mitglied seit
13.02.2006
Beiträge
18.823
Ort
Koblenz
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.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

digitalbath

Mr. Oldschool-Bios
Mitglied seit
04.05.2008
Beiträge
2.453
Ort
Moers
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

Neuling
Mitglied seit
17.01.2022
Beiträge
1
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 :)
 
Zuletzt bearbeitet:

stunned_guy

Moderator , Mr. San Diego, Bulldozer
Hardwareluxx Team
Mitglied seit
17.10.2005
Beiträge
25.994
Ort
Chemnitz
Erster Post und das gleich hier. Das schindet Eindruck :d
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

Mr. Oldschool-Bios
Mitglied seit
04.05.2008
Beiträge
2.453
Ort
Moers
@TAGG
Willkommen! Bin auf Ergebnisse und die mods gespannt!
 
  • Danke
Reaktionen: Tzk

Tzk

Ich Horst
Mitglied seit
13.02.2006
Beiträge
18.823
Ort
Koblenz
Herzlich willkommen bei den Sockel A Bekloppten, @TAGG :bigok:

Bei deinen Boards sollte gutes Material dabei sein, die beiden Asus -E Deluxe und das MSI sehen rein von der Chipsatzwoche vielversprechend aus.
 

Tzk

Ich Horst
Mitglied seit
13.02.2006
Beiträge
18.823
Ort
Koblenz
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.

404 :fresse: Kein Plan von. Klingt aber plausibel .
Um nochmal auf den SIP Kram zurückzukommen (Bus Spec, S.140ff):
The system sends the processor its initialization state in a serial packet using the Serial Initialization Packet (SIP) protocol.
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
Mitglied seit
04.05.2008
Beiträge
2.453
Ort
Moers
@Tzk
Die einzelnen Signale werden zum Glück am Angang kurz erklärt.

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...
Ich denke mal, dass die Delays auch dazu da sind, damit die Datenübertragung auch zur richtigen Zeit startet? Systemtakt --> CPU Takt ?

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.
Ja, genau das meine ich.

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.
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?
 
  • Danke
Reaktionen: Tzk

Ähnliche Themen

Oben Unten