RTS/CTS como vocês estão procedendo?

[1929]

Meus amigos, gostaria de saber como vocês estão fazendo a configuração do RTS e do Frame Threshold nos rádios dos clientes?
Pelo que já li, pouco adianta fazer esta configuração no AP, pois a idéia é controlar o choque de pacotes proveniente de vários clientes ao mesmo tempo. O famoso "nó escondido"

Assim, por default a maioria dos equipamentos vem com o frame em 2346 e o RTS em 2347.
Deste modo o RTS nunca é acionado. E o nó escondido pode se manifestar livremente.

Fizemos uma config remota nos clientes online, deixando o frame em 2346 e o RTS em 2345. O resultado foi muito bom. O consumo médio do link aumentou em mais ou menos 30% e sem aumentar o processamento na RB. Isto indica que mais usuários estão navegando em melhores condições.

Me parece que valores menores de 2346 para o frame seria só indicado para casos extremos. Numa rede bem equilibrada, o rádio cliente deveria ter todas as condições para transmitir um frame o maior possível aceito pelo protocolo. Valores menores , se derem resultado positivo deve ser um indicativo de que a rede não está bem ou a conexão do cliente pode ser melhorada. Tenho usado o frame aliado a outros parâmetros para melhorar o desempenho individual.

Já o RTS, numa rede com muitos usuários, o AP vai receber dados de diversos clientes ao mesmo tempo. Daí ocorre choque de pacotes, que são perdidos e dai precisa ser reenviado. Resultado: latencia alta.
Quando o RTS tem valor menor que o Frame Threshold, um número que seja, o rádio cliente vai ter que pedir autorização para o AP. Assim o AP vai dando uma fila para atendimento. Pode parecer que o AP esteja segurando o usuário, mas na prática isso acaba sendo mais benéfico, pois não havendo o choque de pacotes, elimina-se a necessidade de reenviar os dados.
Logicamente que esta capacidade do AP enfileirar os usuários tem um limite. Se o AP estiver sobrecarregado de usuários, a fila será maior e poderá também haver um retardo na conexão. Mas este retardo também haveria e em intensidade muito maior se não houvesse o mecanismo do RTS ativado.
Aí vai entrar o monitoramento do Ap para decidir até quantos clientes vai ser permitido no AP.

Não estou aqui afirmando nada. Só postei o que observei na prática, aliado ao que já tem sido publicado sobre o RTS.

Assim, se alguém tiver tido o mesmo resultado ou diferente, uma troca de experiencias pode ser proveitoso a todos nós, já que temos achado pouca matéria prática sobre estas configurações.

[alexandrecorrea]

Ja utilizei, em alguns casos melhorava.. em outros.. piorava..

usei valores 512 nos clientes..

[EribertoTorres]

Já andei lendo isso no site do Morimoto e aqui, e estou com vontade de testar, aproveitando que tenho poucos clientes e setores sem clientes. Também estou com equipamento sobrando e posso testar.

1929, qual equipamento emissor e qual equipamento cliente você utilizou?

[1929]

Já andei lendo isso no site do Morimoto e aqui, e estou com vontade de testar, aproveitando que tenho poucos clientes e setores sem clientes. Também estou com equipamento sobrando e posso testar.

1929, qual equipamento emissor e qual equipamento cliente você utilizou?

No início usei mas não notei diferenças significativas. Mas também era uma rede bem menor. A medida que a rede cresce é que o problema do nó escondido surge e então o recurso do RTS pode ser de ajuda.

Ja utilizei, em alguns casos melhorava.. em outros.. piorava..

usei valores 512 nos clientes..

Alexandre, pelo que pude observar , se padronizar em 512 ocorre uma degradação generalizada no setor. Pois todos os pacotes que tiverem tamanho de 512 para cima terão que entrar na fila. Para mim também não rolou bem.
Daí resolvi deixar o mecanismo atuar só em pacotes grandes com 2345. Foi quando começou a dar melhor resultado.
Ainda tenho clientes que não fiz a troca. Mas agora que a maioria já foi trocada, vou remotamente trocando o restante com calma.

Observo que a maioria dos provedores não utiliza este recurso. Na prática é mais ou menos parecido com o que faz o Airmax ou o NV2 da mikrotik que usam o TDMA. Os APs determinam o tempo para cada usuários que está na fila. E evita o choque de pacotes também.
E no tdma é tão eficiente que o protocolo ainda agrega pacotes para formar valores acima de 2346 que é o tradicional do 802.11. Por isso o aumento de banda para o cliente é possível.

