Antecedentes: estou em um ambiente barulhento e estou tentando otimizar minha rede Wi-Fi para ter uma conexão mais estável para um volume um pouco alto de usuários (~ 50-75 em um dia agitado). 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 executar ping no Google e caminhar pelo prédio, andando de AP para AP.
Na maioria dos pontos de acesso Wi-Fi que eu já vi, o limite RTS padrão é definido em 2347 (pelo que li em vários lugares, essa configuração conta como "desativada") e o limite de fragmentação é definido em 2346. Minha marca específica de roteador está definido em 2346 e 2346. Tenho várias perguntas ...
De onde é derivado o valor de 2346? Parece um tanto arbitrário, no entanto, as notas para Frag. O limite indica que ele precisa ter mais de 256 e um número par.
Como estão o RTS e o Frag. Limiares relacionados? Seus valores não podem ser coincidência.
Se modificados, eles devem ser alterados juntos?
Qual é um valor seguro para tentar reduzi-los, para iniciantes?
Minha prioridade não é necessariamente obter largura de banda de pico para cada dispositivo, mas oferecer aos usuários uma largura de banda / conexão estável e consistente.
Respostas:
2346 é o tamanho máximo de quadro 802.11 . Definir os limites de RTS e fragmentação ao máximo significa que nenhum pacote atenderá ao limite.
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 do RTS especifica o tamanho do quadro no qual o transmissor deve usar o protocolo RTS / CTS , que serve principalmente para resolver o problema do nó oculto . Obviamente, isso também aumenta a sobrecarga.
Não necessariamente - se você não tiver um problema de nó oculto, a alteração do limite do RTS não melhorará o desempenho. Para que o RTS / CTS seja ativado, o limite do RTS deve ser igual ou menor que o limite de fragmentação.
Eu começaria definindo-os de modo que um quadro Ethernet padrão seja fragmentado em dois quadros 802.11 (1500/2 = carga útil de 750 bytes + sobrecarga de 34 bytes = 784 bytes) e quaisquer quadros maiores que um terço de um quadro Ethernet padrão usam RTS (534 bytes).
Até onde eu sei, essas duas configurações afetam apenas o transmissor, ou seja, configurá-las no AP faz com que o AP as use para suas transmissões e não faz com que os clientes as usem para suas transmissões.
fonte
Esse cenário misto de b / g é particularmente subótimo. Você pode revisar algumas das discussões anteriores sobre o tópico, como:
O cliente sem fio mais lento determina a qualidade da conexão de todos os outros?
Além disso, outro desempenho assassino ocorre quando o ponto A pode receber o sinal do ponto B, mas B não pode receber o sinal de A. Outra pessoa no ServerFault apontou isso como o "efeito do transmissor oculto". Mais sobre esse fenômeno no link abaixo. Eles apontam que:
" ... Enquanto polarização horizontal é desejada, a falta de antenas omni-direccional polarizado horizontalmente comerciais de baixo custo pode exigir a utilização de antenas verticalmente polarizados. Um bom omni direccional polarizado verticalmente antena vai custar aproximadamente o mesmo que uma antena parabólica. Uso de uma antena omnidirecional ajuda a minimizar o efeito "transmissor oculto". "
http://www.arrl.org/using-ieee-802-11b-operating-under-part-97-of-the-fcc-rules
fonte
Discordo que "se você não tiver um problema de nó oculto, a alteração do limite do RTS não melhorará o desempenho". O uso de CTR / RTS sempre diminui as chances de colisões de dados. Como toda colisão de dados causa corrupção de dados e, portanto, exige que os dados sejam reenviados, menos colisões significam menos reenvios de dados e menos reenvios de dados podem melhorar bastante o desempenho do WiFi; claro, apenas se houver uma quantidade notável de colisões na sua rede.
Para explicar os detalhes: Um nó sempre precisa aguardar um certo período de tempo e detectar o canal para possíveis transmissões antes de declarar um próprio. Somente se não detectar nenhuma transmissão, poderá iniciar uma própria. Sem RTS / CTS, essa transmissão é diretamente uma transmissão de dados. Se agora dois nós tiverem a mesma idéia e iniciarem uma transmissão de dados quase ao mesmo tempo, essas transmissões colidirão. O resultado é que nenhuma transmissão chega a lugar algum, pois todos os dados recebidos serão corrompidos para todos os outros nós e o ponto de acesso.
Se RTS / CTS for usado, a transmissão começará com um pacote RTS sendo enviado pelo nó após a detecção. Somente se a solicitação RTS for respondida por uma resposta CTS, uma transmissão de dados será iniciada. Obviamente, se dois nós quiserem transmitir ao mesmo tempo, seus pedidos de RTS também poderão 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 o desempenho de toda a rede do que uma colisão de dados.
A desvantagem é que o próprio RTS / CTS exige alguma largura de banda de rede por conta própria e introduz novos tempos de detecção durante os quais nenhuma outra transmissão de dados ou transmissão RTS / CTS pode ocorrer. Para piorar as coisas, é claro que o RTS / CTS sempre deve ser executado usando a velocidade mais baixa suportada pela rede, caso contrário, os nós que suportam apenas essa velocidade não o verão. Então, basicamente, você pode dizer que o RTS / CTS sempre reduz o rendimento teórico de toda a sua rede, no entanto, se a sua rede sofrer muitas colisões, seja 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 a taxa de transferência real. Não é o número de nós ocultos,
Li um estudo (atualizarei e adicionarei um link aqui quando o encontrar novamente), o que sugere que, a menos que sua rede seja realmente pequena (menos de talvez 6 nós e cubra apenas uma pequena área) e não esteja isolada 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 levaria tanto tempo quanto um handshake RTS / CTS levaria, há pouco ganho no uso de RTS / CTS, pois se a rede precisa se recuperar de uma colisão de dados muito pequena ou de uma colisão RTS, isso não será suficiente. muita diferença. A melhor recuperação das 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 para nenhum 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á. Por outro lado, se houve uma colisão, apenas o fragmento afetado precisa ser reenviado, e não o pacote inteiro. No entanto, cada fragmento enviado possui uma sobrecarga própria; portanto, quanto mais fragmentos forem enviados, mais sobrecarga será adicionada e sobrecarga é basicamente uma largura de banda desperdiçada que também poderia ter sido usada para transmissões de dados.
fonte