Hvor mange fejl er for mange på dit DSL-internet?

DSL skal levere hastighed og stabilitet. Stabilitet er langt vigtigere end hastighed, men hvordan måler man det?

De foregående artikler handler om det miljø, som DSL skal fungere i, og nu vil jeg i sommervarmen slappe af med en artikel om, hvilke krav vi så stiller til et DSL-system.

Der er to primære ting, som vi kan stille krav om: Hastighed og stabilitet.

Læs også de forgående artikler i serien: 
Når vi snakker hastighed, så er der et loft - altså den højest mulige hastighed, som er defineret dels af den teoretiske grænse, som gode gamle Claude Shannon har beskrevet, og dels en praktisk/implementeringsmæssig grænse.

Dette kommer jeg mere ind på i næste artikel, som handler om modulationsteori.

Vi skal selvfølgelig også sikre os, at producenterne af routere og chipsets bliver presset til at gøre sig umage, så der også er defineret en nedre grænse. Men som I kunne læse i artiklerne om kabler og støj, så er hastigheden særdeles afhængig af de faktuelle forhold på linjen.

Dette har man imødegået ved at definere en række standardscenarier for støj og kabeltyper, og man stiller så krav til en minimums-performance under disse forhold. Alt dette foregår i Broadband Forum (BBF), hvor operatører og leverandører fra hele verden deltager.

For VDSL kan kravene f.eks. findes i TR-114 (annex B er den, der gælder for Europa). Jeg kan anbefale, at interesserede snuser rundt inde på http://www.broadband-forum.org/, der er mange spændende ting, man kan læse om.

Hastighed er én ting, men det er min erfaring, at stabilitet er langt mere væsentlig. Der er ikke noget mere irriterende end en internetforbindelse, som er ustabil. Dette er ikke mindst blevet vigtigt, efter at man introducerede fjernsyn over internettet, også kendt som IPTV.

TIP: Hvis du sidder og føler dig lidt ensom i supporten for en internetudbyder og trænger til at snakke med nogen, så flip et par linjer for IPTV-kunder ... så skal telefonen nok ringe.

Hvad er så kravet for DSL? 
Hvis vi starter i det teoretiske hjørne, så benyttes termen BER (Bit Error Rate) for transmissionssystemer. 

BER er forholdet mellem korrekte bits og fejlbehæftede bits og angives som en negativ potens af 10. Således betyder det, hvis et link har en BER på 10^(-7), at når der sendes 10.000.000 bits må højst én bit være fejlbehæftet.

Tallet er ikke tilfældigt valgt - det er det grundlæggende designkriterium for et DSL system, at BER skal højest være 10^(-7) ved 0 dB margin. Dette tal er ikke specielt imponerende, når man tænker over det. Ved en hastighed på 10 Mbit/s betyder det jo en fejl i sekundet, og hvem kan leve med det?

Det er heldigvis ikke så slemt, for du skal lægge mærke til, at den angivelse er ved 0 dB margin, hvor linjer aldrig kører. I praksis vælger de fleste operatører at køre DSL ved en margin på 6 dB (med andre ord kan støjen øges med 6 dB, uden at linket falder) som er et passende kompromis mellem performancetab og forbedret stabilitet.

Hvis vi antager, at støjen er konstant og fuldstændig hvid, betyder 6 dB margin, at BER falder til omkring 10^(-24), hvilket vil sige en fejl ca. hver 1,5 billioner år. Desværre opfører verden sig sjældent så eksemplarisk, og et mere realistisk bud (baseret på empiriske data) lyder derfor på, at BER <= 10^(-9) ved 6 dB margin. 

Dette kan omsættes til, at der under normal operation går mindst 1 time og 40 minutter mellem bitfejl og typisk noget længere (før du går i panik, så husk, at langt de fleste bitfejl rettes af fejlkorrektionsalgoritmerne - mere om dette i en kommende artikel).

