SCSI enträtselt (2)

Im ersten Teil haben wir den prinzipiellen Ablauf der Kommunikation auf dem SCSI-Bus gesehen. Wer das aufmerksam gelesen hat, wird sich eventuell fragen, was der ganze Aufwand bei SCSI soll. Auch ohne Arbitrierung, Identifikation, Messages und das ganze Brimborium kann man doch auf Geräte zugreifen, wie man ja z.B. beim IDE-Port sehen kann.

Wenn Sie nun diesen Artikel in Ruhe lesen und ihn auch einigermaßen verstanden haben (ganz ruhig, das ist halb so schwierig), dann wissen Sie wirklich, was mit SCSI los ist, und vor allem, was damit möglich ist.

Solange man ein simples System hat wie zum Beispiel DOS oder auch TOS ohne Multitasking, stimmt das auch, aber bei leistungsfähigeren Systemen sieht das anders aus.

Dazu betrachten wir mal den Betrieb mit mehreren Rechnern oder mit mehreren Prozessen, die auf die Geräte zugreifen sollen.

2.1 Leistungssteigerung durch gute Busnutzung

2.1.1 Mehrere Initiatoren

Initiatoren sind SCSI-Geräte, die eine Aktion auf dem SCSI-Bus auslösen. Normalerweise handelt es sich dabei um die Computer auf dem SCSI-Bus, es können aber auch andere Geräte sein, zum Beispiel ein Streamer, der ein Copy-Kommando abarbeitet. Allgemein spricht man daher eben nicht von Computern, sondern von Initiatoren.

Spricht ein Gerät ein anderes an, so ist das angesprochene Gerät das Target, das Ziel der Ansprache.

Für die meisten Benutzer dürfte die Anwendung interessant sein, mehrere Computer gemeinsam auf einem SCSI-Bus zu betreiben. Der Sinn der Sache ist dabei, die SCSI-Geräte für beide Rechner benutzen zu können, ohne diese Geräte doppelt kaufen zu müssen.

Im wesentlichen geht es dabei um Streamer, Scanner und CD-ROMs. Festplatten kann man natürlich auch von beiden Rechnern aus benutzen, aber dabei treten logische Probleme auf, die der Anwender beachten muss.

Beim Zugriff auf Festplatten werden einige Daten gecachet, d.h. Daten, die bereits von der Platte gelesen wurden, und auf die erneut zugegriffen wird, werden im Speicher gehalten, und bei einem erneuten Zugriff müssen diese Daten nicht neu eingelesen werden. Wenn nun zwei Rechner auf die gleiche Partition auf der gleichen Festplatte zugreifen, führt dies unweigerlich zu einer Zerstörung der Daten auf der Platte, Verzeichnisse werden fehlerhaft zurückgeschrieben, weil der eine Rechner eine Änderung gemacht hat, von der der andere nichts weiß. Solange man aber immer nur mit einem Rechner zugreift oder jeder seine eigene Festplatte hat und die des anderen in Ruhe läßt, gibt es dieses Problem nicht.

Genauso gilt dies natürlich auch bei anderen Geräten, man kann logischerweise nicht von beiden Rechnern aus gleichzeitig ein Backup auf den Streamer machen.

Aber um zu SCSI zurückzukommen: Dank des SCSI-Protokolls kann ohne Probleme der eine Rechner auf seiner Festplatte arbeiten und quasi gleichzeitig der andere Rechner auf der seinigen und dabei zum Beispiel ein Backup auf den Streamer durchführen.

Zunächst ist es ja so, dass mehrere Rechner gleichzeitig den SCSI-Bus beanspruchen. Damit es dabei nicht zu Problemen kommt, gibt es wie im ersten Teil des Artikels bereits erklärt, die Arbitrierung. Die Arbitrierung ist aber dabei nicht alles. Zwar reicht das bereits aus, um einen störungsfreien Betrieb zu erhalten, aber die Leistung des Systems ist dabei nicht optimal. Betrachten wir mal den genannten Fall des Backups auf einen Streamer. Rechner A sei der Rechner, der Daten von einer CD-ROM auf seine Festplatte kopiert, und Rechner B schreibt gerade ein Backup auf den Streamer.

