Hallo zusammen!
Vorab herzlichen Dank an _Quax und #felix#, die mir in diesem Thread weiter unten geholfen haben. So ganz habe ich mein Problem mit meinem IDE-Controller nicht in den Griff bekommen. Wenigstens kann ich inzwischen wieder von meiner Seagate-Platte booten - aber Acronis True Image hängt sich nach wie vor auf, wenn ich im DOS-Modus versuche, auf eins der CD-Laufwerke zuzugreifen. Ursprünglich hat das aber gut funktioniert, egal mit welcher IDE-Konfiguration
Jetzt habe ich meine IDE-Stränge folgendermaßen bestückt:
- IDE 1 Master: Seagate-Platte
- IDE 1 Slave: Toshiba-DVD-ROM
- IDE 2 Master: Plextor-Brenner
- IDE 2 Slave: Maxtor-Platte
Jetzt hätte ich gerne ein paar Meinungen zu folgender Frage: Kann es dem IDE-Controller wirklich schaden, wenn man Festplatten und optische Laufwerke gemischt an einem Strang betreibt, wie Quax im oben verlinkten Thread gesagt hat? Oder brauche ich mir deswegen keine Sorgen zu machen?
Es wäre schon ziemlich schade, wenn ich das wieder auf Platte/Platte und Brenner/DVD-ROM ändern müsste. Für die Festplatten-Performance ist die gemischte Konfiguration nämlich außerordentlich förderlich.
Danke im voraus für Eure Hilfe!
CU
Olaf
Archiv Hardware perfekt konfigurieren 12.949 Themen, 54.079 Beiträge
Hi!
Ich glaube um beurteilen zu können, ob der Betrieb von Platte und optischen Laufwerk an einem Kabel den Kontroller schädigen kann, müsste man sich ansehen, wie IDE funktioniert.
Leider weiss ich da zuwenige. Was ich weiss, ist dass die IDE-Schnittstelle eine Art vereinfachtes SCSI-System darstellt. ich vermute also, dass die Signalübermittlung und die Kommunikation vergleichbar abläuft.
Mein Halbwissen zum Thema SCSI:
SCSI ist ein Bus und keine Schnittstelle. Hört sich dumm an, ist aber entscheidend. Früher waren Platten ja bekanntlich nicht intelligent und wurden direkt vom Plattenkontroller angesteuert. Über das Kabel wurde direkt die Plattenmechanik gesteuert.
SCSI/IDE ist da komplizierter. Hier haben wir es mit intelligenten Geräten zu tun, die jeweils einen eigenen Kontroller besitzen (die Platine der Platte z.B. enthält den Plattenkontroller).
Sind an einem Kabel der SCSI/IDE-Kontroler, eine Platte und ein CDROM angeschlossen, dann sind dort eigentlich drei Kontroller über ein Kabel miteinander verbunden.
Diese Kontroller tauschen Datenpakete untereinander aus. Wie das genau funktioniert und wie die Pakete aufgebaut sind, weiss ich nicht.
Was ich weiss, ist, dass die Kontroller, die am Kabel hängen natürlich exakt das verwendete Kommunikationsprotokoll verstehen müssen.
Klartext: sie müssen den Aufbau der Datenpakete kennen und natürlich auch elektrisch so arbeiten, wie es der Bus verlangt.
Ok, was ist mit verschiedenen Übertragungsgeschwindigkeiten auf dem Bus? Nun bei SCSI ist dass so, dass der SCSI-Kontroller mit jedem Gerät und (AFAIK) vor jedem zu übertragenden Datenpaket aushandelt, mit welcher Geschwindigkeit die Übertragung erfolgt.
Das Aushandeln erfolgt natürlich auch durch Übertragen von Datenpaketen. Hier wird dann immer die langsamste mögliche Betriebsart genutzt.
Bei IDE ist das etwas anders, ich weiss nur nicht, was anders ist. ;-)
Man sagt, der Overgead an langsamen Handshake würde SCSI in diesem Teil benachteiligen (IDE ist also irgendwie schneller oder handelt die Übertragungsgeschwindigkeit etwas anders aus). Hier müsste jetzt wieder Onkel Google ran, falls uns das niemand genauer erklären kann...
Ich denke ein defekter Plattenkontroller kann den SCSI/IDE-Kontroller beschädigen, indem er eine Überspannung auf das Kabel legt. Dann prutzelt ein defetes Gerät am Bus den Kontroller im Mainboard...
Ich glaube nicht, dass Datenpakete, die von einem optischen Laufwerk kommen oder verarbeitet werden, irgendwie den SCSI/IDE-Kontroller beschädigen können, egal in welcher Geschwindigkeit die Übertragung erfolgt. Warscheinlich weiss der SCSI/IDE-Kontroller gar nicht, welchen Gerätetyp er anspricht, da die Übetragenen Datenstrukturen grundsätzlich gleich sind (sprich: ein CDROM sendet nicht anders als eine Platte; ein Scanner empfängt die Daten nicht anders als ein MO-Laufwerk).
Es ist zwar denkbar, dass ein Gerät ein Datenpaket an den SCSI/IDE-Kontroller übermittelt, dass dann bei Interpretation im SCSI-Kontroller einen Abstürz auslöst, aber genau dass sollte durch Fehlerbehandlungen im Bus-Protokoll unterbunden werden (und wenn es dass gäbe, dann wäre der SCSI/IDE-Kontroller Schuld am Abrauchen und nicht das Gerät, dass das "falsche" Datenpaket abgesetzt hat).
Wie gesagt, ich glaube das, kann es aber nicht wirklich begründen, da mir die Details (und das Fachwissen) auf dem Gebiet der Bus-Protokolle fehlt.
Bin ich halbwegs klar rübergekommen?
Bis denn
Andreas
[Diese Nachricht wurde nachträglich bearbeitet.]