Siduction Forum
Siduction Forum => Hardware - Support => Topic started by: holgerw on 2011/12/29, 11:46:01
-
Hallo,
seit einigen Tagen habe ich eine OCZ Agility3 mit 60 GB Speicherkapazität.
Ich habe sie per SATA3 Kabel an mein Mainboard angeschlossen, sie wird als /dev/sdb angezeigt. Ein hdparm -tT /dev/sdb zeigt bei Schreiben einen stolzen Wert von knapp 400MB poro Sekunde an.
Nun bin ich der Platte nach Devils Anleitung zu Leibe gerückt, um sie optimal einzurichten. Im Bios habe ich AHCI Modus eingestellt, ein write back caching habe ich bei den Einstellungen nicht gefunden.
Da ich wegen gpt bei meinem Bios nicht sicher war, habe ich laut Anleitung mit fdisk weiter gemacht. Aber schon der erste Aufruf zeigte mir eine ganz andere Ausgabe.
Dann habe ich über OpenSUSE 12.1 mit dem Partitionierer von YaST mein Glück versucht, das Programm bot mir gpt oder mbr beim Erstellen einer Partitionstabelle an. Ich habe mal gpt verwendet und dann Partitionen angelegt. Mein PC kommt wohl doch mit gpt klar, beim Booten taucht vor Erscheinen von Grub noch kurz eine Art Tabelle in den Bios Meldungen auf, die ich zuvor nicht gesehen hatte.
Nun schert sich YaST aber wohl wenig um Optimierungen beim Einrichtwen einer SSD, vielleicht hätte ich im Expertenmodus noch Sachen ändern müssen, ein hdparm -tT /dev/sdb bringt nun beim Schreiben magere 210 MB pro Sekunde.
Da ich die Platte nicht kaputt testen und sie oprtimal einbrichten möchte: Wie gehe ich nun vor? Am liebsten würde ich alle Einstellungen samt der Partitionstabelle löschen, und dann noch einmal mit gdisk nach Ferdinands HowTo vorgehen. Meine andere Festplatte richte ich dann auch gleich mit gpt ein.
Wie bekomme ich die SSD wieder in einen nackten Zustand, ohne sie groß zu belasten?
Viele Grüße,
Holger
-
Es gibt von OCZ für Linux ein Tool in Form eines ISO-image namens ocz-fwupd.iso (133 MBte) unter http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool. Damit kannst Du unter anderem die Firmware updaten und die SSD in den Auslieferungszustand zurückversetzen.
greetz
devil
-
Hallo Ferdinand,
danke für den Hinweis. Ich versuche morgen noch einmal, das Iso herunter zu laden. Der Server mit dem ocz Forum ist wohl zur Zeit überlastet.
Viele Grüße,
Holger
-
werd die tage auch mal mit ssd installieren, hoffentlich brauch ich die iso nicht ;)
-
Hallo,
ich habe nun die ssd umgestöpselt, so dass sie als /dev/sda erkannt wird, mit dem ISO vomn OCZ habe ich die Firmware überprüft, es war die neueste schon installiert, dann habe ich sie mit dem Erase Werkzeug auf dem ISO komplett gelöscht.
Nach Devils Anleitung habe ich die ssd mit gpt versehen und dann zwei Partitionen erzeugt, die Anzeigen stimmten mit denen in Devils Howto weitgehend überein.
Diese habe ich mit ext4 formatiert, auf der ersten Partition habe ich dann siduction xfce 64 Bit installiert.
Trim habe ich mit discard aktiviert, noatime ist natürlich auch in der fstab.
Ein stinknormales hdparm -tT zeigt mir nun bei meiner ssd an:
/dev/sda:
Timing cached reads: 4024 MB in 2.00 seconds = 2012.71 MB/sec
Timing buffered disk reads: 524 MB in 3.01 seconds = 174.13 MB/sec
Bei meiner normalen Festplatte:
/dev/sdb:
Timing cached reads: 4058 MB in 2.00 seconds = 2029.19 MB/sec
Timing buffered disk reads: 412 MB in 3.01 seconds = 136.96 MB/sec
Da stimmt doch etwas überhaupt nicht. Die Festplatten sind mit SATA3 Steckern angeschlossen, AHCI ist aktiviert, und die Geschwindigkeit der Ports auf 6 GB/s gestellt.
Beim ersten Testen nach dem Anschließen noch vor sämtlichen Tuningversuchen mit fdisk, gdisk und weiterem waren die hdparm Werte mehr als doppelt so groß.
Unter dem OCZ Iso ist es übrigens nicht viel besser, es liegt also nicht an siduction.
Ich finde allerdings folgendes eigenartig:
Das System startet schon viel schneller, vom Grub bis zum gdm3 vergehen knapp 10 Sekunden, nach dem Return der Paßworteingabe beim gdm3 habe ich in knapp 5 Sekunden xfce4 mit cairo-dock geladen. Nach einem frischen Neustart braucht LibreOffice nach dem Anklicken gerade mal 2 Sekunden, Icedove ist auch in 2 Sekunden geladen. Das ist meines Erachtens schon sehr flott.
Aber laut hdparm ist da wohl noch einiges nicht in Ordnung. Oder spinnt hdparm? Dann spönne es aber ebenso unter der OCZ ISO wie auch unter OpenSUSE, da iat es nicht besser mit den Werten.
Viele Grüße,
Holger
-
Hallo Holger,
mal zum Vergleich, bei mir sieht das so aus:/dev/sda:
Timing cached reads: 3310 MB in 2.00 seconds = 1654.60 MB/sec
Timing buffered disk reads: 396 MB in 3.00 seconds = 131.93 MB/sec
/dev/sdb:
Timing cached reads: 3242 MB in 2.00 seconds = 1621.01 MB/sec
Timing buffered disk reads: 252 MB in 3.02 seconds = 83.50 MB/secsda ist eine OCZ Vertex, sdb eine "normale" Festplatte, beide per SATA II (ahci) angeschlossen.'noatime und 'discard' sind in der fstab aktiviert, sonst ist nichts getuned.
Das System startet sehr flott und auch der Desktop läuft wesentlich flotter als vorher auf einer normalen HD.
Viele Grüße
Ralf
-
Hm, da liegt doch was total im Argen.
Hier meine Werte von heute (nach mehr als 6 Monaten in Benutzung)/dev/sda:
Timing cached reads: 26856 MB in 2.00 seconds = 13448.41 MB/sec
Timing buffered disk reads: 1118 MB in 3.00 seconds = 372.60 MB/sec
Ich kann aber jetzt beim besten Willen nicht sehen was da (zumindest bei Holger)nicht stimmt. Zu Vertex 2 hab ich keine eigenen Vergleichswerte.
greetz
devil
-
OCZ RevoDrive, on the PCI-e bus:
/dev/sda:
Timing cached reads: 17356 MB in 2.00 seconds = 8688.42 MB/sec
Timing buffered disk reads: 598 MB in 3.00 seconds = 199.03 MB/sec
-
ich hab ähnliche ergebnisse wie holger mit ner vertex 3 128gb
/dev/sda:
Timing cached reads: 1874 MB in 2.00 seconds = 936.57 MB/sec
Timing buffered disk reads: 386 MB in 3.01 seconds = 128.37 MB/sec
dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 5,08539 s, 211 MB/s
-
OCZ Vertex 3 60GB:
/dev/sda:
Timing cached reads: 27696 MB in 2.00 seconds = 13868.26 MB/sec
Timing buffered disk reads: 996 MB in 3.00 seconds = 331.58 MB/sec
Edit: dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 2,56783 s, 418 MB/s
/Edit
Die Disk ist allerdings direkt an einem SATA3 -Port angeschlossen.
Gerade erst komplett gelöscht und nach devils Anleitung neu angelegt, ohne das OCZ-Werkzeug. Also Partitionstabelle neu geschrieben und neue Partitionen angelegt und ext4 formatiert.
Wert einer OCZ agility 2 über eSATA lag bei ca 180MB/sec buffered reads.
Gruß
Jürgen
-
Hallo,
ich habe eine Agility3, oder OCZ hat die SSD falsch bedruckt ;-)
Folgendes spricht allerdings nicht für einen Etikettenschwindel:
root@biber:/home/holger# hdparm -i /dev/sda
/dev/sda: Model=OCZ-AGILITY3, FwRev=2.15, SerialNo=OCZ-C844CC2EOXX4O0RR
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117231408
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-2,3,4,5,6,7
* signifies the current active mode
Danke für Eurer Interesse. Ich werde heute folgendes tun:
Beim Einbau der SSD fehlte mir ein SATA3 Kabel. Ich habe dann das SATA3 Kabel von meinem DVD Brenner genommen und den Brenner mit einem SATA2 Kabel bestückt. Vor einigen Monaten habe ich einen älteren DVD Brenner zusätzlich eingebaut, der hat auch ein SATA2 Kabel.
Den alten Brenner werde ich wieder ausbauen, und der neuere bekommt nun auch ein SATA3 Kabel verpasst.
Ich vermute, das Mainboard passt die Geschwindigkeit bei einem Verbund aus SATA2 und SATA3 der langsameren Verbindung an.
Hoffentlich stimmt meine Vermutung.
Viele Grüße,
Holger
-
Durchaus möglich, Holger.
Aber auch die Qualität des Kabels in Betracht ziehen.
Ich hatte da gewaltige Unterschiede in der notwendigen
Fehlerkorrektur, inzwischen habe ich alle "mitgelieferten" Kabel gegen im Fachhandel gekaufte (mit Clip) ausgetauscht.
Gruß
ayla
-
Hallo @ayla,
das ist hier ziemlicher Murks. Ich habe an der OCZ Agility3 und an meiner normalen Platte nun zwei neue SATA3 Kabel. Ich habe im Bios unter der OCZ3 den DMA Mode von Auto auf UDMA6 gestellt.
Die Platte zeigt unbeeindruckt davon weiterhin magere 2080 M/s Lesegeschwindigkeit und 160M/s Schreibgeschwindigkeit.
Mittlerweile bin ich schon etwas verärgert. Ich hätte die 90 Euro wohl besser gespart. Eigentlich erwarte ich, dass solche Hardware nach dem Anschließen ohne Gefrickel optimal läuft.
Viele Grüße,
Holger
-
hmm, da fällt mir auch nicht mehr viel zu ein.
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?
Was hast Du für eine Geschwindigkeit wenn Du nur die SSD alleine auf Deinem SATA3 - Port hast?
AFAIK dürfte ein SATA3 für ein DVD-Laufwerk nicht nötig sein weil die Geschwindigkeit sowieso nicht ausgenutzt wird -kann mich da aber täuschen.
Gruß
ayla
-
holgerw: Bei meinem Bruder half ein Bios Update des Mainboards, er hat auch eine Agility3, wichtig ist auch die neueste Firmware der Agility3. Nach diesen beiden Updates läuft kubuntu bei meinem Bruder nun störungsfrei und ultraperformant (kubuntu start bis Desktop ca. 5 Sekunden).
Unter http://www.ocztechnology.com/ssd_tools/OCZ_Vertex_3,_Vertex_3_Max_IOPS,_Agility_3,_Solid_3,_RevoDrive_3,_RevoDrive_3_X2_and_Synapse_/ kannst du die neueste Firmware holen.
//edit Sehe gerade, das deine Agility 3 ja schon die 2.15 drauf hat, kanns eigentlich nur noch am MoBo BIOS liegen.
-
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
-
(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.
-
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.
-
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
-
Der erste Beitrag sagt aber auch:
"Nun bin ich der Platte nach Devils Anleitung zu Leibe gerückt, um sie optimal ..."
-
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.
-
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
-
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
-
--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.
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
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
-
Hallo Ferdinand,
nun bei mir unter OpenSUSE, siduction muss ich noch neu auf der SSD installieren:
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
-
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"
-
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
-
@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
-
Hallo Ralph,
hier schicke ich Dir die gewünschte Ausgabe von gdisk:
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
-
Ich habe mir heute noch mal meinen Artikel (http://siduction.org/index.php?module=news&func=display&sid=32) 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
-
@Holger, ja sieht gut aus. Wenn dein System die letzten 20 Prozent der anderen hier nicht erreicht, ist es wohl doch eine Hardware Qualitätsfrage, irgendwelche Leitungsstörungen, etc.
-
Das liegt einfach daran, dass eine Agility keine Vertex 3 ist.
greetz
devil
-
Hallo,
@Holger, ja sieht gut aus. Wenn dein System die letzten 20 Prozent der anderen hier nicht erreicht, ist es wohl doch eine Hardware Qualitätsfrage, irgendwelche Leitungsstörungen, etc.
Das liegt einfach daran, dass eine Agility keine Vertex 3 ist.
Ich bin aber doch zufrieden, denn wie ich hier auch schon schrieb, ist der Rechner ja deutlich schneller, weder OpenSUSE noch siduction snd hier vor Einbau der SSD dermaßen schnell hochgefahren, und ein frisch gestartetes Libreoffice in weniger als zwei Sekunden zu haben, macht richtig Spaß.
@Ferdinand, vielleicht kannst Du die Option --direct in Deinem Artikel vermerken, ich habe auch nach Durchsicht einiger andere Kommentare hier in diesem Thread den Eindruck, dass ohne diese Option die Ergebnisse stark verfälscht werden können, und die Werte mager sind, obwohl der PC viel flotter arbeitet.
Viele Grüße,
Holger