Vroeger was het simpel. Je stuurde een "1", zet 5V op de draad, wacht lang genoeg om de boel te laten stabiliseren en aan de andere kant zie je gegarandeerd 100% van de gevallen een >4V, hoewel de ontvanger vanaf 3V garandeert een 1 te zien.
Tegenwoordig gaat men steeds vaker op het randje zitten. Je wilt een 1 versturen, zet een paar honderd milivolt op een aderpaar, wacht haast lang genoeg dat het aangekomen moet zijn, maar je hebt ondertussen al weer 5 nieuwe bitjes verstuurd, en vertrouwt er op dat die dus op het juiste ritme uitgelezen zullen worden. En als er eens een keer een bitje fout gaat, dan moet de CRC die er maar uitvissen.
Bij grote flash geheugens ligt het aantal foute bits gemiddeld op iets van 4/33000 bits. Maar uitschieters tot wel 15-20 bits. Rond de helft van de pages bevat geen fouten. De FEC is zodanig sterk dat er slechts een heel kleine kans is dat je van die omgevallen bits wat gaat merken.
In theorie, als 90% van de bits goed overkomen, kan je gewoon 90% van de theoretische bandbreedte halen. Minus epsilon. Om die epsilon klein te maken heb je wel enorm grote blokken nodig. Dat is voor internet en zeker telefonie onwenselijk. De epsilon (onnodig verstuurde bitjes) wordt wat groter, maar je hoeft niet een uur te wachten voordat je telefoongesprek aan de andere kant is aangekomen.... (voor ruimteschepen is zo'n theoretische benadering te overwegen. Maar ook daar wil je niet te grote pakketten: Als je verwacht dat 90% van de bitjes goed aankomt, en je ontvangt maar 89% van de bitjes, tja, dan heb je HELEMAAL vette pech: Je kan geen enkel bitje meer vertrouwen).
Maar goed..... Dus als je de FEC zo instelt dat ie steeds zat bitjes verstuurt dat voldoende correcte bitjes aankomen, dan is het helemaal niet zo erg dat die vaak in actie moet komen...
Bij arco zie ik behoorlijke CRC fouten. Dat zijn dus gevallen waarbij de FEC een verkeerde gok heeft genomen over welke bitjes er omgevallen waren. Als je met TCPIP een download doet, dan gaat ie goed om met zeg een paar promille aan verloren pakketjes: er zijn zeg 20 pakketjes tegelijk onderweg tussen de server en jou. Als dan de server van jou computer te horen krijgt: "ik heb pakketjes tot 58 goed ontvangen, daarna 60-65 ook". Dan voelt ie op z'n klompen aan dat 59 zoek is geraakt en verstuurt hem nog een keer. Als dat 0.1% van de pakketjes overkomt, dan gaat je download maar 0.1% langzamer. Gaat dit percentage omhoog dan gaat dit niet meer op. Iedere keer dat zo'n pakketje zoek raakt, reduceert ie ook de snelheid iets. Daarna moet het weer een tijdje helemaal goed gaan voordat ie weer sneller gaat. Heel vroeger bij Casema hadden we 10% van de pakketjes die fout gingen. Dan loopt het uit de klauwen: hij komt nooit meer op snelheid.
Het idee van de ontwerpers van TCPIP was dat pakketjes verloren zouden gaan omdat er een link overbelast is. Dus meer sturen heeft geen zin en zelf een beetje dimmen is wel aardig. Maar als dat idee over wat er aan de hand is, niet klopt, dan gaat het fout. Zoals toen bij Casema: steeds een stapje langzamer, maar nooit sneller. En die 10% verloren pakketjes hangt niet af van hoe druk het is....