Aplicações que requerem baixa latência (tais como conversas telefónicas) não podem utilizar o pedido automático de repetição (ARQ); devem utilizar a correcção de erros de avanço (FEC). Quando um sistema ARQ descobre um erro e o retransmite, os dados reenviados chegarão tarde demais para serem utilizáveis.

Aplicações onde o transmissor imediatamente esquece a informação assim que ela é enviada (como a maioria das câmeras de televisão) não podem usar ARQ; eles devem usar FEC porque quando um erro ocorre, os dados originais não estão mais disponíveis.

Aplicações que usam ARQ devem ter um canal de retorno; aplicações que não têm canal de retorno não podem usar ARQ.

Aplicações que requerem taxas de erro extremamente baixas (tais como transferências de dinheiro digital) devem usar ARQ devido à possibilidade de erros incorrigíveis com FEC.

A engenharia de fiabilidade e inspecção também faz uso da teoria dos códigos de correcção de erros.

InternetEdit

Numa típica pilha TCP/IP, o controlo de erros é efectuado em múltiplos níveis:

• Cada frame Ethernet usa a detecção de erros CRC-32. Frames com erros detectados são descartados pelo hardware receptor.
• O cabeçalho IPv4 contém um checksum protegendo o conteúdo do cabeçalho. Pacotes com checksums incorretos são descartados dentro da rede ou no receptor.
• O checksum foi omitido do cabeçalho IPv6 a fim de minimizar os custos de processamento no roteamento da rede e porque a tecnologia atual da camada de link é assumida para fornecer detecção de erros suficiente (veja também RFC 3819).
• O UDP tem um checksum opcional cobrindo a carga útil e as informações de endereçamento nos cabeçalhos UDP e IP. Pacotes com soma de verificação incorreta são descartados pela pilha de rede. O checksum é opcional sob IPv4, e requerido sob IPv6. Quando omitido, assume-se que a camada de link de dados fornece o nível desejado de proteção de erro.
• TCP fornece um checksum para proteger a carga útil e as informações de endereçamento nos cabeçalhos TCP e IP. Pacotes com checksums incorretos são descartados pela pilha de rede, e eventualmente são retransmitidos usando ARQ, seja explicitamente (como por exemplo, através do triple-ack) ou implicitamente devido a um timeout.

Telecomunicações de espaço profundoEditar

O desenvolvimento de códigos de correção de erros foi fortemente acoplado ao histórico de missões de espaço profundo devido à extrema diluição da potência do sinal em distâncias interplanetárias, e a limitada disponibilidade de energia a bordo de sondas de espaço. Enquanto as primeiras missões enviaram os seus dados não codificados, a partir de 1968, a correcção de erros digitais foi implementada sob a forma de códigos convolucionais (suboptimamente descodificados) e códigos Reed-Muller. O código Reed-Muller foi bem adaptado ao ruído a que a nave estava sujeita (correspondendo aproximadamente a uma curva de sino), e foi implementado para a nave Mariner e usado em missões entre 1969 e 1977.

As missões Voyager 1 e Voyager 2, que começaram em 1977, foram projetadas para fornecer imagens coloridas e informações científicas de Júpiter e Saturno. Isto resultou no aumento dos requisitos de codificação, e assim, as naves espaciais foram suportadas por códigos convolucionais (de preferência Viterbi) que podiam ser concatenados com um código Golay (24,12,8) externo. A nave Voyager 2 suportou adicionalmente uma implementação de um código Reed-Solomon. O código concatenado Reed-Solomon-Viterbi (RSV) permitiu a correção de erros muito poderosos, e permitiu a viagem prolongada da nave espacial até Urano e Neptuno. Após as atualizações do sistema ECC em 1989, ambas as naves usaram a codificação V2 RSV.

O Comitê Consultivo para Sistemas de Dados Espaciais atualmente recomenda o uso de códigos de correção de erros com desempenho similar ao código RSV do Voyager 2 como mínimo. Os códigos concatenados estão cada vez mais a cair em desuso com as missões espaciais, e são substituídos por códigos mais poderosos tais como códigos Turbo ou códigos LDPC.

