erschienen in: GO64! - Das Magazin für Computerfreaks, Ausgabe 8/2000

Peripheriebusse für Speichermedien - oder der SCSI-vs.-IDE-Glaubenskrieg

Hello World,

Früher schien die Festplattenwelt in Ordnung. SCSI war der angesagte Standard, für das armselige IDE-Interface hatte man bestenfalls Spott übrig: Langsame Übertragungsraten, hohe CPU-Last beim Datentransfer und nur zwei Geräte pro Anschluß.

Heute sieht die Welt anders aus. Das IDE-Interface weist längst ähnliche Übertragungsraten auf wie der aktuelle SCSI-Standard und die Prozessorlast scheint bei Verwendung von SCSI-Geräten stellenweise sogar höher zu liegen. Verkehrte Welt? Unternehmen wir also einen Ausflug in die Computerhistorie.

IDE - die Anfänge

Das Kürzel IDE steht für Integrated Device Electronics. Die Idee bei der Entwicklung dieses Interfaces war, daß Festplatten (an andere Peripheriegeräte dachte man damals noch nicht) die komplette Interface-Elektronik enthalten sollen. Für den Commodore-Anwender ist dies jedoch überhaupt nicht revolutionär, denn intelligente Peripheriegeräte gab es hier von Anfang an. Tatsächlich war dies zur damaligen Zeit jedoch längst nicht Standard. Laufwerke gab es meist nur "roh" und waren lediglich mit einem rudimentären Interface vergleichbar mit einem heutigen PC-Floppyanschluß ausgestattet. Wollte man so ein Laufwerk an den eigenen Rechner anschließen, so war eine zusätzliche Interfacekarte vonnöten. Später wurde diese Karte mit in die Laufwerkselektronik integriert.

Aber warum?

Die Frage ist berechtigt. Bereits damals gab es existierende Profilösungen, sei es nun der von Commodore verwendete IEEE488-Bus oder der im High-End-Bereich verwendete SCSI-Bus, warum also noch einen weiteren Bus? Wie so meist beim "Industriestandard" war wohl der Kostenfaktor ausschlaggebend. Die Commodore-Laufwerke waren beispielsweise immer mit einer eigenen, in manchen Fällen sogat zwei, CPUs ausgestattet und es wurden teure Kommunikationsbausteine benötigt. Die Geschwindigkeit des IEEE488-Bus war indes konzeptionsgemäß eher langsam, da dieser Bus ursprünglich zur Steuerung und Abfrage von Meßgeräten entwickelt wurde.

SCSI, das Small Computer System Interface, war hingegen neu und leistungsfähig - aber ebenfalls teuer. Über die weiteren Gründe läßt sich nur mutmaßen, doch gemessen am simplen IDE-Interfacemodell mag den PC-Entwicklern vielleicht einfach das Protokoll zu aufwendig gewesen sein.

Das IDE-Interface

Was macht das IDE-Interface nun so simpel? Aus Computersicht verhält es sich wie ein beliebiger I/O-Baustein, beispielsweise ein 6526. Auch die Programmierung verhält sich entsprechend: Statusregister lesen, Kontrollregister beschreiben und Daten transferieren. Reserviert für diese Register sind vier Blöcke zu jeweils 8 Adressen, die Selektion geschieht mittels zweier Auswahlsignale (/CS0 und /CS1) sowie dreier Adreßleitungen. Die Anbindung an ein Computersystem ist somit denkbar einfach und auch die Programmierung gestaltet sich hinreichend simpel gemäß dem folgenden Schema:

  1. Warten, bis Gerät bereit (Status abfragen)
  2. Track- und Sektoradresse übertragen
  3. Schreib/Lesebefehl übertragen
  4. Warten bis Daten übertragen bzw. gelesen (Status abfragen)
  5. fertig oder zurück zu (1)
Hier offenbart sich auch, wieso IDE früher als langsam und rechenzeitfressend verschrieen war: Der Computer wartete die meiste Zeit auf eine Bereitmeldung bzw. ausstehende Daten (busy waiting). Dieses Verfahren ist PC-Benutzern auch als PIO-Mode bekannt, das Kürzel steht hierbei für polled I/O.

Zwar wurden PCs über die Zeit immer schneller (und somit auch die Übertragungsraten der diversen PIO-Modes), doch das grundsätzliche Verfahren blieb: Die CPU mußte stets auf die Festplatte warten.

Von PIO zu DMA

DMA (Direct Memory Access) ist spätestens seit dem Amiga als die Lösung zur Beschleunigung eines Computersystems bekannt: Warum soll die CPU mit der simplen Aufgabe beschäftigt werden, Daten aus dem Speicher zu einem Peripheriegerät oder -baustein zu schaufeln? Wäre es nicht sinnvoller, wenn man diesem lediglich mitteilen könnte, wieviel Daten von wo nach wo transferiert werden müssen - den Rest erledigt es von alleine?

