PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : AGP/PCI fix – Wovon ist das abhängig?


mirp
2004-02-23, 10:31:55
Meine Vermutung war bisher, dass das eine Funktion des Chipsatzes ist. Und das will ich jetzt mal genauer wissen.

Daraus würden sich folgende Fälle ergeben:

Chipsatz beherrscht "AGP/PCI fix" nicht. => Es gibt auch kein Mainboard mit diesem Chipsatz, welches "AGP/PCI fix" anbietet.
Chipsatz beherrscht "AGP/PCI fix". => Es ist abhängig vom Mainboard, ob "AGP/PCI fix" angeboten wird.

Wenn dem so ist, könnte man doch mal eine Liste der Chipsätze aufstellen und danach ordnen, ob die Funktion beherrscht wird.

CrazyIvan
2004-02-23, 10:52:58
AFAIK ist letzteres der Fall. Nicht der Chipsatz muss dies unterstützen, sondern das Mainboard. Im Grunde geht es ja darum, dass man für AGP/PCI einen separaten Taktgeber + Teiler bereitstellt. Daher müsste das eigentlich unabhängig vom benutzten Chipsatz möglich sein.

Oder irre ich?

huha
2004-02-23, 11:50:59
Es könnte zwei Möglichkeiten geben:

Der Teiler für den PCI/AGP-Takt muß ja variabel sein, schon allein deshalb, daß man verschiedene FSBs fahren kann (100 Mhz, 133, 166, 200 etc.)
Jetzt kommt es also nur noch darauf an, inwiefern sich die Teile regeln lassen und wie das geschieht; hier spielt der Chipsatz wahrscheinlich die zentrale Rolle.

-huha

Endorphine
2004-02-23, 12:44:14
Ist vom Aufbau des Chipsatzes abhängig. Das was gemeinhin als "Fix" bzw. "Frequency Lock" bezeichnet wird meint eigentlich die asynchrone Anbindung von PCI-Bus und AGP. Das mindert die Performance und ist für 99,9% aller Anwendendungen unnötig (da es meist nur eine Hand voll Standard FSB-Takte gibt, die es zu unterstützten gilt). Frequenzteiler bzw. -multiplikatoren sind sehr einfach zu realisieren. Asynchron angebundene Controller erfordern dagegen Logik, um beide Seiten zuverlässig ohne Datenstau und starken Durchsatz- und Latenzzeitverlust zu verbinden.

Aufklärung können hier nur Chipsatzdokumentationen bringen. Damit kann man dann definitiv sagen, ob es mit einem Chipsatz möglich ist oder nicht. Alternativ kann man natürlich auch von der praktischen Seite 'rangehen und schauen, ob irgendein Mainboard den Asynchronbetrieb implementiert hat. Wenn sich kein Board findet weiss man dann aber nicht, ob sich die Mainboardhersteller um die Implementierung drücken oder ob der Chipsatz es nicht erlaubt.

HOT@Work
2004-02-23, 14:27:31
Der Chipsatz ist das Problem bei der Sache:

VIA:
Alle bis auf KT/PT880: AGP/PCI Takt ist von FSB bzw. Referenztakt abhängig. Es gibt verschiedene Teiler (bei KT600 bis 1/6 glaub ich). Die 880er und damit wahrscheinlich auch die 890er haben fixen PCI/AGP(falls vorhanden)

NV:
Bei NForce1/2: PCI/AGP fix auf 66/33
Beim NForce3 150 soll der PCI/AGP aus dem Referenztakt errechnet werden (also net fix; bitte korrigieren wenn Falsch!!)
NForce3 250: Glaskugel kaputt

Intel:
Ab 8xx ist der PCI/AGP fix, davor haben sich Boardhersteller wie ABit mit Tricks beholfen.

SIS:
Bei SIS war der FSB erst ansynchron vom Rest (Pentium Chipsätze) danach AFAIK aus Performance- und Preisgründen aber nicht mehr, also auch ne Teilerreglung wie bei VIA.

AMD:
750/760: Teiler
8xxx: keine Ahnung, glaube aber Teiler vom Referenztakt

ALi:
waren die letzten Chipsätze (Athlon, P4) alle asynchron (also fix), bis auf den 1687 der ja bekanntlich ein 8xxx von AMD ist.
Wenn ALi die eigene Chipsatzline konsequent weiterverfolgt, werden die neuen auch fix sein hoffe ich (Glasskugel weiss auch nix :D).

