+ Responder ao Tópico

  1. Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.

    Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.


    O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.

    Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.

    Mesmo que você venda planos tipo 2M de download e 1M de upload, o trafego vindo dos clientes (O upload somado de todos) será muuuuuito baixo, se digamos 20 clientes de 2Mbps de download consomem uns 12Mbps de trafego agregado, o upload mal vai chegar em 2Mbps, usar um data rate com throughput 3 ou 4x maior que essa média é mais que suficiente, o download até sobe muito as vezes (5 ou 6 pessoas abrem um vídeo maior, mais ou menos ao mesmo tempo), mas o upload raramente tem picos muitos altos.


    Volto a repetir: O checksum do pacote na parte de wifi é respondido no data rate da parte que enviou, e a parte de sincronia e cia (Envio do SSID, por exemplo) é feito no preambulo, que é o menor data rate do modo, o preambulo em A é de 1 ou 2Mbps, em N a 6Mbps. Ainda que você selecione o uso de MCS15 nos 2 lados, tem um moooooooooonte de dados passando em data rate de 2 ou 6Mbps o tempo todo, numa modulação BPSK bem "lenta", e isso é feito porque esses dados tem prioridade, pode perder um pacote do cliente que se for preciso ele reenvia, mas se perder pacote de sincronização a conexão cai e demora muitos segundos pra reconectar (Renegociar chave e cia). Ter data rate baixo no meio não degrada rede quando ele tem tráfego baixo, geralmente é o contrário, data rate baixo não perde pacotes (MCS15 com sinal -70dBm perde muito pacote) então o gasto total de tempo nesse envio é menor, mesmo usando um data rate mais baixo (Porque não precisa ficar reenviando pacotes perdidos).


  2.    Publicidade


  3. Citação Postado originalmente por rubem Ver Post
    Se tem upload de 1Mbps, e usar MCS0, em 20MHz ele tem throughput na casa dos 3Mbps, é meio pouco mesmo. Mas em MCS1 já são uns 6Mbps, já tem dado de sobra.

    Quem usa dupla polarização (Pra que usar single em pleno 2016?), os equiptos operam com mesmos sinais em MCS8 ou 9, ou seja, pode usar MCS9 no cliente, que tem throughput na casa dos 10 a 14Mbps, ter um upload de 1M num data rate desse é absolutamente tranquilo.


    O checksum de cada pacote de wifi enviado pelo AP é respondido pelo cliente no mesmo datarate do envio. Mas a resposta do pacote TCP dado pelo computador do destinatário é feita no que se contabiliza como upload mesmo. Ou seja, um data rate baixo não diminui a capacidade de envio de pacotes por parte do AP.

    Assim como tem que ver o throuhput agregado no data rate de TX da torre, tem que ver o throughput agregado de upload dos clientes. Se os clientes tem, na média, uns 2 ou 3Mbps de tráfego de upload, é melhor não usar MCS0 como TX neles, mas sim MCS1, porque o tráfego está muito perto do limite de throughput do MCS0.

    Mesmo que você venda planos tipo 2M de download e 1M de upload, o trafego vindo dos clientes (O upload somado de todos) será muuuuuito baixo, se digamos 20 clientes de 2Mbps de download consomem uns 12Mbps de trafego agregado, o upload mal vai chegar em 2Mbps, usar um data rate com throughput 3 ou 4x maior que essa média é mais que suficiente, o download até sobe muito as vezes (5 ou 6 pessoas abrem um vídeo maior, mais ou menos ao mesmo tempo), mas o upload raramente tem picos muitos altos.


    Volto a repetir: O checksum do pacote na parte de wifi é respondido no data rate da parte que enviou, e a parte de sincronia e cia (Envio do SSID, por exemplo) é feito no preambulo, que é o menor data rate do modo, o preambulo em A é de 1 ou 2Mbps, em N a 6Mbps. Ainda que você selecione o uso de MCS15 nos 2 lados, tem um moooooooooonte de dados passando em data rate de 2 ou 6Mbps o tempo todo, numa modulação BPSK bem "lenta", e isso é feito porque esses dados tem prioridade, pode perder um pacote do cliente que se for preciso ele reenvia, mas se perder pacote de sincronização a conexão cai e demora muitos segundos pra reconectar (Renegociar chave e cia). Ter data rate baixo no meio não degrada rede quando ele tem tráfego baixo, geralmente é o contrário, data rate baixo não perde pacotes (MCS15 com sinal -70dBm perde muito pacote) então o gasto total de tempo nesse envio é menor, mesmo usando um data rate mais baixo (Porque não precisa ficar reenviando pacotes perdidos).

    Bom gostaria de analisar o meu cenario , esta abaixo a tabela de clientes neste setor , estou usando protocolo ativo da intelbras , e nos clientes estou usando MCS 11 nos clientes , então seria equivoco meu fazer isso certo , se fixar nos clientes MCS 0 , 1 ou ate 3 estaria suficiente seria isso ?

    Clique na imagem para uma versão maior

