Re: Solved: Schlechte Schreibrate auf ssd im Batteriebetrieb
Am Dienstag, 12. März 2013 schrieb Jürgen Bausa:
> Jürgen Bausa <Juergen.Bausa <at> web.de> writes:
> > Ich habe ein Asus X101 Netbook, das vor kurzem ein Update von squeeze
> > auf wheezy (Kernel 3.2.0-4-686-pae, kde) und auch eine neue ssd
> > (msata Crucial m4 32 GB) bekommen hat. Jetzt wollte ich den Durchsatz
> > der Platte messen und mir ist aufgefallen, dass im Batteriebetrieb die
> > Schreibrate extrem abfällt (Die Leserate ist dagegen immer gut).
>
> Jetzt habe ich die Lösung gefunden: hdparm ist schuld! hdparm scheint die
> Platte in einen Energiesparmodus (APM) zu schicken, der (zumindest bei
> meiner Crucial m4) zu einer sehr geringen Schreibrate führt. Wenn ich
> hdparm deinstalliere oder folgendes in die /etc/hdparm.conf einfüge:
>
> /dev/sda {
> apm = 255
> apm_battery = 255
> }
>
> wird APM sowohl mit Netzteil als auch im Batteriebetrieb ausgeschaltet.
> Damit habe ich dann wieder die "hohe" Schreibrate.
>
> Bleibt die Frage, was APM bei einer SSD macht und ob das überhaupt Sinn
> macht. Zu diesem Thema habe ich im Netz leider nichts gefunden.
Interessant.
Habe hdparm installiert und kann bei der Intel SSD 320 hier keine
Performance-Enbrüche gesehen.
> jba@lina:~$ dd if=/dev/zero of=tempfile bs=1M count=256
> conv=fdatasync,notrunc
> 256+0 Datensätze ein
> 256+0 Datensätze aus
> 268435456 Bytes (268 MB) kopiert, 4,84281 s, 55,4 MB/s
ist allerdings immer noch unterirdisch für sequentielles schreiben.
merkaba:~> mount /dev/merkaba/zeit /mnt/zeit
merkaba:~> cd /mnt/zeit
merkaba:/mnt/zeit> dd if=/dev/zero of=tempfile bs=1M count=256
conv=fdatasync,notrunc
256+0 Datensätze ein
256+0 Datensätze aus
268435456 Bytes (268 MB) kopiert, 1,95136 s, 138 MB/s
merkaba:/mnt/zeit> rm tempfile
merkaba:/mnt/zeit> dd if=/dev/zero of=tempfile bs=1M count=256
conv=fdatasync,notrunc
256+0 Datensätze ein
256+0 Datensätze aus
268435456 Bytes (268 MB) kopiert, 1,97496 s, 136 MB/s
merkaba:/mnt/zeit>
Oho, da hab ich auch schonmal mehr gesehen:
merkaba:/mnt/zeit> dd if=/dev/zero of=tempfile bs=1M count=256 conv=fsync
256+0 Datensätze ein
256+0 Datensätze aus
268435456 Bytes (268 MB) kopiert, 1,38255 s, 194 MB/s
merkaba:/mnt/zeit> rm tempfile
merkaba:/mnt/zeit> dd if=/dev/zero of=tempfile bs=1M count=256 conv=fsync
256+0 Datensätze ein
256+0 Datensätze aus
268435456 Bytes (268 MB) kopiert, 1,78092 s, 151 MB/s
merkaba:/mnt/zeit> rm tempfile
merkaba:/mnt/zeit> dd if=/dev/zero of=tempfile bs=1M count=256 conv=fsync
256+0 Datensätze ein
256+0 Datensätze aus
268435456 Bytes (268 MB) kopiert, 1,84724 s, 145 MB/s
merkaba:/mnt/zeit> filefrag -v tempfile
Filesystem type is: ef53
File size of tempfile is 268435456 (65536 blocks, blocksize 4096)
ext logical physical expected length flags
0 0 366592 32768
1 32768 399360 32768 eof
tempfile: 1 extent found
Ob notrunc da mit reinspielt?
Allerdings ist das auch eine recht kleine SSD vom Platz her gesehen. Und da
ich hier und da immer mal wieder Hinweise gesehen, dass auch beim gleichen
Modell mit unterschiedliche Kapazität teilweise unterschiedliche
Geschwindigkeiten rauskommen…
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: