Bitowa stopa błędów BER (Bit Error Rate) jest z definicji znormalizowaną miarą jakości transmisji, dlatego prawidłowo określa się ją jako stosunek liczby błędnych bitów do całkowitej liczby odebranych bitów. Czyli bierzemy wszystkie bity, które dotarły do odbiornika, liczymy ile z nich jest uszkodzonych (różnią się od tego, co wysłano) i dzielimy: BER = N_błędnych / N_całkowitych. Dzięki temu dostajemy wartość bezwymiarową, najczęściej bardzo małą, np. 10⁻⁶, 10⁻⁹ itd. Taka forma jest standardem w telekomunikacji, w dokumentacjach urządzeń, w normach ITU-T, a także w specyfikacjach Ethernetu, światłowodów czy systemów radiowych. W praktyce wygląda to tak: jeśli w teście przesyłasz 10⁹ bitów, a analizator błędów pokaże 100 błędnych, to BER = 100 / 10⁹ = 10⁻⁷. Proste, ale bardzo użyteczne. Producenci sprzętu często deklarują np. „BER < 10⁻¹² przy SNR = …” i na tej podstawie można porównywać modemy, transceivery optyczne czy systemy radiowe. W systemach z korekcją błędów (FEC) czasem rozróżnia się BER przedkorekcją (pre-FEC BER) i pokorekcją (post-FEC BER), ale idea jest ta sama: zawsze dzielimy liczbę błędnych bitów przez całkowitą liczbę bitów w danym strumieniu. Moim zdaniem najważniejsze w zrozumieniu BER jest właśnie to „uśrednienie” – nie interesuje nas sama liczba błędów, tylko ich udział w całej transmisji. Dzięki temu można porównywać różne systemy o różnych prędkościach i różnych czasach pomiaru. W testach laboratoryjnych używa się generatorów wzorcowych sekwencji bitowych (PRBS) i specjalizowanych analizatorów, które dokładnie liczą zarówno wszystkie bity, jak i błędy. To jest dobra praktyka inżynierska: zawsze bazować na statystyce, a nie na pojedynczych przypadkach. W eksploatacji sieci też patrzy się na BER jako kluczowy parametr SLA – im niższy BER, tym wyższa jakość usług transmisyjnych, mniej retransmisji, mniejsze opóźnienia i ogólnie stabilniejsza praca systemu.
W przypadku bitowej stopy błędów BER kluczowe jest zrozumienie, że jest to miara względna, a nie absolutna. Interesuje nas, jaki odsetek wszystkich przesłanych bitów został uszkodzony, a nie sama liczba błędów ani różnica między jakimiś dwoma liczbami. Z mojego doświadczenia częsty błąd polega na myleniu „procentu błędów” z jakimś rodzajem bilansu poprawnych i niepoprawnych bitów. Podejście oparte na dzieleniu liczby błędnych bitów przez liczbę poprawnych bitów wydaje się na pierwszy rzut oka logiczne, bo ktoś myśli: „porównam błędy do tego, co poszło dobrze”. Problem w tym, że taka definicja nie jest skalowalna i nie jest zgodna z przyjętymi w branży standardami. Jeśli system działa bardzo dobrze i błędów jest mało, to mianownik (liczba poprawnych bitów) jest praktycznie równy całkowitej liczbie bitów, więc wynik będzie podobny do poprawnego BER, ale już przy większych zaburzeniach zaczyna się rozjeżdżać. Co gorsza, w skrajnym przypadku, gdy transmisja jest prawie całkowicie zniszczona i poprawnych bitów jest bardzo mało, taki „wskaźnik” przestaje mieć sens praktyczny. Równie mylące są odpowiedzi oparte na różnicy między liczbą poprawnych i liczby błędnych bitów albo między całkowitą liczbą bitów a liczbą błędnych. To są po prostu inne sposoby policzenia liczby poprawnych bitów, czyli informacja typu: „ile bitów jednak się udało”. Taka liczba może być przydatna pomocniczo, ale nie jest stopą błędów. Stopa błędów zawsze musi być znormalizowana do całkowitej liczby zdarzeń, które analizujemy – w tym przypadku do liczby wszystkich odebranych bitów. W przeciwnym razie nie można porównywać dwóch systemów o różnym czasie pomiaru albo różnej przepływności. Typowy błąd myślowy polega też na traktowaniu BER jak jakiejś „różnicy jakości”, np. poprawne minus błędne. W telekomunikacji i w normach takich jak ITU-T G.821 czy G.826 używa się podejścia probabilistycznego: BER jest estymacją prawdopodobieństwa, że pojedynczy bit zostanie przekłamany. Żeby to miało sens, licznik (błędne bity) musi być dzielony przez liczbę wszystkich obserwowanych bitów. Dlatego wszelkie formuły oparte na różnicach albo na dzieleniu przez liczbę poprawnych bitów są po prostu niezgodne z definicją i prowadzą do mylnych wniosków przy analizie jakości łączy, projektowaniu systemów korekcji błędów czy ocenie zgodności z wymaganiami SLA.