|
||||
2.1.3 QueuingDisconnect ist nicht alles, was SCSI bietet. Die nächste interessante Möglichkeit zur Leistungssteigerung ist das Command-Queing. Dabei werden mehrere Kommandos an das SCSI-Gerät geschickt, das dann entscheidet, in welcher Reihenfolge die Kommandos abgearbeitet werden. Voraussetzung dazu ist, daß 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 muß 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 Queing 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ückliefern, und muß 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. SCSI - Enträtselt Teil 2 - 8 / 15
|
||||
|