Es freut mich, wenn ich Euch etwas rüber bringen kann. Zwar ist das Thema zu komplex, um es mit ein paar Zeilen füllen zu wollen, aber am zweiten Weihnachtstag bin ich für eine Zugabe über den synchronen bzw. asynchronen Bus gerne bereit:
Der synchrone Bus hat auf einer separaten Taktleitung ein Taktsignal. Es wird von einem Schwingquarz stabilisiert und formt den Zeitrhythmus für alle Vorgänge auf dem Bus. Dieses Taktsignal ist ein symmetrisches Rechtsecksignal mit einer Taktfrequenz
f.
Jenes sich wiederholende Signalstück des Taktsignals (LOW-Phase zuzüglich HIGH-Phase) bildet einen Taktzyklus oder einfach Takt. Ein solcher Takt dauert eine Taktzykluszeit T=1/
f. Bei einem angenommenen FSB von 400 MHz dauert also ein Taktzyklus T= 1/40 hoch 8 = 2,5 Nanosekunden (1 Nanosekunde ist eine milliardstel Sekunde). Dass nicht alle Komponenten dieses Tempo mithalten können, liegt auf der Hand. Allerdings orientieren sich die angeschlossenen Komponenten am Taktsignal und alle Zeitbedingungen sind relativ zu diesem Taktsignal beschrieben. Die "Zeitbedingungen", also das Timing, sind sehr kompliziert. Soweit z.B. festgelegt ist, dass ein Speicherbaustein in der ersten Hälfte des Folgetaktes nach der Datenanforderung durch ein Read-Signal die Daten bereitzuhalten hat, der Speicherbaustein jedoch zu langsam ist, muss die Speichersteuerung einen Wartetakt (Waitstate) einlegen. Dieser Waitstate ist entweder durch ein Signal des Bausteins ausgelöst oder er ist in der Speichersteuerung bereits einprogrammiert.
Da sich die Hersteller von Komponenten an diese Buseigenheiten halten, gibt es von da her keine Probleme, außer die Speichermodule haben ein nicht exaktes Timing (bzw. der User verursacht ein solches durch eine nicht stimmige BIOS-Einstellung).
Aus diesem Grund ist der synchrone Bus auch verbreitet und grundsätzlich stabil.
Doch wozu dann einen asynchronen Bus-Takt?
Ist ein Speichermodul in der Lage, angeforderte Daten nach 4,1 Taktzyklen auszugeben, sind aber 5 Taktzyklen erforderlich, weil jeder Vorgang immer eine ganze Anzahl von Taktzyklen braucht (wenn z.B. durch eine Busspezifikation ein Bus immer drei Zyklen zu je 10ns beim Auslesen eines RAM-Moduls benötigt), würde ein schnelleres RAM-Modul keine Verbesserung bringen, weil das feststehende Busprotokoll dieses RAM-Modul genauso schnell ansteuert, wie das langsamere RAM-Modul.
Durch die Verwendung des asynchronen Busses werden diese Nachteile ausgeglichen, denn der asynchrone Bus verzichtet auf das Taktsignal und arbeitet bei allen Busvorgängen mit Synchronisations und Bestätigungssignalen, den sogenannten
Handshakes.
Bei einem Lesezugriff auf einen Busbaustein legt der Busmaster, das ist die CPU, die Adresse und die Anforderungsignale auf den Bus. Der angesprochene Baustein, der Slavebaustein, erkennt diese Signale und beginnt damit, die abgefragten Daten bereitzustellen. Falls die angefragten Daten vorhanden sind, wird dies vom Baustein durch ein Bestätigungsignal angezeigt. Die CPU liest die Daten und nimmt das Anforderungsignal zurück. Im Gegenzug nimmt der Slavebaustein sein Bestätigungsignal zurück und ist für den nächsten Transfer bereit. Im Gegensatz zum synchronen Bus können alle Bustransfers eine beliebige Zeit in Anspruch nehmen, denn der asynchrone Bus ist ereignisgesteuert (und eben nicht zeitgesteuert wie der synchrone Bus).
Deshalb gibt es beim asynchronen Bus (abgesehen von den Handshake-Signalen) keine Wartezeiten. Daraus folgt, dass ein schnellerer Speicherchip den Bus sofort schneller zum Laufen bringt- und
daraus folgt wiederum (mögen es manche auch nicht hören wollen), dass der asynchrone BUS dem synchronen BUS überlegen ist. Daran ändert auch der zusätzliche Aufwand durch die
Handshakes nichts.
Wer noch etwas über das Verhältnis des RAM/FSB zum Performance-Level lesen möchte, der kuckt hier:
https://www.computerbase.de/forum/t...eme-intel-x38-x48.380113/page-64#post-4620553
