OS-Optimierungen für Flash-SSDs

Ich habe ein paar Gedanken zum Booten, die ich gerne mit euch teilen möchte. Kurz zum Hintergrund: Habe (noch) keine SSD, benutze XP und habe mir gerade den Startvorgang angesehen, der ja mit einer (guten) SSD deutlich schneller läuft. Ich nutze selbst überwiegend Standby (S3), aber trotzdem einige Erkentnisse:

  • Beim Start meines XP (2 Jahre alt, typische Vielnutzer-Installation) werden 216 MB an Daten gelesen
  • Ich habe mir die Dateien per Zugriffsprotokoll angesehen:
    • Gesamt 879 Dateien (inkl. Autostart, z.B. Skype)
    • 150 Dateien sind < 1 KB
    • 204 Dateien sind 1 KB bis 10 KB
    • 262 Dateien sind 10 KB bis 100 KB
    • 226 Dateien sind 100 KB bis 1 MB
    • 37 Dateien sind > 1 MB, Spitzenreiter Skype.exe mit 22 MB
  • Der Bootvorgang dauert etwa eine Minute (5.400er-Platte). Wenn davon auch nur ein Drittel auf die Lesevorgänge der Platte entfällt, ist das schon eine riesige Verschwendung! Grund: Man könnte doch die oben genannten 216 MB in eine große Datei packen, diese bei jedem Booten in den RAM laden und von dort aus weiterstarten:
    • Die Datei könnte einmalig angelegt werden und 1x pro Monat aktualisiert werden
    • Laden der Datei in den RAM beim Booten dürfte 3 Sekunden dauern
    • Fehlen Dateien im RAM, wird dieser Rest eben "normal" von der Platte geladen
Problem ist wohl, dass Windows keine solche Mechanik unterstützt? Ist doch eigentlich kein rocket science! Könnte man sowas basteln? Ich meine, auch eine SSD ist beim Zugriff auf kleine Dateien langsamer. Dafür läd sie die 200 MB aber in 2 Sekunden, und im RAM sind Wartezeiten nahe null anzunehmen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen ;) )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.
Und den ganzen Kram schon im Ram zu speichern ist nicht möglich.. sobald der PC aus ist, ist der Ram wieder leer. ;)
Beim Booten geht die meiste Zeit für die Initialisierung von Hardwareteilen oder Diensten drauf. Ich hab in meinem Notebook eine lahme 5400er gegen eine 16GB Mobi ersetzt. Booten geht zwar schneller, aber dauert trotzdem noch ca. 50Sek. und der XP-Balken muss 6mal durchlaufen. Aber nur bei 1-2 Balken zwischendurch leuchtet mal eben die SSD/HDD-Lampe auf, ansonsten langweilt die sich zu Tode. :d
 
Ich habe mal einige Tests durchgeführt mit verschiedenen Dateisystemen, Clustergrößen und Alignments.

Tests durchgeführt mit PCMark05 (File Write Bench) und einem Transcend 2GB Flash Modul.

STANDARD-AUSRICHTUNG ("krumme" 32 KB):

26.297 - fat32 16k
26.113 - fat16 64k
26.002 - fat16 32k
25.994 - fat32 512b
25.936 - ntfs 16k
25.664 - ntfs 4k
25.251 - ntfs 64k
25.196 - ntfs 512b

OPTIMIERTE AUSRICHTUNG (16 MB):

26.767 - fat16 64k
26.667 - fat32 16k
26.632 - fat16 32k
26.306 - ntfs 4k
26.161 - fat32 512b
26.069 - ntfs 64k
25.608 - ntfs 16k
25.294 - ntfs 512b


FAZIT:

Mit der optimierten Ausrichtung war alles insgesamt 1,5% schneller. FAT ist schneller als NTFS. Je höher die Clustergröße, desto höher die Geschwindigkeit.
Vielleicht stellt ja jemand ähnliche Tests an?

Bei mir war der Abstand merkbar, aber längst keine 18% wie bei antiram. Liegt das an nilfs?

Gute Nacht ;)
 
