staging.inyokaproject.org

Die Diskussion stellt die Fortsetzung von Artikel zu SSD dar. Evtl wird auf dortige Posts bezug genommen.

noisefloor schrieb:

• Baustelle/SSD/Geschwindigkeitstest gilt in weiten Teilen für alle HDs

Huhu!

Gibt es denn schon einen Artikel Speedtests? Oder etwas Vergleichbares? Oder müsste der, wie quasi fdisk, neu angelegt werden?

Liebe Grüße,

Flo

Hallo,

AFAIK gibt es sowas nicht.

Gruß, noisefloor

Hallo,

und, wie geht's hier weiter?

Gruß, noisefloor

Ich finde den Artikel vollständig, korrekt und 100% SSD-bezogen (wer macht das schon mit seiner alten Magnetplatte?). Beim "fine tuning" einer SSD ist er wirklich nützlich oder gar Voraussetzung.

Mein Votum: gut und fertig.

Viele Grüße,
Ingo

Guten morgen ☺

ingo2 schrieb:

Ich finde den Artikel vollständig, korrekt und 100% SSD-bezogen (wer macht das schon mit seiner alten Magnetplatte?).

Letzteres dient aber auch nur als Grund, weil im Moment ein SSD-Hype da ist. Wenn SSDs einmal Standard werden sollten, interessiert die Geschwindigkeit auch niemanden mehr. Ich sehe keinen 100%igen SSD-Bezug. Das sind Befehle die man auf jede HD los lassen kann.

Beim "fine tuning" einer SSD ist er wirklich nützlich oder gar Voraussetzung.

Im Artikel taucht kein einziger Link auf, der irgendwie mit fine-Tuning von SSDs etwas zu tun hat 😕

Wie wäre es, wenn man das ganze etwas strafft und in Tuning#Festplatte einbaut?

Oder jemand schreibt einen Artikel zu hdparm und den Teil mit dd könnte man dann in Shell/dd unterbringen.

Sorry für meine Meinung
kaputtnik

kaputtnik schrieb:

Wenn SSDs einmal Standard werden sollten, interessiert die Geschwindigkeit auch niemanden mehr.

😲
Die Speed ist doch – mehr oder weniger – der einzige Grund, sich eine SSD zu kaufen? Und: Alleine zum Einrichten der SSD habe ich zigmal die Speed getestet. Einfach, um zu verifizieren, ob z. B. eine Änderung des SSD/Scheduler etwas gebracht hat.

Ich sehe keinen 100%igen SSD-Bezug. Das sind Befehle die man auf jede HD los lassen kann.

Da gebe ich Dir recht. Natürlich kann man die auch auf eine HDD loslassen. Dazu kann ich aber nicht wirklich etwas sagen, da mir beim Einsatz einer HDD keine Einsatzmöglichkeiten einfallen: HDD einbauen, anklemmen, fertig. Was will man da (und vor allem für was) noch groß tunen?

Im Artikel taucht kein einziger Link auf, der irgendwie mit fine-Tuning von SSDs etwas zu tun hat 😕

Link nicht, aber es wird ausführlich beschrieben, wozu diese Tests gut sind.

Wo der Artikel schlussendlich auftaucht, ist mir wurscht. Den einzigen Wunsch den die ich habe, ist, dass der Artikel nicht gesplittet wird und SSDler die Speedtests über drei Artikel zusammensuchen müssen. Das wäre kontraproduktiv.

Liebe Grüße,

Flo

kaputtnik schrieb:

Oder jemand schreibt einen Artikel zu hdparm .....

Sorry für meine Meinung
kaputtnik

Die vollständige Dokumentation gibt es schon hier. Ob es Sinn macht, das alles in UU-Form zu bringen und einen Roman daraus zu machen, bezweifele ich.

hdparm ist ein sehr mächtiges, aber auch potentiell gefährliches Werkzeug mit zig Optionen. Ist auch geeignet, um eine HD in die ewigen Jagdgründe zu schicken 😉

Viele Grüße,
Ingo

Hi,

bitte nicht übel nehmen, aber ich kann die hier genannten Dinge nicht nachvollziehen

UbuntuFlo schrieb:

