Obwohl ich mich in den vergangenen Wochen eingehend mit SCSI- und IDE- Technik befasst habe, habe ich einige Beobachtungen gemacht, die ich nicht verstehe. Wenn ich in einem Rechner zwei HDDs anschließe (bei Scsi an 2940UW, bei IDE-Rechnern beide Platten jeweils an eigen Strang), läuft das kopieren schweinelangsam. Die Platten waren halbwegs modern und sollten daher echte effektive Schreibraten von mindestens 5-10 MB/s bringen, so daß das Kopieren von 2 GB eine Sache von max.3-5 Minuten sein dürfte. Doch in wirklichkeit hat es eine halbe Stunde gedauert. Ich möchte mich mal als Profi bezeichnen, der alles einwandfrei konfiguriert hat, im normalen Betrieb liefen die Platten jeweils mit üblicher Speed. Sind den effektive Werte so weit unter irgenwelchen Prospekt-Transfer-Daten. Was soll der Humbug? Zumindest bei SCSI sollten die Platten doch ihre Speed ausreizen können, ohne das der Bus ausbremst. Wer weiß, woran sowas liegt??
Archiv SCSI 2.798 Themen, 12.895 Beiträge
Im realen, alltäglichen Rechner sind 5-10MB/s bereits recht gut. Typischerweise liegen sie sogar unter 5MB/s. Aber 2GB in 30 Minuten - das ist schon ein wenig arg langsam. Wenn wir davon ausgehen, daß HDs und Controller völlig in Ordnung sind, dann muß der Hemmschuh auf dem MoBo - nein ich mach Spaß: NATÜRLICH im WinXYZ zu suchen sein. Ich unterstelle mal, Du benutzt ein solches. Sofern die 2GB auf der Zielplatte ohne das mindeste Fehlerchen angekommen sind, ist ein Hardwaredefekt wohl auszuschließen.
Eine der beteiligten Platten könnte im langsameren PIO-Mode laufen, bzw. DMA ist nicht aktiviert. Oder ein CD-Laufwerk am selben Kabel einer Festplatte bremst diese.
Wahrscheinlicher bremst das WinXYZ die ganze Chose, nicht (nur ;-)) ), weil es ein WinXYZ IST, sondern weil Du ggf. allzu viele Hintergrundprozesse am laufen bzw. nicht beendet hast.
Ich tippe jedoch mal auf einen Virenscanner. Ein Virenscanner kann bei derart großen Dateien ohne weiteres der Grund sein. Denn der prüft die Datei VOR ihrer eigentlichen Verwendung, hier: dem kopiert werden, erst einmal komplett durch. D.h., die Datei muß zweimal bearbeitet werden, was auf eine halbierte Zeitspanne hinausläuft für das eigentliche Kopieren. Und 15 Minuten für 2GB sind zwar auch nicht berauschend, aber schon "normaler". Probier´s mal ohne Virenscanner und ohne VERIFY. Soweit ich mich entsinne, ist das VERIFY standardmäßig aktiv, was zwar sicherer ist, aber auch Zeit kostet, also bei so großen Dateien auffallen muß. Manche Virenscanner, z.B. AVP, haben eine Option, nur Dateien unterhalb einer anzugebenden Dateigröße zu bearbeiten, größere flutschen durch. Möglich, nicht aber empfehlenswert - aus Sicherheitsgründen.
...und daß irgendwelche HDs mit diesem oder jenem System bzw. Controller ihre "Speed" zeigen bzw. ausreizen könnten, ist nichts anderes als ein sich hartnäckig selbst am Leben erhaltendes Märchen: geflunkert!
Welches Betriebssystem hast Du?
Win98?
Hast Du Syncrondatenübertragung im Gerätemanager bei den Festplatten aktiviert?
Teilt sich der SCSI Controller einen IRQ mit einem anderen Device?
Danke für die Tips, Jungs. Ich hoffe, das weniger erfahrene User diese Tips lesen und was bei lernen. Ich kann getrost davon ausgehen, das meine Systeme praktisch perfekt konfiguriert sind. Das sooll um Gottes Willen nicht arrogant klingen, sondern lediglicg Fehlerquellen als Erklärung von Vornherein ausschließen. Ich wollte mit meinem Beispiel lediglich verdeutlichen, daß sogar bei SCSI die praktische Leistung himmelweit von theoretischen Transferleistungen entfernt sind. Ich glaube, daß wird vom Prinzip her auch ewig so bleiben, halt solange, wie Festplatten Datenspeicher Nr.1 bleiben...
Ich war halt nur frustriert, daß selbst ein alter Hase wie ich nicht davon verschont bleibt und suche nun nach halbwegs plausiblen Erklärungen. Ich kann es ohne Rat von HDD-Spezialisten nicht nachvollziehen. Die Platten schieben heute locker 30-40 MB durch die Gegend, die eine schiebt, die andere saugt, der Controller jagt´s grinsend über´n Bus... verdammt nochmal, wo bleibt´s hängen???
Na dann, Prost Mahlzeit!
Wieso ein Fake? Ich habe ja nicht nach Konfigurationstips gesucht, sondern nach einer Erklärung, wie dieses Phänomen selbst bei sauber konfigurierten Rechnern sowohl bei SCSI als auch bei IDE auftritt. Eure Tips sind besonders für Einsteiger sehr hilfreich und sinnvoll, nur war ich selbst schon einige Schritte weiter. Macht ja nix, wertvolle Tips können nicht oft genug veröffentlicht werden. Jeder fängt schließlich mal klein an. Außerdem seit Ihr offenbar engagierte Experten, an die ich mit Sicherheit in Zukunft die eine oder andere Praxis-Frage stellen werde. Zu guter Letzt war Pfützner, der die ganze Sache plausibel erklärt, daß meine ursprüngliche Frage sehr zufriedenstellend beantwortet wurde. Hier jedenfalls nochmals besten Dank an alle!
Die Platten liefern 30-40MB/s nur als Dauertransferrate und die ist eine rein theoretische Angabe, weil in der Praxis kein Betriebssystem sequentiell liest (also linear hintereinander), sondern in Blöcken von wenigen Byte bis ca. 256kB mit nötigen Zugriffen dazwischen. Die dauern ... SCSI-Platten mit 10000 rpm liefern im zufälligen Zugriff bei 4kB Transfergröße ca. 450kB/s, unabhängig von der Dauertransferrate, bei 32kB Transfergröße (Durchschnittsgröße aktueller Betriebssysteme) ca. 3 - 4 MB/s. Bei 64kB dann ca. 5MB/s. 30-40MB/s schafft in der Praxis niemand. Die Differenz zu realen Werten entsteht durch die Zugriffszeiten der Platten. Die Platten sind also nicht nur im direkten Kopieren, sondern tatsächlich IMMER so langsam. Bei 30 - 40MB/s müßten selbst große umfangreiche Programme in Sekundenbruchteilen starten, tatsächlich dauerts dann immer ein paar Sekunden mehr. Genauso wird bei Zugriffszeiten gelogen, aktuelle IDE-Platten (5400 rpm) mit ca. 10msec, alte lagen mal bei 15 - 16msec. Fragt sich wie die Neuen real schneller sein sollen wenn Alte wie Neue für'n Full Stroke 24msec brauchen?
Vergleich zu SD-RAM vs. DDR-RAM: DDR-RAM ist theoretisch doppelt so schnell wie SD-RAM, (wenn der Speicherinhalt fortlaufend gelesen wird). Im realen Betrieb ist DDR-RAM nur 2 - 3% schneller, weil auch hier nicht fortlaufend, sondern in Blöcken unterschiedlicher Größe gelesen wird. Zwischendurch muß auf andere Speicherstellen zugegriffen werden, hier geht ebenfalls Zeit verloren. Zugriffe dauern immer ein paar Takte, und die Taktrate beträgt bei SD- wie bei DDR-RAM 133MHz. Die Zugriffe dauern bei beiden gleich lange. Selbst bei Videobearbeitung (= große Blöcke) ist DDR-RAM max. 10% schneller als SD-RAM.
Wir werden belogen was das Zeug hält, und die allgegenwärtigen selbsternannt allwissenden PC-Zeitschriften sind längst zum Erfüllungsgehilfen der verkaufsorientierten Industrie geworden, genau wie die Benchmarks auch.
Was haben die Zeitschriften nicht schon alles geschrieben:
USB alles super, seriell und parallel ade - paar Monate später kleinlaut: quälend langsam, gigantischer Overhead;
IDE hat in Sachen Eigenintelligenz längst SCSI eingeholt - eine simple Betrachtung eines Kopiervorgangs zwischen 2 Laufwerken offenbart die Lüge, IDE ist nach wie vor dümmer!
IDE unterscheidet sich nur im Interface von SCSI - da muß die c't aber beide Augen fest zugedrückt haben, incl. der Hühneraugen.
Die Reihe ließe sich beliebig fortsetzen. Ich bin da sehr vorsichtig geworden, auch weil AutoCAD 2000 auf einem alten Pentium III @ 1GHz schneller läuft als auf einem Pentium 4 @ 2GHz, stand so zumindest mal in einer PC-Intern, der ich aber auch nicht alles glaube...
Diese Erklärung finde ich wirklich plausibel. Tröstend bleibt da wohl die Hoffnung, daß eine neue Platte mit 50% mehr Speeed dann wohl auch in der Praxis proportional schneller ist. Interessant wäre nur der Anreiz für Entwickler von Datenrettungstools und Backupprogrammen Prog´s zu entwickeln, die versuchen, zumindest für Kopiervorgänge Daten sequentiell zu übertragen. Rein Hardwaremäßig scheint das ja möglich zu sein.
Die SCSI/IDE-Frage stellt sich für mich übrigens aus Qualitätsgründen nicht mehr. Abgesehen von meiner technischen Überzeugung ist es die Verarbeitung der SCSI-Platten, die mich mehr überzeugt. Die Reduzierung der Garantie auf ein Jahr bei IDE spricht Bände. Dann lieber 5 Jahre bei SCSI und 18 GB statt 100 GB Kernschrott.
Falls es Nickles in einem seiner Bücher noch nicht geschrieben hat, sollte er Deine Erklärung ruhig übernehmen. Damit können sicher etliche Wissenslücken gestopft werden! Danke nochmal dafür!
"IDE und SCSI praktisch dasselbe" - ne auch, wat´n Brüller!
Das KANN schon nicht stimmen, wenn man sich mal überlegt, was für Geräte am IDE-Controller lediglich angeschnlossen werden können und was alles an einem SCSI-Controller! Sicher, für HDs, CD/DVD-ROMs bzw. -Brenner (auch wenn die SCSI-Ausführungen mittlerweile eingestellt wurden...schnief!) keine Probleme. Aber wer hat schon mal von IDE-Scannern gehört????
Ich erinnere mich noch, daß bei der SCSI-Treibersammlung CorelSCSI von vor zig Jahren Treiber für SCSI-Drucker und SCSI-Bildschirme dabei waren. IDE ist nicht mal aus Versehen für sowas geeignet. SCSI aber sehr wohl. Das MUß sich auch in der "Architektur" der Controller-Hardware niederschlagen. "SCSI" MUß deswegen recht was komplizierter ausfallen als "IDE". Ein IDE-Controller kann max. 4 Geräte ansteuern, ein SCSI-Controller mind. 8 - und die in ohne Probleme in denkbarst wildester Mischung, was es an SCSI-Geräten eben so gibt. Und alles nach den individuellen Fähigkeiten betrieben, nicht wie bei IDE "one size fits all".