+ Responder ao Tópico



  1. #1

    Padrão Ccq x data rate

    Pessoal fazendo os testes aqui e cheguei a uma conclusão, CCQ 99%/100% é melhor que CCQ 60% e Data Rate Alto.

    Fixando a Modulação a menor possível fica uma rede perfeita!

  2. #2

    Padrão Re: Ccq x data rate

    Quando vc baixa a modulação automaticamente sobe o CCQ, mas se ccq esta baixo e vc tem que forçar a modulação baixa algo esta mal, eu sei que no mundo real não *e fácil fazer todos Station ter sinal perfeito, mas deve tentar um ccq no automático e com carga na rede de no minimo 90%, ai sim vc baixa modulação e melhora o ccq.



  3. #3

    Padrão Re: Ccq x data rate

    CCQ abaixo de 100% quer dizer pacote perdido, quer dizer que o chipset de RF teve que desperdiçar processamento para enviar o que já enviou antes, gasta processamento a toa, e cria JITTER, um ping vai a 4ms porque não há perda enquanto o seguinte vai a 50ms porque parte dele foi perdida 10 vezes.

    Selecionar data rate alto não adianta nada se não chegar no CCQ máximo (Mais de 95%). Data rate com CCQ de 60% é data rate ERRADO, está faltando sinal pra entregar todos os pacotes sem perdas. A função da opção de configurar QUALQUER data rate é essa, adequar o data rate ao sinal (Não importa o que você quer, tem que usar o sinal que tem).

    Data rate baixo não gera perda de pacotes, afeta ping mas afeta de modo UNIFORME, todo pacote tem delay, não há jitter (Há variação de ping ao longo de minutos mas aí não conta, quando dá tempo do computador e o servidor organizarem a nova dinâmica de pacotes a sensação de navegação ruim pro cliente não existe). Jitter atrapalha MUITO coisa tipo IPTV, chamada de voz, até rádio via web, porque o cache uma hora enche porque o ping cai pra 40ms, e outra hora esvazia porque o ping sobe pra 200ms, uma mísera chamada de voz que em tese consumiria 40kbps fica cheia de falhas por conta disso, o jitter ferra com a montagem dos pacotes, fica falhando/engasgando só por uns pacotes, e cliente obviamente vai questionar porque paga por digamos 10Mbps mas não consegue fazer uma mísera chamada de voz sem engasgos.

    (Eu tenho isso com a OI, cheia de jitter por problemas na rede interna, em gerenciador de downloads baixo vídeos do Youtube em segundos, mas uma mísera chamada de voz ou streaming de AUDIO não rola, comum ver ping de 80ms (Não na média) e jitter de 120ms, ou seja, ping varia de 80 a 200ms. Pra download computador e servidor se organizam pra enviar noutra "cadência", mas com streaming não tem isso, se falhou um pacote o áudio picota/engasga mesmo, dá sensação de ter uma conexão lixo)

    Se o CCQ não está passando de 95% (Ou pelo menos 90%) baixa esse data rate e faz teste de tráfego (Testa ethernet a ethernet, dava do inútil teste do sistema operacional da CPE, aí hora que chega pacote real de cliente pela porta ethernet a CPU está ocupada DESPERDIÇANDO processamento pelo reenvio de pacote perdido (Por culpa de data rate alto demais pro nível de sinal), e a parte de ethernet cria mais um delay no caminho, demora pra responder checksum de pacote e cria delay até na porta ethernet, por conta de processamento desperdiçado na porta de RF!).

    No geral terá mais tráfego digamos em MCS14 com CCQ de 96%, do que com MCS15 com CCQ de 85%. Esquece os picos de tráfego, analise a média e veja como fica o ping enquanto faz o teste (Ethernet a ethernet), esse pacote a parte que é o ping já tem prioridade (Ping tem prioridade) e ainda assim é normal em teste de throughput o sistema operacional dizer que transporta 90Mbps, mas aí um ping de 1400 bytes não só tem demoras tipo 60 a 100ms, como perde alguns! É baixar o data rate, que quando não sobe o throughput, pelo menos para com isso de perder alguns pings ou pacotes (Faz 2 testes separados ethernet a ethernet, 1 teste dá 80Mbps, mas 2 testes dá 25Mbps cada um! É problema de faltar processamento pra muito pacote simultâneo, digo, o chipset dá conta, mas só quando a etapa de RF não está desperdiçando processamento com reenvio de pacotes (CCQ ruim tipo 80%).