Falsch geraten, ich sitze öfters bei Bekannten mit IDE-Rechnern um dieses oder jenes Problem zu diskutieren/probieren. Und da sind natürlich auch aktuelle Modelle bei und da finde ich die gleichen Beschränkungen immer noch. Bezüglich Rechnerkonfiguration brauch ich mich nicht zu verstecken, ich hab da genügend praktische Erfahrung. Wenn ich keine Ahnung hätte würde ich mit Sicherheit auch kein vernünftig laufendes SCSI-System hinkriegen...
Wenn das Brennen da so gut klappt empfehle ich mal hinterher einen Blick in die Log-Datei. Da kannst du dann nachlesen wie oft Burn Proof den Rohling retten mußte, nur weil Du nach Beginn des Brennprozesses andere Programme gestartest hast. Burn Proof verhindert ja nicht den Buffer Underrun, kann nur nach Unterbrechung fortsetzen. IDE ist auch mit neuester Hardware nicht multitaskingfähig. SCSI ist mit guter Konfiguration dagegen in der Lage den Buffer Underrun zu verhindern. Wenn der Cacheinhalt unter einen bestimmten Wert fällt macht der Brenner einen Bus reset, gemäß den Regeln von SCSI bekommt dieser dann sofort Befehlsgewalt über den Bus (er übernimmt die Rolle des Hostadapters!) und fordert die Daten des Quelllaufwerkes an, womit die Befehlsgewalt sofort auf dieses übergeht. In der Regel kommt es aber nicht soweit, selbst beim Starten von "dicken" Anwendungen nach Beginn des Brennprozesses fehlen in der Restpufferanzeige grade mal ein, höchstens zwei Kästchen.
Einige weitere Beispiele:
Master und Slave eines IDE-Kanales behindern sich immer gegenseitig: Der Kanal bleibt von der Anforderung des OS bis zur Übertragung des letzten Bits blockiert, auch während der Zugriffszeit. Das andere Laufwerk kann keine Daten übertragen und der Controller kann auch keine Folgeaufträge erteilen. Kommandos gehen bei IDE immer zu Lasten der Transferrate.
Bei SCSI gibt das Laufwerk für die Dauer der Zugriffszeit und des Cachefüllens den Bus frei, andere Geräte können zwischendurch Daten übertragen und der Hostadapter weitere Anforderungen erteilen. Kommandos werden übertragen wenn der Bus ohnehin grade frei ist. Die Datenübertragung erfolgt bei IDE immer erst aus dem Cache und den Rest direkt vom Medium. Bei SCSI nur aus dem Cache, ist der Cacheinhalt übertragen gibt das Laufwerk den Bus frei und meldet sich selbständig ohne zutun des Hostadapters wieder an wenn der Cache wieder voll ist. Wer was wann über den Bus überträgt bestimmen bei SCSI die Geräte, bei IDE der Controller. SCSI ist bei Multitasking immer im Vorteil, weil alle Geräte gleichberechtigt Zugang zum Bus haben. Gleiches gilt für alle gleichzeitig laufenden Lese- und Schreibprozesse, egal ob sie sich auf ein oder mehrere Laufwerke beziehen. SCSI-Laufwerke teilen sich die Bandbreite des Busses, was bei IDE nie passiert, jedes Laufwerk bekommt exklusiv Zugriff, die gesamte Bandbreite wird im Extremfall verschwendet um ein paar kbyte zu übertragen.
Deshalb ist ein U2W-SCSI-System mit 80MB/s Bandbreite effektiv auch schneller als ein UDMA-100-System.
Simples kopieren von Laufwerk zu Laufwerk:
Bei IDE werden die Daten vom Quelllaufwerk über South- und Northbridge ins RAM übertragen und von da zurück bis zum Ziellaufwerk. Das gesamte System ist direkt am Nutzdatentransfer beteiligt. Zudem geht's immer nur in eine Richtung, was die Transferrate halbiert.
Bei SCSI werden die Daten aus dem Cache des Quelllaufwerkes direkt in den Cache des Ziellaufwerkes übertragen. Das System und auch der SCSI-Hostadapter sind nicht am Nutzdatentransfer beteiligt. Man könnte rein theoretisch den Hostadapter nach Auftragserteilung entfernen - der Kopierprozeß läuft unbeeindruckt weiter. Theoretisch wie gesagt, aktuelle Betriebsysteme nehmen solcherlei Attacken übel.
Wie an anderer Stelle schon erwähnt kann eine einzelne SCSI-Platte auch mehrere Anforderungen gleichzeitig ausführen, nicht nur das, sie sucht sich dabei auch noch den kürzesten Weg zwischen allen angeforderten Blöcken. Eine IDE-Platte kann das nicht und muß die von Host vorgegeben Reihenfolge einhalten.
Praktisches Beispiel:
Nehmen wir an es sind gleichzeitig 6 E/A-Prozesse aktiv, wobei die zu lesenden Daten der E/A-Prozesse 1, 3 und 5 am Anfang, und die Daten der E/A-Prozesse 2, 4 und 6 am Ende der Platte liegen. Alle EIDE-Platten führen die E/A-Prozessen in der Reihenfolge ihres Eintreffens aus, also nacheinander 1, 2, 3, 4, 5, 6. Dabei macht die Platte mindestens 5 Full Stroke Zugriffe.
Eine SCSI-Platte holt zunächst alle Daten am Anfang der Platte, und danach alle Daten am Ende der Platte. Oder umgekehrt, abhängig von der Position der Leseköpfe vor Beginn der Ausführung. Sie braucht also nur einen Full Stroke Zugriff. In die Berechnung geht sowohl die Zugriffszeit als auch Latenz, die Dauer einer halben Umdrehung, mit ein. Zugegeben ein extremes Beispiel, aber so funktioniert es nun mal. Grade Windows NT und 2000 lesen Daten in mehreren gleichzeitigen Prozessen, ich bin deshalb der Meinung das diese auf einem IDE-Rechner nichts zu suchen haben, und stehe damit nicht alleine da. Bei SCSI läßt sich die Performance von SCSI zudem noch durch Registry-Einträge steigern. Den meisten Hostadaptern liegen diesbezüglich Informationen bei, beziehungsweise sind bei den Treibern im Internet enthalten.
Schon an diesen Beispielen ist ersichtlich das es mit der Eigenintelligenz bei IDE nicht weit her ist. DMA-Modus und CRC sind die einzigsten Punkte. Ansonsten herrscht Dummheit.
Hast du schon mal darüber nachgedacht das IDE nicht direkt von CD-Rom/DVD booten kann? Gebootet (und auch gelesen) wird mittels ATAPI-Protokoll - und das besteht zu über 70% aus SCSI-Protokoll-Software. Für's CD-Brennen gilt das Gleiche, hier ist zusätzlich ein ASPI-Treiber nötig - ASPI = Advanced SCSI programming interface).
Auch Du kommst also nicht ohne SCSI aus ...
GarfTermy
Markus Klümper