SCSI unterfordert?

CD-ROM und Streamer sind beides Geräte, die ihre Daten relativ langsam vom Medium lesen oder darauf kopieren. Relativ langsam heißt hier, dass die Daten wesentlich schneller über den SCSI-Bus transportiert werden können. Betrachten wir einen etwas moderneren SCSI-Bus mit 8 Bit Breite und FAST-SCSI, so können die Daten mit bis zu 20MB/sec übertragen werden, während das CD-ROM mit etwa 1,5 MB/sec die Daten lesen kann und der Streamer mit ca 200 kB/sec. Dadurch würde der Bus unnötig belegt, wenn man Daten anfordert und der Bus bleibt solange belegt, bis die Daten komplett geliefert wurden.

Um diese unnötige Verzögerung zu vermeiden, gibt es die Möglichkeit zum Disconnect. Dabei gibt das Target den Bus frei, bis es die Daten überhaupt vom Medium gelesen hat, und meldet sich dann beim Initiator zurück, um die Übertragung auszuführen.

Der Ablauf wird dabei über Messages ausgeführt. Zunächst musste vom Initiator bei der Übertragung des Kommandos

ATN gesetzt werden, um dem Target anzuzeigen, dass man eine Message - heißt ja eigentlich Nachricht, aber schließlich geht es hier um SCSI - abgeben möchte (s. SCSI-enträtselt, Teil 1) . In der daraufhin vom Target eingeleiteten Message-Out-Phase verschickt der Initiator ein Message-Byte mit einer Identify-Message.

Bit 7 6 5 4 3 2 l 0

Identify DiscPriv LUNTAR Reserved Reserved LUNTRN

Dabei ist das Bit 7 gesetzt, was kenntlich macht, dass es sich bei der Message um 'identify' handelt. Je nach dem, ob Bit 6 gesetzt ist oder nicht, teilt der Initiator mit, dass das Gerät einen Disconnect ausführen darf, falls es dies für sinnvoll hält.

Danach kann es halt passieren, dass das Target irgendwann eine Message-In-Phase einläutet und darin dem Initiator mitteilt, dass es einen Disconnect ausführen möchte (Messagebyte 04h). Wenn der Initiator nichts dagegen hat (er könnte mit einer sofortigen Messagephase und der Antwort-Message 'MESSAGE-REJECT' den Disconnect ablehnen), wird der Bus daraufhin freigegeben, und irgendwann wird sich das Gerät mit einem Reconnect zurückmelden. Der Reconnect läuft dann genauso wie eine komplette Selektion eines Initiators an ein Target, also mit Arbi-trierung um den Bus und anschließender Selektion des Initiators durch das Target. Obwohl hier nun die Selektion vom Target durchgeführt wird, wird das Target jetzt nicht als Initiator bezeichnet, um keine Verwirrung entstehen zu lassen. Sonst müßte man ja immer beachten, wer nun einen Reconnect durchgeführt hat.

Wann denn nun?

Eine kleine Frage am Rande ist natürlich dabei das Kriterium, wann das Target einen Disconnect und wann es einen Reconnect durchführt. Oben hatte ich das noch als 'falls es das für sinnvoll hält' abgetan. Dazu gibt es natürlich (wer hätte jetzt etwas anderes erwartet) eine Möglichkeit, dies bei dem Gerät zu erfragen oder auch einzustellen.

Dazu gibt es eine Parameterseite - man nennt das 'mode page' - die mit dem Kommando 'Mode Sense' gelesen und mit 'Mode Select' geändert werden kann.