Zuletzt bearbeitet:
crysel schrieb:
Wieso sollte das Laden der Daten in den Ram schneller gehen als das ganz normale Laden beim Hochfahren (du musst die Daten doch irgendwie in den Ram schreiben bzw. von deiner HDD erstmal lesen ;) )? Der Knackpunkt ist und bleibt die lesende Festplatte, wobei selbst eine alte 5400er deine 216MB in wenigen Sekunden gelesen haben wird.
Zum Vergrößern anklicken....

stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.
 
Was bei einer SSD wiederrum auf 80-240ms reduziert werden würde :-)
 
DerRob schrieb:
stichwort zugriffszeit. für die eine 216mb-datei brauchst du 1x etwa 15ms, um auf die datei zuzugreifen. für die 879 einzelnen dateien brauchst du allerdings schon etwa 13 sekunden, um überhaupt auf die dateien zuzugreifen.
Zum Vergrößern anklicken....

Naja, ok das hast du Recht. Aber dann müsste man erstmal eine große Datei hinbekommen.. könnte natürlich gezippt werden, dann beim Start in den Ram, dort entpacken lassen (sollte ja wesentlich schneller gehen :d ) und dann laden... da es sowas für den Bootvorgang aber nicht gibt --> SSD :p :d
 
crysel schrieb:
da es sowas für den Bootvorgang aber nicht gibt
Zum Vergrößern anklicken....
So'n bißchen gibt's das schon u. wird von Microsoft ständig weiterentwickelt. Der Defragmentierer legt sich die Dateien, die er für's booten benötigt schon zusammen. Vista analysiert angeblich auch selbsständig die bootlogs u. baut das entsprechend um.

Das Problem entsteht ein klein bißchen weiter hinten im Bootprozess: Wenn die Services geladen werden bzw. spätestens beim Autostart: Die starten alle parallel und nicht staggered. Die Dateien sind auch nicht gerade klein: Viruskiller, verschiedene Updater, Skype, ... Da rennt der Schreib-/Lesekopf nur hin und her.

SSDs werden schon über kurz oder mittellang die Systemplatte ersetzen. Denn irgendwie tut sich Microsoft schwer den Bootprozess zu verkürzen - auch wenn sie ständig Verbesserungen einbauen (die aber von anderen Dingen wieder aufgefressen werden).

bg,
7oby
 
wie finde ich heraus, wie groß meine Eraseblocks sind um mein Alignment richtig anzupassen ?

Im ersten Beitrag unter Vorbereitung kommt man auf einen Post,der auf das OCZ Forum widerum verweist, dieser Link ist jedoch für User gesperrt. Hab mich sogar extra dort angemeldet, aber auch so kann man nicht drauf zugreifen!
 
iometer nehmen und dann testen
128k; 100% random; 100% write; align I/O on 128k
256k; 100% random; 100% write; align I/O on 256k
512k; 100% random; 100% write; align I/O on 512k
1M; 100% random; 100% write; align I/O on 1M
2M; 100% random; 100% write; align I/O on 2M
4M; 100% random; 100% write; align I/O on 4M
8M; 100% random; 100% write; align I/O on 8M
16M; 100% random; 100% write; align I/O on 16M
32M; 100% random; 100% write; align I/O on 32M

die average I/O response time steigt zuerst langsam an. Ab einer bestimmsten Blockgröße (test x) verdoppelt sie sich dann immer im Vergleich zum vorherigen Blockgröße. Die Blockgröße bei test x ist die Größe der Eraseblocks.
zb.
1M Test: average I/O response time ca. 300ms
2M Test: average I/O response time ca. 600ms
4M Test: average I/O response time ca. 900ms
8M Test: average I/O response time ca. 1200ms <----- Größe der Eraseblocks = 8MB
16M Test: average I/O response time ca. 2400ms
32M Test: average I/O response time ca. 4800ms

im Anhang als iometer pattern. Bin mir aber nicht sicher obs woanders läuft weil ich es händisch editiert habe.
 

