Dat men tegenwoordig ECC gebruikt ipv parity kan ik wel uitleggen.
Zoals Maarten al zegt: De data wordt 8-bytes-tegelijk opgehaald. Als iedere byte een negende bit heeft zijn dat samen 8 extra bits.
Stel dat ik 64 bits heb en ik verklap je dat er precies 1 fout is opgetreden hoeveel bitjes heb je dan nodig om aan een volgend systeem door te geven welk bitje dat geweest is? Het antwoord is "ongeveer 6". Met 6 bitjes kan je aangeven WELKE van de 64 fout is. Van een fout bitje hoef je niet op te geven of ie 0 of 1 is geweest: als ie fout is dan moet ie de andere waarde gehad hebben.
Maar nu zijn er niet 64 bits maar 64+6. En de mogelijkheid "geen fout" moet ook nog aangegeven worden. Je hebt dus minimaal 7 bits nodig om dit alles te kunnen coderen. Nu heeft men tijden geleden inderdaad een manier gevonden om met 7 controle bitjes per 64 databits 1 fout te kunnen corrigeren. Als ik het goed heb was dat "reed-solomon": twee kerels die dat samen uitgevonden hebben.
Als je het simpeler aanpakt kan je het princiepe van fout-corectie inzien, het werkelijke reed-solomon is efficienter (heeft minder extra bits nodig) maar doet precies hetzelfde.
Die 64 databits kan je in een matrix zetten van 8x8 bits. Van iedere horizontale rij neem je de parity en zet je er rechts naast. Van iedere kolom neem je de parity en die zet je er onder. Nu heb je 16 extra bits. Als er dan in rij 3, kolom 5 een fout optreed dan zal je precies de parity van rij 3 en die van kolom 5 zien dat die niet meer kloppen. Flip je het bitje op 3,5 dan klopt alles weer. Treed er nog een fout bitje op, dan kunnen er twee situaties ontstaan. Als het op dezelfde rij of kolom gebeurt, dan flipt de rij-of-kolom parity weer naar "goed" en weet je niet op welke rij deze twee fouten hebben plaatsgevonden. Gebeurt het op een andere rij EN kolom , bijvoorbeeld rij4, kolom 6, dan weet je dat er een probleem zit in rij 3 en 4, en in kolom 5 en 6, maar niet welke combinatie. Dat kan 3,5 en 4,6 zijn of 3,6 en 4,5. Kortom, bij twee fouten zie je nog wel dat er IETS is misgegaan maar niet wat.
Deze methode werd tot niet zo heel lang geleden op flash geheugens toegepast, maar dan met grotere groepen van bitjes. (4096 bits).
Tegenwoordig is men wiskundig NOG een stapje verder dan reed-solomon. Stel je hebt 4096 bits en er zitten TWEE fouten in. Hoeveel mogelijkheden zijn er dan? Dan zijn er 4096*4095/2 mogelijke combinaties van 2 fouten. Samen met 4096 enkele fouten en 1 "alles goed" heb je iets van 24 bits nodig om dat te coderen. Maar als je 512 bytes met ieder een parity hebt, dan heb je maarliefst 512 bits waar je wat mee kan. Ruimschoots meer dan de 24 die je voor 2 fouten nodig hebt. Met de modernste wiskunde kunnen ze gewoon zoveel bitjes aan controle toevoegen zodat je ook inderdaad voor 4096 bits ongeveer per 12 toegevoegde bits ongeveer 1 extra fout kan tolereren. Dit is wat moderne flash geheugens doen. De fabrikant zegt dat je per 4096 bits zelden meer dan 8 fouten hebt, en dan gebruiken ze een code die 13 fouten kan corrigeren door 176 check bits toe te voegen.
Het maken van de check bits is niet het grootste probleem: dat is relatief eenvoudig. Bijvoorbeeld een MD5sum en dan de laagste zoveel bitjes opslaan zal best aardig werken. Maar met 1 fout kan je als computer makkelijk alle mogelijke 1-fout situaties aflopen en controleren of dat hem misschien was. Met 2 fouten tegelijk kan dat ook nog net, maar met meer wordt het al heel snel veel te veel rekenwerk. De slimmigheid zit hem daarin dat je met een redelijke berekening kan uitkomen op "dan zitten de fouten in posities x,y,z, u, v en w.".
Merk op dat moderne flash geheugens gewoon HEEL regelmatig fouten hebben. Denk aan gemiddeld iets van vier bits per 4096 opgeslagen bits. (denk aan 50/50 tussen: "niets aan de hand" en "8 fouten"!) Dus als je je SSD op 300Mbyte per seconde aan het uitlezen bent, dan is er niet veel tijd om de fouten te corrigeren! En dat moet dus HEEL regelmatig wel gebeuren. Als er 1x per uur een keertje een fout in zou zitten waardoor je dan die ene keer 1s moet wachten is dat geen probleem. Maar nu zit er (bij 300Mbyte/s) tienduizenden keren per seconde een te corrigeren fout in. Dat moet snel.
Dat is de stand van zaken betreffende ECC.