Limite RTS, fragmentação e outras configurações avançadas de WiFi

Question

Histórico: Estou em um ambiente barulhento e estou tentando otimizar minha rede Wi-Fi para ter uma conexão mais estável para o volume relativamente alto de usuários (~ 50-75 em um dia movimentado). Existem 4 APs, e eu já ajustei os canais e transmita energia e, no geral, tenho uma cobertura bastante decente. No entanto, ainda recebo cerca de 10% de queda de pacotes ao fazer ping no Google e andar pelo prédio, passando de AP para AP.

Na maioria dos APs WiFi que eu vi, o Limite RTS padrão é definido como 2347 (pelo que eu li em vários lugares, essa configuração conta como "desativado"), e o Limite de Fragmentação é definido como 2346. Meu particular marca do roteador é definida em 2346 e 2346. Eu tenho várias perguntas ...

1. De onde o valor de 2346 é derivado? Parece um pouco arbitrário, no entanto, as notas para Frag. Limiar indica que precisa ser maior que 256 e um número par.

2. Como estão o RTS e o Frag. Limiares relacionados? Seus valores não podem ser coincidência.

3. Se modificadas, elas devem ser alteradas juntas?

4. Qual é o valor seguro de tentar abaixá-los, para começar?

Minha prioridade não é necessariamente obter largura de banda de pico para cada dispositivo, mas fornecer aos usuários uma conexão / largura de banda estável e consistente.

    

Answer 1

1. 2346 é o tamanho máximo 802.11 . Definir o RTS e os limites de fragmentação como o máximo significa que nenhum pacote atenderá ao limite.

2. O limite de fragmentação limita o tamanho máximo do quadro. Isso reduz o tempo necessário para transmitir o quadro e, portanto, reduz a probabilidade de que ele seja corrompido (ao custo de mais sobrecarga de dados). O limite RTS especifica o tamanho do quadro no qual o transmissor deve usar o protocolo RTS / CTS , que é em grande parte para resolver o problema do nó oculto . Isso obviamente também adiciona sobrecarga.

3. Não necessariamente - se você não tiver um problema de nó oculto, a alteração do limite de RTS não melhorará o desempenho. Para que o RTS / CTS efetue o kick no limite de RTS deve ser o mesmo ou menor que o limite de fragmentação.

4. Eu começaria definindo-os de modo que um quadro Ethernet padrão fosse fragmentado em dois quadros 802.11 (1500/2 = carga de 750 bytes + sobrecarga de 34 bytes = 784 bytes) e quaisquer quadros maiores que um terço de um padrão Quadro Ethernet usa RTS (534 bytes).

Até onde sei, ambas as configurações afetam apenas o transmissor, ou seja, configurá-las no AP apenas faz com que o AP as use para suas transmissões e não faça os clientes usá-las para suas transmissões.

    

Answer 2

Esse cenário misto b / g é particularmente sub-ótimo. Você pode rever algumas das discussões anteriores sobre o tópico, como:

O cliente sem fio mais lento dita a qualidade de conexão de todos os outros?

Além disso, outro matador de desempenho ocorre quando o ponto A pode receber o sinal do ponto B, mas B não pode receber o sinal de A. Alguém no ServerFault apontou isso como o "efeito do transmissor oculto". Mais sobre esse fenômeno no link abaixo. Eles apontam que:

"... Enquanto a polarização horizontal é desejada, a falta de antenas omnidirecionais comerciais horizontais horizontais pode exigir o uso de antenas polarizadas verticalmente. Uma boa antena verticalmente polarizada omnidirecional custará aproximadamente o mesmo que uma antena parabólica. . O uso de uma antena omnidirecional ajuda a minimizar o efeito de "transmissor oculto". "

link

    

Answer 3

