Op 5 juli 2017 22:13:02 schreef Max1966:
CRC errors (Up/Down) 0/371
FEC errors (Up/Down) 1832/269293
Stel ik stuur 10 cijfers, bijvoorbeeld 0123456789, die tel ik op (45) en het laatste cijfer daarvan stuur ik mee. 01234567895. Mocht ik nu iets krijgen als 01236567895, dan kan ik de eerste 10 cijfers optellen (47) en controleren dat het NIET klopt. Een CRC fout.
ZOU ik weten dat de 5e positie "onbetrouwbaar" is, dan zou je die opnieuw kunnen uitrekenen op basis van de 9 andere cijfers en de checksum.
Dit is min-of-meer wat er gebeurt als er Forward Error Correcting wordt toegepast. In werkelijkheid wordt de checksum zodanig uitgerekend dat ALS er fouten optreden je niet alleen weet DAT er iets fout is gegaan, maar ook WAT er fout is gegaan.
In de basis is het niet zo heel moeilijk om een code te bedenken waarmee je met twee verschillende checksums vaak kan achterhalen wat er fout is gegaan. De moderne wiskundige ontwikkelingen die dit praktisch hebben gemaakt zijn die waarbij gegarandeerd kan worden dat je het ALTIJD kan achterhalen en dat je efficient kan uitrekenen wat er mis is gegaan om het te corrigeren.
Voorbeeld van een JBF methode (flash storage, tot zeg 20 jaar geleden):
je wilt 16 cijfers versturen. Zet ze in een 4x4 vierkant en doe horizontaal en verticaal de bekende checksums:
code:
0123 6
4567 2 (22)
8912 0 (20)
3456 8 (18)
5948 4\6
Ik krijg nu uit m'n hoofd rechtsonder 2 verschillende waardes. Als je het binair doet hoort er maar 1 waarde uit te komen. OFWEl ik heb een rekenfout gemaakt OFWEL het werkt niet als je het decimaal doet. Ik heb horizontaal de som-van-de-cijfers tussen haakjes erbij gezet en daarna dus de tientallen weggelaten.
Krijg je nu een "kloptniet" in de 2e rij en de 3e kolom dan weet je dat het cijfer in de 2e rij, 3e kolom waarschijnlijk de foute is. En je kan uitreken wat ie wel moet zijn geweest.
Hier gebruiken we totaal 10 extra check-cijfers op slechts 16 cijfers die overgestuurd worden. Door dit soort systemen op een grotere hoeveelheid data tegelijk toe te passen kan je met minder extra bitjes toe (een lager percentage dan). Dit heet dus Forward Error Correcting: Zonder de bron lastig te vallen met "stuur dat nog eens" ("Watte?" ) kan je de data corrigeren ook al zijn er fouten opgetreden.
Om een ander voorbeeldje te geven van waar FEC gebruikt wordt: Op SD kaarten. Moderne kaarten verliezen van iedere 4096 bytes aan data gemiddeld zo'n 8 bits bij het teruglezen. De code die gebruikt wordt heeft iets van 176 bits aan extra data, en kan dan iets van 11 bits corigeren. (misschien maak ik nu ergens een rekenfout, de marge tussen gemiddelde aantal fouten en wat ie kan corrigeren is dacht ik veel groter).
Een CRC error treed dus op als een datapakket zodanig verminkt is geraakt dat er meer bitjes zijn omgevallen dan wat de FEC kan corrigeren. EIGENLIJK hoort dat niet te gebeuren. Bij een SD kaart ben je dan (een deel van) je data kwijt. Bij een network device is er altijd nog een "retransmit": de ontvangende kant ziet pakketjes 6 7 en 9 binnenkomen en als ie dan ook 10 en 11 heeft gezien weet ie dat 8 een ongelukje heeft gehad en vraagt ie om een herzending. Bij dingen als TV waarbij het geen zin heeft om 2 sec later het beeld van 2 sec geleden nog in te vullen wordt dat dan weer niet gedaan.