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



  1. Citação Postado originalmente por rubem Ver Post
    Esse cliente "bom" está usando na verdade MCS13 no Tx, é o data rate de 216M a 40MHz. Passar ele pra MCS14 realmente vai piorar o CCQ já que pra SUBIR o data rate precisa sinal MAIOR.

    O cliente "ruim" está usando MCS12 de TX, se o CCQ tá bom então deixa pra lá, só seria um problema se perder ping (-l 1470 , nem vale a pena dar ping comum de 32 bytes). Mas se for pra mudar algo, tem que usar um data rate menor que o atual, se no modo automatic o cliente está em MCS12 e tráfego nalgum sentido é ruim, tem que BAIXAR o data rate pra ter menos perda de pacotes, e testar as opções ABAIXO de MCS12.

    Veja os data rates nominais:
    http://mcsindex.com/

    162M e 180M são MCS12 em 40MHz de largura (Precisa mesmo usar 40MHz?), o tempo de guarda pode ser diferente nos 2 lados.

    E 216M, o data rate de TX do cliente "bom", é MCS13.

    A sensibilidade de cada data rates está no datasheet:
    https://dl.ubnt.com/loco_m5_datasheet.pdf
    No exemplo de MCS13, a sensibilidade é de -79dBm. Mas se usar -78dBm a rede será um lixo, precisa ter uma MARGEM entre sensibilidade e o sinal presente (E o que vale é o sinal do chain0 e chain1, não a barrinha colorida), eu só considero boa a rede que tem essa margem em 20dBm. Ou seja, se a sensibilidade é de -79dBm, o maior CCQ e throughput com o sinal lá pelos -59dBm.

    (E o cliente "bom", que está usando MCS13 (216M) tem sinal melhor que -59dBm, ele tem -58dBm)

    O cliente ruim em MCS12 tem sinal -75dBm (No chain1, nivela pelo PIOR), e a sensibilidade em MCS12 é de -84dbm, ou seja, ele tem apenas 9dBm de margem! Põe ele num data rate que dê 20dBm de margem até a sensibilidade que terá ZERO perda de pacotes (Que seria MCS8, mas é melhor não baixar tanto, é melhor aumentar a antena desse cliente, sinal -75dBm não devia ser usado, trabalha com sinais APENAS acima de -70dBm, pra usar pelo menos MCS10).

    Essa margem que falo é tipo o SNR, mas o SNR é a margem até o RUÍDO, um SNR tipo 10dBm gera uma rede lixo, e pra mim uma margem de 10dBm até a SENSIBILIDADE (Do data rate usado) também.
    Se aplicar a mesma fórmula de SNR pra margem até a sensibilidade, a conta não bate porque com 20dBm de margem até o throughput fica ok, mas 20dB de SNR nem sempre.

    Fica em 15 a 20dBm de sensibilidade que tá ok, no mínimo uns 13dBm se for rede que pode ter qualidade baixa, mas menos de 12dBm nunca.

    https://community.ubnt.com/t5/Wirele...dB/td-p/464171


    E esse seu problema é mais uma prova que o software é burro na seleção automatica de data rate, usa MCS12 com -75dBm, com margem péssima de 9dBm, ao invés de baixar o data rate pra ter perda menor de pacotes. Se o software funcionasse corretamente com a mudança automática só haveria perda de pacotes com sinais inferiores a -80dBm, pois esse é o sinal mínimo pra ter um pingo de qualidade com MCS8.

    E canal de 40MHz geramente precisa sinal um pouco mais alto (2 ou 3dBm) que a 20MHz, se não vende planos de 10M pra cima não vejo pra que ficar gastando processamento do chipset com mais portadoras usando 40MHz.
    O CCQ caiu pra 70% qdo mudei o cliente pra mcs 13 Clique na imagem para uma versão maior