Anhänge

  • eraseblocktest.zip
    1,1 KB · Aufrufe: 502
Zuletzt bearbeitet:
ich hab im ocz forum folgendes gefunden:

The default settings are normally the most desirable settings, with the exception of the “KB Write Block Size,” which uses a default value of 2048. Choosing the proper value is as much a function of the Flash SSD controller ASIC as anything else. The following are the different values we would recommend for different brands of drives:

2048 Mtron, Samsung, Sandisk, and Intel

8192 MyDigitalSSD

16384 Ridata, Transcend, SuperTalent, Patriot

16384 OCZ Core 1 and Core 2

If you are uncertain of the proper value, and have not contacted us about a choice, we suggest using 8192 as a generally useful default value for unknown drives.
Zum Vergrößern anklicken....
werde es selbst mal testen, aber so weiss ich ungefähr, was mich erwartet :)
 
Da es sich offenbar noch noch nicht herumgesprochen hat werd ich mal den Erleuchter spielen :cool:
Unter WinXP32 kann man den ausgeblendeten Ram bis 4GB und darüber hinaus für eine Ramdisk nutzen :eek:
Hier im Bootland gibts einen interessanten Thread über alle möglichen Ramdisk Treiber, die aktuellste Gavotte RAMDisk 1.0.4096.5 200811130.
Funzt bei mir ganz gut(4GB auf WXP32 home mit boot.ini /PAE /3GB). Die Ramdisk nutzt bei der PAE Einstellung offenbar ausschließlich den ausgeblendeten Speicher, egal was für eine Diskgröße man einstellt. Das sind bei mir etwa 768MB, also grad so ausreichend :rolleyes:
Aber wer will, der kann es ja mit bis zu 64GB, wenn ich das richtig verstanden hab, ausprobieren :eek: :stupid:
 
@ vander

Interessant :)


@ all

Weiss jmd wie man unter Vista x64 das Config-Tool "RAMDrivProperties" zum Laufen bekommt? Unter x86 geht es.
 
Freddy Mercury schrieb:
...
Man könnte doch die oben genannten 216 MB in eine große Datei packen, diese bei jedem Booten in den RAM laden und von dort aus weiterstarten:
...
Problem ist wohl, dass Windows keine solche Mechanik unterstützt? Ist doch eigentlich kein rocket science! Könnte man sowas basteln? Ich meine, auch eine SSD ist beim Zugriff auf kleine Dateien langsamer. Dafür läd sie die 200 MB aber in 2 Sekunden, und im RAM sind Wartezeiten nahe null anzunehmen.
Zum Vergrößern anklicken....
So, bin grad beim Thread öffnen über dein Posting gestolpert, k.A. warum ich das bisher übersehen hab :banana:
Du hast etwas zu einfach gedacht :hmm:, es werden nicht nur einfach die Executables geladen, hier werden die Geräte initialisiert(Stichwort: Timeout und Wartezeiten zur Ladezeit addieren), es werden evtl. Datendateien nachgeladen(oder hast du die auch in deinem Logfile :rolleyes:?) und einige der Programme entpacken sich eventuell. Alles in allem eine recht komplexe Angelegenheit die schnell undurchschaubar werden kann. Deshalb ist es einfacher, schneller und sicherer mal eben den kompletten Ram + den Konfigurationszustand aller Geräte in eine Datei zu sichern(wenn die Geräte so ein Vorgehen per Treiber unterstützen, dann können sie sich auch selbst neu initialisieren).
Übrigens klingt diese Technik entfernt so ähnlich wie Rocket Science und Wunder über Wunder, Windows kann das sogar schon :eek:
Yap, der gute alte Ruhezustand läßt grüßen :wink:
 
antiram schrieb:
iometer nehmen und dann testen

......
Zum Vergrößern anklicken....

besten dank .... ich hab mich dämlich gesucht nach dem eraseblock meiner ssd

nach deinem hinweis liegt die verdoppelung bei der SSD Mobi 3500 (3525) von 2 auf 4MB
somit ist der eraseblock 2mb groß ?