Im wesentlichen gibt es dort zwei Dinge, die die Disconnect und Reconnect-Bereit-schaft steuern, zum einen ist es eine Angabe für den Füllungsgrad der Puffer auf der Platte (das Plattencache), wann jeweils ein Reconnect beim Schreiben (die buffer empty ratio) oder ein Reconnect beim Lesen (buffer füll ratio) ausgeführt werden soll. Als zweites gibt es eine Grenze, die angibt, wie lange der Bus belegt bleiben darf, ohne dass Daten über den Bus transportiert werden. Wird diese Zeit überschritten, führt das Target ebenfalls einen Disconnect aus.

Die komplette Erklärung entnehmen sie am besten der SCSI-2, Abschnitt 8.3.3.2 Disconnect-Reconnect page.

Es besteht übrigens auch für den Initiator die Möglichkeit, von sich aus einen Disconnect einzuleiten, dazu muss er ATN setzen und in der daraufhin folgenden Message-Out-Phase die Message DISCONNECT verschicken.

So, und nun machen wir am bes'ten eine kurze Pause und denken mal darüber nach, was uns das denn bringt. Falls Sie das nun nach der Erklärung noch nicht raus haben, sollten sie den bisherigen Teil des Artikels vielleicht nochmals lesen. Alternativ kann ich es natürlich auch erklären.

Na, noch nicht klar?

Ok, der Sinn der Sache ist natürlich, dass beide Geräte nur soviel den SCSI-Bus benutzen, wie nötig ist. Bei dem Beispiel eines Streamers und eines CD-ROM haben wir eine insgesamt zu übertragende Datenmenge von etwa 1,7 MB/sec. Ein 'normaler' SCSI-Bus kann aber schon 5 MB/sec übertragen. Würde der Bus dabei permanent belegt, hätte man eine erheblich geringere Leistung beim Zugriff auf die Geräte.

2.1.2 Mehrere Tasks

Im Prinzip sieht es genauso aus, wenn man mit mehreren Programmen von einem Rechner aus auf die Geräte zugreifen möchte. Um das zu verallgemeinern, betrachten wir jedoch nicht unbedingt Programme, sondern Tasks, den Grund werden wir später noch sehen.

Stellen Sie sich vor, ein Programm kopiert gerade Daten von der CD auf die Festplatte und ein anderes möchte gerne Daten von der Festplatte lesen. Die Situation ist die gleiche wie bei mehreren Rechnern auf dem SCSI-Bus, nur dass die Programmierung etwas schwieriger ist. Hierbei muss eben der SCSI-Treiber dafür sorgen, dass ein zweites Programm erst dann auf die SCSI-Schnittstelle zugreift, wenn das erste Programm fertig ist oder eben gerade ein Disconnect aufgetreten ist.

Solange das CD-ROM die Daten noch nicht in seinem Puffer hat, kann das andere Programm weiterhin Daten lesen und weiterarbeiten. Bei Betriebssystemen, die dies wirklich nutzen können, ist der Unterschied frappierend. Ein sehr gutes Beispiel dafür ist Linux, man merkt in der Task, die auf die Festplatte zugreift fast gar nicht, dass jemand anderes da auch noch auf dem Bus arbeitet. Eine viel gestellte Frage zu SCSI ist aus diesem und dem vorhergehenden Abschnitt auch einfach zu beantworten: Wozu werden SCSI-Geräte unter anderem mit ihrer maximalen Transfergeschwindigkeit auf dem SCSI-Bus angegeben? Liest man bei einem CD-ROM davon, dass es bis zu 20 MB/sec übertragen kann, denkt man doch zunächst, dass dies keine Vorteile bringt, können die schnellsten CD-Laufwerke doch gerade 3 MB pro Sekunde von der CD lesen. Angesichts der Tatsache aber, dass man aufgrund der kürzen Übertragungszeiten den Bus länger freigeben kann, ist der Sinn einer solchen Angelegenheit klar.

