[DE] [gelöst] ssd und devils Anleitung - weitere Unstimmigkeiten

[holgerw]

Hallo,

danke für Eure Hinweise. Ich habe nun dem ASUS Mainboard M4A87TD EVO eine Bios Aktualisierung mit der Version 2001 verpasst:
http://www.asus.com/Motherboards/AMD_AM3/M4A87TD_EVO/#download

Leider hat sich an der Geschwindigkeit der SSD nicht viel geändert.

Was ist das für ein Schrott.

Höchstens noch: Nach nochmaligem Lesen deines letzten Posts.
Du sprichst dort nur vom Austausch der Kabel -auch an Deinem Brenner. Heißt das, Dein Brenner hängt noch am gleichen Port wie deine SSD?

@ayla: Das Mainboard hat 6 Ports, alle haben SATA3 mit 6 G/s.

An Port 1 hängt die SSD, an Port 2 die Samsung Festplatte, an Port 5 der DVD Brenner und an Port 6 ein Kombi-Kartenlesegerät.

Es darf doch nicht sein, dass ich, um volle Geschwindigkeit bei der SSD zu haben, alle anderen Ports frei machen muss. Das wäre eine Fehlkonstruktion von Asus.

Am liebsten würde ich den PC morgen den Alternate Leuten um die Ohren knallen. Mit dem Mainboard bin ich mittlerweile sehr unzufrieden, die Werbung seitens Asus Xtreme Power Solution For Extreme Performance ist eine Frechheit.

Viele Grüße,
  Holger

[dibl]

(sorry for English ...)

Holger, what is the SATA3 controller chip on the Asus board?  I have a Marvell 9128 on Asus P6X58D-E, and it works for one year with aptosid/slh kernels.

[ayla]

Bin jetzt nicht an meinem PC und kann deshalb den Controller nicht nachschauen, hol ich morgen früh nach.

@Holger:
Ich hatte das auch nicht als dauerhafte Lösung gemeint ,
sondern um mal einzugrenzen woher dieses Verhalten kommt.
Wenn, nach abziehen aller anderen Geräte, deine Geschwindigkeit immer noch so niedrig ist liegt es entweder an einer falschen Einstellung im BIOS oder einer Fehlfunktion entweder des Controllers oder der SSD, wenn die Geschwindigkeit dann aber steigt wäre es eine Bestätigung deiner Vermutung daß diese durch ein anderes Gerät beeinflusst wird.
Ich weiß nicht es auf deinem Board mehrere SATA-Controller gibt, aber falls ja wäre im letzten Fall die Lösung ziemlich einfach indem du die SSD separat auf einen Controller hängst und alle anderen Geräte auf einen anderen.

[devil]

Die Platte hat ja, wenn ich den ersten Eintrag des Threads richtig lese, im 0riginalzustand 400 MByte/s erreicht? Dann kann es ja weder an den Kabeln noch dem Controller liegen.

greetz
devil

[ralul]

Der erste Beitrag sagt aber auch:
"Nun bin ich der Platte nach Devils Anleitung zu Leibe gerückt, um sie optimal ..."

[ayla]

aber auch daß die Einstellungen im BIOS verändert wurden.

Was auf fehlerhafte Einstellungen hindeutet, ich würde aber, wenn ich da nichts finde, auch versuchen andere Fehlerquellen auszuschließen.

[holgerw]

Hallo,

zunächst: Keiner meiner Beiträge ist Kritik an Euch, weder an Devils Anleitung, noch an Ratschlägen, mal alle anderen Festplatten zu entfernen.

Ich bin ungehalten über die Situation, und warum SSDs zum Teil dermaßen schwierig einzurichten sind, nicht über Eure Beiträge.

Und Ihr wisst ja vermutlich auch schon, dass ich ein sehr geduldiger Mensch bin ;-)

@ayla: Im Bios kann ich für die SATA3 Schnittstellen eins bis vier AHCI, Raid oder IDE einstellen, und getrennt dann für die Schnittstellen fünf und sechs.

Das bedeutet doch, dass es zwei Controller sind. Den Kartenleser brauche ich nicht, den werde ich mal lahmlegen. Dann packe ich Brenner und Samsung HD an Port fünf und sechs, die SSD lasse ich an Port eins.

Ich werde berichten.

Viele Grüße,
  Holger

[holgerw]

Hallo,

bei Alternate gab mir eine Technikerin den Rat, hdparm mit der Zusatzoption --direct aufzurufen.

Ein hdparm --direct -tT /dev/sda zeigt mir nun eine Schreibgeschwindigkeit zwischen 300 und 400 MB/s an.

Damit setze ich meine Frage auf gelöst. Anmerkungen, auch zu der Zusatzoption direct, sind natürlich weiterhin willkommen.

Danke für Eure Hilfsbereitschaft.

Viele Grüße,
  Holger

[devil]

--direct
           

 Use  the kernel´s "O_DIRECT" flag when performing a -t timing test.  This bypasses the page cache, causing the reads to go directly from the drive into
              hdparm's buffers, using so-called "raw" I/O.  In many cases, this can produce results that appear much faster than the usual page cache method,  giving
              a better indication of raw device and driver performance.