Die Speed ist doch – mehr oder weniger – der einzige Grund, sich eine SSD zu kaufen? Und: Alleine zum Einrichten der SSD habe ich zigmal die Speed getestet. Einfach, um zu verifizieren, ob z. B. eine Änderung des SSD/Scheduler etwas gebracht hat.

Rein aus Interesse: In welchem Bereich lagen die Änderungen?

Ich sehe keinen 100%igen SSD-Bezug. Das sind Befehle die man auf jede HD los lassen kann.

Da gebe ich Dir recht. Natürlich kann man die auch auf eine HDD loslassen. Dazu kann ich aber nicht wirklich etwas sagen, da mir beim Einsatz einer HDD keine Einsatzmöglichkeiten einfallen: HDD einbauen, anklemmen, fertig. Was will man da (und vor allem für was) noch groß tunen?

Tuning#Festplatte; Es gibt und gab schon immer Tuningmöglichkeiten für Festplatten und andere Geräte. Genau das was Du hier sagst, wird vllt in ein paar Jahren genauso für SSD gelten: SSD einbauen, anklemmen, fertig. Was will man da (und vor allem für was) noch groß tunen? 😉

Im Artikel taucht kein einziger Link auf, der irgendwie mit fine-Tuning von SSDs etwas zu tun hat 😕

Link nicht, aber es wird ausführlich beschrieben, wozu diese Tests gut sind.

Aha... Wozu sind Geschwindigkeitstests gut? Oh, um die Geschwindigkeit zu messen... wusste ich gar nicht... 😇

Ne im Ernst: Was ich möchte ist lediglich ein Linkbereich, der auf Optimierungsmöglichkeiten hinweist. Ihr verlinkt zwar von anderen Artikeln auf diesen, aber wenn dieser Artikel durch die Suche gefunden wird, steht der Leser im Regen, weil er nicht weiß, wie er wo was optimieren kann.

Wo der Artikel schlussendlich auftaucht, ist mir wurscht. Den einzigen Wunsch den die ich habe, ist, dass der Artikel nicht gesplittet wird und SSDler die Speedtests über drei Artikel zusammensuchen müssen. Das wäre kontraproduktiv.

Dann sind viele Seiten hier im Wiki kontraproduktiv.

Wie wäre es, wenn man den Artikel allgemein HD-Geschwindigkeitstest nennen würde? Unabhängig von SSD. Dann kann man zB auch von Tuning#Festplatte hierhin verlinken.

ingo2 schrieb:

Die vollständige Dokumentation gibt es schon hier. Ob es Sinn macht, das alles in UU-Form zu bringen und einen Roman daraus zu machen, bezweifele ich.

Nicht jeder ist dem englischen so mächtig, das er diese Man-Page versteht.

hdparm ist ein sehr mächtiges, aber auch potentiell gefährliches Werkzeug mit zig Optionen. Ist auch geeignet, um eine HD in die ewigen Jagdgründe zu schicken 😉

Das ist ein Argument für einen Artikel, nicht dagegen 😉

Gruß
kaputtnik

Huhu!

kaputtnik schrieb:

Rein aus Interesse: In welchem Bereich lagen die Änderungen?

Das korrekte Alignment brachte die SSD von 150 MB/s auf 230. Alle weiteren Anpassungen brachten sie nun auf die finale Speed von etwa 275. Das ist der Wert eines vollkommen optimierten Maverick mit ext4. Unter Natty habe ich nicht nicht optimiert (nur ausgerichtet) und ich bin in besagtem Bereich von +/- 240 MB. Es bringt also einiges.

Was ich möchte ist lediglich ein Linkbereich, der auf Optimierungsmöglichkeiten hinweist. Ihr verlinkt zwar von anderen Artikeln auf diesen, aber wenn dieser Artikel durch die Suche gefunden wird, steht der Leser im Regen, weil er nicht weiß, wie er wo was optimieren kann.

Hmm, dazu soll der obige Kasten da sein, der auf die SSD-Artikelserie hinweist. Alternativ kann man, wenn gewünscht, noch einen Linkbereich zu den einzelnen Optimierungen legen.

Wie wäre es, wenn man den Artikel allgemein HD-Geschwindigkeitstest nennen würde? Unabhängig von SSD. Dann kann man zB auch von Tuning#Festplatte hierhin verlinken.