Eu discordo que "se você não tiver um problema de nó oculto, a alteração do limite de RTS não melhorará o desempenho". Usando o CTR / RTS sempre diminui as chances de colisões de dados. Como cada colisão de dados causa corrupção de dados e, portanto, exige que os dados sejam reenviados, menos colisões significam menos reenvio de dados e menos reenvio de dados pode melhorar bastante o desempenho do WiFi; claro, somente se houver uma quantidade notável de colisões em sua rede.

Para explicar os detalhes: Um nó sempre tem que esperar por um certo período de tempo e sentir o canal para possíveis transmissões antes de declarar um próprio. Somente se não detectar transmissões, poderá iniciar uma própria. Sem RTS / CTS, esta transmissão é diretamente uma transmissão de dados. Se agora dois nós tiverem a mesma ideia e iniciarem uma transmissão de dados quase ao mesmo tempo, então essas transmissões irão colidir. O resultado é que nem a transmissão faz isso em qualquer lugar, pois todos os dados recebidos serão corrompidos para todos os outros nós e para o AP.

Se RTS / CTS for usado, a transmissão começa com um pacote RTS sendo enviado pelo nó após a detecção. Somente se essa solicitação RTS for respondida por uma resposta CTS, uma transmissão de dados será iniciada. Naturalmente, se dois nós quiserem transmitir ao mesmo tempo, seus pedidos RTS também podem colidir com o mesmo efeito negativo que nenhum RTS é recebido. A diferença é que toda a rede se recuperará muito mais rapidamente de uma colisão RTS do que de uma colisão de dados. Portanto, uma colisão RTS é menos prejudicial para todo o desempenho da rede do que uma colisão de dados.

A desvantagem é que o próprio RTS / CTS requer alguma largura de banda de rede e introduz novos tempos de detecção durante o qual nenhuma outra transmissão de dados ou transmissões RTS / CTS podem ocorrer. Para tornar as coisas ainda piores, é claro que o RTS / CTS sempre deve ser executado usando a velocidade mais lenta que a rede suporta, caso contrário, os nós que suportam essa velocidade não o verão. Então, basicamente, você pode dizer que o RTS / CTS sempre diminui o throughput teórico de toda a sua rede, no entanto, se sua rede sofre muitas colisões, ou pelo problema do nó oculto (que também pode ser causado por nós de outras redes usando apenas o mesmo canal como sua rede) ou porque seu WiFi está lotado (à medida que mais nós aumentam a chance de colisões aleatórias), ele pode de fato aumentar o throughput real. Não é o número de nós ocultos, o número de colisões é o fator importante aqui, não importa como elas sejam causadas.

Eu li um estudo (atualizarei e adicionarei um link aqui uma vez que consegui encontrá-lo novamente), o que sugere que a menos que sua rede seja realmente pequena (menos de 6 nós e cobrindo apenas uma pequena área) e não isolado de outras redes usando o mesmo canal, usando RTS / CTS quase sempre tem um efeito bastante positivo na prática. Então, por que o valor limite? Se o envio dos dados demorasse tanto tempo quanto o handshake RTS / CTS, o ganho com o uso do RTS / CTS é pequeno, já que a recuperação de uma colisão de dados muito pequena ou de uma colisão RTS não será necessária. muita diferença. A melhor recuperação de colisões RTS é porque os pacotes RTS são muito pequenos, enquanto os pacotes de dados geralmente não são. Mas para pacotes de dados muito pequenos, o RTS / CTS apenas adiciona sobrecarga sem ganho prático.

E agora você também sabe como um limite de fragmentação pode melhorar o desempenho da rede. Por um lado, limita o tamanho dos pacotes enviados e, como explicado acima, quanto menor o pacote em uma colisão, mais rápido a rede se recuperará dele. E, por outro lado, se houve uma colisão, apenas o fragmento afetado por ela precisa ser reenviado, não o pacote inteiro. No entanto, cada fragmento enviado tem uma sobrecarga própria, portanto, quanto mais fragmentos forem enviados, mais overhead que será adicionado e sobrecarga será basicamente a largura de banda desperdiçada que poderia ter sido usada para transmissões de dados.