Página 6 de 9 PrimeiroPrimeiro ... 23456789 ÚltimoÚltimo
+ Responder ao Tópico



  1. Citação Postado originalmente por rubem Ver Post
    Se tem certeza que não tem loop na rede (Uma bridge conectada via cabo e via wifi, digamos), também voto em pau no chipset ou no firmware.

    Se enviar novo firmware não ajudou (1 em cada 100 vezes ajuda), pau no chipset.
    Ruben existe uma bridge direta, tem um sxt enviando ponto a ponto para outro, o sxt que esta no ponto principal está na classe 88.6, a omni e 88.1, o sxt que recebe setei la no quick set dele bridge e tinha conectado e funcionado na hora pegando a classe 5.1 que e a minha rede interna, ao verificar o ip dele aparece que esta na mesma da omni 88.1 mas aparece desabilitado ja que em bridge o sxt que recebe assimilou o ip da rede interna, será que esta influenciando?

  2. Citação Postado originalmente por 1929 Ver Post
    Sim, explicação perfeita.... mas eu fico com uma dúvida.

    Se o sinal é alto com uma leitura de noise destas, o SNR vai ser alto o que é muito desejável para uma boa conexão.

    Tem um vídeo da Computech onde eles comentam sobre ambientes de exposição por exemplo, com dezenas e dezenas de redes instaladas por cada expositor. E todos convivem dentro deste ambiente que aparentemente é altamente poluído.
    Segundo eles, o que importa não é o número de SSIDs no local, mas sim o SNR que os usuários do AP chegam ao AP. Que o firmware está preparado para escutar todos os SSID e separar o que está configurado nele.

    Neste caso postado por exemplo o canal citado está com uma porcentagem alta de ocupação, mas o Noise Floor é praticamente o mesmo.
    Isto me deixou confuso com relação a informação que a leitura nos dá. Que vantagem tem de estar lá listado o Noise, se na prática só damos importância a porcentagem de ocupação?
    Não estou me opondo, pois também escolho pela porcentagem de ocupação.
    Mas tenho uma desconfiança de que um canal deveria ser descartado o uso no caso de uma alta taxa de ocupação aliado a um Noise Floor baixo.
    Pelo que sempre testo, aí entra a sensibilidade.
    Se seto pra MCS15, com sensibilidade em -75dBm, e o sinal que quero está em -55dBm, terei CCQ de 100%, e podem ter meia duzia de SSID's lá pelos -80 a -76dBm que não vai atrapalhar.

    Uma coisa é o pacote pequeno e em datarate baixo que leva o SSID, esse pacote é emitido na potência máxima setada, e é lido até quando está na sensibilidade mínima usável (Uns -95 a -100dBm, dependendo do aparelho).

    Já o pacote de dados do cliente, esse vai no esquema de modulação que você setou, é um pacote maior e num datarate maior. Digamos que está usando MCS15, o SSID é emitido em BPSK (Legível até em -95dBm), mas o MCS15 está em 64QAM, legível só bem acima de -75dBm.

    O Airview nos UBNT mais recentes mostra no gráfico a ocupação por "hits", apenas enviar SSID dá poucos hits, é um canal usado mas pouquíssimo usado, gera um gráfico bem esparso comparado a um canal onde está tendo mesmo troca de dados do usuário.

    Também é bom cuidar que cliente de AP, mesmo sem tráfego, gera uns pontos altos e esparsos no Airview, são os dados de sincronia trocados a cada X segundos pra ver se o cliente e AP ainda estão presentes (Um pergunta pro outro "Ainda tá aí?"), você pode estar de costas pro AP, escanear o canal como relativamente vazio, mas em meia hora esse cliente começa a navegar, mandar dados de usuário, aí o canal fica bem ocupado, seja lá qual data rate ele usar vai ocupar todo o canal massivamente, depende mais do numero de pacotes usado.


    Assim como tem um SNR mínimo a se respeitar, pra garantir a legibilidade do pacote de dados, se aplicar essa margem nos sinais alheios acho que tem como ter CCQ ótimo.

    Nunca tirei tempo de tentar coisa tipo conseguir -40dBm num canal onde tem sinal alheio chegando em -60dBm, provavelmente não vai prestar porque -60dBm ainda é muito legível, mas onde tem sinal alheio a -76dBm, se o SEU sinal está em -55dbm o CCQ vai ficar no máximo.

    Eu não confiava tanto no Channel usage do Mikrotik porque ele parece que tinha me enganado umas vezes, mas quando tive um Airview de UBNT em mãos pude notar, o que as vezes está com uso baixo é na verdade um cliente que está sem tráfego, e o pouco uso do canal é apenas a troca de pacotes de sincronia (E sabe que tem cliente que fica com CPE ligada 24h mas que trafega dados realmente só 3h por dia, nessas 3h ele te atrapalhará, se usar esse canal.

    Aqui um exemplo, 2 extremos, o scan de SSID vai mostrar os 2 canais com SSID na casa dos -60dBm, mas... em 5400MHz aparentemente é um cliente, tem dados esparsos, no waterfall view tem rajadas amarelas, mas isso é nível de sinal, se for uma rajada a -60dBm por MINUTO atrapalha pouco, pra isso ele mostra em baixo o numero de hits, que é bem baixo, aparentemente são MENOS de 20 hits em 5 minutos! Isso não é nem o ping do Windows verificando se tem internet, isso é realmente só a CPE trocando dados com o AP pra verificar status:
    Clique na imagem para uma versão maior

Nome:	         airview.jpg
Visualizações:	44
Tamanho: 	193,2 KB
ID:      	63261

    Isso quer dizer que posso usar 5400MHz no meu PTP?
    Agora pode.
    Mas e daqui 2 horas, quando o cliente chegar em casa e começar a navega? Aí vai ficar como o outro extremo em 5800MHz, canal cheio de uso, mas sem aumentar o nível do SSDI.

    Agora provavelmente terá CCQ de 100%, mas quando esse cliente navegar, e competir pela ocupação do canal, o CCQ cai pra 80 ou 90% e o provedor fica louco.

    Não que o channel usage do MK não funcione, é que ele é igual o Airview, ele mostra o uso AGORA. E o scan de SSID não mostra as respostas de clientes, se você estiver de costas pro AP, com um cliente de frente pra você, hora que esse cliente começar a trafegar ele vai atrapalhar muito, se essa CPE estiver ligada pelo menos o Airview te permite descobrir isso, mas em MK não tem nada.
    (E também nem toda CPE fica ligada 24x7, tem gente que desliga tudo umas 16h por dia, ainda pode ter CCQ ruim nalguns horários)

    Se aplicar a regra do SNR aos sinais alheios, de quase 35dBm de distância se usar datarate alto, talvez dê pra viver com sinal alheio de -70dBm, duvido um pouco, o que já testei é com sinal abaixo da sensibilidade do data rate e foi ok, atrapalho zero.

    Clique na imagem para uma versão maior

Nome:	         snr.20MHz.PNG
Visualizações:	914
Tamanho: 	115,1 KB
ID:      	63262Clique na imagem para uma versão maior

Nome:	         SNR-table.jpg
Visualizações:	58
Tamanho: 	40,2 KB
ID:      	63263



  3. Citação Postado originalmente por renanssj5 Ver Post
    Ruben existe uma bridge direta, tem um sxt enviando ponto a ponto para outro, o sxt que esta no ponto principal está na classe 88.6, a omni e 88.1, o sxt que recebe setei la no quick set dele bridge e tinha conectado e funcionado na hora pegando a classe 5.1 que e a minha rede interna, ao verificar o ip dele aparece que esta na mesma da omni 88.1 mas aparece desabilitado ja que em bridge o sxt que recebe assimilou o ip da rede interna, será que esta influenciando?
    Se está em bridge, tanto faz o IP, ela passa tudo quanto é dado porque se baseia no mac adress, pode ser ip local ou real que uma bridge passa.

    E a questão de pegar só 10M numa porta também não afeta isso, antes de acionar o DHCP a porta faz algumas trocas de dados pra estabelecer comunicação, se em 100M ela não consegue, parte pra 10M, e só depois de uma duzia de pacotes trocados sem erro é que o DHCP client faz a requisição pro DHCP server.

    E dá um ping rumo ao IP local da Omnitik, porque além da porta estar em 10M, pode ter perda de pacote. Mas ping com pacote grande.
    O normal seria
    ping -t 192.168.88.1
    Pra usar um ping com pacote grande, igual o tamanho dos pacotes de dados (Limitados pelo MTU), acrescente a variável -l de large, e o tamanho do pacote em bytes
    O ping normal é com 32 bytes, ele equivale a
    ping -t 192.168.88.1 -l 32
    Mas pra ver se não tem perda de pacotes REAIS, perto do limite do MTU, testa
    ping -t 192.168.88.1 -l 1400
    ping -t 192.168.88.1 -l 1450
    ping -t 192.168.88.1 -l 1470

    O máximo que poderia acontecer via cabo é o ping normal ficar em 1 ou 2ms, e o ping com pacote grande subir pra 2 a 4ms.
    Se, via cabo, o ping com pacote de 1400 bytesm der algo tipo 10ms, e perder 1 a cada 10 pings (É o que geralmente vejo com rádio que fica em 10M depois de tempestade), isso é uma perda de 10% dos pacotes, a navegação fica sofrida.

    E mesmo que já tenha trocado a porta, pra uma que aceita 100M, dá o ping igual, porque se o chipset foi afetado ele vai perder pings ou dar tempos enormes também nas outras portas. Em CI de switch isso é comum, queima só 1 porta mas as outras são um pouco afetadas, perdem alguns pacotes grandes.

    (E navegação usa pacotes grandes, não pequenos, mesmo o status do WhatsApp usa pacotes de uns 500B pra cima, até isso (Que gera tráfego tipo 1 ou 2kbps) é afetado)

  4. Citação Postado originalmente por rubem Ver Post
    Se está em bridge, tanto faz o IP, ela passa tudo quanto é dado porque se baseia no mac adress, pode ser ip local ou real que uma bridge passa.

    E a questão de pegar só 10M numa porta também não afeta isso, antes de acionar o DHCP a porta faz algumas trocas de dados pra estabelecer comunicação, se em 100M ela não consegue, parte pra 10M, e só depois de uma duzia de pacotes trocados sem erro é que o DHCP client faz a requisição pro DHCP server.

    E dá um ping rumo ao IP local da Omnitik, porque além da porta estar em 10M, pode ter perda de pacote. Mas ping com pacote grande.
    O normal seria
    ping -t 192.168.88.1
    Pra usar um ping com pacote grande, igual o tamanho dos pacotes de dados (Limitados pelo MTU), acrescente a variável -l de large, e o tamanho do pacote em bytes
    O ping normal é com 32 bytes, ele equivale a
    ping -t 192.168.88.1 -l 32
    Mas pra ver se não tem perda de pacotes REAIS, perto do limite do MTU, testa
    ping -t 192.168.88.1 -l 1400
    ping -t 192.168.88.1 -l 1450
    ping -t 192.168.88.1 -l 1470

    O máximo que poderia acontecer via cabo é o ping normal ficar em 1 ou 2ms, e o ping com pacote grande subir pra 2 a 4ms.
    Se, via cabo, o ping com pacote de 1400 bytesm der algo tipo 10ms, e perder 1 a cada 10 pings (É o que geralmente vejo com rádio que fica em 10M depois de tempestade), isso é uma perda de 10% dos pacotes, a navegação fica sofrida.

    E mesmo que já tenha trocado a porta, pra uma que aceita 100M, dá o ping igual, porque se o chipset foi afetado ele vai perder pings ou dar tempos enormes também nas outras portas. Em CI de switch isso é comum, queima só 1 porta mas as outras são um pouco afetadas, perdem alguns pacotes grandes.

    (E navegação usa pacotes grandes, não pequenos, mesmo o status do WhatsApp usa pacotes de uns 500B pra cima, até isso (Que gera tráfego tipo 1 ou 2kbps) é afetado)
    Obrigado pela grande aula vc e um mestre, segunda testarei o seu tutorial mas a porta esta a 100mbs, isso tenho certeza, pode e claro estar afetada por causa da ether 1 que esta em loop mas está desabilitada, mas como vc falou uma pode influenciar a outra.






    Dei uma corrida ali e fiz o teste, não perdeu pacotes via Ethernet nem com 1470, estou usando aqui na minha casa um ponto a ponto e nele está tudo ok, o balanceador de carga tp link tb estragou uma das saídas a porta 5, pensei que ele poderia estar ruim tb mas no local ele opera mandando os 30mb da adsl e aqui em casa no ponto a ponto tb esta passando toda a banda, fiz um bandwitch test para um ilimitado e vejam so, ela ta travada em 10mb mesmo via wireless, ta mostrando 13.5 em interfaces mas e meio fake, o real ta dentro do quadro de teste, esse chip so pode ter sido condenado.Clique na imagem para uma versão maior

Nome:	         bandwitch teste.jpg
Visualizações:	66
Tamanho: 	215,0 KB
ID:      	63266



  5. Hum, mas você fez o teste rumo a um IP que está conectado via wifi também nesse datarate de 26M?

    Se for, é normal o throughput ficar nesses 12,5Mbps, até 14Mbps também. Mas o teste de banda vai ficar abaixo depois do trabalho de trocar pacotes e tal, 8,4 Mbps acho pouco mas toda vez que vi limite na porta o limite era realmente uns 10Mbps (Se você limitar manualmente a 10M num equipamento bom, de PC a PC é fácil ver troca de dados a 1,2MB/s, que dá quase 10Mbps mesmo).

    Se o teste foi feito com tráfego pela porta ethernet (Com um cabo de rede entre os equipamentos 192.168.5.101 e o equipamento 10.1.1.99), então realmente a ethernet ainda tem problema mesmo.

    (Mas pelo que entendi o teste passa por wifi com data rate de 26M, que vai trafegar 13 ou 14Mbps só em condições boas. O datarate de 19M (MCS2) trafega 10M só em PTP, mas em PTMP até um MCS4 (39M) é capaz de sofrer pra passar de 10Mbps estável, porque os outros clientes podem estar com trafego (Mesmo só conectados, existe troca de pacotes de sincronia, a etapa de RF trabalha mesmo que a interface não apresente tráfego pro IP do cliente, lá aparece o tráfego de pacotes do usuário, não o trafego de dados de sincronia e status))






Tópicos Similares

  1. Respostas: 0
    Último Post: 09-02-2015, 14:57
  2. Respostas: 5
    Último Post: 18-12-2012, 09:29
  3. Não tenho mais de 1 processo de som por vez, pq?
    Por MasterMan no fórum Sistemas Operacionais
    Respostas: 1
    Último Post: 24-02-2005, 23:35
  4. Não envia maior de 2MB.
    Por no fórum Servidores de Rede
    Respostas: 2
    Último Post: 16-06-2004, 08:46
  5. Respostas: 6
    Último Post: 05-04-2004, 08:20

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L