Re: Verständnisfrage zu top

On Wed, Dec 29, 2010 at 12:20:37AM +0100, Marc Santhoff wrote:
> Am Dienstag, den 28.12.2010, 23:38 +0100 schrieb Marc Santhoff:
> > > Es ist auch so, dass Platten, die nicht für Notebooks
> > > vorgesehen sind, nur für eine begrenzte Anzahl Spin-up/
> > > -down-Zyklen konzipiert sind. Häufiges Hoch- und Runter-
> > > fahren führt zu vermehrtem Verschleiß und somit zu einer
> > > verkürzten Lebensdauer. Und wenn ich häufiger eine neue
> > > Platte nachkaufen muss, ist das auch nicht gerade "grün".
>
> Nachtrag: Energiesparen wollen ist natürlich Blödsinn, schließlich baut
> man ja eine 2. Platte ein. Aber die OCZ-Teile als Beispiel sind mit 2W
> im Betrieb angegeben, immerhin.

Ich kann nicht konkret für die OCZ sprechen, aber mit Allgemeinwissen
kann man diese 2W wohl ziemlich schnell tot reden, weil ein Flash-Chip
wirklich nur beim schreiben viel Strom braucht, beim lesen extrem wenig
und ohne Zugriff verschwindend gering.
Ich denke beim lesen wird das SATA-Interface noch am meisten Strom
brauchen.
Anders sieht es aus wenn die mit *DRAM beschleunigt sind.
DRAM jeglicher Art braucht viel Strom (man rechnet so mit 0,2 bis 0,8W
pro DRAM-chip) und wegen des notwendigen Refreshes einen nennenswerten
Teil davon auch ohne echte Zugriffe.
Ich halte das viele Buffern von teilweise 60MB und mehr aber für absoluten
Unsinn, weil die Dinger nur buffern müssen, damit die in mehreren
Flashblöcken gleichzeitig schreiben können, um dadurch auf eine
erträgliche Bandbreite beim schreiben zu kommen.
Dafür reicht in der Regel 1-2MB SRAM und SRAM ist im Strommverbrauch
wiederum sehr genügsam.
Im RAM des SSD gebufferte Daten sind ja letzlich nicht dauerhaft
gespeichert und Schreibcache im RAM hat das OS schließlich auch.
Meiner Meinung nach ist so viel Speicher nur für Unsinnige Benchmarks.
Bei Festplatten sieht das mit viel Buffer teilweise anders aus.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message