Wer kann's?

Leider haben wir auf dem Atari bisher nicht die Möglichkeit, dies wirklich auszunutzen. Prinzipiell bietet Magic zwar die Möglichkeit dazu, aber bisher ist es nicht nutzbar. Wie beim vielbeschworenen Hintergrundtransfer - der übrigens nur geringe Vorteile bietet - kann man den Disconnect benutzen, um während des Disconnect Rechenzeit an andere Programme freizustellen. Vom Disconnect bis zum Reconnect kann man immerhin Zeit abgeben, aber einen vollen Disconnect, währenddessen andere Programme auf andere Geräte zugreifen können, gibt es leider noch nicht. Immerhin merkt man dabei, dass man zum Beispiel während eines längeren Kopiervorganges von einer CD in anderen Programmen weiterarbeiten kann, aber mehr geht leider noch nicht. Einen Teil kann man sich aber nutzbar machen, GEMAR kann zum Beispiel einen getrennten Thread für das Schreiben auf den Streamer benutzen. Dabei merkt man den Vorteil deutlich, wenn man den Streamer an einem anderen Bus hat als die Festplatte, von der die Daten kommen. Es kann daher sinnvoll sein, ein langsameres Gerät wie den Streamer oder das CD-ROM auf den ACSI-Bus zu legen, während die Festplatten an SCSI angeschlossen sind.

2.1.3 Queuing

Disconnect ist nicht alles, was SCSI bietet. Die nächste interessante Möglichkeit zur Leistungssteigerung ist das Command-Queuing. Dabei werden mehrere Kommandos an das SCSI-Gerät geschickt, das dann entscheidet, in welcher Reihenfolge die Kommandos abgearbeitet werden.

Voraussetzung dazu ist, dass ein Disconnect aufgetreten ist. Währenddessen ist ja der Bus frei, und statt eines Kommandos an ein anderes Gerät kann bereits das nächste Kommando abgeschickt werden. Das SCSI-Gerät kann dann entscheiden, in welcher Reihenfolge die aufgelaufenen Kommandos bearbeitet werden.

Um den Zusammenhang zwischen den Kommandos herzustellen - man muss ja wissen, zu welchem der laufenden Kommandos ein Reconnect gehört - werden ebenfalls Messages benutzt. Dazu bezeichnet der Initiator nach der Identify-Message, die ja im unmittelbaren Anschluß an die Kommando-Übertragung versandt wird, mit einer weiteren Message das laufende Kommando mit einer eindeutigen Nummer. Diese Nummer bezeichnet den laufenden Kontakt - man nennt das Nexus -, um einen eindeutigen Bezug herstellen zu können.

Nach einem Reconnect meldet das Target wiederum diese Nummer, um den Nexus zu identifizieren, mit dem der Betrieb jetzt weitergehen soll. Was das Target aus dem Queuing macht, ist ihm überlassen. Eine denkbare Optimierung ist zum Beispiel zwei SCSI-Zugriffe auf die gleichen Blöcke der Festplatte.

In diesem Fall kann das Gerät die gleichen Daten an beide Zugriffe zurück liefern und muss sie nur einmal vom Medium lesen. Bei einem Zugriff, der mehr Daten übertragen soll, als in das Cache des Gerätes passen, spart es erhebliche Zeit, die Daten jeweils in den Puffer zu lesen und dann zweimal mit voller Geschwindigkeit, die der Bus hergibt, an die zwei laufenden Zugriffe zu übertragen.

Selbstverständlich könnte man dies auch im Treiber durchführen, aber dort wäre es logisch erheblich schwieriger unterzubringen, da SCSI-Kernroutinen normalerweise nichts über die verschiedenen Geräte und ihre Verhaltensweisen wissen. Eine Festplatte und ein CD-ROM haben da zum Beispiel normalerweise erheblich unterschiedliche Datenaufbauten, was zu unterschiedlichen Strategien des Caching führen kann. Das Gerät dagegen weiß schließlich am allerbesten, was es macht und wie es aufgebaut ist, kann also besser handeln.

