Página 2 de 3 PrimeiroPrimeiro 123 ÚltimoÚltimo
+ Responder ao Tópico



  1. #7

    Padrão Re: Método mais correto de trabalhar com MCS?

    Citação Postado originalmente por Batmam Ver Post
    Mais usando mcs 7 não vai ficar 1x1?
    sim, mas foi o maior que permitiu melhorar o ccc... O resultado final foi mil vezes melhor do que antes que estava no automático.

  2. #8

    Padrão Re: Método mais correto de trabalhar com MCS?

    E sobre essa questão de cada fabricante ter seus algoritmos, uma coisa que é do padrão IEEE 802.11_, é a obrigatoriedade de só baixar data rate depois de 3 perdas consecutivas de pacote.

    Não importa o que o fabricante quer, se quer certificação pra estar de acordo com os padrões da IEEE tem que respeitar isso. Notem a palavra obrigatoriedade, tá lá bem claro nos drafts da IEEE, só pode diminuir data rate depois de 3 perdas consecutivas. Não é 30% de perdas, é 3 perdas consecutivas. 3 pacotes perdidos. E uma coisa MUITO comum é ter 1 perda a cada 2 ou 3 pacotes, a rede fica um LIXO mas o padrão da IEEE não deixa o firmware reduzir o data rate!

    A hora de aumentar largura de canal, amentar data rate, mudar canal, escolher ack timeout, mudar intervalo de guarda (A, B e G não tinham), a junção/aglutinação de pacotes menores, isso sim o algoritmo pode definir a vontade, mas das únicas coisas que lembro que os protocolos da IEEE exigem é ter que esperar 3 perdas CONSECUTIVAS de pacote pra reduzir data rate.

    Como eu disse, isso não afeta a vida de conexão com sinal sobrando, ou sinal fixo (PTP tem sinal fixo. Quando muito varia 2dBm com chuva. Só se tiver instalação porca ou visada parcial pra variar mais), afeta sinal variando, uma hora tem -55dBm num cliente e tá tudo link em MCS15, meia hora depois entra outro com -70dBm, aí perde 40% dos pacotes (Mas não perde 3 consecutivos! Lembrem que conforme a conexão o pacote tem que ser reenviado do usuário final, o navegador é que vai ter que reenviar os pacotes, não a CPE, por isso é mais raro ter 3 perdas consecutivas de pacote em provedor típico, é bem diferente de notebook conectado direto no modem) mas apesar dessas perdas o sistema burro pra cacete (Seria um algoritmo burro pra caramba) tá lá insistindo em MCS15.

    Cansei de ver MCS15 com sinal lixo tipo -75dBm, sistema insistindo nessa burrice, porque não tem nenhum algoritmo atuando especificamente nisso, tem uma grande propaganda no auto-fall-back dos fabricantes pra reconectar ao perder conexão (Geralmente sem negociar novas chaves, o que tornaria a queda mais demorada) justo porque eles não tem muito o que fazer pra EVITAR queda, é fácil testar, fixa em MCS0 e vai o mais longe possível até a conexão cair (Bota um ping pra ver), pode ser em casa. Aí bota em automático, fica do lado do roteador, ele vai subir rapidinho pra MCS15, e quando for caminhando pra longe a conexão cairá muito antes de chegar onde foi antes, vai reconectar (Porque o algoritmo de auto-fall-back sim é bem estruturado) mas até chegar no final terá duzias ou centenas de pacotes perdidos, por conta desse tempo de reconexão (Isso que os algoritmos de auto-fall-back são bons! Em 2003 era um terror, 2 minutos pra reconectar quando algo caia, mesmo indo pro lado do roteador, que com seus 40-50MHz, e 4MB de Ram, não conseguiam processar tanta coisa rápido).

    Fabricante que quer garantir mais banda, digamos a Mimosa ou a Cambium nos seus protocolos proprietários, não usam o padrão IEEE não só pelo TDMA, a diminuição de data rate é muito rápida, em vários rádios bons que usam a faixa aberta de 5GHz, mas não usam o IEEE, é botar a mão na frente de uma antena de disco que o sinal cai e o data rate cai junto rapidinho, quando muda pra IEEE 802.11 você bota a mão, o CCQ cai, o ping aumenta, mas o data rate não diminui.



  3. #9

    Padrão Re: Método mais correto de trabalhar com MCS?

    Citação Postado originalmente por rubem Ver Post
    E sobre essa questão de cada fabricante ter seus algoritmos, uma coisa que é do padrão IEEE 802.11_, é a obrigatoriedade de só baixar data rate depois de 3 perdas consecutivas de pacote.

    Não importa o que o fabricante quer, se quer certificação pra estar de acordo com os padrões da IEEE tem que respeitar isso. Notem a palavra obrigatoriedade, tá lá bem claro nos drafts da IEEE, só pode diminuir data rate depois de 3 perdas consecutivas. Não é 30% de perdas, é 3 perdas consecutivas. 3 pacotes perdidos. E uma coisa MUITO comum é ter 1 perda a cada 2 ou 3 pacotes, a rede fica um LIXO mas o padrão da IEEE não deixa o firmware reduzir o data rate!

    A hora de aumentar largura de canal, amentar data rate, mudar canal, escolher ack timeout, mudar intervalo de guarda (A, B e G não tinham), a junção/aglutinação de pacotes menores, isso sim o algoritmo pode definir a vontade, mas das únicas coisas que lembro que os protocolos da IEEE exigem é ter que esperar 3 perdas CONSECUTIVAS de pacote pra reduzir data rate.

    Como eu disse, isso não afeta a vida de conexão com sinal sobrando, ou sinal fixo (PTP tem sinal fixo. Quando muito varia 2dBm com chuva. Só se tiver instalação porca ou visada parcial pra variar mais), afeta sinal variando, uma hora tem -55dBm num cliente e tá tudo link em MCS15, meia hora depois entra outro com -70dBm, aí perde 40% dos pacotes (Mas não perde 3 consecutivos! Lembrem que conforme a conexão o pacote tem que ser reenviado do usuário final, o navegador é que vai ter que reenviar os pacotes, não a CPE, por isso é mais raro ter 3 perdas consecutivas de pacote em provedor típico, é bem diferente de notebook conectado direto no modem) mas apesar dessas perdas o sistema burro pra cacete (Seria um algoritmo burro pra caramba) tá lá insistindo em MCS15.

    Cansei de ver MCS15 com sinal lixo tipo -75dBm, sistema insistindo nessa burrice, porque não tem nenhum algoritmo atuando especificamente nisso, tem uma grande propaganda no auto-fall-back dos fabricantes pra reconectar ao perder conexão (Geralmente sem negociar novas chaves, o que tornaria a queda mais demorada) justo porque eles não tem muito o que fazer pra EVITAR queda, é fácil testar, fixa em MCS0 e vai o mais longe possível até a conexão cair (Bota um ping pra ver), pode ser em casa. Aí bota em automático, fica do lado do roteador, ele vai subir rapidinho pra MCS15, e quando for caminhando pra longe a conexão cairá muito antes de chegar onde foi antes, vai reconectar (Porque o algoritmo de auto-fall-back sim é bem estruturado) mas até chegar no final terá duzias ou centenas de pacotes perdidos, por conta desse tempo de reconexão (Isso que os algoritmos de auto-fall-back são bons! Em 2003 era um terror, 2 minutos pra reconectar quando algo caia, mesmo indo pro lado do roteador, que com seus 40-50MHz, e 4MB de Ram, não conseguiam processar tanta coisa rápido).

    Fabricante que quer garantir mais banda, digamos a Mimosa ou a Cambium nos seus protocolos proprietários, não usam o padrão IEEE não só pelo TDMA, a diminuição de data rate é muito rápida, em vários rádios bons que usam a faixa aberta de 5GHz, mas não usam o IEEE, é botar a mão na frente de uma antena de disco que o sinal cai e o data rate cai junto rapidinho, quando muda pra IEEE 802.11 você bota a mão, o CCQ cai, o ping aumenta, mas o data rate não diminui.
    .


    Vou verificar para entender melhor o Standar 802.11n /ac o que disse ao respeito de mudança de MCS automática. Em principio-lhe adianto que quem me informou respeito dos algoritmos foi a Ubiquiti em consulta realizei faz algum tempo. A mesma coisa Mikrotik. Nao faz sentido a IEEE determinar sobre a mudança de MCS com perda de pacotes MINIMO de 3 pacotes. Faz sim definir o MAXIMO de 3 pacotes para realizar a mudança de MCS, porem como não estudei esse detalhe estarei me informando.

  4. #10

    Padrão Re: Método mais correto de trabalhar com MCS?

    No site da IEEE .org tem que pagar, vou procurar os PDF's salvos em algum lugar. No sanet.st tinha mas procurei agora e só tem livros de outros autores, não os drafts originais.

    Mas pra facilitar o suporte eu também diria pra deixar tudo em automático.

    Mas equipamento pra uso avançado tem as opções de configuração manual porque são pra usuário avançado. Roteador doméstico de R$ 70 não tem quase nada de opções porque é pra usuário que mal consegue configurar um SSID e senha, um firmware esmiuçado demais iria só exigir um suporte muito mais caro (Ao invés de telefonistas, precisaria botar técnicos no call-center).



  5. #11

    Padrão Re: Método mais correto de trabalhar com MCS?

    Citação Postado originalmente por 1929 Ver Post
    Eu concordo com o Rubem... Mostrei isso semana passada para uma pessoa responsável pelo suporte de um provedor... Ele estava receoso de baixar o data rates... Fixamos o MCS em 7 e foi só alegria. O cliente vivia reclamando que não conseguia ter conexão estável.. De noite então era um sufoco.. Como eu mesmo vi na casa da pessoa o sofrimento. Dei uma conversada com o funcionário do suporte e daí em diante estabilizou... Tem que ir testando para ver como fica o CCQ. Estava em 80 e fomos baixando um a um o MCS até bater em 99 o CCQ.
    isso no cliente ou no painel?

  6. #12

    Padrão Re: Método mais correto de trabalhar com MCS?

    Citação Postado originalmente por AndrioPJ Ver Post
    isso no cliente ou no painel?
    Olá Companheiro, quanto tempo.....

    Sim, no cliente