Quasar
2004-02-23, 22:38:36
Original geschrieben von HOT@Work
Intel:
Ab 8xx ist der PCI/AGP fix, davor haben sich Boardhersteller wie ABit mit Tricks beholfen.


Das kann ich direkt schon einschränken:

Gilt nur für xx > 40. Der i840 (und i820, sowie i810 und 815 samt Varianten) hatten noch Teiler (leider - mein P3-S könnte per Multi sicher auch 1,7GHz schaffen. Per FSB habe ich bisher nur 1550MHz probiert.)

Palpatin
2004-02-24, 00:07:55
Beim Nforce 3 ist der AGP fest bei 66MHZ und der PCI wird aus dem Referenztakt gerechnet bei 233 266 und 300 wird dann 1/7 1/8 1/9 Teiler gesetzt. Beim KT800 ist der PCI Teiler im 1/6 und der AGP Teiler immer ein 1/3 des Referenztaktes.

LOCHFRASS
2004-02-24, 01:42:34
Original geschrieben von Quasar
Das kann ich direkt schon einschränken:

Gilt nur für xx > 40. Der i840 (und i820, sowie i810 und 815 samt Varianten) hatten noch Teiler (leider - mein P3-S könnte per Multi sicher auch 1,7GHz schaffen. Per FSB habe ich bisher nur 1550MHz probiert.)

Bei meinem 815er Brett gabs auch Teiler für mehr als 133 MHz, beim BX geht sowas auch, http://lab.mentanpin.net/index_e.htm

Quasar
2004-02-24, 10:00:35
Original geschrieben von LOCHFRASS
Bei meinem 815er Brett gabs auch Teiler für mehr als 133 MHz, beim BX geht sowas auch, http://lab.mentanpin.net/index_e.htm

Teiler != Fix

LOCHFRASS
2004-02-24, 13:40:40
Original geschrieben von Quasar
Teiler != Fix

Der PCI/AGP Fix bei den aktuellen Boards ist auch nicht mehr als Teiler für jede FSB Stufe...

CrazyIvan
2004-02-24, 14:29:07
@ Quasar & Lochfrass

Könnte man nicht für PCI/AGP nen eigenen Taktgeber verwenden? Oder gibt es das Probs bei der Synchronisation bzw. dadurch hervorgerufene hohe Latenzen?

LOCHFRASS
2004-02-24, 16:27:53
Original geschrieben von CrazyIvan
@ Quasar & Lochfrass

Könnte man nicht für PCI/AGP nen eigenen Taktgeber verwenden? Oder gibt es das Probs bei der Synchronisation bzw. dadurch hervorgerufene hohe Latenzen?

Beim BX gehts wohl, das müsste ich mal ausprobieren, Board und CPU sollten wohl leicht zu beschaffen sein. =)

HOT
2004-02-24, 16:35:40
Original geschrieben von LOCHFRASS
Der PCI/AGP Fix bei den aktuellen Boards ist auch nicht mehr als Teiler für jede FSB Stufe...

Das ist nicht korrekt. AGP und PCI wird je nach Chipsatz synchronisiert oder geteilt.
Der NForce2 muss Das Signal erst synchronisieren, bevor es Nutzbar wird, da er den AGP eben asynchron ansteuert.
Diese Techniken gibt es schon ewig, werden aus Kostengründen und oft auch aus Performancegründen von vielen Herstellern nicht verbaut.
VIA z.B. steuert erst ab xT880 in seinen Chipsätzen asynchron den AGP/PCI an, aber auch nur weil Intel und NVidia das "Feature" auch bieten.
Bei SIS ist das wohl sogar konfigurierbar, das war es schon bei den Pentiumchipsätzen. Hier ist es eher eine Sache des MB Herstellers ob asynchron oder net.

HOT
2004-02-24, 16:37:52
Original geschrieben von LOCHFRASS
Beim BX gehts wohl, das müsste ich mal ausprobieren, Board und CPU sollten wohl leicht zu beschaffen sein. =)

Beim BX geht das NUR beim PCI. Der AGP ist es AFAIK nicht möglich gewesen. Abit bot solche lösungen mit BX für 133MHz FSB, aber eben mit 89MHz AGP Takt an.