Wenn der Artikel allgemeingültig ist, kann man das machen. Das kann ich allerdings nicht beurteilen, da ich den Artikel nur für und mit SSD-Einsatz geschrieben habe.

Liebe Grüße,

Flo

UbuntuFlo schrieb:

... Wenn der Artikel allgemeingültig ist, kann man das machen. Das kann ich allerdings nicht beurteilen, da ich den Artikel nur für und mit SSD-Einsatz geschrieben habe.

Also ich hab das jetzt alles mal mit meiner HDD durchgespielt.

foo@navis:~$ sudo hdparm -tT /dev/sda
[sudo] password for ed: 

/dev/sda:
 Timing cached reads:   578 MB in  2.00 seconds = 288.78 MB/sec
 Timing buffered disk reads:  138 MB in  3.04 seconds =  45.44 MB/sec
foo@navis:~$ sudo hdparm -tT --direct /dev/sda 

/dev/sda:
 Timing O_DIRECT cached reads:    52 MB in  2.08 seconds =  25.04 MB/sec
 Timing O_DIRECT disk reads:   86 MB in  3.01 seconds =  28.55 MB/sec
foo@navis:~$ cd /tmp/
foo@navis:/tmp$ 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, 21.0682 s, 51.0 MB/s
foo@navis:/tmp$ echo 3 > /proc/sys/vm/drop_caches 
bash: /proc/sys/vm/drop_caches: Keine Berechtigung
foo@navis:/tmp$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1.1 GB) kopiert, 22.3434 s, 48.1 MB/s
foo@navis:/tmp$ dd if=tempfile of=/dev/null bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1.1 GB) kopiert, 7.63127 s, 141 MB/s
foo@navis:/tmp$ rm tempfile 

Von den unterirdischen Werten einmal abgesehen, sehe ich nicht, warum das nicht auch mit einer HDD gehen sollte. Einzig das Löschen des Caches hat nicht hin gehauen (siehe Markierung).

–> Umbennen in HD-Geschwindigkeitstest +1

Dafür wäre es lediglich nötig die Hinweise am Anfang noch etwas allgemeiner zu halten. Wie wir in diesem Fall mit der Hinweisbox umgehen wollen, weiß ich ehrlich gesagt nicht. Ich finde schon, dass er innerhalb der Serie sinnvoll ist...

Liebe Grüße

martin

ramnit schrieb:

Von den unterirdischen Werten einmal abgesehen

🤣

Dafür wäre es lediglich nötig die Hinweise am Anfang noch etwas allgemeiner zu halten. Wie wir in diesem Fall mit der Hinweisbox umgehen wollen, weiß ich ehrlich gesagt nicht. Ich finde schon, dass er innerhalb der Serie sinnvoll ist...

Schau Dir mal an, ob die neue Version so besser ist.

Liebe Grüße,

Flo

ramnit schrieb:

foo@navis:/tmp$ echo 3 > /proc/sys/vm/drop_caches 
bash: /proc/sys/vm/drop_caches: Keine Berechtigung

Einzig das Löschen des Caches hat nicht hin gehauen (siehe Markierung).

Was passiert, wenn Du sudo benutzt? Vielleicht muss man das nur noch dazu schreiben? Vielleicht habe ich es auch vergessen. Ich muss das zu Hause nochmal antesten (hier nur Windows).

Liebe Grüße,

Flo

UbuntuFlo schrieb:

ramnit schrieb:

foo@navis:/tmp$ echo 3 > /proc/sys/vm/drop_caches 
bash: /proc/sys/vm/drop_caches: Keine Berechtigung

Einzig das Löschen des Caches hat nicht hin gehauen (siehe Markierung).

Was passiert, wenn Du sudo benutzt?

Hab die Zeile entfernt. Hatte ich aber auch probiert. Selber Fehler. Keine Berechtigung für SU ist ja eher selten... 😲

Wrgs, mein Fehler im Artikel (so glaube ich).

Versuche mal vor dem Kommando mit sudo -i in die Root-Shell zu kommen. Siehe auch Baustelle/SSD/Scheduler (Abschnitt „I-O-Scheduler-temporaer-setzen“).

Da der „normale“ sudo-Befehl in diesem Fall nicht funktioniert, wechselt man mit folgendem Befehl im Terminal in eine Rootshell...

Liebe Grüße,

Flo