+ Responder ao Tópico



  1. Citação Postado originalmente por 1929 Ver Post
    é o que tenho feito. Só que 512 segurou muito. Coloco no cliente inicialmente em 2345 e fragmentation em 2346 obrigando o RTS a agir só nos frames maiores e observo . Depois reduzo para 1023 o fragmentation em 1924. E sempre observando.
    Só que estes valores achar o ideal nem sempre é fácil, pois o desempenho muda conforme tem mais ou menos usuários conectados.

    Um valor alto pode ser bom quando tem poucos usuários, mas ineficiente com muitos usuários.
    é aí que eu penso que o TDMA leva vantagem, pois ele trabalha de forma automática dividindo o tempo pelo número de usuarios conectados.

    E na RB do AP como tem deixado?
    Na RB em Advanced deixa em none o hw protection mode?
    O HW protetion mode em NONE?
    E deixa em branco os campos Hw fragmentation threshold e HW protetion thresholt em zero?

    E o frame time life deixa em zero?
    1929, não uso RB nos APs, uso Ubiquiti.
    Quanto ao fragmentation, só abaixaria ele para clientes com sinal mais baixo, longe do AP. Para clientes com bom sinal, deixaria ele em 2346. Abaixar também o fragmentation de 2346 para 1924 não faz muito sentido, pois a diferença é muito pouca. Aqui ou uso o fragmentation em 2346, ou uso valores como 1024 e 512.

    Abraços,
    Jonas Lima

  2. Citação Postado originalmente por jlima2001 Ver Post
    1929, não uso RB nos APs, uso Ubiquiti.
    Quanto ao fragmentation, só abaixaria ele para clientes com sinal mais baixo, longe do AP. Para clientes com bom sinal, deixaria ele em 2346. Abaixar também o fragmentation de 2346 para 1924 não faz muito sentido, pois a diferença é muito pouca. Aqui ou uso o fragmentation em 2346, ou uso valores como 1024 e 512.

    Abraços,
    Jonas Lima
    Houve um erro de digitação. Não é 1924 mas 1024, que é múltiplo de 8. Sempre utilizar múltiplos de 8 é o ideal.
    Tem razão, se baixasse pouco menos que 2346 a diferença não seria nem sentida.
    Com 1024 serão sempre enviados frames até com este valor máximo. E em casos de sinal menos favorecido, isto poderia ser benéfico. Nunca tinha visto nada escrito mas por dedução também penso como você.
    Já o RTS em 512 vai obrigar o ra´dio cliente pedir autorização sempre que o frame for de 512 ou mais. Frames menores vão ser enviados mesmo sem autorização já que o risco de choque compensa não enviar um overhead.
    Não sei se tem como monitorar isso na rede, mas se houvesse uma ferramenta que mostrasse estes frames transitando já seria uma mão na roda para ver onde estaria estatisticamente o ponto ideal, que varia de rede para rede e de horário para horário. E este último detalhe é o que acho o ponto fraco do RTS/CTS. Não dá para a gente ficar trocando estas config em função do horário.



  3. Citação Postado originalmente por 1929 Ver Post
    Houve um erro de digitação. Não é 1924 mas 1024, que é múltiplo de 8. Sempre utilizar múltiplos de 8 é o ideal.
    Tem razão, se baixasse pouco menos que 2346 a diferença não seria nem sentida.
    Com 1024 serão sempre enviados frames até com este valor máximo. E em casos de sinal menos favorecido, isto poderia ser benéfico. Nunca tinha visto nada escrito mas por dedução também penso como você.
    Já o RTS em 512 vai obrigar o ra´dio cliente pedir autorização sempre que o frame for de 512 ou mais. Frames menores vão ser enviados mesmo sem autorização já que o risco de choque compensa não enviar um overhead.
    Não sei se tem como monitorar isso na rede, mas se houvesse uma ferramenta que mostrasse estes frames transitando já seria uma mão na roda para ver onde estaria estatisticamente o ponto ideal, que varia de rede para rede e de horário para horário. E este último detalhe é o que acho o ponto fraco do RTS/CTS. Não dá para a gente ficar trocando estas config em função do horário.
    Perfeito!

    O fragmentation indica o tamanho máximo do frame sem haver fragmentação. Se o valor é 1024, frames maiores que isso serão divididos em 2 ou mais frames. Usar fragmentation baixo pode ser útil em clientes com sinal fraco ou com muita interferência. No caso do frame não ter sido entendido pelo AP, reenviar frames menores é mais rápido do que o cliente ter que reenviar todo um frame grande. Entretanto, fragmentation pequenos aumentam o overhead da rede, pois são necessários mais ACKs e também mais RTS/CTS se estiverem em uso.

    Abraços,
    Jonas Lima

  4. Citação Postado originalmente por Roberto21 Ver Post
    Olá Guilherme boa noite!


    Amigo aqui tive que desabilitar o controle de piso de ruído, era um tal de cliente desconectando que chega dava ''nojo'', desabilitei e ai sim as antenas começaram a funcionar normalmente.

    Se você for da intelbras, favor me orientar...

    Abração.
    Roberto,

    no caso do WOM estar como AP, não é recomendado deixar o piso de ruído no modo automático. Ele funciona muito bem como cliente, pois só existe um sinal a ser considerado, que é do AP. Assim ele consegue definir a margem de trabalho. Se vc notar, quando troca de Cliente para AP, o piso de ruído volta para o modo Manual. Neste caso, deve regular ele considerando o sinal do pior cliente. Outro ponto a se atentar é não deixar margem muito baixa entre o sinal e o piso de ruído, sendo o valor de 20 dB de SNR ideal para a maioria das aplicações.

    No seu caso, o WOM estava como AP ou Cliente? E se estava como cliente, qual margem de SNR vc deixou configurada?



  5. Então...ativando o piso de ruído nas ''station'' qual o ganho de desempenho que a função trás?






Tópicos Similares

  1. Respostas: 26
    Último Post: 23-01-2016, 12:46
  2. TP-Link TL-WA7510N ou Intelbras WOM 5000?
    Por Poemander no fórum Intelbras
    Respostas: 53
    Último Post: 26-05-2015, 18:52
  3. Respostas: 5
    Último Post: 06-02-2015, 18:00
  4. Intelbras wom 5000
    Por hizunspire no fórum Intelbras
    Respostas: 35
    Último Post: 22-09-2013, 23:53
  5. TL-WA5210G um Bom Equipamento para 2.4 Ghz
    Por OnlineZap no fórum Redes
    Respostas: 40
    Último Post: 06-06-2012, 19:17

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L