2.2 Andere Messages

2.2.1 BUS DEVICE RESET

Um ein Gerät einzeln zurückzusetzen, ohne das andere Geräte davon betroffen sind, wie es beim Setzen der Reset-Lei-tung auf dem SCSI-Bus ist, kann man eine RESET-Message an ein Gerät versenden.

Das Gerät verfährt dann, als hätte es einen 'har reset' erhalten, verwirft alle laufenden Transfers, Command Queues, Geräte-Reservierungen, Konfigurationen und was sonst noch so ansteht.

Außerdem liefert das Gerät dann beim nächsten Zugriff 'Unit Attention', damit alle erfahren, dass der Zustand des Gerätes nicht mehr gültig ist.

2.2.2 Abort

Aus verschiedenen Gründen ist es sinnvoll, ein laufendes Kommando abbrechen zu können. Ein wesentlicher Grund wäre zum Beispiel, dass man vom Initiator aus einen präventiven Lesezugriff machen möchte, um maximale Datenraten zu erreichen. Dabei würde ein Treiber mehr Daten von der Platte anfordern, als eigentlich ursprünglich benötigt werden. Der Grund dafür ist die Erwartung, dass die Daten, die den ursprünglich angeforderten folgen, wahrscheinlich in Kürze auch angefordert werden. Ein gutes Beispiel dafür sind Harddiskrecorder.

Dabei ist normalerweise davon auszugehen, dass die Daten auf der Festplatte komplett Sektor für Sektor benötigt werden. Damit der SCSI-Overhead, der durch Arbitrierung, Selektion, Kommandoübertragung und den ganzen Rattenschwanz zusammenkommt, nicht einen so hohen Anteil an der Übertragimgsdauer hat, werden bei solchen Geräten immer sehr große Datenmengen angefordert.

Falls dann jedoch dies plötzlich nicht eintritt, zum Beispiel, weil der Anwender auf einmal am Jogshuffle rumdreht (dieser Vorwärts-rückwärts-Hebel zum Suchen einer Musikposition) stellt sich ja unerwarteterweise heraus, dass die angeforderten Daten gar nicht benötigt werden, aber dafür ganz andere.

Um nicht die Restzeit des laufenden Kommandos abwarten zu müssen, bricht man einfach das laufende Kommando ab, indem man eine ABORT-Nachricht an die Festplatte versendet. Die Platte führt das laufende Kommando nicht zu Ende, und man kann das neue Kommando absetzen.

Mit ABORT kann man so natürlich auch laufende Kommandos abbrechen, die sonst nicht abbrechbar erscheinen, zum Beispiel das Formatieren einer Festplatte.

Ein häufig anzutreffender Aberglaube betrifft die Vermutung, dass auf einem weiten SCSI-Bus - also 16 oder 32 Bit breit -bereits ein vorhandenes 8-Bit-Gerät die weiten Transfers der weiten Geräte unterbindet.

Dem ist nicht so, weil ein weiter Transfer erst dann durchgeführt wird, wenn einer der beiden Teilnehmer einen weiten Transfer anfordert. Dazu wird einfach die Message WIDE DATA TRANSFER REQUEST (WDTR) verschickt, die dann entweder akzeptiert wird, indem mit einer entsprechenden WDTR-Message geantwortet, oder mit der Message MESSAGE REJECT abgelehnt wird.

WIDE DATA TRANSFER

Der erste, der die Nachricht überträgt, meldet dabei seine maximale Transferweite, und der Antwortende meldete seine Weite, jedoch maximal die, die vom ersten gemeldet wurde. Die zulässige Breite ist damit ausgehandelt und kann bis auf weiteres benutzt werden.