Os diferentes tipos de missões de espaço profundo e orbitais que são conduzidas sugerem que tentar encontrar um sistema de correcção de erros de tamanho único será um problema contínuo. Para missões próximas à Terra, a natureza do ruído no canal de comunicação é diferente daquela que uma nave espacial em uma missão interplanetária experimenta. Adicionalmente, como uma nave espacial aumenta sua distância da Terra, o problema da correção do ruído se torna mais difícil.

Emissão por satéliteEditar

A demanda por largura de banda do transponder de satélite continua a crescer, alimentada pelo desejo de entregar televisão (incluindo novos canais e televisão de alta definição) e dados IP. A disponibilidade de transponder e as restrições de largura de banda têm limitado este crescimento. A capacidade do transponder é determinada pelo esquema de modulação selecionado e pela proporção da capacidade consumida pela FEC.

Armazenamento de dadosEditar

Códigos de detecção e correção de erros são freqüentemente usados para melhorar a confiabilidade dos meios de armazenamento de dados. Uma faixa de paridade capaz de detectar erros de bit único estava presente no primeiro armazenamento de dados em fita magnética em 1951. O código rectangular ideal utilizado nas fitas de gravação codificadas em grupo não só detecta como também corrige erros de um só bit. Alguns formatos de arquivo, particularmente formatos de arquivo, incluem um checksum (na maioria das vezes CRC32) para detectar corrupção e truncagem e podem empregar arquivos de redundância ou paridade para recuperar porções de dados corrompidos. Os códigos Reed-Solomon são usados em discos compactos para corrigir erros causados por arranhões.

Discos rígidos modernos usam códigos CRC para detectar e códigos Reed-Solomon para corrigir erros menores em leituras setoriais, e para recuperar dados de setores que “deram errado” e armazenar esses dados nos setores sobressalentes. Os sistemas RAID utilizam uma variedade de técnicas de correcção de erros para corrigir erros quando um disco rígido falha completamente. Sistemas de arquivos como ZFS ou Btrfs, assim como algumas implementações de RAID, suportam a limpeza e resilversão de dados, o que permite que blocos defeituosos sejam detectados e (esperançosamente) recuperados antes de serem utilizados. Os dados recuperados podem ser reescritos exatamente para a mesma localização física, para substituir blocos em outro lugar no mesmo hardware, ou os dados podem ser reescritos em hardware de substituição.

Memória corretiva de errosEditar

Memória DRAM pode fornecer uma protecção mais forte contra erros suaves, confiando em códigos correctores de erros. Essa memória corretiva de erros, conhecida como memória ECC ou EDAC-protegida, é particularmente desejável para aplicações de missão crítica, tais como computação científica, financeira, médica, etc., bem como aplicações de espaço profundo devido ao aumento da radiação no espaço.

Controladores de memória corretores de erros usam tradicionalmente códigos Hamming, embora alguns usem redundância modular tripla.

Interleaving permite distribuir o efeito de um único raio cósmico potencialmente perturbando múltiplos bits fisicamente vizinhos através de múltiplas palavras, associando bits vizinhos a diferentes palavras. Desde que um único evento perturbador (SEU) não exceda o limite de erro (por exemplo, um único erro) em qualquer palavra em particular entre acessos, ele pode ser corrigido (por exemplo, por um código de correção de erro de um único bit), e a ilusão de um sistema de memória livre de erros pode ser mantida.

Além do hardware fornecer recursos necessários para o funcionamento da memória ECC, os sistemas operacionais geralmente contêm recursos de relatórios relacionados que são usados para fornecer notificações quando os erros soft são recuperados de forma transparente. Uma taxa crescente de erros de software pode indicar que um módulo DIMM precisa ser substituído, e tais informações de feedback não estariam facilmente disponíveis sem os recursos de relatórios relacionados. Um exemplo é o subsistema EDAC do kernel Linux (anteriormente conhecido como Bluesmoke), que coleta os dados de componentes habilitados para verificação de erros dentro de um sistema de computador; além de coletar e relatar os eventos relacionados à memória ECC, ele também suporta outros erros de soma de verificação, incluindo aqueles detectados no barramento PCI.

A poucos sistemas também suportam a limpeza de memória.