[alexandrecorrea]

Eu acredito que este valor seja para a camada 2.. portanto não são pacotes.. mas FRAMES .. e exatamente como voce (@@1929;) disse, 512 eh muito pouco.. na época em que fiz testes, nem mikrotik era famoso ... utilizava Terabeam Plus com cartoes Orinoco Gold !! um espetaculo !!

Penso que se for feito um teste com frames maiores.. deve ser uma boa solução !!

[AndrioPJ]

fico até com medo de postar mais toma aí o

RTS Threshold

3.1 Quando e em que circunstâncias eu iria fazer uma alteração a esta?

RTS pode precisar de ser ajustado para uma taxa mais baixa em CPEs conectados a APs que estão congestionadas, especialmente quando você tem nós ocultos. Por exemplo, se você tem um AP com 30 CPEs +, você quase certamente terá CPEs que são incapazes de discernir quando certas CPEs outras radiodifusão (a parte do "senso transportador de CSMA / CA). Neste caso, esses CPEs provavelmente tentam transmitir ao mesmo tempo um outro CPE está também a transmitir. Isso fará com que ambos os dispositivos que recuar e tentar novamente. Enquanto isso é aceitável ocasionalmente, excesso de tentativas pode causar grandes problemas em sua rede. Definir o CPE RTS para um valor menor pode ajudar a aliviar este problema.

3.2 O que faria um ajuste muito baixo (0 a algumas dezenas ou centenas)

susceptível de causar?

Na fixação RTS, você está tentando encontrar um equilíbrio entre alta sobrecarga devido a erros e sobrecarga elevada devido a quadros RTS. Apesar de quadros RTS são curtos, eles têm toda a sobrecarga (inter-frame espaços, cabeçalhos, etc) de outros quadros sem fio. Definir esse valor muito baixo irá causar um RTS / CTS troca de essencialmente cada frame. Enquanto isso deve fazer com que o número de tentativas de ser reduzida, a sobrecarga do RTS / CTS provavelmente vai causar mais problemas do que os erros fizeram seus antecessores. Lembre-se, você está definindo isso porque você já é congestionada. Eu não sugiro definir muito menor do que 128, embora eu sei de outras pessoas que usaram definições mais baixas do que isso. Na maioria dos casos, todos os CPEs sobre o AP será definido o mesmo.

A fonte que citou esta errada, esse texto foi retirado (e bem mal traduzido) de http://www.tranzeo.com/

A fonte correta é: http://support.tranzeo.com/knowledge...ory_id=0&sid2=

[1929]

Porque ter medo? Que eu saiba voce não faltou com o respeito para com ninguém, nem administradores, nem moderadores e nem contra outros usuários. Não enviou mensagens de baixo calão para a administração e nem pediu para ser removido do forum como houve casos. A maioria dos usuários nem ficam sabendo do que acontece nos bastidores e o quanto a equipe do Under tenta reajustar. Quando não dá não dá.

Este texto que foi postado e retirado do site da Tranzeo e não da fonte que você citou no post, já é bem conhecido. O do Morinoto citado anteriormente também. Eles dão a base teórica da coisa.

Mas na prática nem sempre o resultado é o mesmo já que outros fatores se apresentam. Só o monitoramento da rede é que pode chegar a um denominador comum.
Por isso eu acho que começar a mexer no RTS com valores mais altos é mais indicado. Valores muito baixos só indicam que a rede tem um problema, seja no cliente ou no AP.
Deixar desativado o RTS no cliente, para redes pequenas pode ser a melhor opção.

Eu fiz um teste e baixei o RTS para 512 num setor e o resultado foi desastroso. Isso porque a rede suportava frames de 2346 , mas limitar em 512 no RTS obrigava a fila no AP crescer muito e isso prejudicou o Throughput. Voltei para 2345 e deslanchou na hora.
Por isso volto a frisar, a prática é a mãe dos resultados. A teoria é para você saber o que está acontecendo e ajudar a tomar decisões.

Pessoal, pode alterar sem medo. Caso não dê o resultado esperado é só retornar ao que estava.
Mas precisa alterar num número significativo para aparecer resultados. Não adianta alterar só num cliente, pois os choques continuarão. Quando a maioria estiver sob controle e os choques começarem a diminuir é que os resultados deverão surgir.
Façam os testes e postem. A idéia é chegarmos a um denominador comum para confirmar o que obtive, se é válido ou não.

[jeffparre]

To querendo fazer uns testes aqui, mas tenho uma duvida, aqui uso radios ubnt nas torres e nos clientes, no ap (que fica na torre) devo tirar o tick do off em RTS Threshold ou somente nos radios dos clientes?

Outra duvida, mexo nessas opcoes abaixo?

Aggregation: Frames Bytes Enable

vlw

Abracos

[jeffparre]

Alguem vai responder minha duvida?

[izaufernandes]

Quando comprei o wavion, caro pra caramba e que não rendia o preço, o pessoal do suporte recomendava deixar o rts do cliente em 256 e a fragmentação desativada. Agora eu penso que funcionaria bem se fosse automatico porque se o fator muda com o ambiente e o ambiente muda com o tempo (mais ou menos clientes, interferência que degrada a capacidade do radio, banda passante que vai do minimo ao extremo do radio nos horarios de pico) o técnico teria que avaliar e alterar nos clientes, mesmo acessando remotamente não é muito viavel. Más se a coisa for critica e o parametro melhorar a situação aí vale a pena.

[jeffparre]

To querendo fazer uns testes aqui, mas tenho uma duvida, aqui uso radios ubnt nas torres e nos clientes, no ap (que fica na torre) devo tirar o tick do off em RTS Threshold ou somente nos radios dos clientes?

Outra duvida, mexo nessas opcoes abaixo?

Aggregation: Frames Bytes Enable

vlw

Abracos

Alguem vai me ajudar aí pra participar dos testes e postar os resultados?

[1929]

To querendo fazer uns testes aqui, mas tenho uma duvida, aqui uso radios ubnt nas torres e nos clientes, no ap (que fica na torre) devo tirar o tick do off em RTS Threshold ou somente nos radios dos clientes?

Outra duvida, mexo nessas opcoes abaixo?

Aggregation: Frames Bytes Enable

vlw

Abracos

Se você tiver clientes em b/g/n não ativa o Agregation. O agregation serve para juntar frames em casos de trabalhar em N puro.
Com rádios legacy ( b/g) o frame máximo que o protocolo envia é 2346.
Assim, para ativar o RTS você tem que deixar ele em 2345, assim o mecanismo é ativado sempre que o frame for maior que 2345.

No Ap da torre, seja mikrotik ou Ubiquiti, não ativa o RTS. O AP não precisa pedir licença aos clientes para transmitir e receber. Quem precisa pedir licença são os rádios clientes.
Teoricamente sem o RTS, os clientes só iriam transmitir quando o AP estivesse livre. Mas como os clientes não escutam os outros clientes , eles podem ficar enviando ao mesmo tempo pensando que o AP está livre e isso dá choque de pacotes que são perdidos.
Quando ativa o RTS no cliente, ele vai pedir ao AP licença para transmitir. Quando ele recebe do AP autorização, o AP irá dar preferencia para ele. É como se encontrasse a estrada livre e o choque de pacotes será extremamente reduzido. Ainda haverá pois ainda estarão trafegando pacotes menores que 2345. Aí é que vai entrar o acompanhamento do desempenho para ver se é vantajoso diminuir para valores menores que 2345. no RTS

[EribertoTorres]

Aqui tem as definicoes de alguns dos aspectos que estamos trabalhando:
http://www.hardware.com.br/tutoriais...o/pagina5.html

Foi um dos artigos que usei como referencia no que mencionei no meu primeiro post neste tópico.

[1929]

Já andei lendo isso no site do Morimoto e aqui, e estou com vontade de testar, aproveitando que tenho poucos clientes e setores sem clientes. Também estou com equipamento sobrando e posso testar.

1929, qual equipamento emissor e qual equipamento cliente você utilizou?

Me desculpe Eriberto, não tinha visto seu questionamento antes.

Nas torres tenho mikrotik e ainda alguns Nano. Em todos eles deixo desativado o RTS.

Nos clientes é variado. Tenho rádios b/g e b/g/n Por enquanto nada de N puro.

Se você tiver poucos clientes talvêz o mais prático seria deixar desativado o RTS no cliente pois a possibilidade de choque de pacotes será bem menor.
Mas nada impede de fazer o teste. Veja quanto de banda estão consumindo ao todo e depois de alterar o RTS vê se aumentou o consumo. Caso positivo é porque deu resultados.

- - - Updated - - -

Já andei lendo isso no site do Morimoto e aqui, e estou com vontade de testar, aproveitando que tenho poucos clientes e setores sem clientes. Também estou com equipamento sobrando e posso testar.

1929, qual equipamento emissor e qual equipamento cliente você utilizou?

Me desculpe Eriberto, não tinha visto seu questionamento antes.

Nas torres tenho mikrotik e ainda alguns Nano. Em todos eles deixo desativado o RTS.

Nos clientes é variado. Tenho rádios b/g e b/g/n Por enquanto nada de N puro.

Se você tiver poucos clientes talvêz o mais prático seria deixar desativado o RTS no cliente pois a possibilidade de choque de pacotes será bem menor.
Mas nada impede de fazer o teste. Veja quanto de banda estão consumindo ao todo e depois de alterar o RTS vê se aumentou o consumo. Caso positivo é porque deu resultados.

- - - Updated - - -

Já andei lendo isso no site do Morimoto e aqui, e estou com vontade de testar, aproveitando que tenho poucos clientes e setores sem clientes. Também estou com equipamento sobrando e posso testar.

1929, qual equipamento emissor e qual equipamento cliente você utilizou?

Me desculpe Eriberto, não tinha visto seu questionamento antes.

Nas torres tenho mikrotik e ainda alguns Nano. Em todos eles deixo desativado o RTS.

Nos clientes é variado. Tenho rádios b/g e b/g/n Por enquanto nada de N puro.

Se você tiver poucos clientes talvêz o mais prático seria deixar desativado o RTS no cliente pois a possibilidade de choque de pacotes será bem menor.
Mas nada impede de fazer o teste. Veja quanto de banda estão consumindo ao todo e depois de alterar o RTS vê se aumentou o consumo. Caso positivo é porque deu resultados.

[EribertoTorres]

Me desculpe Eriberto, não tinha visto seu questionamento antes.

Nas torres tenho mikrotik e ainda alguns Nano. Em todos eles deixo desativado o RTS.

Nos clientes é variado. Tenho rádios b/g e b/g/n Por enquanto nada de N puro.

Se você tiver poucos clientes talvêz o mais prático seria deixar desativado o RTS no cliente pois a possibilidade de choque de pacotes será bem menor.
Mas nada impede de fazer o teste. Veja quanto de banda estão consumindo ao todo e depois de alterar o RTS vê se aumentou o consumo. Caso positivo é porque deu resultados.

Vamos lá, entao em todo equipamento que transmite para o cliente, desativo o RTS de cara?
No cliente, por hora, desativo o RTS?
Como eu faco a medicao de que deu certo?

[1929]

Vamos lá, entao em todo equipamento que transmite para o cliente, desativo o RTS de cara?
No cliente, por hora, desativo o RTS?
Como eu faco a medicao de que deu certo?

Desativa no ap da torre.

No cliente se forem poucos não deverá aparecer resultados. Pois o choque de pacotes é pequeno.

Mas para testar, ativa nos clientes e vê se vai dar aumento de consumo de banda.

Se houver aumento de consumo é porque mais clientes conseguiram navegar melhor.

[EribertoTorres]

Desativa no ap da torre.

No cliente se forem poucos não deverá aparecer resultados. Pois o choque de pacotes é pequeno.

Mas para testar, ativa nos clientes e vê se vai dar aumento de consumo de banda.

Se houver aumento de consumo é porque mais clientes conseguiram navegar melhor.

Tenho um PtP (que é um cliente dedicado por assim dizer), vou testar nele entao. Passa os 4 Mbps tranquilo, mas quero ver se subo o máximo de banda (atualmente em 12 Mbps).

[jlima2001]

Se habilitar RTS em PtP irá diminuir o bandwidth. O controle RTS/CTS só traz resultados válidos para muitos clientes com muito tráfego num mesmo AP. Em alguns casos, até mesmo com poucos clientes é vantajoso, mas tem que estar havendo bastante tráfego e esses clientes tem que estar distantes uns dos outros.

Abraços,
Jonas Lima

[alexandrecorrea]

Ponto-a-Ponto não tem problema com "hidden-node", portanto não ha necessidade de ativar o RTS/CTS.

No caso de AP-Multi-Ponto, o RTS/CTS deve ser ativo no lado CLIENTE e não no AP !!

Este é um dos motivos que, se for fazer testes, leva algum tempo.

[EribertoTorres]

Justamente. Em um PtP que tenho, quero justo subir o bandwith e nas setoriais matar o nó oculto rss.