Code: [Select]

hdparm  -tT /dev/sda

/dev/sda:
 Timing cached reads:   25612 MB in  2.00 seconds = 12823.95 MB/sec
 Timing buffered disk reads: 1160 MB in  3.00 seconds = 386.62 MB/sec


Code: [Select]

hdparm --direct -tT /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   920 MB in  2.00 seconds = 459.37 MB/sec
 Timing O_DIRECT disk reads: 1482 MB in  3.00 seconds = 493.93 MB/sec


den Schalter kannte ich noch nicht, ich bin mir noch nicht ganz im Klaren, was er für die wirkliche Performance bedeutet. Ich werd mal noch ein wenig weiterforschen.

greetz
devil

[holgerw]

Hallo Ferdinand,

nun bei mir unter OpenSUSE, siduction muss ich noch neu auf der SSD installieren:

Code: [Select]

biber:/home/holger # hdparm --direct -tT /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   898 MB in  2.00 seconds = 448.40 MB/sec
 Timing O_DIRECT disk reads: 938 MB in  3.01 seconds = 311.64 MB/sec
biber:/home/holger #

Unter dem Live Linux von OCZ sind die Werte leicht anders, aber in einer für mich akzeptablen Höhe. Ich muss mal sehen, wie ich unter OpenSUSE den Scheduler des Kernels anpassen kann. Am Wochenende ist dann siduction dran.

Viele Grüße,
  Holger

[rolandx1]

hdparm --direct -tT /dev/sda

/dev/sda:
 Timing O_DIRECT cached reads:   716 MB in  2.00 seconds = 358.09 MB/sec
 Timing O_DIRECT disk reads: 1066 MB in  3.00 seconds = 355.11 MB/sec

na sieht doch gleich besser aus als

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1674 MB in  2.00 seconds = 836.90 MB/sec
 Timing buffered disk reads: 402 MB in  3.00 seconds = 133.83 MB/sec

und entspricht vorallem auch mehr der "gefühlten performance"

[ayla]

hmm, ich hab das auch mal auf eine SATA3-fähige und an den SATA3-Port angeschlossene "normale" Festplatte (sdb) angewandt.
Dabei fällt mir auf daß die Werte mit oder ohne --direct für die nicht "cached" reads identisch sind. Nur bei der SSD (sda) ergeben sich Abweichungen.
Wäre interessant zu erfahren woher dies kommt.

http://en.wikipedia.org/wiki/Page_cache
http://www.thomas-krenn.com/de/wiki/Linux_Page_Cache_Grundlagen

Die beiden o.g. Seiten bieten mir dafür keine Erklärung -oder ich hab sie mal wieder nicht verstanden .

hdparm -tT /dev/sdb
/dev/sdb:
 Timing cached reads:   27620 MB in  2.00 seconds = 13830.04 MB/sec
 Timing buffered disk reads: 346 MB in  3.01 seconds = 115.06 MB/sec

root@nescaya: hdparm --direct -tT /dev/sdb
/dev/sdb:
 Timing O_DIRECT cached reads:   852 MB in  2.00 seconds = 425.67 MB/sec
 Timing O_DIRECT disk reads: 348 MB in  3.01 seconds = 115.79 MB/sec

 root@nescaya: hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   27778 MB in  2.00 seconds = 13910.40 MB/sec
 Timing buffered disk reads: 996 MB in  3.00 seconds = 331.96 MB/sec

root@nescaya: hdparm --direct -tT /dev/sda
/dev/sda:
 Timing O_DIRECT cached reads:   924 MB in  2.00 seconds = 461.40 MB/sec
 Timing O_DIRECT disk reads: 1402 MB in  3.00 seconds = 466.88 MB/sec

Gruß
ayla

[ralul]

@ayla
Ist doch klar dasselbe: der cached reads Test cached gar nicht ...

@holger
ich würd mich trotzdem nochmal für ein output interessieren
/sbin/gdisk -l /dev/sda

[holgerw]

Hallo Ralph,

hier schicke ich Dir die gewünschte Ausgabe von gdisk:

Code: [Select]

biber:/home/holger # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 117231408 sectors, 55.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 1037213A-A25D-41BA-8BC4-77168FF7DE30
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 117231374
Partitions will be aligned on 2048-sector boundaries
Total free space is 16570093 sectors (7.9 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        41945087   20.0 GiB    EF00  Linux/Windows data
   2        41945088        83888127   20.0 GiB    0700  Linux/Windows data
   3        83888128       100663295   8.0 GiB     0700  primary
biber:/home/holger #

Viele Grüße,
  Holger

[devil]

Ich habe mir heute noch mal meinen Artikel durchgeschaut. Dabei fiel mir auf, dass der nicht mehr ganz korrekt ist. Durch Änderungen am Debian Dateisystem musste ich Kapitel "TRIM testen" und "Browser-Cache ins Ram auslagern" leicht abändern. Die Einträge für shm, die vorher auf /dev/shm lauteten, lauten jetzt /run/shm.

greetz
devil