Kurze Frage zu SSD-Festplatten (Boot-Geschwindigkeit, Qualität)

hallo,

ich habe die erste hier :

hdparm -i /dev/sdb

/dev/sdb:

Model=TS8GSSD25H-M, FwRev=20101227, SerialNo=2011090245383760529
Config={ HardSect NotMFM Fixed DTR>10Mbs }
RawCHS=15498/16/63, TrkSize=0, SectSize=576, ECCbytes=0
BuffType=DualPort, BuffSize=1kB, MaxMultSect=1, MultSect=off
CurCHS=15498/16/63, CurSects=15621984, LBA=yes, LBAsects=15621984
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=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-7

* signifies the current active mode

hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads: 2496 MB in 2.00 seconds = 1247.50 MB/sec
Timing buffered disk reads: 292 MB in 3.00 seconds = 97.27 MB/sec

Ich lasse auch noch mal iozone drüber laufen, damit man aussagekräftige Werte bekommt.

Gruß Fr@nk

was heißt normal, schneller als meine HDDs ist sie auf jeden Fall

Gruß Fr@nk

Zitat von lola

hdparm -tT /dev/sdb

/dev/sdb:
Timing cached reads: 2496 MB in 2.00 seconds = 1247.50 MB/sec
Timing buffered disk reads: 292 MB in 3.00 seconds = 97.27 MB/sec

Der hdparm-Test sagt nichts aus. Mein System:
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 1700 MB in 2.00 seconds = 850.44 MB/sec
Timing buffered disk reads: 356 MB in 3.01 seconds = 118.19 MB/sec

# hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 1634 MB in 2.00 seconds = 817.02 MB/sec
Timing buffered disk reads: 264 MB in 3.01 seconds = 87.57 MB/sec

Die erste Platte ist eine SSD mit 60GB, die zweite ist eine mech. von WD mit 1TB. Booten von der SSD von Power On bis VDR Bild dauert 30sec, bei der mech. 45sec. System ist ein verpatchtes Suse 11.2 mit vdpau.

Gruß
e9hack

Zitat von e9hack

Der hdparm-Test sagt nichts aus

stimmt, darum habe ich mal auf die SSD geschrieben und gelesen:

time dd if=/dev/zero of=/media/Data/test2 bs=1M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 32,7235 s, 32,8 MB/s

real 0m32.797s
user 0m0.006s
sys 0m2.677s

time dd if=/media/Data/test2 of=/dev/null
2097152+0 Datensätze ein
2097152+0 Datensätze aus
1073741824 Bytes (1,1 GB) kopiert, 10,6984 s, 100 MB/s

real 0m10.813s
user 0m1.051s
sys 0m3.639s

Zitat

Booten von der SSD von Power On bis VDR Bild dauert 30sec, bei der mech. 45sec. System ist ein verpatchtes Suse 11.2 mit vdpau.

sagt aber so auch nichts viel aus (außer, das es bei mir schneller geht )

Gruß Fr@nk

hallo,

hier noch mal ein Oberflächentest mit obiger SDD und Vergleich mit drei anderen HDDs auf gleicher HW und SW (Kernel 2.6.38 auf AMD 780/SB710 Chipset).

nur Lesetests, da Platten nicht leer sind

Gruß Fr@nk

Ein Festkörperlaufwerk ... interessant!

Zitat von FireFly

Ein Festkörperlaufwerk ... interessant!

jo , (kommt aus dem deutschen Wikipedia)

hier noch eines

und auch einen normalen USB Stick gemessen

Bei den Festkörpern fallen mir die periodischen Einbrüche der Transfergeschwindigkeit auf. Vielleicht sind das die Übergänge der internen Chips. Beim USB Stick wundere ich mich auch über die Ausreißer der Zugriffszeiten an den Enden

Gruß Fr@nk

Lola wie hast die schönen Grafiken gemacht? Dann könnte ich mal den USB3.0 Stick Benchmarken.

Johns