(del676)
2004-02-27, 08:42:38
also rein theoretisch könnte man ja am Mainboard nen extra taktgeber für agp+pci draufklatschen, obwohl man sich bei den K8T800 chips ned so ganz sicher is, denn laut MSI wollen sie im K8T800 board nen AGP+PCI fix im nächsten Bios integrieren ...

aber man kann ja durch HW modifikationen am PLL (wie die japse das machen) den FSB höher drehen und pci/agp locken

HOT
2004-02-27, 10:28:51
Original geschrieben von Ulukay
also rein theoretisch könnte man ja am Mainboard nen extra taktgeber für agp+pci draufklatschen, obwohl man sich bei den K8T800 chips ned so ganz sicher is, denn laut MSI wollen sie im K8T800 board nen AGP+PCI fix im nächsten Bios integrieren ...

aber man kann ja durch HW modifikationen am PLL (wie die japse das machen) den FSB höher drehen und pci/agp locken

Das nützt dir nix denn der Chipsatz das Signal dann nicht mehr synchronisieren kann, darum geht es doch. Es gabt aber vielleicht noch höhere Referenztaktteiler, die noch nicht implementiert sind, aber von AOpen überlegt werden.

Quasar
2004-02-27, 10:33:19
Original geschrieben von LOCHFRASS
Der PCI/AGP Fix bei den aktuellen Boards ist auch nicht mehr als Teiler für jede FSB Stufe...

Dutzende von nicht-ganzzahligen Teilern? :gruebel:

StefanV
2004-02-27, 11:53:08
Original geschrieben von HOT
Beim BX geht das NUR beim PCI. Der AGP ist es AFAIK nicht möglich gewesen. Abit bot solche lösungen mit BX für 133MHz FSB, aber eben mit 89MHz AGP Takt an.

Nein, LOCHFRASS hat schon recht.

Es gibt einige Seiten im Netz, die sich mit der Asynchronen Taktung des AGPs des BX beschäftigen...

StefanV
2004-02-27, 11:53:37
Original geschrieben von Quasar
Dutzende von nicht-ganzzahligen Teilern? :gruebel:

Nö, die 'Normalen' Teiler, der Rest ist eine BIOS geschichte...

Quasar
2004-02-27, 22:48:57
Ich würde sagen, es ist eine PLL-Geschichte. Wenn das das nicht kann, kann das BIOS können können, was es will - es nützt nix.

PhoenixFG
2004-02-28, 13:44:35
Gibt es eigentlich einen Weg dem BIOS noch einen zusätzlichen Teiler beizubringen?

Ich weiß z.B. dass der PLL auf meinem Mainboard auch einen Teiler 1:6 bereitstellen kann. Das BIOS teilt aber nur bis max. 1:5. Damit laufen beim Anheben des FSB PCI- und AGP-Takt recht schnell aus der Spezifikation raus.

MfG

mirp
2004-03-05, 17:15:11
Wie lässt sich der AGP/PCI-Takt eigentlich auslesen, wenn es nicht im BIOS steht? In den diversen Diagnose-Tools habe ich diese Angabe noch nicht gesehen.

StefanV
2004-03-05, 17:35:50
Original geschrieben von mirp
Wie lässt sich der AGP/PCI-Takt eigentlich auslesen, wenn es nicht im BIOS steht? In den diversen Diagnose-Tools habe ich diese Angabe noch nicht gesehen.

Garnicht, das merkst du erst dann, wenn nicht mehr viel geht ;)

Gast
2004-03-05, 21:05:17
Original geschrieben von PhoenixFG
Gibt es eigentlich einen Weg dem BIOS noch einen zusätzlichen Teiler beizubringen?

Ich weiß z.B. dass der PLL auf meinem Mainboard auch einen Teiler 1:6 bereitstellen kann. Das BIOS teilt aber nur bis max. 1:5. Damit laufen beim Anheben des FSB PCI- und AGP-Takt recht schnell aus der Spezifikation raus.

MfG

Wär das nicht über ein simples BIOS-Update möglich?

haifisch1896
2004-03-05, 21:35:15
Aber erstmal die Register finden.
Beim KT333 gab es ein Board von ? (Hersteller wird noch ergänzt), welches entgegen allen anderen per BIOS einen Teiler 1:6 beherrschte. Vielleicht wurden ja frühe Platinen des jeweiligen Mainboards mit einer PLL ausgerüstet, die diesen Teiler hatten.
Vielleicht würde mein Board (8K3A ohne Plus) das auch unterstützen. Wäre der Hammer.
Gruß,
Hendrik