t4kers 3dfx Einstieg

  • Grundsätzlich bin ich ja auch dafür, das beste rauszuholen...SSDs sind da aber so ein Knackpunkt. Habe im Hinterkopf, dass aufgrund der mangelnden Unterstützung für SSDs diese nicht richtig genutzt werden unter alten OS und damit schneller aussteigen!?

    Viele Grüße
    soggi

    Das ist m.W.n. nur halb richtig. Win98(SE) unterstützt kein TRIM.
    TRIM sorgt - ganz verkürzt - dafür, dass direkt nach dem Löschen von Daten in einem Block der gesamte Block geleert wird (wobei noch benötigte Daten im gleichen Block entweder auf andere Blocks umverteilt, oder in Cache zwischengelagert und nach Löschen des Blockes zurückgeschrieben werden). Dieser Vorgang nennt sich Garbage Collection und müsste ansonsten direkt vor jedem Schreibvorgang in einen Block mit als gelöscht markierten Daten durchgeführt werden, was Performancenachteile zur Folge hätte.
    Die durch das notwendige Umverteilen von Daten entstehenden zusätzlichen Schreibvorgänge bezeichnet man als Write Amplification und sind im Alltagsbetrieb ein nicht unerheblicher Verschleißfaktor von Flashzellen. (Daher hält eine nur zu drei Viertel gefüllte OS-SSD länger als eine, die gegen 90% gefüllt ist: Die Flashzellen können gleichmäßiger abgenutzt werden und es fällt weniger Write Amplification an - Stichwort "Overprovisioning".)
    Die entstehenden Performancenachteile fallen bei Win98(SE) und den alten Kisten, auf denen es läuft aber nicht wirklich ins Gewicht. Außerdem implementieren viele moderne SSD-Controller Garbage Collection periodisch unabhängig von TRIM.
    Ein weiterer Effekt ist, dass durch TRIM die Umverteilung von noch benötigten Daten vor dem Löschen eines Blockes effektiver gestaltet werden kann. Dadurch fällt potentiell die Write Amplification geringer aus, was zu einer längeren Lebensdauer des Flashspeichers führt.

    Da Win98(SE) allerdings im Betrieb deutlich weniger Daten auf die SSD schreibt als neuere Windowsversionen, sollte die tatsächliche Belastung durch Win98(SE) deutlich geringer ausfallen als durch moderne Betriebssysteme, die viel öfter auf die SSD schreiben. Außerdem nutzen vermutlich die meisten von uns ihre Retrokiste nicht fürs Webbrowsing o.ä., weswegen generell eher wenig Daten geschrieben werden müssen. Besonders wer viel Arbeitsspeicher hat und dementsprechend keine große Auslagerungsdatei benötigt, hat unter Win98(SE) im normalen Betrieb wenig Verschleiß an seiner SSD.

    Damit hält die SSD in der Retrokiste in der Realität vermutlich deutlich länger als im Alltagscomputer und potentiell auch länger als HDDs, bei denen sich auch außerhalb des Betriebes langsam Dichtungen verabschieden, Lager verharzen etc.


    PS: Wenn ich in der Darstellung aus meiner Laienperspektive heraus Fehler gemacht habe, bitte gern korrigieren! :thumbup:

  • Das Szenario in meinem Hinterkopf sagte mir nur, dass die Speicherzellen nicht gleichmäßig "abgenutzt" werden können. Dass das nur bei gleich viel geschriebener Datenmenge sinnvoll vergleichbar ist, ist klar.

    Viele Grüße
    soggi

  • Sorry, ich bemüh mich immer alles richtig darzustellen und komm dadurch oft was oberlehrermäßig rüber. :S

    Die gleichmäßige Abnutzung der Zellen wird über den Controller gesteuert; Stichwort "Wear Leveling". Das OS hat da wenig Einfluss - es kann nur den Controller unterstützen, indem es ihm aktiv mitteilt, welche Pages gelöscht werden können/sollen, sodass ein guter Controller die Chance hat, möglichst viel Garbage Collection mit möglichst wenig Schreibvorgängen durchzuführen. Das ist eben ein positiver Effekt von TRIM bei vielen Flash-Controllern für SSDs.
    Dadurch, dass die Strategie von Garbage Collection von Controller zu Controller unterschiedlich ist, fallen die Einsparungen bei den Schreibvrgängen dann mal mehr und mal weniger ins Gewicht.
    Und wie gesagt: Der Anwendungsfall "Retro-Daddelkiste" stellt eh verhältnismäßig wenig Schreibvorgänge in Aussicht. Deswegen hätte ich keine Bedenken gegenüber Lebensdauer von SSDs in "unseren" Rechnern. :)

  • Sorry, ich bemüh mich immer alles richtig darzustellen und komm dadurch oft was oberlehrermäßig rüber.


    Ich find es gut solange das was geschrieben wird auch richtig ist.

    3dfx SYSTEME (Silent/low Noise) Windows 98 SE:

    QDI Legend V2200 AGP +Diamond Monster 3D +Videologic Apocalypse 3Dx | ASUS P2B-B | PII 450 | 128MB | 32GB CF
    Matrox G400 MAX +Matrox m3D +Orchid Righteous 3D² SLI | ASUS P3B-F | PIII 1100 | 256MB | 8GB CF
    Voodoo 5 5500 AGP | ASUS TUSL2-M | PIII-S 1400 | 256MB | 120GB SSD
    Voodoo 5 5500 AGP | EPoX EP-8K5A3+ | AthlonXP 3000+ | 512MB | 16GB CF |

  • Das ist aber so auch nicht ganz richtig. Das ATA TRIM Kommando verteilt keinerlei Daten um, sondern sorgt nur für die Löschung vollständig freier Blöcke. Es kommt also zu keinen Read-Modify-Write Zyklen, sondern lediglich zu einem Write!

    Dabei wird der SSD eine Liste an logischen Blockadressen (LBAs) übermittelt, die "leer" sind. Das geschieht über das ATA DATA SET MANAGEMENT Kommando, sofern ein vorangehendes IDENTIFY DEVICE Kommando nachweisen kann, daß das Blockgerät TRIM unterstützt. Die Blockliste wird über einen entsprechend befähigten Dateisystemtreiber bzw. ein Interface zu selbigem ermittelt.

    Datenumverteilung findet nur bei der Garbage Collection statt, die keinen bestimmten, vordefinierten Standards folgen muß, weil es kein Host Interface gibt. GC kann also eine Blackbox bleiben.

    Mehr Infos dazu gibt's in diversen ATA TRIM Command Proposals, z.B. [diesem hier].

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    Einmal editiert, zuletzt von GrandAdmiralThrawn (14. Mai 2018 um 08:50)

  • Sorry, ich bemüh mich immer alles richtig darzustellen und komm dadurch oft was oberlehrermäßig rüber. :S


    Nö, ich fand's nicht oberlehrermäßig...ist doch ordentlich geschrieben. :thumbup:

    Viele Grüße
    soggi

  • Das ist aber so auch nicht ganz richtig. Das ATA TRIM Kommando verteilt keinerlei Daten um, sondern sorgt nur für die Löschung vollständig freier Blöcke. Es kommt also zu keinen Read-Modify-Write Zyklen, sondern lediglich zu einem Write!

    Danke für die Klarstellung! :thumbup:
    Verstehe ich es richtig, dass TRIM damit im Endeffekt tatsächlich keinerlei Einfluss auf die Haltbarkeit der SSD hat, sondern ausschließlich Geschwindigkeitsvorteile bietet? (Ausgenommen, der Controller verschiebt z.B. im Rahmen von Wear Leveling den Inhalt von gelöscht markierten, aber nicht geleerten Blöcken, sodass unnötige Writes entstehen.)

  • Meine Entschuldigung vorab für den massiven Thread Derail! ;) Aber Thread Derails sind letzlich für mich wie Wasser für den Fisch. :rolleyes:

    Also das mit dem Wear ist soweit mich meine Kenntnis bringt (leider) implementierungsabhängig. Je nach SSD Typ sendet der Controllertreiber (in letzter Instanz unter dem Dateisystemtreiber) erst Mal TRIM (ATA Modell) oder UNMAP (SCSI Modell) mit den zugehörigen LBAs an die SSD. Im SCSI Modell ist das Zeug u.a. auch ein Bestandteil einer standardisierten Thinprovisioninglösung, hier weicht nicht nur das Kommando ab, sondern auch dessen Konfigflags.

    Eine SSD im SCSI Modell kann jetzt ein LBPRZ Flag (Logical Block Provisioning Read Zeroes) setzen. Je nachdem wie das Flag gesetzt ist, liefert die SSD dann bei einem Lesezugriff auf unmapped Pages nur Nullen (LBPRZ = 0) oder zufällig generierte Daten (LBPRZ = 1) zurück. In beiden Fällen kann das eigentlich der SSD Controller erledigen ohne den NAND anfassen zu müssen, wenn er pro Page ein Flagbit vorhält. aber das ist dann eben Implementierungsfrage. Genauso kann es sein, daß er SSD Pages beim UNMAP einfach wegnullt, also beschreibt.

    Im ATA Sektor ist das interne Handling des TRIM Befehls nicht ganz gleich, aber ähnlich; Statt LBPRZ kennt ATA die Bits 5 und 14 des Data Word 69, so wie es von IDENTIFY DEVICE zurückgeliefert wird. Stehen diese beiden Bits auf 1, so muß die SSD für getrimmte Pages Nullen zurückliefern. Und das war's aber auch schon. Ob die Pages jetzt von TRIM wirklich gelöscht werden, oder ob es eine interne Tabelle in der Firmware dazu gibt, ist unklar. Wahr ist, ein solches Flag bräuchte minimum 1 Bit pro Page (clear oder nicht clear). Wenn man eine Standardpagegröße von 4kiB annimmt, dann bräuchte eine 2TiB SSD eine Tabelle die 64MiB groß wäre. Nicht winzig, aber sicher nicht unmachbar.. Dann müßte man nur in dieser internen Tabelle pro geleerter Page ein Flag setzen, anstatt die Pages echt zu nullen.

    Zusätzlich gibt es noch das entsprechende DEALLOCATE Kommando im NVMe Protokoll, aber zu dem kann ich gar nichts sagen, weil ich mich damit Nüsse auskenne.

    In der Praxis scheint es mir aber doch so zu sein (ab hier keine von mir klar belegbaren Infos mehr!), daß die meisten SATA SSDs die Pages wirklich hart löschen, also ein WRITE auslösen, das alles mit 0 oder manchmal auch alles mit 1 überschreibt (Der Host bekommt beim Lesen immer 0 zurück). Damit löst also TRIM auch eine Abnutzung der NAND Zellen aus, wenn so implementiert. TRIM bringt dann nur mehr Speederhalt bei Schreibzyklen, aber die Reduktion der Abnutzung betrifft dann maximal noch eine parallel laufende Garbage Collection, die jetzt mit mehr freien Pages arbeiten kann, also weniger Writes erzeugen muß, um zu funktionieren.

    Es scheint aber auch SSDs zu geben, die die Daten einfach auf dem Flash belassen, und die Zelle nur als frei markieren. Damit könnte man also auch nach einem TRIM immer noch alles auslesen, wenn die Flagbits 5 und 14 w.o. beschrieben nicht gesetzt sind.

    Allerdings kann ich das alles eben nicht zu 100% beweisen.

    Leider können wir halt nicht so leicht in die interne Funktionsweise eines SSD Controllers reinschauen. Im Prinzip müßte man die SSD vollschreiben, dann löschen & TRIMmen, aufreißen, die NAND Chips auslöten und mit einem eigenen Controller analysieren um zu sehen ob die Dinger wirklich genullt sind, oder doch nicht. Nur pfh, wer kann/macht sowas?


    Quellen: [Oracle Linux Advanced Storage Interfaces], [Seagate 1200 SSD Product Manual], [Micron S650DC Series 1.8-Inch SAS NAND Flash SSD Specs], [libata Entwicklerdiskussion].

    PS.: Wenn hier ungewünscht, empfehle ich, die SSD Diskussion zu splitten und zu verschieben.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Ich benutze in der Tat wirklich Windows XP. Leider hatte ich jedoch mit dem Mainboard und dem IDE/SATA-Adapter Probleme, sodass die SSD immer in den PIO-Mode zurückgestuft wurde. Schlussendlich habe ich durch eine kurze Unachtsamkeit (CPU Kühler saß nach Tausch nicht richtig) das Mainboard leider über den Jordan geschickt.

    Für den Neuaufbau habe ich nun folgendes Setup in Planung:

    Asus A7V600-X (Neu)

    AMD Thunderbird C 1,33 Ghz / Zalman CNPS 7000B-CU

    Kingston HyperX KHX3200A/1G PC3200 Cl2 1GB

    OEM Geforce3 64MB mit VGA und DVI / Zalman ZM80D-HP mit optionalem Lüfter

    Voodoo 3 3000 PCI

    Crucial 64 GB SSD
    Seasonic SS-380hb Netzteil
    LG SATA DVD Brenner

    Aktuell sind die Teile noch im Zulauf zu mir. Wenn ich alles zusammen habe, dann gibt es Bilder von der Kiste. Bei dem Umbau habe ich wieder viel wert auf die Lautstärke und DVI gelegt. Dies ist mir wichtiger als zeitgerechte Peripherie. Viele Peripheriegeräte sind daher deutlich neuer. Mir ist lediglich wichtig, dass CPU und Grafikkarte aus der gleichen Epoche stammen. Den beiden Komponenten gilt mein größtes Interesse. Auf SD-Ram wäre ich schon scharf gewesen, jedoch habe ich festgestellt, dass der KT133A wirklich extrem buggy war und diesen auch die Voodoos nicht wirklich mögen...

    Einmal editiert, zuletzt von t4ker (11. Juni 2018 um 20:46)

  • Also ich finde, der KT133a ist ein richtig guter Chipsatz gewesen und es gab richtig geile Boards damit.

    Ich hatte bereits das Asus A7V133 und das A7V133-C in jeweils verschiedenen Revisionen, das Abit KT7A, das MSI K7T Turbo, das ECS K7VZA und habe noch das EpoX 8KTA3 in einem meiner Testrecher im Einsatz. Ich hatte nie Probleme mit den Boards, die sind mir allesamt extrem positiv in Erinnerung geblieben.

    Der KT133 "ohne A" ist allerdings recht shaky und relativ lahm.

    Wie hast du das mit der Voodoo 3 vor? Steckst dann das VGA Kabel um, wenn du Glide nutzen willst? Oder hast ne Switchbox dran? Oder GF3 per DVI angeschlossen und V3 per VGA?

  • Oder GF3 per DVI angeschlossen und V3 per VGA?

    --> genauso sieht mein Plan aus :)

    Ich habe noch ein Enmic 8ttx+ (baugleich mit dem Epox 8KTA3) in Aussicht. Leider sind jedoch 2 Kondis aufgebläht. Eventuell versuche ich mich dann doch nochmal am Projekt mit SD-Ram und KT133A. Dann aber defintiv mit bootbarer PCI-SATA Controllerkarte.

  • Also ich finde, der KT133a ist ein richtig guter Chipsatz gewesen und es gab richtig geile Boards damit.

    Ein EP-8KTA3+ Pro dient als Unterbau für mein V5-System.:thumbup: Finde ich so ziemlich die ideale Plattform, weil der Athlon XP 2600+ Thoroughbred B drauf läuft, das Board noch einen ISA-Slot für DOS-Sound und einen eingebauten RAID-Controller hat. So hat man ordentlich Dampf für späte Win98-Spiele, aber gute Kompatibilität für (nicht geschwindigkeitsabhängige) DOS-Spiele und kann den 686B-Bug locker umgehen.

    Vorher hatte ich ein Abit KT7A-Raid mit 2100+ Palomino und wunderte mich über die fürchterliche Instabilität. Dann habe ich über den 686B-Bug gelesen und die Installation mit HDD am ersten IDE-Kanal und CD-Laufwerk am RAID-Controller wiederholt. Danach lief das System perfekt stabil. Offenbar haben tatsächlich die Datenverluste beim Transfer zwischen den IDE-Kanälen die Installation korrumpiert. So habe ich gelernt, dass man bei der Southbridge den zweiten IDE-Kanal deaktivieren muss und idealerweise einen SATA-/IDE-Controller dazunimmt und wurde etwas weniger n00b.:spitze:

  • Wobei ich selbst wiederum nie etwas von dem Bug gemerkt habe. Allerdings hatte ich solche Boards erst weit später mit den latest BIOSen und aktuellen Treibern am Laufen - da dürfte einiges ausgemerzt worden sein. Der Bug bzw. die Bugs sind bis heute irgendwie mysteriös und mMn lange nicht komplett aufgedeckt.

    Viele Grüße

    soggi

  • Angeblich sind ja auch nicht alle Boards mit VIA 82C686B-Chips betroffen: Es lässt sich lesen1, VIA habe den Bug bei neueren Chips in Hardware gefixt. Das könnte aber auch eine Vermischung mit dem KT133A-Bug2 sein.

    Andererseits gibt es Berichte3 über ähnliche Probleme wenigstens unter Linux-basierten OS schon mit VIA Apollo-Chipsätzen, die Probleme mit allen über den PCI-Bus angebundenen VIA-Southbridges nahelegen.

    Du hast i.m.A. völlig Recht, dass das Wasser in dieser Sache ziemlich schmutzig scheint und die Sache vermutlich nie vollständig aufgeklärt wurde.

    1https://www.au-ja.de/review-kt133a-1.phtml ("Angeblich gibt es eine neuere Revision des Chips, in der der Fehler beseitigt wurde.")

    2https://www.heise.de/newsticker/mel…-Bug-37647.html

    3https://web.archive.org/web/2003021022…119_103.html#17

  • Nicht zu vergessen die Artikel von Nero24 auf Planet3DNow! Bin grad auf Arbeit, ist mir zu müßig, die Links aufm Handy zusammenzusuchen. ;)

    Viele Grüße

    soggi

  • Angeblich sind ja auch nicht alle Boards mit VIA 82C686B-Chips betroffen: Es lässt sich lesen1, VIA habe den Bug bei neueren Chips in Hardware gefixt. Das könnte aber auch eine Vermischung mit dem KT133A-Bug2 sein.

    Meinen Erinnerungen nach gab es keine fehlerbereinigte Revision des betroffenen Southbridge-Chip.

    Der Fix war nur in Software: Es wurden Anpassungen im BIOS bzgl. des Busmasterings gemacht sowie im Chipsatztreiber von VIA.

    Wie du vermutest wird es verwechselt worden sein, denn der Bug der Northbridge wurde mit einem neueren Stepping in Hardware behoben.

    "Ich habe einen Penis! Und ich werde ihn benutzen..." ~Gronkh

  • Den Rechner habe ich nun nochmal einer gründlichen Überarbeitung unterzogen, da ich zufällig an ein "perfektes" Enmic 8TTX+ mit KT133A Chipsatz gekommen bin. Leider lies sich anscheinend der Zalman CNPS7000 nicht richtig montieren, wodurch mein geliebter XP-M 2400+ mit Barton Kern und meiner 2100+ Palomino hopps gegangen sind. Augenscheinlich lag der Kühler nicht richtig auf dem DIE der CPU auf. Leider bemerkte ich dies zu spät... Aber schon Wahnsinn, dass auf dem ollen KT133A Mainboard sogar die Bartons laufen. Leider lässt sich aber kein höherer Multi als 12,5 anwählen, da das Mainboard anscheinend kein 5bit FID hat.

    Auch wurde der Rechner so aufgebaut, dass immer bei Bedarf meine Voodoo 5 5500 AGP die Bilder auf den Monitor zaubern darf. Die meiste Zeit bleibt sie allerdings zur Schonung in der Vitrine :). Das Kabelmanagement war erstmal provisorisch. Installiert habe ich Windows XP, obwohl das hier im Forum recht unbeliebt ist.

    Aktueller Stand des Rechners:

    Cooltek K2 Gehäuse mit 120mm Enermax TB Silence Gehäuselüfter

    Enmic 8TTX+ mit KT133A Chipsatz mit Zalman NB47J Northbridgekühler

    AMD XP Thoroughbred A 1700+ (unlocked) @ 2000+ (1670 Mhz) mit Verax P14Cu Kühler zusätzlich an einer Zalman Fanmate Lüftersteuerung

    4x 256 MB PC133 CL2 Infineon SD-Ram (Slot 1 / 2: DS | Slot 3 / 4: SS)

    Nvidia Geforce Quadro 900 XGL / 128 MB @ Ti4600 mittels Rivatuner mit Zalman ZM80D-HP Heatpipe von gedrosselten Tagan Lüfter gekühlt

    Seasonic SS-380HB Netzteil

    Promise TX2 Plus SATA 300 PCI Karte

    Crucial M4 64 GB SSD / SATA DVD Brenner

    Soundblaster Audigy Platinium EX PCI

    D-Link 10/100 Lankarte PCI

    USB 2.0 PCI Karte (mit 2 Ports für den Front-USB) mit ALI M5273 Chipsatz

  • Ich habe nun endlich alle Wunschkomponenten zusammen und verbaut :). Dies dauerte leider unerwartet lange. Das System läuft nun allerdings rund und ich bin vorerst zufrieden. Das Retrogamen macht richtig Freude. Das System stellt meinen jugendlichen Wunsch-PC dar. Für die Vitrine habe ich noch eine V5 5500 AGP / Leadtek Geforce 2 Ultra / Geforce 3 OEM und Leadtek Ti4600 erhaschen können. Verschiedene nette gewünschte Sockel A CPUs (Thunderbird C 1,33 Ghz & 1,4 Ghz, XP 1800+ T-Bred B JUIHB, XP-M 2400+ 1,45V) habe ich auch bekommen. Lediglich bei den Mainboards habe ich kein Glück, da gefühlt 80% defekt bei mir ankommen.

    Aktueller Stand des Rechners:

    Cooltek K2 Gehäuse mit 120mm Enermax TB Silence Gehäuselüfter

    Enmic 8TTX+ mit KT133A Chipsatz mit Zalman NB47J Northbridgekühler

    AMD XP Thoroughbred A 1700+ (unlocked) @ 2000+ (1670 Mhz) mit Zalman CNPS6000-CU

    4x 256 MB PC133 CL2 Infineon SD-Ram (Slot 1 / 2: DS | Slot 3 / 4: SS)

    MSI Ti4600 128 MB mit Zalman ZM80D-HP Heatpipe und ZM-OP1 Zusatzlüfter

    Seasonic SS-380HB Netzteil

    Promise TX2 Plus SATA 300 PCI Karte

    Crucial M4 64 GB SSD / SATA DVD Brenner

    Soundblaster Audigy Platinium EX PCI

    D-Link 10/100 Lankarte PCI

    USB 2.0 PCI Karte (mit externen Port für den Front-USB) mit Via VT6412L Chipsatz