Hier ist eine Crucial m4 mit 64 GB (und aktueller Firmware) im Einsatz. Vom Einschalten bis zum Fernsehbild vergehen etwa 8 Sekunden. Intel-Board mit Fast Boot (verkürzt BIOS Post extrem), SSD an SATA 6G, Arch Linux + selbstgestrickter Rest. Im letzten c't-Heft (also nicht die neue vom kommenden Montag) wurde das SSD-Thema etwas beleuchtet. Einige SSDs für SATA 6G sind demnach nicht mehr so toll sparsam. Und die von CafeDelMar genannten SSDs gehören dort eher zu den langsameren Vertretern, die sich von modernen Festplatten im Durchsatz kaum unterscheiden (aber dennoch im Energieverbrauch, in den Zugriffszeiten und der Lautheit). Als Dateisystem hab ich ext4 gewählt, gemountet wird mit der Option discard für TRIM-Support. Außerdem hab ich das Journalsync von 5 auf 50 Sekunden hochgeschraubt. Meine Erfahrungen sind noch begrenzt, weil erst anderthalb Monate in Gebrauch. Würde mich über ein paar Tipps hier freuen!

$ hdparm -I /dev/sda
Model Number: M4-CT064M4SSD2
Firmware Revision: 0009


$ hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   11584 MB in  2.00 seconds = 5796.20 MB/sec
 Timing buffered disk reads: 1354 MB in  3.00 seconds = 450.95 MB/sec


$ hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   11986 MB in  2.00 seconds = 5997.13 MB/sec
 Timing buffered disk reads: 1372 MB in  3.00 seconds = 456.88 MB/sec


$ hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   11810 MB in  2.00 seconds = 5910.23 MB/sec
 Timing buffered disk reads: 1370 MB in  3.00 seconds = 456.67 MB/sec

Zitat von johns

Lola wie hast die schönen Grafiken gemacht?

mit Ksnapshot geschossen. Oder meinst Du, mit welchem Programm ich die Tests gemacht habe?

Gruß Fr@nk

Zitat von rechenknechtler

Und die von CafeDelMar genannten SSDs gehören dort eher zu den langsameren Vertretern

aber gerade beim Booten (je nach System einige 1000 recht kleine Dateien) macht sich die Zugriffszeit von 0,7ms zu 16 bzw. 17ms bei den Stromsparplatten deutlich bemerkbar. Solch kleine SSD macht sicher auch nur als Systemplatte Sinn.

Gruß Fr@nk

Zitat von lola

aber gerade beim Booten (je nach System einige 1000 recht kleine Dateien) macht sich die Zugriffszeit von 0,7ms zu 16 bzw. 17ms bei den Stromsparplatten deutlich bemerkbar.

Auf alle Fälle. Wenn man mit Standby technisch und gefühlsmäßig klarkommt, dann lässt sich wohl auf eine SSD im HTPC sowieso verzichten. Es gibt ein Projekt, das sich mit der von dir angesprochenen Problematik der verteilten Dateien auf ext4 beschäftigt. Da wird versucht die Dateien, die während dem Bootvorgang gebraucht werden, auf der Platte entsprechend hintereinander anzuordnen: E4RAT Steht noch auf meiner "Mal mit rumspielen!"-Liste...

Gruß

Zitat von rechenknechtler

Hier ist eine Crucial m4 mit 64 GB (und aktueller Firmware) im Einsatz. Vom Einschalten bis zum Fernsehbild vergehen etwa 8 Sekunden.

Das glaube ich irgendwie nicht. Mein System ist zwar nicht aktuell, aber auch nicht langsam. Das Starten des Kernels bis der Kernel-Log-Daemon beendet wird, dauert 11sec. Das Starten des VDR mit ein paar Plugins bis zum OSD dauert ca. 10sec. An 8 sec kann ich da nicht glauben.