Bitfejl, som BER angiver, er ikke en særlig praktisk målemetode, da det per definition forudsætter en seriel strøm af data. DSL implementerer ikke som standard et serielt interface, så det er svært at lave en direkte måling af BER på et DSL system. 

Metoden, der benyttes, er i stedet, at estimere BER ud fra antallet af CRC-fejl på linjen (Cyclic Redundancy Check, en meget udbredt algoritme til at detektere fejl i data - For de nysgerrige: http://en.wikipedia.org/wiki/Cyclic_redundancy_check).

Det er vedtaget på baggrund af en analyse og et væld af praktiske målinger, at en CRC fejl svarer til 20 eller 50 bitfejl afhængig af, om DSL systemet benytter FAST eller INTERLEAVED datapath (mere om datapath i en kommende artikel om fejlkorrektion).

Stabilitet, kogt ned til de to primære parametre
Et DSL-system rapporterer en lang række performance- og fejlvariable, og tricket er at nedkoge den store mængde information til kun det relevante. 

Når vi snakker stabilitet, er der, set fra brugerens synsvinkel, to primære fænomener, der giver anledning til oplevet ustabilitet:

CRC fejl - mindre fejl på linjen f.eks. forårsaget af støj eller clipping (overstyring af linedriver) resulterer i, at modtagne datapakker er fejlbehæftede (hvilket detekteres vha. CRC algoritmen). Kundens oplevelse er, at datapakken skal retransmitteres eller er tabt. Ved surf giver det sig udslag i øget latenstid, og ved IPTV giver det potentielt et glitch på TV billedet.

Et glitch defineres som en fejl af kort varighed. Se f.eks. forklaring her. Faktisk vil 10 på hinanden SES betyde, at linket reinitialiserer, men det er ikke relevant for forklaringen.

Reinitialiseringer - større fejl (eller gentagne fejl) på linjen resulterer i, at DSL-linket brydes og derefter genforhandles. Kundens oplevelse er et totalt udfald af datastrømmen af typisk 30-60 sekunders varighed. Denne type fejl kan virkelig lave sure kunder, så her bør man som ISP gøre sig ekstra umage!

Tiden har betydning
Forestil dig følgende to tænkte scenarier: Du har 20 Mbps downstream (interleaved), og vi måler på din linje i et døgn:

1) Din linje oplever en DS-CRC fejl præcist en gang i minuttet.

2) Din linje kører fuldstændig perfekt i 23 timer og 59 minutter. I de sidste 60 sekunder kommer der 24 DS-CRC fejl i sekundet.

I begge tilfælde er antallet af CRC fejl 1440, og dermed - hvis vi udelukkende betragter antallet af CRC fejl - er de to linjer præcist lige ustabile. Men er din oplevelse som kunde den samme? 

I det første tilfælde er du garanteret, at blive generet af fejlene. I det andet tilfælde er der en ikke ubetydelig sandsynlighed for, at du enten sover eller laver noget andet lige i de kritiske 60 sekunder.

Det sidste scenarie er i øvrigt det mest realistiske - CRC-fejl kommer som regel i bursts.

Derfor er det interessant at kigge på spredningen i tid for CRC-fejlene. Til det benytter vi to tidsbaserede parametre:

- Errored Seconds (ES) - Antallet af 1-sekunders intervaller hvor mellem 1-17 CRC-fejl er detekteret.

Severely Errored Seconds (SES) - Antallet af 1-sekunders intervaller hvor 18 eller flere CRC-fejl er detekteret.

Genbesøger vi eksemplet ovenfor og introducerer ES i ligningen, kan vi se, at det nu er muligt at skelne de to scenarier.

CRC er stadig 1440, men i det ene tilfælde er ES=1440/SES=0, og i det andet er ES=0/SES=60 [2]. Denne information kan hjælpe med at klassificere fejltype og kilde.

Quality of Experience
CRC, ES, SES, NSA, BER ... fancy forkortelser kan jeg hælde ud af ærmet, men problemet med alle disse parametre er, at det er objektive tal, og vi mangler koblingen over til kundernes subjektive oplevelse.