Nome:	         cliente bom mcs 13.JPG
Visualizações:	33
Tamanho: 	64,4 KB
ID:      	63505

  2. Veja que o throughput usado SUBIU, em auto ele fica em 213M, fixo em MCS13 ele vai pra 240M. Data rate mais alto precisa sinal mais alto.

    213M e 240M são tudo MCS13, mas muda o tempo de guarda (Short Guard Interval, ou Long Guard Interval).

    Testa então MCS12, pro CCQ subir.

    (E o "pouco download" que fala do cliente, é perda de pacote, se ele fica a 1km da torre, um ping devia levar 1 ou 2ms, se o ping -l 1450 leva 20 a 50ms isso é um pacote que foi enviado, 2ms depois não houve resposta, aí ele foi enviado de novo, a resposta foi enviada 1 ou 2ms depois mas a resposta é que foi perdida, e assim o tempo total pro ping e sua resposta sair e chegar foi de 20ms, toda demora em distância curta é pacote perdido, porque se pacote é perdido ele é reenviado. É bem diferente de um ping rumo ao Japão, aí é questão de distância e vários roteamentos no caminho)

    De qualquer forma -75dBm é sinal baixo demais pra conseguir alguma coisa que presta, nesse cliente ruim o jeito seria colocar o AP da torre fixo em MCS12 a 20MHz (E esse cliente fixo em MCS10 talvez) , limitar o data rate de TODOS por causa de 1 cliente. Acho melhor ir melhorar o sinal dele, fazer ele subir pra -70dBm ou mais (Nos 2 chains pelo menos isso de sinal), aí sim daria pra deixar o AP da torre com data rate auto.

    (Veja que limitando o TX Rate no cliente você só altera o... TX do cliente, que é o upload (TX do cliente é o RX no AP da torre, sai do cliente e entra no AP, é o upload do cliente). Se quer melhor APENAS o download, teria que baixa o TX da TORRE, dado que sai da torre e vai pro cliente é TX na torre e RX do cliente, é o download. Com -75dBm não tem muito o que fazer nesse cliente, baixa TX Rate na torre só por causa dele pode ser feito, mas baixaria o download de todos, com MCS12 na torre mal dá pra trafegar 60 ou 70Mbps agregado)



  3. Citação Postado originalmente por rubem Ver Post
    Veja que o throughput usado SUBIU, em auto ele fica em 213M, fixo em MCS13 ele vai pra 240M. Data rate mais alto precisa sinal mais alto.

    213M e 240M são tudo MCS13, mas muda o tempo de guarda (Short Guard Interval, ou Long Guard Interval).

    Testa então MCS12, pro CCQ subir.

    (E o "pouco download" que fala do cliente, é perda de pacote, se ele fica a 1km da torre, um ping devia levar 1 ou 2ms, se o ping -l 1450 leva 20 a 50ms isso é um pacote que foi enviado, 2ms depois não houve resposta, aí ele foi enviado de novo, a resposta foi enviada 1 ou 2ms depois mas a resposta é que foi perdida, e assim o tempo total pro ping e sua resposta sair e chegar foi de 20ms, toda demora em distância curta é pacote perdido, porque se pacote é perdido ele é reenviado. É bem diferente de um ping rumo ao Japão, aí é questão de distância e vários roteamentos no caminho)

    De qualquer forma -75dBm é sinal baixo demais pra conseguir alguma coisa que presta, nesse cliente ruim o jeito seria colocar o AP da torre fixo em MCS12 a 20MHz (E esse cliente fixo em MCS10 talvez) , limitar o data rate de TODOS por causa de 1 cliente. Acho melhor ir melhorar o sinal dele, fazer ele subir pra -70dBm ou mais (Nos 2 chains pelo menos isso de sinal), aí sim daria pra deixar o AP da torre com data rate auto.

    (Veja que limitando o TX Rate no cliente você só altera o... TX do cliente, que é o upload (TX do cliente é o RX no AP da torre, sai do cliente e entra no AP, é o upload do cliente). Se quer melhor APENAS o download, teria que baixa o TX da TORRE, dado que sai da torre e vai pro cliente é TX na torre e RX do cliente, é o download. Com -75dBm não tem muito o que fazer nesse cliente, baixa TX Rate na torre só por causa dele pode ser feito, mas baixaria o download de todos, com MCS12 na torre mal dá pra trafegar 60 ou 70Mbps agregado)
    Verdade troquei o mcs para 12 no cliente bom e o CCQ estabilizou bem em 99.1 99. e 100%.

    e um sinal de -67 db eu fixo em quanto ? o MCS ?

  4. Com -67dBm eu usaria MCS11, e só olhar a sensibilidade no datasheet e acrescentar 20dBm.






Tópicos Similares

  1. Duvidas Modem Speedy..?
    Por no fórum Servidores de Rede
    Respostas: 1
    Último Post: 04-09-2002, 18:34
  2. Dúvidas Path.
    Por no fórum Servidores de Rede
    Respostas: 1
    Último Post: 21-08-2002, 08:52
  3. Duvidas Ipchains / Iptables!!!
    Por no fórum Servidores de Rede
    Respostas: 2
    Último Post: 20-08-2002, 14:39
  4. Limitar o logon e outra duvida ..
    Por MarcelScan no fórum Servidores de Rede
    Respostas: 1
    Último Post: 28-07-2002, 14:35
  5. Limitar o logon e outra duvida ..
    Por MarcelScan no fórum Servidores de Rede
    Respostas: 1
    Último Post: 24-07-2002, 20:45

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L