# Performanceprobleme beim Datendurchsatz (SATA -> WD1500ADFD)

## Nightfire

Hallo, ich habe ein paar Probleme mit mein Gentoo-systeme. Ich weiss nicht ob das normal ist.

Zuerst mal eine kurze Hardwareübersicht

lspci

```

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)

00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)

00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)

00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)

00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)

00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)

00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev a2)

00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97 Audio Controller (rev a1)

00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev a2)

00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) (rev a2)

00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge (rev a2)

00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control

02:07.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 12)

02:0b.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)

02:0d.0 RAID bus controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01)

02:0e.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01)

```

```

Festplatten: 2 x Western Digital WD1500ADFD (Raptor) - 10.000 u/min

CPU/kernel: 2.6.16-ck6-r1 #3 SMP Fri Apr 21 16:47:39 x86_64 AMD Athlon(tm) 64 Processor 3500+ GNU/Linux

Netzwerkkarten: 2 Onboard (1x mavel youkon (Gbit) und einmal nvidia (nur 100Mbit), und eine Gbit karte als PCI-Version

```

Auf dem Mainbord (Gigabyte GA-K8NS Ultra 939) sind 2 Sata Controller, ein Nvidia und ein Silicon Image. Egal an welchen ich meine beiden Raptorplatten anschliesse, mehr als 22 - 25 MB/s 

transfehrrate kommt nicht zustande. Habe eine datei kopiert und die Zeit gestoppt. 

```

time cp /platte1/datei.riesengross /platte2

```

Ich weiss echt nicht woran das liegt. Wenn ich Mickeysoft windows auf den Rechner isntalliere, das habe ich testweise getan habe ich eine transferrate von über 80 MB/s. Wie kann das sein?

hier noch die ausgabe von HDPARM

```

fritz ~ # hdparm -Tt /dev/sdb1

/dev/sdb1:

 Timing cached reads:   3788 MB in  2.00 seconds = 1893.82 MB/sec

 Timing buffered disk reads:  250 MB in  3.02 seconds =  82.90 MB/sec

```

und wem es noch weiterhilft meine kernel config.

```

  http://www.opensourceprojekt.de/kernelconfig.txt

```

Ich hoffe irgendjemand weiss was hier schiefläuft oder kann mir sagen das diese langsame geschwindigkeit normal für linux ist (was ich nicht hoffe).

Mfg NightyLast edited by Nightfire on Sat Apr 22, 2006 1:27 pm; edited 2 times in total

----------

## Nightfire

Ich habe grade mal von der gentoo livecd gestartet und musste feststellen das die transferrate auch da so gering ist  :Sad: 

----------

## fk

Hallo

Ist für diese Festplatten DMA Aktiviert?

----------

## Nightfire

Hmmm das sind sata Platten, da ist das soweit ich weiss defaultmässig aktiv, mit hdparm kann man da nix einschalten.  :Sad: 

----------

## fk

Was sagt denn

```
hdparm -d /dev/sd... 
```

----------

## Nightfire

fritz ~ # hdparm -d /dev/sdb

/dev/sdb:

fritz ~ # hdparm -d /dev/sda

/dev/sda:

----------

## caraboides

Nimm mal lieber ein hdtestprogramm wie bonnie, kann sein dass das kopieren wie du es machst nicht so optimal. Das mit DMA solltest du mal ueberpruefen. Im Kernel Aktiv, bios usw.

Benchmark:

app-benchmarks/bonnie

----------

## fk

Oben hast du sdb1 genommen, nim das doch jetzt auch mal

----------

## Nightfire

@ fk 

das ist die ausgabe wenn ich sdb1 nehme

fritz ~ # hdparm -d /dev/sdb1

/dev/sdb1:

@ caraboides

Vielleicht ist das nicht so Optimal. Ich teste Bonnie mal. Alledernings nützt es mir nicht viel wenn Bonnie da irgendwas kopiert und ich dann Werte angezeigt bekomme die sich gut anhören. Das muss ja im Betrieb genau so funktionieren. Meine Transferrate liegt ja auch bei 22 - 26 MB/s und das ist für GBit ziemlich schwach. Habs mal mit Windows probiert da hatte ich im LAN auch noch 55 MB/s.