Damit diese Nachricht nicht jedesmal übertragen werden muss, gilt sie solange als ausgehandelt, bis sie ungültig wird (ach was).

Ungültig wird dieser Zustand durch

1. einen Hard Reset (Setzen der Resetleitung auf dem Bus)

2. ein Device Reset (per Message BUS DEVICE RESET)

3. einen Power On-Zyklus (also Ab- und Anschalten eines der Geräte).

Damit kann man also auch ein Wide-SCSI-Gerät ohne Probleme an einen 8-Bit-Bus anschließen. Da die Anforderung nicht bestätigt wird, wird eben nur mit 8 Bit Breite übertragen.

Dieser Wert wird übrigens für jedes Gerät getrennt ausgehandelt, damit immer zwei Geräte miteinander das maximal Mögliche nutzen und nicht ein langsames Gerät alle anderen ausbremst.

2.2.4 SYNCHRONOUS DATA TRANSFER REQUEST

Ähnlich wie bei der WDTR-Message geht es bei der SYNCHRONOUS DATA TRANSFER REQUEST (SDTR) Message um das Aushandeln maximaler synchroner Transferraten.

Dabei handeln die Geräte eben aus, mit welcher synchronen Rate die Daten übertragen werden können.

Genauso wie bei WDTR gilt diese Aushandlung solange, bis einer der genannten Fälle die Absprache ungültig macht.

2.3 Verschiedenes

SCSI ist zu komplex, um es in einem Artikel komplett auszubreiten. Nachdem man die Grundzüge verstanden hat - ich hoffe, das ist jetzt so - ist es jedoch so, dass man die auftretenden Fragen problemlos anhand der Norm beantworten kann.

Einige Themen, die jedoch immer wieder aufkommen, will ich jedoch noch in loser Sammlung behandeln.

2.3.1 Unit Attention

Immer wieder stolpern Anwender über die Frage, was 'Unit Attention' bedeutet bzw. was mit einem Jumper einer Festplatte zu machen ist, mit dem man 'Unit Attention' abschalten kann.

Im wesentlichen ist Unit Attention nur ein Status, der eine Gruppe von bestimmten Zuständen zusammenfaßt. Prinzipiell liefert jedes Gerät nach eine Zugriff ein Status-Byte, das entweder besagt, dass alles in Ordnung ist oder dass ein Fehler aufgetreten ist. Das Bit 1 im Status bedeutet dabei 'Check Condition', man soll also nachfragen, was wohl los ist.

Dazu wird das Kommando 'Request Sense' benutzt, das eine recht genau aufgeschlüsselte Fehlermeldung liefert. Darin steht nun zunächst, dass es sich um Unit Attention handelt sowie eine weitergehende Information über den Grund dafür. Üblich sind dabei eben, dass das Gerät gerade eingeschaltet wurde, oder dass ein Reset auftrat, oder dass ein Medium gewechselt wurde (wenn es ein wechselbares Medium ist). Eine Änderung der Laufwerksparameter, wie sie mittels Mode Select möglich ist, führt ebenfalls dazu.

Im allgemeinen handelt es sich also um Fehlermeldungen, die mit irgendwelchen Zustandsänderungen des Gerätes zusammenhängen.

Für einen Treiber ist dies wichtig, weil damit alle Absprachen mit dem Gerät neu erfolgen müssen. Für Wechselplatten muss eben die neue Partitionsstruktur eingelesen werden, bei Geräten, mit denen synchrone oder weite Transfers abgehandelt waren, müssen diese erneuert werden.

Für Atari-Anwender ist dies insofern interessant, als ein Gerät mit eingeschalteter Unit Attention auf Reset und 'Power On' erst mit einem TOS ab 2.06 bzw. 3.06 gebootet werden kann. Dies liegt daran, dass ältere Versionen von TOS nur einen Versuch machen, von einem Gerät zu booten. Schlägt dieser fehl (eben durch die Unit Attention), wurde das Gerät als nicht bootbar eingestuft. Neuere TOS-Versionen machen dann einfach einen zweiten Versuch, der dann auch problemlos klappt.