Im Prinzip ja, aber... Anders als der C64 verfügen PCs über zwei Bussysteme: Einen Speicherbus, welcher mit Prozessorgeschwindigkeit läuft (da die Speicherzugriffszeit leider nicht mit der Prozessorgeschwindigkeit gleichgezogen hat, ist es heute allerdings nur noch ein Bruchteil, nämlich die sogenannte Front Side Bus-Geschwindigkeit) und einen langsamen Peripheriebus (ISA von Industry Standard Architecture) mit 8MHz. Damals dachte noch niemand daran, daß Prozessoren einmal mit mehreren zehn MHz getaktet werden würden - und so erwies sich der ISA-Bus zunehmend als Flaschenhals. Ob nun die CPU selbst auf die Daten wartete oder durch einen langsamen DMA-Zugriff ausgebremst wurde, war da eher nebensächlich. Warum also die Dinge verkomplizieren? Außerdem verfügte man lange nicht über die heutigen Speichermengen - und ob nun ein MB in 1s oder 0.5s geladen wurde, wen kümmerte das schon? Und während andere Hersteller schon mit Multitasking-Maschinen aufwarteten, in denen das Warten auf die Festplatte sich als ständiges Ruckeln der anderen Tasks bemerkbar gemacht hätte, war man auf PCs noch mit Singletask-Betriebssystemen selig. Wozu also der Aufwand?

Mit der Einführung schnellerer Peripheriebusse, immer größerem Hauptspeicher und echt multitasking-fähigen Betriebssystemen war diese Frage jedoch auf einmal sehr akut. Heute verfügt jeder IDE-Controller über einen DMA-Übertragungsmodus, der SCSI-Geschwindigkeiten in nichts nachsteht.

Warum eigentlich dann überhaupt SCSI?

Die Frage wird meist von Leuten gestellt, welche nur über einen Rechner verfügen und auch nie an die Grenzen der PC-Gehäusekapazität stoßen. Konzeptionell unterscheiden sich SCSI und IDE dadurch, daß SCSI als externes I/O-Bussystem zur universellen Anwendung entworfen wurde. IDE hingegen ist nüchtern betrachtet lediglich eine besondere Anschlußart für Festplattenspeicher an den Prozessorbus. Aus diesem Grund sind die Kabellängen bei IDE sehr kritisch und dürfen eine bestimmte Länge keinesfalls überschreiten und es lassen sich an ein IDE-Interface nur Festplatten und artverwandte Speicher (z.B. CDROM, DVD) anschließen.

SCSI hingegen ist ein geräteunabhängiger Peripheriebus. Welches Gerät hieran angeschlossen ist, ist unerheblich, da Interface und Übertragungsprotokoll nicht auf eine bestimmte Geräteklasse zugeschnitten sind. Zudem lassen sich - je nach SCSI-Version - bis zu 7 bzw. 15 Geräte anschließen, bei IDE sind es lediglich zwei. Der Betrieb der zwei IDE-Geräte erfolgt jedoch in wechselseitigem Ausschluß, wohingegen bei SCSI ein überlappender Betrieb möglich ist. Doch der für SCSI-Verwender wichtigste Grund ist die externe Natur von SCSI: Geräte können bequem von einem Rechner ab- und an einen anderen angesteckt werden, ja es ist sogar ein Mischbetrieb möglich - und so ist insbesondere in Musikstudios öfter zu beobachten, daß Rechner, Sampler und Festplatten bzw. CDROM-Laufwerke an einem einzigen Strang hängen und wechselweise aufeinander zugreifen. Dieses Kunststück ist mit IDE nicht möglich.

Fazit?

Für die meisten Anwendungen reicht sicherlich das heutige EIDE-Interface mit seinen schnellen DMA-Transfermethoden aus. Und angesichts des Mehrpreises für SCSI-Laufwerke überlegt man sich sehr schnell, ob sich das CDROM-Laufwerk für den Zweitrechner vielleicht nicht alleine aus den Differenzkosten finanzieren läßt. Zudem ist die heutige Welt im Gegensatz zu der vor 10 bzw. 20 Jahren nicht nur absolut PC-dominiert, auch sind Netzwerktechnologien entsprechend schnell und allgemein verfügbar, so daß SCSI als "Datenaustauschmedium" zwischen unterschiedlichen Rechnern bzw. Rechnerfamilien weitgehend ausgedient hat.

Anders sieht es aus in Anwendungsgebieten mit speziellen Anforderungen, so z.B. der redundanten Datenhaltung (RAID) oder in besonderen Umfeldern wie das erwähnte Beispiel des Musikstudios. Auch aus dem Hochleistungsbereich ist SCSI nicht wegzudenken und wartet heutzutage mit einer Datenübertragungsrate von bis zu 320MB/s auf. Im Heimbereich sind solche Datenaufkommen jedoch (noch) eher die Ausnahme.