----------

## Nightfire

Hier die Ausgabe von bonnie

fritz ~ # bonnie -d /test/

File '/test//Bonnie.7365', size: 104857600

Writing with putc()...done

Rewriting...done

Writing intelligently...done

Reading with getc()...done

Reading intelligently...done

Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...

              -------Sequential Output-------- ---Sequential Input-- --Random--

              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---

Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU

          100 59922 99.3 764692 100.1 921683 99.9 75773 100.0 2327114 100.0 113529.9 99.3

----------

## Nightfire

hab auch grade mal top beim kopieren laufen lassen 

Es sieht so aus als ob das die CPU zu 100% auslastet

Cpu(s):  6.7% us, 11.7% sy,  0.0% ni,  0.0% id, 73.2% wa,  2.0% hi,  6.4% si

----------

## caraboides

Schaut doch gut aus, das heisst, das es schon mal alles geht. (Bei mir sinds nur 29 Mbyte/sek ;-(

Ach ja ueber Gbit bekommst du auch max 80-90 Mbyte rueber, aber zum testen den Netzwerk leistung nehme leiber Netio (gibt es auch fuer Windindows)

.

Das Problem ist, bei Kopieren von fiels, dass der Arm erst hin muss und dann liest, wenn die Daten verstreut sind dauert es auch länger. Di ereine Io-Leistung kann dann von dem realen Gebrauch variieren . Welchen IO-Scheduler nimmst du?, da kann man auch mal tests machen. 

Ach ja SMB ist sau lahm, dass Protokoll ist ein Witz.

----------

## Nightfire

Also IO-Scheduler sagt mir eigentlich gar nichts. 

Übers lan kopiere ich sowieso per ftp und nicht mit samba, aber selbst da hab ich nicht mehr transfehleistung... 

Ich hab zum desten mit dd if=/dev/zero of=/test.file angelegt.

Die platte ist fast bis auf das betriebssystem komplett leer. Von daher denke ich nicht das die daten da allzusehr verstreut lagen :/

----------

## caraboides

Io-scheduler -> googeln

Der regelt wie das System verschiedene Anfragen an die Platte schickt. Es gibt im Kernel 4 Stueck (oder Mehr) di erecht unterschiedliche ergebnisse liefern.

Du kannst im Kernel alle aktivieren, und sie dann im laufenden Betrieb ueber /proc aendern. In der KernelDoku steht dazu ne Menge, es gab auch mal im Linux-Magazin dazu einen guten Artikel:

http://www.linux-magazin.de/Artikel/ausgabe/2005/04/kerntechnik/kerntechnik.html

----------

## Nightfire

War schon am googlen. Damit muss ich mich jetzt erstmal auseinander setzen. Das klingt auf jedenfall interessant. Werde nachher hier verlauten lassen wie es gelaufen ist.

----------

## Nightfire

Hmmm ich habe jetzt alle 4 Schedules ausprobiert.

Da wären: 

Anticipatory I/O scheduler                                      │ │

Deadline I/O scheduler                                          │ │

CFQ I/O scheduler                                               │ │

No-Op I/O scheduler 

Ich habe alle der Reihe nach getestet. Ich würde fast behaupten die tun sich von der Performance

zumindest auf meinem System nicht viel. Wobei das auch andere Gründe haben kann  :Sad: 

Ich hab sogar schon die Dateisysteme gewechselt.

----------

## Jinidog

Wo liegt denn nun eigentlich dein Problem?

Dein hdparm-Test sagt doch, dass die Platten 80 MB/s an Datendurchsatz schaffen.

20 MB/s beim Kopieren ist doch gar nicht schlecht. Schließlich ist beim Kopieren so einiges mehr los als ein reiner Datendurchsatz,

da müssen Leseköpfe zu den richtigen Stellen auf der Datenscheibe bewegt werden (und das gleich auf zwei Platten) und auch das Dateisystem will aufrecht erhalten sein.

Ergo kann die Kopiergeschwindigkeit gar nicht so hoch sein wie der Datendurchsatz.

Übrigens kenne ich keinen Taschenrechner, der 20 MB/s an Datein kopieren kann. Aber vielleicht ist da die neuste Entwicklung an mir vorbei gegangen.

----------

## Masta Pete

in der ausgabe die du von top gepostet hast, ist der waiting wert(wa) relativ hoch. ich hab zwar kein sata system hier, aber auf allen ide und scsi systemen hier konnte ich so hohe wa werte nur bei deaktivierten dma feststellen. eventuell bietet der hersteller der platten ja ein testtool, mit dem du sie prüfen kannst.

lg

pete

----------

## Nightfire

@ Jinidog

Also als gut würde ich das nicht bezeichnen. Ich weiss nicht ob du gelesen hast, um welche Platten es sich handelt. Davon mal abgesehen ist das für _alle_ Sataplatten zu wenig ausserdem habe ich wenn ich windows installiere einen 4x so hohen Datendurchsatz. Da kann doch was nicht stimmen, oder willst du damit andeuten das man mit so grotten schlechter Performance leben muss wenn man gentoo benutzt? Ich hoffe mal nicht.

@ Masta Pete

Ich habe auf der Webseite vom Hersteller nichts gefunden was unter Linux läuft. Wie gesagt unter Windows ist alles in Ordnung  :Sad: 

----------

## think4urs11

welches Dateisystem benutzt du unter Windows?

welches Dateisystem benutzt du unter Linux?

Benutzt du ein FS-Journal unter Linux?

Ist Windows 'wirklich' 4x schneller oder tut es nur so - d.h. sind die Platten nach Ende des Kopiervorganges im Explorer noch aktiv oder nicht?

----------

## Jinidog

Der Datendurchsatz ist laut hdparm in Ordnung. Also ist es kein Problem mit den Interfaces, es liegt woanders, wenn es denn eins gibt.

Ich denke eher, du testest auf irgendeine Weise unfair und Windows lässt noch ein bisschen den Cache spielen.

Wenn du eine große Datei in ein recht volles Dateisystem schreibst, würde mich der verlangsamte Kopierprozess nicht wundern und das auch den hohen wa-Wert erklären.

Solange du alles solche Sachen bei deinem Kopierbenchmark nicht berücksichtigst, ist der Fehler wohl eher dort zu suchen.

Mach mal was sinnvolles, erstell eine Ramdisk und kopiere mal darein. Das wäre dann ein Ergebnis, bei dem man mal schauen kann, wie schnell die Daten von den Platten kommen.

----------

## SinoTech

 *Jinidog wrote:*   

> 
> 
> [...]
> 
> Mach mal was sinnvolles, erstell eine Ramdisk und kopiere mal darein. Das wäre dann ein Ergebnis, bei dem man mal schauen kann, wie schnell die Daten von den Platten kommen.

 

Also RAM disk ist nicht so gut. Habe ich eben mal probiert und hatte HDD -> RAM = 120 MB/s und beim zurück kopieren ca. 400 MB/s ... da wurde wohl irgendwo böse gepuffert.

Mit dd und /dev/zero kann man aber anscheinend ganz gut testen:

```

$  time dd if=/dev/zero of=test_file bs=5M count=1024

1024+0 records in

1024+0 records out

5368709120 bytes (5.4 GB) copied, 93.9795 seconds, 57.1 MB/s

real    1m34.038s

user    0m0.010s

sys     0m8.500s

```

Das sieht doch einigermasen realistisch aus.

Mfg

Sino

----------

## Nightfire

Windows NTFS

unter linux habe ich mittlerweise 4 Dateisysteme ausprobiert:

aktuell Reiserfs, davor Ext3, Ext2 und Xfs 

Die Ergebnisse lagen nah bei einander.

Wie ich schon erwähnt habe waren beide Platten fasst leer, auf beiden Systemen. 

Was windows angeht kann ich behaupten das die Platten nach dem kopiervorgang nichts mehr machen. Da zum einen die Festplatten hdd's aus sind

und zum anderen höre ich auch keine Geräusche mehr. 

Und ja sie sind effektiv 4 mal schneller. Das habe ich sogar mit der Stopuhr getestet. Weil man mir gesagt hat ich soll den angezeigten Werten nicht trauen. Und rein vom empfinden merkt man auch wenn etws drastisch viel schneller geht. Also in dem fall sagen wir 3 bis 4 mal so schnell.

ich hab sogar ne datei die auf ner frisch formatierten Platte mittels dd if=/dev/zero of=/hdd2/test angelegt, da sollte es auch keine grossartige verstreuung der einzelnen bits geben. auf der Zielplatte war ebenfalls bis auf das system nix drauf.

Und ich weiss nicht ob ihr mich hier falsch versteht. Ich bin absolut kein Windowsanhänger ich benutze es nichtmal. Ich habe es lediglich zum testen installiiert weil gentoo nich ausm Quark kommt und ich einen Vergleich auf meinem System brauchte. Und da ist leider die Performance was das kopieren an geht sehr erbärmlich.

----------

## Nightfire

Ich habe die selben probleme auf meinem neuen rechner. Hier handelt es sich aber um einen NForce4 Chipsatz mit einem Amd Athlon 64 X2 4400+ . Bei 20 - 30 MB/s macht der Dicht. Ich glaube irgendwie das ich hier etwas falsch mache  :Sad:  Btw. Die Festplatte sind die selben.

Hier mal die Spezifikationen:

Western Digital WD1500ADFD (Raptor)

Drehzahl    10000 RPM 

Interne Datenübertragungsrate    816 Mbit/s 

Externe Datenübertragungsrate    150 MBps 

Suchzeit    4,6 ms 

Puffergröße    16 MB 

Durchschnittliche Latenzzeit    3 ms 

Schnittstelle  Serial ATA

----------

## Scorpion_DE

Hi Nightfire,

meine Voraussetzungen sind ähnlich. Ich besitze ein ASUS A8N-SLI (nForce4), Athlon 64 X2 4600+, 1 GB Hauptspeicher und eine Raptor74. Hier mal meine Werte zum Vergleich:

```

the ~ # hdparm -tT /dev/sdc4

/dev/sdc4:

 Timing cached reads:   3696 MB in  2.00 seconds = 1847.88 MB/sec

 Timing buffered disk reads:  196 MB in  3.01 seconds =  65.07 MB/sec

the ~ # time dd if=/dev/zero of=test_file bs=5M count=1024

1024+0 records in

1024+0 records out

5368709120 bytes (5.4 GB) copied, 83.3363 seconds, 64.4 MB/s

real    1m23.676s

user    0m0.004s

sys     0m9.721s

```

Bitte führe den zweiten Test einmal aus und poste das Ergebnis.

Beachte beim Anschliessen der Platten an den Controller, daß der SiliconImage am PCI-Bus hängt. Eine relistische Bandbreite bei 32Bit/33MHz wäre hier so 100-120 MByte/s (abhängig von der Implementierung/dem BIOS). Hast du nun beide Platten am PCI-Bus und kopierst von der einen auf die andere mit 80 Mbyte/s eine große Datei, dann wird ja mit 80 Mbyte/s gelesen und gleichzeitig mit 80 Mbyte/s geschrieben. Das wären 160 Mbyte/s. Das kann kein PCI-Bus wie er auf deinem Board vorhanden ist. Hier muss also was mit der Messmethode nicht stimmen.

Die SATA-Schnittstellen des nForce4 sind über einen eigenen Kanal direkt mit der Southbridge verbunden. Das Limit der PCI-Bus gibt es nicht, höhere Transferraten wären möglich.

@all: Was mir noch einfällt. Unter Windows ist ja NCQ aktiv. Wie sieht es denn damit unter Linux aus? Allerdings lassen sich damit allein die Unterschiede wohl nicht erklären.

Zwei Fragen habe ich noch:

- Wieviel Hauptspeicher hast du?

- Mit welchen dateigrößen hast du getestet?

Gruß Scorpion

----------

## Anarcho

NCQ kannst du im Moment vergessen.

Im 2.6.17er kernel soll wohl was verbessert werden und neue Features erst im Kernel 2.6.18 kommen.

----------

