.


Also ich find den duvok nicht schlecht.

Wo tuvok keine Fragen hat ist "gut" drin!

Warum sollte das am IDE-Bus nicht auch was bringen. Wer sich heute mit SCSI, Queuing und Busen beschäftigt wird nicht mehr verstanden.

Mich wunderts nicht, es macht micht halt traurig :heul:

Wieso braucht ein Busen einen terminator?

Hast schon mal einen Computer mit IDE-Kabeln/Geräten und mit SCSI-Kabeln/Geräten offen gehabt, oder beschäftigst Du Dich rein wissenschaftlich theoretisch mit dem Thema Bus?

Wenn dann je einen, hat ja zwei Endpunkte!

.


Bus
Busen


oder


Bus
Bussen



Ich bin fürs erste ist doch lustiger.

.



Also mir gehts um die praktische Anwendung.

Hab auch nicht das Labor um die Signale auf dem IDE-Bus zu analysieren. Als Info hab ich nur Windows und die Treiber und Herstelleraussagen und das INet......ja die Leistung der eigenen Sys auch noch.


Wer schon mal eine Feuerübung in einer Schule mitgemacht hat, wurde angehalten die Schule im Gänsemarsch zu verlassen.

Es ist die schnellste Methode eine Schule komplett zu räumen.
Will ich aber bestimmte Schüler haben kann ich lange warten bis die rauskommen. Da wärs halt besser ich könnt die Namen durchsagen und die Schüler kommen dann.
Und ich hab halt festgestellt das auf meinen Boards unter W2K,XP diese Durchsage nicht richtig funktioniert.
Ich sags absichtlich so blumig weils sonst keiner lesen würde.

.



Also hier jetzt die Unterschiede von command queuing in grafischer Form.


www.members.aon.at/temp0/commandqueuing.JPG


Ich geh davon aus das die Promise-Controller niemal und die Intel-onboard Controller unter W2K,XP nur das normale Queuing unterstützen.


Promise Bios und Treiber 2.00.0.24. Benchmarks höher und schneller als alles was ich von zwei PATA im Web gesehen habe.

www.members.aon.at/temp0/hdtachboot.JPG

Leistung unter W2K,XP 50% der Leistung die ich unter NT40 erreiche mit SoftwareRaid.

Es geht dabei nur um den Random-Access-Modus bei sequentillen Lesen oder Schreiben.



Wenn ich am OnoardController ein Software-Raid einrichte hab ich die gleiche schwache Leistung. Der Grund ist das command queuing nicht funktioniert. Daher werden die Platten beim gleichzeitigen Zugriff gebremst und sind daher langsamer als eine Platte alleine.
Die Promise Controller verhalten sich ebenso nur das hier bei 4Platten die Leistung nicht über der einer Platte hinausgeht.

An den Onboardcontroller sind jeweils nur zwei Platten vom Leistungeinbruch bedroffen, man hat also zwei unabhängige Kanäle bei Intel.