Re: Performance Festplatte

On Sun, Sep 16, 2001 at 05:51:52PM +0930, Greg Lehey wrote:
> On Sunday, 16 September 2001 at 9:56:14 +0200, Joerg Wunsch wrote:
> > As Greg Lehey wrote:
> >
> >>>> Schreibzugriffe auf die Festplatte dauern
> >>>> allerdings ewig(z.B. beim Auspacken eines Tar-Archives). [...]
> >>>> Liegt das an dem Filesystem von FreeBSD?
> >
> >>> Nein, an IDE. :-)
> >
> >> Hast Du das gemessen?
> >
> > Für tagged command queuing weiß ich nicht, ob es Vergleiche gibt.
>
> Ich auch nicht. Bei ATA spielt Tagged Queueing aber deswegen nicht so
> sehr eine Rolle spielt, weil die Controller weniger Kommando-Overhead
> haben, mindestens in meiner Erfahrung.

TCQ ermoeglicht mehrere gleichzeitige Schreiboperationen.
Siehe hierzu die Erklaerung unten.

> >> Ich hab's; IDE ist bei der Übertragung genau so schnell wie SCSI.
> >
> > Stimmt nicht ganz. IDE spielt hier seit Jahren mit SCSI Hase und
> > Igel. ,,Ich bin all hier.'' Aber inzwischen ist SCSI (bei
> > Parallelübertragung -- von Glasfaser rede ich nicht) eben auch schon
> > bei 160 MB/s angekommen.
>
> Wen kümmert's? Die Scheiben können nicht so schnell übertragen, und
> nach wie vor spielt die Suchzeit die weitaus größte Rolle. Überleg'
> mal lieber, wieviel Bandbreite pro Platte übrigbleibt. Bei ATA-100
> mit Tagged Queueing gibt's pro Platte minimal 50 MB/s. Bei <foo>SCSI
> mit 160 MB/s und 15 Scheiben gibts nor etwas über 10 MB/s.

Was aber fuer die meisten Situationen immer noch ausreicht.
Ich denke nicht das hier irgendein spuerbares Limit existiert.
Vom maximalen einer Platte bleibt man in der Realitaet meist ein gutes
Stueck entfernt.

> >> Die Übertragungsrate hängt eher vom Modell als vom Interface ab.
> >
> > Richtig. Bei IDE gibt's dafür wahrscheinlich noch mehr Schrott zu
> > kaufen.
>
> In letzter Zeit habe ich keinen Schrott gesehen. Ich habe im letzten
> Jahr beruflich eine Kiste mit 40GB IBM DTLA-Platten auf
> Zuverlässigkeit gestestet und keine Probleme festgestellt; dafür war
> ich von der Performance recht beeindruckt. c't konstatiert auch, dass
> kaum eine SCSI-Platten den DTLAs in Punkto Übertragungsrate nahekommt.

Keine Frage das es zuverlaessige IDE Platen gibt.
Die Geschwindigkeit muss sich natuerlichen den physischen
Beschraenkungen ergeben - es sei den man schaltet den Schreibcache ab.
Wobei ich keine Erfahrung habe wie gut TCG auf IDE funktioniert.
Das aendert aber nichts daran das es erschreckend viel IDE Schrott gibt.

> >>> Du kannst den Schreibcache der Platte einschalten ...
> >
> >> So macht's aber jeder anderer.
> >
> > Ist Linux == ,,jeder andere''?
>
> Nein.
>
> > Bei Solaris zum Beispiel wäre ich mir nicht sicher. Wenn sie
> > transaction logging vernünftig und sicher hinbekommen wollen, müssen
> > sie sich auch sicher sein, daß die Daten auf dem Medium auch
> > angekommen sind. Hardware-RAID-Systeme haben dafür extra einen
> > batteriegepufferten Cache-RAM, damit sie eine zuverlässige Pufferung
> > anbieten können. Und Solaris /ist/ in der Beziehung langsam. Selbst
> > ein VxFS auf einem schicken tollen Solaris-Server mit A5000 Arrray
> > dran (immerhin fibre channel Platten) ist rein gefühlsmäßig meinem
> > Notebook mit softupdates unterlegen, was die Geschwindigkeit eines
> > rm -rf betrifft.

Solaris war bei inode Operationen schon immer recht langsam.
Selbst ohne Softupdates ist FreeBSD in solchen Faellen schneller.

Aber bei Sun haben Platten ja auch immer eine OEM Firmware.
Evtl. haben deren Platten einen anderen Interleave als die Dinger
normalerweise haben und koennen deshalb auf den Schreibcache
verzichten.
Auf SCSI Platten von Sun ist jedenfalls der Schreibcache immer
abgeschaltet, waehrend die Hersteller die Modelle fast immer mit
eingeschaltetem Cache auf dem normalen Markt verkauft haben.
Spuerbar ist das aber lediglich beim newfs...

> > Die Diskussion um write cache einschalten oder nicht hatten wir ja
> > schon auf den Listen. Fakt ist, auf meinen SCSI-Platten ist es beim
> > `make world' praktisch kein Unterschied (weshalb ich ihn ausschalte),
> > während die IDE-Fans einen Riesenaufschrei von sich gegeben haben, als
> > Søren den write cache standardmäßig ausgeschaltet hat.
>
> Ja, ich habe auch einen sehr großen Unterschied festgestellt. Das
> macht aber die ATA-Platten nicht schlechter.

Die Theorie ist da relativ einfach:
Fuer den durchaus wahrscheinlichen Fall das hinternanderliegende
Bloecke gespeichert werden:
Der erste Block wird geschrieben und der 2. muss im Speicher der
Festplatte sein noch bevor das Schreiben des 1. abgeschlossen ist -
ansonsten gibt es eine Strafumdrehung.
Frueher hat man das mit einem Versatz der Bloecke gemacht (interleave),
was aber die Maximale Schreib-/Lesegeschwindigkeit reduziert.
Heute verlaesst man sich darauf das der naechste Block bereits im
Speicher der Platte ist.
Um das zu ereichen muss die Platte aber mit mindestenz 2 Schreib-
operationen gleichzeitung beauftragt werden!
Bei IDE ist man da auf den Schreibcache angewiesen.
Bei SCSI ermoeglicht TCQ das mehrere physicalische Schreiboperationen
ausstehen koennen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message