klogd 1.4.1, log source = ksyslog started.
klogd 1.4.1, log source = ksyslog started.
<6>[    0.000000] Initializing cgroup subsys cpuset
<6>[    0.000000] Initializing cgroup subsys cpu
<5>[    0.000000] Linux version 3.0.4-64-suse-11.2 (root@vdr) (gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) ) #1 SMP PREEMPT Tue Aug 30 13:30:52 CEST 2011
<6>[    0.000000] Command line: root=/dev/disk/by-id/ata-OCZ-VERTEX2_OCZ-xxxxxx-part1 resume=/dev/disk/by-id/ata-OCZ-VERTEX2_OCZ-xxxxxx-part5 splash=silent quiet vga=0x317
......
<6>[   11.250331] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
<6>[   11.256271] EXT4-fs (sda7): mounted filesystem with ordered data mode. Opts: (null)
<6>[   11.375042] EXT3-fs: barriers not enabled
<6>[   11.375249] kjournald starting.  Commit interval 5 seconds
<6>[   11.376169] EXT3-fs (sdb13): using internal journal
<6>[   11.376175] EXT3-fs (sdb13): mounted filesystem with writeback data mode
<6>[   11.456749] fuse init (API version 7.16)
Kernel logging (ksyslog) stopped.




Oct 22 18:42:31 vdr vdr: [2918] (vdr.c:539) VDR version 1.7.21 started
Oct 22 18:42:31 vdr vdr: [2918] (vdr.c:541) switched to user 'vdr'
Oct 22 18:42:31 vdr vdr: [2918] (vdr.c:561) codeset is 'ISO-8859-1' - known
Oct 22 18:42:31 vdr vdr: [2918] (i18n.c:145) found 28 locales in /usr/share/vdr/locale
Oct 22 18:42:31 vdr vdr: [2918] (plugin.c:194) loading plugin: /usr/lib64/vdr/libvdr-epgsearch.so.1.7.21
Oct 22 18:42:31 vdr vdr: [2918] (plugin.c:194) loading plugin: /usr/lib64/vdr/libvdr-live.so.1.7.21
......
Oct 22 18:42:42 vdr vdr: [3488] (thread.c:251) KBD remote control thread started (pid=2918, tid=3488)
Oct 22 18:42:42 vdr vdr: [3489] (thread.c:251) receiver on device 1 thread started (pid=2918, tid=3489)
Oct 22 18:42:42 vdr vdr: [3490] (thread.c:251) TS buffer on device 1 thread started (pid=2918, tid=3490)
Oct 22 18:42:42 vdr vdr: [3482] [demux_vdr] PMT changed, resetting demuxer
Oct 22 18:42:42 vdr kernel: [   28.786030] wlan0: no IPv6 routers present
Oct 22 18:42:42 vdr vdr: [2918] (osd.c:1989) OSD size changed to 1280x720 @ 1
Oct 22 18:42:42 vdr vdr: [2918] (timers.c:565) timer 1 (1 2015-2145 VPS 'Tatort~Tatort: Mauerpark') set to event Son 23.10.2011 20:15-21:45 (VPS: 23.10 20:15) 'Tatort: Mauerpark'

Gruß
e9hack

Zitat von lola

mit Ksnapshot geschossen. Oder meinst Du, mit welchem Programm ich die Tests gemacht habe?

Gruß Fr@nk

Ich meinte mit welchen Programm. Dachte es wäre ein sinnvolles Programm, was entweder PNG ausgibt oder eine Tabelle die mit einem anderen Programm in ein PNG umwandelt werden.

Mit einem X11 Programm kann man schlecht auf dem Server testen.

Johns

Zitat von johns

Mit einem X11 Programm kann man schlecht auf dem Server testen

auf dem Server testen geht damit schlecht. Müsste man sich remote das Bild holen. Macht aber alles auf dem Server wenig Sinn.

Programm ist palimpsest, unter Debian bsw. Bestandteil von den Gnome-disk-utilitys

Gruß Fr@nk

Habe schon eine dreistellige Anzahl an Tanscend-SSDs verbaut.
Bei gleicher Modellbezeichnung gab es deutliche Chargenunterschiede - die ersten waren noch Sata1 , schwankende Grösse des nutzbaren Bereichs (war ein Problem wegen 1:1Kopie)... und alles unter der gleichen Produktnummer geliefert.
Letztenendes sind mir jetzt aber kein Ausfälle bewusst, nur sollte man sich nicht darauf verlassen dass man die gleichen Testergebnisse von anderen reprodzuieren kann...

Garry

Zitat von e9hack