Nome:	         radios.JPG
Visualizações:	77
Tamanho: 	19,7 KB
ID:      	63896

  4. Se tem equipto MIMO, não use MCS0 a 7, isso são data rates de polarização simples.

    Esses sinais -65dBm pra mim dá pra MCS13, tem que conferir o datasheet pra ter certeza, mas no mínimo MCS12 eles suportam. -71dBm talvez só MCS11 (Tem que ver o datasheet, a sensibilidade). Mas com esses sinais não vejo nenhuma necessidade de usar digamos MCS8 ou 9, tem sinal suficiente pra MCS11.

    (MCS8 é um MCS0 duplo, não use data rates de polarização simples (Só 1 chain) se o equipamento suporta 2. Veja os data rates nominais em www.mcsindex.com )

  5. Ola rubem tenho acompanhado o tópico a algum tempo. Quero parabenizar e agradecer você pelo, esforço e a disposição que você tem para responder as duvidas da galera e trazer para o grupo um material bacana e consistente, pucos se dispõe a fazer isso. Aprendi bastante sobe mcs e consegui aplicar boa parte desse conhecimento na pratica. Porem eu cheguei a um empasse e gostaria, que se você pudesse esclarecer alguma duvidas que eu tenho.
    A rede do provedor que eu trabalho consiste em MK e Ubiquit. Mas todos trabalham de modo separado (nao conecto mk em Ubi e vice-verça). A maioria de rede e Mk.
    Trabalhamos com Rb 912 e 922 nas torres, e todos os clientes usam sxt.
    Consegui melhorar bastante a rede porem ainda to enfrentado alguns problemas.
    Em alguns painéis com bastante clientes nivel de ccq ficou muito bom, mas ja em outros com um numero reduzido de clientes eu nao consegui ategir a mesma qualidade. Nas imagens pode observar o painel mais lotado da rede. Ele ficou muito bom( não sei se e possível melhorar) mas ja em outros que tem menos clientes eu não consigo um bom resultado. Tenho algumas reclamações sobre perdas de pacotes, eu faço ping do painel para o cliente e fica alto ou para de responder, as vezes isso acontece com apenas 1 cliente do painel enquanto os outros fica tudo ok.Clique na imagem para uma versão maior

Nome:	         image1.png
Visualizações:	25
Tamanho: 	219,0 KB
ID:      	65151Clique na imagem para uma versão maior

Nome:	         image3.png
Visualizações:	23
Tamanho: 	150,5 KB
ID:      	65152Clique na imagem para uma versão maior

Nome:	         image4.png
Visualizações:	21
Tamanho: 	146,8 KB
ID:      	65153Clique na imagem para uma versão maior

Nome:	         image5.png
Visualizações:	23
Tamanho: 	153,2 KB
ID:      	65154Clique na imagem para uma versão maior

Nome:	         imagem2.png
Visualizações:	22
Tamanho: 	217,6 KB
ID:      	65155
    Se tiver como você me dar algumas dicas de como melhorar agradeço. E agradeço mais uma vez pelo esforço de vir aqui e compartilha o conhecimento com a galera.

  6. Também não acho que tenha como melhorar isso, 70 clientes numa RB912 é coisa pra caramba, é um hardware meio comum (Só com um sistema operacional ótimo pra ficar ok), se tivesse instalações porcas duvido que teria esses CCQ com mais de 15 clientes.

    Acho que o pouco que dá pra melhorar são esses clientes com RX meio ruim:
    Clique na imagem para uma versão maior

Nome:	         1.jpg
Visualizações:	24
Tamanho: 	293,6 KB
ID:      	65156

    Na prática eles só vão atrapalhar hora que eles requisitarem muitos pacotes. Estar apenas conectado, sem gerar tráfego, não consome processamento da RB, precisa consumo de tráfego pra "incomodar", por isso não necessariamente o cliente de sinal ruim é o que tem ping ou CCQ ruim, teria que ver o tráfego (Marca pra exibir as colunas Ack Timeout e TX/RX bytes (Somatória), veja se hora que tem ping ruim não tem tráfego nalgum cliente com TX/RX bytes aumentando rápido (Indicando consumo)).

    Ou marca a aba P Throughput, o pass throughput tá meio relacionado ao CCQ mas quando o sinal é ruim (Por culpa da zona de Fresnel parcial) ele é alto quando o rádio está sem tráfego, mas hora que há consumo de dado o pass throughput cai, e falo cair pra menos de 1Mbps as vezes, sem que o CCQ caia tanto. O cliente que tiver um pass thrgouhput tão baixo quando tem tráfefo (Quando não tem tráfego não conta) tem problema físico no sinal, precisaria ir nesse cliente ver se tem como subir antena ou reposicionar.


  7.    Publicidade




Visite: BR-Linux ·  VivaOLinux ·  Dicas-L