Hermed vil jeg introducere en ny fancy forkortelse, QoE (Quality of Experience).

Hvor QoS (Quality of Service) er en objektiv parameter, der kan kvantificeres direkte (f.eks. CRC-fejl eller latency), er QoE en subjektiv parameter og dermed et udtryk for, hvordan kvaliteten opfattes af slutbrugeren.

Måleenheden for QoE er typisk MOS (Mean Opinion Score), som fremkommer ved at udsætte en forsøgsgruppe for fejl i tv-oplevelsen og sammenfatte middelværdien af deres resulterende subjektive oplevelse af kvaliteten. Nedenstående graf viser den ikke lineære sammenhæng mellem det objektive og det subjektive. Det subjektive QoE kriterium kan mappes over i nogle målbare QoS parametre, som vi dermed kan opstille nogle specifikke og målbare krav for.

Broadband Forum TR-126 (Tabel 12&14) specificerer følgende QoE kriterier for IPTV:
  • For SD (Standard Definition) TV, maksimum én artefakt per time
  • For HD (High Definition) TV, maksimum én artefakt per 4 timer

En artefakt er en fejl på linjen, som giver et synligt resultat på tv'et (sort skærm, glitch, udfald af lyd, etc.).

Hvis vi mapper QoE direkte til QoS vil det sige, at en linje er perfekt til SD IPTV, hvis der mindst går en time mellem hver CRC-fejl og tilsvarende for HD IPTV mindst fire timer mellem hver CRC-fejl.

Dette er dog en absolut worst case-betragtning, idet enkeltstående CRC-fejl overhovedet ikke påvirker tv-oplevelse, da IPTV platformen (i hvert fald den, Fullrate benytter) foretager fejlkorrektion på applikationslaget. 

Min erfaring siger, at IPTV er ganske immunt for såvel enkelte som bursts af CRC-fejl, men at REIN (Repetitive Electrical Impulse Noise), som jeg beskrev i artiklen om støj, er den type fejl, som giver størst problemer.

Nok om kvalitet for denne gang. Klummen holder lidt ferie og vender stærkt tilbage med den første artikel om, hvordan vi så implementerer DSL.

God sommerferie til jer alle!

Læs også første artikel i serien: Dine internetkabler er en Ferrari på en grusvej



Ytringer på debatten er afsenders eget ansvar - læs debatreglerne
Indlæser debat...
mest debaterede artikler

Computerworld
Jens Højgaard skrev negativ anmeldelse på Trustpilot - nu er han blevet sagsøgt for 11.419 kroner
En negativ anmeldelse på Trustpilot om et inkassofirma har indtil videre kostet den selvstændige hvidevare-reparatør Jens Høgni Højgaard flere tusinde kroner og en tur i retten. Forklaringen er, at inkassofirmaet har forbudt kunder at udtale sig negativt i offentlighed om selskabet.
CIO
Har rulllet Mac-computere ud til 90.000 ansatte: Her er seks nyttige erfaringer fra IBM's store Mac-udrulningsprojekt
På lidt over et år har IBM rullet 90.000 Mac-computere ud til medarbejderne, mens virksomheden har gjort sig en hel række erfaringer. Læs her, hvad IBM har lært af projektet.
Comon
Overblik: Her har du ni af årets allerbedste bærbare computere
Her har du en liste over ni af de bedste bærbare computere, du kan købe i Danmark.
Channelworld
Overblik: Det ved vi efter første retsmøde i den store Atea-bestikkelsessag
Den første sag om bestikkelse af offentlige ansatte kører i disse dage, hvor offentlige ansatte anklages for at have modtaget bestikkelse fra it-giganten Atea.
White paper
Tjekliste: 10 tegn på, at du har behov for at modernisere din Backup og Recovery løsning
Gennemgå denne tjekliste for at afgøre, om dit miljø har behov for en mere moderne tilgang til backup og recovery. Hvis ikke du kan tjekke nogen af disse af, kan det være tid til at revurdere din databeskyttelse strategi.