könnte wer bei seiner mobi die ergebnisse mal verifizieren ?
 
Zuletzt bearbeitet:
Wie kann man Acronis True Image beibringen die Partitionen auch dorthin zu legen wo man sie gerne hätte...die SSD war so schön aligned vorher..jetz gleich nochmal..nur wie?
 
Die einfachste Variante für mich(mit dem Ghost), einfach ne aligned Partition anlegen und dann vom Image in die Partition schreiben. Sollte doch mit jedem Backup Prog klappen das in Partitionen zurücksichern kann.
Die aligned Partition hab ich der Einfachheit halber mit der VISTA InstallDVD erstellt.
 
erstmal danke an antiram für deine ausführungen .. hat mir sehr geholfen.
auch an HISN der oben ungewöhnlich ausführlich ;-) tipps konsolidiert.

ich habe gestern abend noch bis in die nacht div. settings durch den bench gejagt.
da ich meine vergleichsweisen schlechten write werten noch nicht ganz beheben konnte.
die read werte meiner Mobi 3525 sind hingegen top.
problem ist aber nicht die SSD (treiber,oder firmware).
hier scheint generell der controller dir ursache zu sein.
denn auch bei 3x getestete HDDs sind die write werte 512KB und 4KB eher mittelklasse.

habe mein optimum für den ICH10 und der SSD bei dem alignment mit 64 ausgemacht.
der unterschied zu 128 ist aber marginal im 4KB (- 0,05MBs).
im vergleich zu höheren werten im aligment (oder auch kein alignment)
bringen beide werte jedoch eine verdoppelung im 4KB test. 512KB nur marginal (ggf sogar nur messtoleranz).

gänzlich unberührt vom alignment bleiben die read werte.
ebenfalls ohne nennenwerte auswirkung bei mir die allocation size...
egal ob windows standard, 512,2048,4096, 32k,64k... wirkt sich nicht erkennbar aus.

habe alle durchläufe mit write cache im IDE gefahren.
denke ohne writecache würden die werte eher sinken .. da bei mir der controller der übeltäter ist ..
dürfte die writecache funktion sich in meinem fall positiv auswirken.

fazit .. bin aber nach der verbesserung dennoch sehr zufrieden mit der performance (4K = 1,3MBs).
aber befürchte .. am wochenende muss sich mein fileserver von seinem areca controller verabschieden =)

wenn interesse an den detail ergebnissen besteht .. hänge ich die tabelle auf wunsch gerne an..

greetz
 
Zuletzt bearbeitet:
Kostenlose Alternative ist Gavotte Ramdisk (aber nicht die 1.1 Version, die ist Uralt).

@HisN
kann man auch die WBEM auch auf die Ramdisk umbiegen? Und kann ich das dann auch ohne ein Image speichern/laden laufen lassen? Sprich: einfach die Kiste aus machen und fertig. Oder muss ich was besonderes beachten?
 
Punkt 3 im Eingangspost.
Einfach per Registry umbiegen in die Ramdisk.
 
Ich finde den Tipp auch irgendwie seltsam und unnötig, gerade dass er nicht empfiehlt das Pagefile in ne RAM-Disk zu legen... Nein, er will's ja gleich abschalten! :-/

Der Großteil der anderen Tipps dort ist aber ok. Trotzdem würde ich das was dort drinnen steht garantiert _nicht_ irgendwo als Sticky stehen lassen!
 
@ sukrim
genau so sehe ich das auch! ich persönlich verwende nur die tipps die mir logisch erscheinen und die übrigen können andere ausprobieren ;)
jedenfalls bleibt meine pagefile an
 
Swap-Datei in die Ramdisk oder ganz abschalten halte ich persönlich auch für Nonsense. Deshalb kommt das nicht in Post #1. Genau das gleiche mit dem 2n Level-Cache, das war für Prozessoren die den noch nicht im DIE hatten. Gibts sowas heute noch?
@Snoopy
Superfetch schau ich mir genauer an, bzw würdest Du vielleicht erläutern warum Du das wie oder nicht benutzen würdest?
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh