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

  1. Entendi...

    ou seja, teoricamente teria que dar sempre 100% de CCQ, o que em PMP nem sempre estabiliza em 100%, já que são vários clientes para serem atendidos e uma variação é de se esperar...

  2. A perda de pacotes sempre vai existir, o CCQ vai variar independente de usar TDMA ou OFDM típico.

    A variação no CCQ e throughput depende muito também das 64 portadoras de 315KHz cada, num PTP distante elas variam muito entre si, uma chega 10dBm mais alto que a outra portadora.
    Aqui uma análise, olha os pontos indo de digamos -35 a -85dBm no canal da direita:
    Clique na imagem para uma versão maior

Nome:	         airview_rocket_silicon_valley_0.jpg
Visualizações:	23
Tamanho: 	617,6 KB
ID:      	64908
    Se ficar só nos pontos na imagem no meio só com mais de 20 hits (Cor azul claro), eles ficam em digamos -65 e -75dBm, acho que o rádio iria exibir esse SSID como -70dBm (Porque é a média).

    A variação entre os pacotes é enorme, 10, 15 ou 20dBm de diferença entre uma portadora e outra as vezes ocorre, esse sinal que veio assim está ilegível e vai precisar ser retransmitido. Se usar um coding rate 1/2 quer dizer que tem só metade do dados trazendo pacotes do cliente, se perder só umas partes ainda tem 100% de espaço extra pra repetir o dado que foi perdido antes, nesse caso uma perde de 20% durante a transmissão ainda não derruba o throughput.

    (No caso de um MCS7 ou MCS15, é 5/6, ou seja, 86% dos dados nas portadoras é pacote do cliente, só tem uns 15% de margem, e... perder 10% é normal em conexão perfeita, pra passar de 15% de perdas (E começar a diminuir o throughput) é bem fácil. No MCS6 ou MCS14 o coding rate é 3/4, só 75% com dados útil, passa pra 25% de espaço "livre" que pode ser usado pra reenviar dado perdido antes, essa diferença entre 15 e 25% de espaço sobrando pra retransmissão faz diferença só quando o percentual de perdas está perto disso, uma perda de 20% afeta MCS7 mas não afeta MCS6 (Digo, com ou sem ela o thrpughput do data rate será o mesmo))

    OFDM é isso aqui só no papel:
    Clique na imagem para uma versão maior

Nome:	         ofdm7GHz.jpg
Visualizações:	17
Tamanho: 	48,3 KB
ID:      	64909
    Tem que dar um zoom naquela variação lá em cima, não é sinal perene e equalizado, tem variação de pelo menos 10dBm, aqui a maioria dos hits está ao redor dos -55dBm, mas olhas uns hits lá em baixo a -90dBm, são dados perdidos seja com OFDM padrão ou com TDMA:
    Clique na imagem para uma versão maior