Das glaube ich irgendwie nicht. Mein System ist zwar nicht aktuell, aber auch nicht langsam. Das Starten des Kernels bis der Kernel-Log-Daemon beendet wird, dauert 11sec. Das Starten des VDR mit ein paar Plugins bis zum OSD dauert ca. 10sec. An 8 sec kann ich da nicht glauben.

Dann ist das hier vergleichsweise puristisch. Man könnte noch auf udev in der Ramdisk verzichten und die notwendigen Module händisch eintragen, wenn es was bringt. Kernel ist der normale Arch Linux Kernel übersetzt mit -march=native, kann mir nicht vorstellen, dass das von Bedeutung sein sollte.

Oct 23 20:30:17 localhost kernel: [    0.000000] Initializing cgroup subsys cpuset
Oct 23 20:30:17 localhost kernel: [    0.000000] Initializing cgroup subsys cpu
Oct 23 20:30:17 localhost kernel: [    0.000000] Linux version 3.0-ARCH (tux@htpc) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Sun Oct 23 11:38:06 CEST 2011
Oct 23 20:30:17 localhost kernel: [    0.000000] Command line: root=/dev/sda1 ro quiet
...
Oct 23 20:30:17 localhost kernel: [    3.849990] EXT4-fs (sda1): re-mounted. Opts: discard
Oct 23 20:30:17 localhost kernel: [    3.866330] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Oct 23 20:30:17 localhost /usr/sbin/crond[718]: (CRON) STARTUP (1.4.8)
Oct 23 20:30:17 localhost /usr/sbin/crond[718]: (CRON) INFO (Syslog will be used instead of sendmail.): No such file or directory
Oct 23 20:30:17 localhost /usr/sbin/crond[718]: (CRON) INFO (running with inotify support)
Oct 23 20:30:17 localhost kernel: [    4.383154] NET: Registered protocol family 10
Oct 23 20:30:17 localhost kernel: [    4.388720] NET: Registered protocol family 4
Oct 23 20:30:17 localhost kernel: [    4.390329] NET: Registered protocol family 5
Oct 23 20:30:17 localhost kernel: [    4.473740] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Oct 23 20:30:17 localhost vdr: [926] VDR version 1.7.21 started
Oct 23 20:30:17 localhost vdr: [926] switched to user 'tux'
Oct 23 20:30:17 localhost vdr: [926] codeset is 'UTF-8' - known
Oct 23 20:30:17 localhost vdr: [926] found 28 locales in /usr/local/share/locale
Oct 23 20:30:17 localhost vdr: [926] loading plugin: /usr/local/lib/vdr/libvdr-xineliboutput.so.1.7.21
...
Oct 23 20:30:18 localhost vdr: [926] timer 4 (9 2222-0045 'Durst') set to event Don 27.10.2011 22:25-00:35 (VPS: 27.10 22:25) 'Durst'
Oct 23 20:30:18 localhost vdr: [955] video directory scanner thread ended (pid=926, tid=955)
Oct 23 20:30:18 localhost vdr: [967] [xine..put] Detected video size 720x576
Oct 23 20:30:18 localhost vdr: [965] [xine..put] Client 0 connected: 127.0.0.1:44289
Oct 23 20:30:18 localhost vdr: [965] loading /var/local/lib/vdr/plugins/xineliboutput/allowed_hosts.conf
Oct 23 20:30:18 localhost vdr: [965] [xine..put] cxSocket: setsockopt(SO_SNDBUF): got 262142 bytes
Oct 23 20:30:18 localhost vdr: [965] [xine..put] Trying PIPE connection ...
Oct 23 20:30:18 localhost vdr: [965] creating directory /var/local/lib/vdr/plugins/xineliboutput/pipes.926
Oct 23 20:30:18 localhost vdr: [965] removing /var/local/lib/vdr/plugins/xineliboutput/pipes.926
Oct 23 20:30:18 localhost vdr: [965] [xine..put] cBackgroundWriterI initialized (buffer 512 kb)
Oct 23 20:30:18 localhost vdr: [965] [xine..put] cTcpWriter initialized (buffer 512 kb)
Oct 23 20:30:18 localhost vdr: [965] [xine..put] Pipe open