Beiträge von GrandAdmiralThrawn

  • Der Solid State Disk Thread

    Also zur Preisleistung muß man sicher nichts sagen. PATA SSDs sind und bleiben füre ihre Größe wohl zu teuer, so wie halt auch die meisten modernen SATA SSDs. Aber wennst deinem 855er Chipsatz den letzten, ultimativen Kick geben willst, dann ist das wohl der Weg. :D

    Ich habe mir das damals für mein JVC Subnotebook auch überlegt (auch ein 855er, und das hat SEHR viel überlebt), aber da ich auch eine bessere GPU und eingebautes UMTS/HSDPA wollte, blieb mir nur der Weg zum neuen Notebook (+SATA SSD halt).

    Ich denke aber, du kannst hier in jeder Ecke mit einer Verbesserung rechnen. Leistung, Temperatur, Laufzeit, Robustheit. Ist nur eine Frage, ob man den stolzen Preis zahlen will, würde ich meinen. Eine SLC mit Indilinx Controller ist auf PATA halt die absolute Königsklasse. Etwas besseres existiert in diesem Segment nicht!

  • Der Solid State Disk Thread

    Schneller als eine 4200rpm Travelstar wird eine Solidata PATA SSD wohl immer sein. Wenn ich eine 2.5" 60GB PATA HDD zu ersetzen hätte, würde ich mit ziemlicher Sicherheit eine Solidata P1 64GB kaufen. Solidata setzt Indilinx Controller ein, die besten, die es nach Intel und SandForce gibt. Es ist auch nicht zu erwarten, daß die Pagegröße bei SSDs in der nächsten Zeit signifikant sinkt (schon gar nicht um Faktor 1024!!), damit müssen wir also sicher noch sehr lange leben.

    Bei PATA gibt es zwar keine TRIM Implementierung, aber die P1 wäre eine SLC, die nicht stark beeinträchtig sein dürfte. Mehr Speed bekommst also hier garantiert, selbst wenn Mal alle Pages voll sind, das wage ich zu sagen. Dazu natürlich noch andere Vorteile: Geringere Wärmeentwicklung, Lautlosigkeit, marginal geringerer Energieverbrauch, Erschütterungsresistenz..

    Ganz billig ist der Spaß natürlich nicht, [siehe hier].

    Es wäre darauf zu achten, daß dein Notebook mindestens ATA100 anbietet, um den Speed der Solidata auch nutzen zu können! Also besser keine BX-basierten Uraltbooks etc. ;)

    Ein Bild:
    [Blockierte Grafik: http://www.dpie.com/storage/solidata-p1-ide-ssd.jpg]

  • Der Solid State Disk Thread

    Laut einigen Herstellern wären ja SSD Controller, die feingranularer arbeiten (z.B mit 512 Byte Pages, so wie bei Festplattensektoren) einfach zu komplex, zu stromhungrig, zu heiß. Warum das so ist, weiß ich aber auch nicht. Scheinbar sind SSD Controller hier wesentlich komplexer, als konventionelle HDD Controller, die momentan locker mit bis zu 3.9 Millarden Sektoren hantieren können. Bei einer 512GB SSD mit 512kB Pages wäre dies ein Total von nur knapp einer Million Pages...

    Offenbar mußte man hier also gewaltig "tricksen", um diese NAND SSD Controllerchips realisieren zu können, daraus ergeben sich halt ein paar Nachteile. ;)

  • Der Solid State Disk Thread

    Das ist die am schwersten zu beantwortende Frage bezüglich SSDs. Es hat in erster Linie mit dem Adressierungssystem der SSDs zu tun, das viel grobgranularer ist, als ein konventioneller Festplatten-Adressraum, oder eben auch der Adressraum eines Dateisystems wie NTFS. SSDs haben - wie oben erwähnt - eine kleinste adressierbare Einheit von entweder 512kBytes oder 1MByte. Dateisysteme arbeiten aber viel feingranularer (Blockgrößen zwischen 512 Byte und ~64kB).

    Das heißt, wenn du nur einen 64kB Block auf die SSD schreibst, dann flushed die SSD diesen Block mitsamt einer kompletten 512kB Page auf die NAND Chips raus (Write Amplification! Es wird mehr geschrieben als nötig!). Zudem weiß die SSD nicht, wo genau diese 64kB innerhalb der 512kB Page liegen, weil sie nichts kleineres als 512kB adressieren kann. Eine Festplatte geht hier anders vor, und verwirft den übriggebliebenen Rest eines Sektors einfach, und schreibt künftig in den nächsten weiter.

    Bei 512kB Pages wäre dies aber eine enorme Platzverschwendung, unleistbar! Also wennst in besagte Page oben nochmals schreiben willst, muß die Page zuerst AUSGELESEN werden, dann dem Betriebssystem/Dateisystem übergeben. Das Dateisystem weiß, wo die zuvor geschriebenen 64kB liegen, fügt z.B. weitere 128kB hinzu (MODIFIZIEREN), und dann wird die gesamte Page wieder GESCHRIEBEN. Das ist ein READ-MODIFY-WRITE Cycle, der nötig wird, sobald zuviele Pages partiell beschrieben wurden, und in der SSD nicht mehr als "komplett frei" markiert sind. Sobald die SSD anfangen muß, statt WRITE Cycles READ-MODIFY-WRITE durchzuführen, geht die Performance absolut in den Keller.

    Und je mehr Write Amplification die SSD hat, desto schneller bist in einem solchen Zustand angelangt. Write Amplification läßt sich z.B. reduzieren, indem man Writes cached, blockt, und dann gesammelt rausschreibt, um nach Möglichkeit nicht allzuviel "Shrapnell" auf zuviele Pages aufteilen zu müssen. So versucht man, Pages nach Möglichkeit immer gleich vollzuräumen, damit künftige Schreibvorgänge auf "komplett frische" Pages durchgeführt werden können (nur WRITE Cycles nötig).

    Nun, Samsung Controller sorgen dafür (wie auch einige andere, JMicron, Toshiba), daß die SSD relativ flott degeneriert. Das Resultat ist eine absolut miese Schreibleistung, und ein schlechtes Verhalten bei Multiple/Random Write I/O. Zudem können SSDs keine Daten löschen, wie eine Festplatte. Wenn du im Betriebssystem eine 4GB Datei löschst, so müßte die SSD einen Haufen READ-MODIFY-WRITE durchführen, weil die 4GB Datei sicher mit 500 anderen Dateien zusammen auf tausenden Pages verteilt liegt. So könnte eine simple Löschoperation MINUTEN dauern! Also löscht man nur die MFT Einträge, und läßt die Pages alle so, wie sie waren.. im als "beschrieben" markierten Zustand.

    Gegenmaßnahmen sind die bereits erwähnte Reduktion der Write Amplification, und - das einzige, was letzten Endes wirklich hilft - ATA TRIM. Das TRIM Kommando sammelt alle Dateisysteminformationen aus MFT/FAT/iNode Tables zusammen, gleicht diese mit den SSD Pages ab, und "befreit" Speicher, der nicht mehr wirklich belegt ist auf der SSD. Damit können einige Pages wieder als "frei" markiert werden => Reine WRITE Cycles wieder möglich....

    Nachtrag: Es scheint, als würde die Senkung der Schreibleistung durch das oben beschriebene Phänomen eine drastischere Auswirkung auf MLC-basierte SSDs haben, im Vergleich zu SLC. Zumindest ist dies bei Intel SSDs der Fall.

    So, ich hoffe, das war nicht zu romanartig..

  • Der Solid State Disk Thread

    SSDs haben per se keinen Einfluß drauf, wo eine Partition beginnt. Aber der "übliche" Start einer Windows Partition ist Sektor Nummer 63. Das ist also bei Byte Nummer 32.256. Nun, das ist etwas schlecht, da SSDs in Pages (Speicherseiten) organisiert sind, die zumeist 512kB oder 1MB als kleinste adressierbare Einheit aufweisen. Beginnt eine Partition bei Sektor 63, dann können so manche Datenblöcke auf der Partition "zwischen" zwei SSD Pages liegen, sind also auf zwei Pages aufgeteilt. Wird ein solcher Block geschrieben, so muß die SSD zwei komplette Pages schreiben (1 oder 2MB für nur einen Block im Worst Case!), oder sogar Lesen-Modifizieren-Schreiben, was eine höhere Write Amplification bedeutet (unnötige Schreibvorgänge..).

    So sollte man also beim Partitionieren darauf achten, die Partition zur Sicherheit genau bei 1MB beginnen zu lassen (Sektor Nummer 2.048), um sicherzustellen, daß ungeachtet der Blockgröße die Filesystemblöcke immer sauber mit den SSD Pages abschließen. Das kann nicht nur mehr Lebensdauer bringen, sondern durch Vermeidung unnötiger Schreibvorgänge auch in mehr Leistung resultieren.

    Windows 7 macht dies bei der Installation von selbst, sofern es eine SSD erkennt. Ältere Betriebssysteme nicht, hier muß man für das "Block/Page Alignment" manuell sorgen, und danach ggf. per fixmbr den Bootsektor nochmal nachliefern. Linux macht es einem hier besonders einfach: Im Setup kann man üblicherweise direkt die Sektornummer für den Start einer Partition bestimmen... Hier muß der Bootmanager/MBR nicht nachträglich neu geschrieben werden, wenn man frisch installiert.

  • Android Handy's

    Also das positivste an Android ist wohl, daß es quelloffen ist. Das heißt, es ruhen wohl genügend Paare sehr aufmerksamer Augen auf dem Code, der da wirklich z.B. am Milestone läuft. Wenn Google hier Datamining-Software einbauen würde, so würde man das im Quellcode natürlich sehen. Weiters ist Open Source dahingehend günstig, daß es die Entwicklung völlig freier Tools für Android sehr einfach machen dürfte. Quasi jeder Entwickler kann wohl einfach hergehen, und Code für dieses System bauen. Diesen Vorteil hat Symbian noch nicht so lange.

    Zur Sicherheit kann ich keine Stellung beziehen, da ich einfach zu wenig weiß. Weiters ist Android noch recht neu, aber die Aussichten auf eine große Softwarevielfalt sind dank Quelloffenheit ziemlich gut, würde ich Mal meinen.

  • Raid-Frage

    Initialisierung ist nicht so unterschiedlich von Verifikation. Bei einem Parity RAID geht der Controller üblicherweise her, und generiert über den gesamten Array die Paritätsblöcke, schreibt sie und prüft deren Integrität (auch wenn das Array noch leer ist!).

    Eine Initialisation kann auch durchgeführt werden, wenn das Array schon partitioniert, formatiert und bespielt wurde. Dabei werden die Paritätsblöcke üblicherweise eben neu geschrieben, während sie bei der Verifikation nur generiert und mit den gespeicherten Blöcken verglichen werden.

    Verify: Paritätsblöcke werden aus Datenblöcken neu generiert und mit gespeicherten Paritätsblöcken verglichen, um deren Integrität zu prüfen.
    Initialize: Paritätsblöcke werden aus Datenblöcken neu generiert und neu geschrieben, dabei eventuell auch mit bereits vorhandenen Paritätsblöcken abgeglichen.

    Natürlich kann die Implementierung von Controller zu Controller abweichen, aber das sollte es in der Regel so ca. sein.

    Übrigens geschieht dies nicht bitweise, sondern blockweise. Der einzige RAID-Level, bei dem bitweise gearbeitet wurde, war RAID-2 auf Basis von Hamming-Codes. RAID-3 arbeitete schon Byteweise, spätere RAID-Levels dann wesentlich schneller, weil blockweise. Alle heute implementierten RAID Levels arbeiten also blockweise, wenn es um Striping oder das Generieren von Paritätsdaten geht.

    "Gute" Software-RAIDs machen übrigens auch Gebrauch von solchen Initialisationspraktiken, so wie etwa bei md / mdadm im Linux. Kreiert man hier ein RAID-5, wird eine Initialisation durchgeführt, die mit der von HW Controllern vergleichbar ist, und auch entsprechend lange dauert. z.B. so für ein 4-Disk RAID-5: mdadm -C /dev/md1 -l5 -n4 /dev/sd[a-d].

  • Der Solid State Disk Thread

    Das ist bei mir der Grund, warum ich auf die 320GB Postville warte, wenn's ums Mainsys geht. Das würde reichen, aber die 160er ist zu knapp bemessen für OS+Apps+Games. So macht der Vorschlag von Andy wohl am meisten Sinn. Bei Spielen hast noch am seltensten anspruchvolles I/O.

  • Der Solid State Disk Thread

    Sammys sind ziemlich günstig, aber relativ schlecht bei multiplem bzw. Random I/O, zudem degenerieren sie relativ stark (Write Amp). Bei deiner Auswahl, und den gegebenen Preisunterschieden würde ich am ehesten zu einer SF-1200 greifen. Der schlägt sich unter allen Bedingungen erstklassig, sogar im Vergleich zur teureren Intel, und TRIM ist auch an Bord.

  • Opera Probleme

    Mußte leider wieder auf 10.11 zurück, aber nicht wegen VA... sondern weil ich's ums Verrecken nicht schaffe, dem 10.60er Java beizubringen im CentOS Linux. Der 10.1x hatte noch eigene Optionen dafür, der 10.60er aber nicht mehr.. Keine Ahnung wie man den dazu bringt, Java zu verstehen. Das Plugin frißt er ja nach wie vor nicht, aber wie er die Java Binaries finden können soll, weiß ich auch ned.. Weak.