Nome:	         ofdm_iir_rx_wbx.png
Visualizações:	17
Tamanho: 	547,7 KB
ID:      	64910

    TDMA não tem como mudar o comportamento dos sinais, com 64 portadoras não tem como todas chegarem sem variação, cravadas em -55dBm, independente do que usar. Não tem como garantir 100% de CCQ, se algumas rajadas tem sinal muito baixo ela será ilegível igual.



  3. É disso que gosto, resposta com provas...com embasamento...Contra gráficos não há argumentos...
    E me trouxe uma coisa que eu não sabia e creio que a grande maioria também não...

    Que a leitura de 100% na verdade não é 100%, mas como definir... algo como "até aqui não causa prejuízo então o firmware assume que é 100%"... seria mais ou menos isso?

  4. Não sei se dá pra resumir em só uma frase, mas dá pra dizer que "Cabe mais de 100% de throughput".

    No caso do MCS7, o coding rate é 5/6, são cinco sextos em uso, 83,3% em uso, significa que tem 16,7% levando dados vazios, que podem levar reenvios.

    Se com 83% chega em 150Mbps, com 100% daria digamos 170Mbps. Mas... só existiria isso em câmara anecoica, onde não tem reflexo nem obstáculos. No mundo realmente ficaria sempre abaixo disso, ficaria fácil chamar de propaganda enganosa.

    Mas pode ver assim também: Com MCS5 você usa o MESMO esquema de modulação 64QAM, como o throughput cai comparado a MCS7 se usa a mesma modulação?

    Cai porque muda só o percentual de uso com dados úteis. Por isso também a sensibilidade quase não muda, muda 1 ou 2dBm de MCS7 pra MCS6, e desse pra MCS5. Mas hora que baixa pra MCS4 aí a sensibilidade muda 5 ou 6dBm, e muda porque muda o esquema de modulação, passa pra 16QAM.

    Um 16QAM com 5/6 de dados legítimos talvez daria na mesma (Em throughput e desempenho geral) que MCS5, então MCS4 usa só 3/4 com dados novos.

    MCS3 usa só METADE com dados novo, o resto dos bits é reenvio, pra cada bit com dados novo tem um bit redundante, ou seja, se perder METADE ainda manterá o throughput que o data rate promete. Por isso ele consegue conexão ok mesmo com sinal ruim tipo -75dBm (Sinal abaixo até mesmo da sensibilidade de MCS7!).

    Não é porque o modo poderIA ter 110% do que tem hoje que existe um jeito do usuário conseguir isso. O padrão é feito não usando todos o bits com dados novos por NUNCA tem sinal perfeito, SEMPRE tem bit perdido, SEMPRE precisa um reenvio, então um protocolo preparado pro mundo real já se precavê e faz envio redundante de uns bits. No caso de MCS3 tudo é enviado com redundância (Coding rate nomeado como 1/2, ou 50%), se o sinal está ruim não faz sentido usar todos os bits com dados novos, vai perder muuuuuuuito pacote, ter que reenviar um pacote inteiro gasta 4x mais tempo que ter um coding rate com 1/2 ou 2/3 que limita o throughput.

    Enfim, o padrão é feito assim justo pra lidar com o mundo real, onde todos os bits NUNCA saem legíveis, onde sempre tem alguns ilegíveis. Só o que a gente pode fazer é usar um data rate e code rate conforme o nível de sinal presente, e analisar o espectro pra ver a variação no sinal presente (Acho que só com NLoS o sinal varia mais que 10dBm. Em LoS o Airview da Ubiquiti sempre me mostrou variação a maioria na casa dos 10dBm, é o normal).



    (Alias, baterias também suportam mais de 100% de carga. Lithium e chumbo-acido (Gel, água, VRLA) suportam as vezes 120 a 130% da capacidade informada. Mas... suportam isso por umas 10 cargas, depois a célula vai pro lixo. O fabricante informa valor nominal da tensão que permite uma vida útil longa, porque na vida real nunca tem temperatura de ambiente tipo 1°C pra poder usar alta tensão e ter 105% de capacidade. E até motores podem ter central remapeada pra aumentar potência, libera rotação maior, remapeia a relação ar x combustível e consegue mais potência em algumas rotações, o fabricante não faz isso porque ele se foca no uso no mundo real, com rotações mais baixas, com foco em baixo consumo e baixa emissão de poluentes. Deixa ver, processadores também podem ser "overclockados" pra 110 a 150% do clock original, memórias também, mas isso gera calor e exige tensão com menos ripple, coisas difíceis de se corrigir no mundo real. Então digamos que o padrão OFDM está dentro do que é praticado em quase todo mercado, enviar bit invalido ou redundante onde poderia estar enviando bit "novo" é pra adequar às situações no mundo real, com sinal sempre variando, sempre refletindo em objetos, e o uso de duzias de portadoras também é pra driblar esse problema, o sinal varia e reflete de forma diferente em todo o espectro, cada portadora vai ter sua variação mas na média sempre tem um bom percentual legível. Se fosse transmitir uma única portadora de 20MHz teria altas chances de ela inteira ficar ilegível nalguns bits, perderia muito dado.

    Eu queria achar uma imagem, mas como se representa uma rajada de 100 bits, que representa um code rate de 1/2 onde na prática só 50 bits é de dados novos? Não achei imagem no google pra representar isso e provavelmente é porque não tem como. O esquema de modulação (4QAM, 16QAM, 64QAM) até dá, o monte de portadoras (64 de 315MHz num canal de 20MHz?) dá pra ver na análise de espectro, mas o code rate complica, é só o uso de um ou outro percentual de bits (0 ou 1) levando dados pra formar um pacote.






Visite: BR-Linux ·  VivaOLinux ·  Dicas-L