Übrigens werden Fehlermeldungen immer an alle Initiatoren gemeldet, die von dieser Meldung betroffen sind. Dies ist auch ein Grund, warum Identifikation bei der Selektion Pflicht ist (siehe Teil l dieses Artikels), denn das Gerät muss wissen, an wen die Meldung bereits geliefert wurde. Fehler, die einen Zugriff betreffen -zum Beispiel ein Lesefehler - werden nur an denjenigen gemeldet, der den Fehler ausgelöst hat.

2.3.2 Prioritäten

Bei der Vergabe des Busses in der Arbi-trierungsphase haben die Geräte ja Prioritäten, die der ID des Gerätes entsprechen (s. Teil 1). Ein sinnvoller Feintrimm der Leistung des SCSI-Busses ist daher die sinnvolle Vergabe der SCSI-Ids.

Im allgemeinen braucht man darum keine Sorge zu tragen, in besonderen Fällen kann es sich jedoch lohnen.

Benutzt man zum Beispiel einen CD-Brenner in einem System mit echt genutzten Disconnects, dass also andere Tasks während des Disconnect den Bus benutzen können, ist es sinnvoll, dem Brenner eine höhere SCSI-Id zu geben als dem Host.

Der CD-Brenner gibt nämlich den Bus per Disconnect frei, solange er genügend Daten im Puffer hat. Während der Bus frei ist, kann ein Thread des Brennvorganges - normalerweise handelt es sich um getrennte Threads für das Schreiben und das Einlesen der Daten - weitere Daten von der Platte lesen und zum Brennen aufbereiten.

Will nun der Brenner einen Reconnect durchführen und gleichzeitig der Rechner weitere Daten sammeln - oder auch ein anderes Programm auf die Platte zugreifen - gewinnt der Rechner mit der höheren ID den Bus, womit der Brenner warten muss, bis der Bus wieder frei ist. Zwar führt dies nicht sofort zu einem 'Buffer Underrun', aber damit wird immerhin das Risiko erhöht. In kritischen Fällen, in denen man knapp an der Grenze liegt, kann es ausreichen, den Brenner auf eine höhere ID zu legen als den Hostadapter. Mit Sicherheit führt das nicht dazu, dass ein System, mit dem man kaum schafft, CDs zu brennen, auf einmal ohne Probleme durchkommt, aber immerhin ist es ein Sicherheitsgewinn. Tests beim Brennen von CDs mit gleichzeitig starker Belastung des SCSI-Bus zeigen eindeutig diese Besserung, leider ist der Grenzzustand jedoch nur sehr schwierig herbeizuführen, daher kann man es nicht so einfach mit einem kurzen Test nachvollziehen.

2.4 Was bringt's?

Auf dem Atari haben wir leider von einigen der Möglichkeiten keinen Nutzen. Disconnect und dessen Vorteile bei mehreren Programmen können wir genauso wenig nutzen wie Command-Queuing.

SCSI wird uns noch lange begleiten, solange wir es nur wollen. Natürlich kann ich mir die nächstbeste Billig-DOSe kaufen, und dabei nur IDE verwenden, aber wer das macht, besonders im Hinblick auf Leistungsfähigeres als Windows 95, vergibt halt einfach einige Vorteile, die er sonst hätte.

Insbesondere bei der Betrachtung der wirklich leckeren Features, die andere Systeme haben - z.B. RAID 0 unter NT -kann man schnell erkennen, welche Vorteile SCSI bietet.

Jeder darf Leistung verschenken, soviel er will, aber ich will einfach nicht. Und deswegen kommt mir nichts anderes als SCSI ins Haus, jedenfalls nicht für die primären Geräte.

Steffen Engel

---

---