11 maio 2010

Por que testes do Inmetro e Anatel serão inúteis?

A Anatel anunciou hoje que, em parceria com o Inmetro e o CGI.Br farão testes para medição da qualidade da banda larga fixa no país. Os testes estão sendo feitos em 160 residências de consumidores das empresas Oi, NET, Telefônica e GVT. Apesar das boas intenções, está longe de alcançar o objetivo: impulsionar a melhoria no serviço prestado.

Estatísticas insuficientes
O Brasil possui mais de 15 milhões de contratantes de serviço banda larga. Mesmo assim, os testes de medição serão feitos em apenas 160 residências. Isto representa menos que 0,0011%. Esta amostragem é (desculpem a expressão) infinitamente insignificante e não pode ser considerado um teste válido. Se os resultados se mostrarem favoráveis às empresas, elas utilizarão destes dados para afirmar que seus serviços estão de acordo com as exigências do Inmetro e da Anatel. Você concorda?

Não bastasse isso, os testes serão feitos através do SIMET - Sistema de Medição de Tráfego de Última Milha. Este programa realizará testes de velocidade, DNS, ping e outros critérios, e reportar automaticamente todas as informações de volta para o CGI.Br. O programa e a proposta são interessantes, porém os resultados serão duvidosos.

O que realmente importa é a velocidade máxima contratada
Veja os principais critérios técnicos utilizados no teste, para fazermos uma análise posteriormente:


Grandeza
Critério
Disponibilidade
Maior ou igual a 99% (equivalente a 7,2h de interrupção ou menos a cada mês)
Vazão/Velocidade Média
Média maior que 60% da vazão/velocidade máxima contratada
Vazão/Velocidade Instantânea
Valor instantâneo mínimo de 20% da vazão/velocidade máxima contratada
Perda de Pacotes
Perda máxima de 2% (dois por cento) do volume de dados enviados
Tempo para estabelecimento de conectividade IP
Tempo máximo de 1 minuto
Número de tentativas para estabelecimento de conectividade IP
Valor máximo de 2 tentativas

Estes critérios são interessantes, porém podem apresentar resultados facilmente distorcidos ou simplesmente, questionáveis. O principal motivo é que o teste será feito possivelmente com servidores do CGI.Br, como a outra ponta da conexão entre o serviço ADSL contratado. Para representar o nível de desconfiança nos resultados (NDR), considerei uma avaliação de 0 a 5.
  • Disponibilidade
    Para identificar que durante 1 mês o serviço de ADSL foi devidamente oferecido, ininterrupto (maior ou igual a 99%), seria preciso considerar que: a) não faltaria luz; b) não haveria enchentes; c) teria que provar que não houveram incidentes naturais, externos ou adversos à conectividade. 
    NDR - 

  • Vazão/Velocidade Média
    Este critério parece ser inteligente, e razoável, não fosse por um detalhe: as empresas costumam
    limitar a velocidade, com regras inteligentes em seus roteadores, baseadas em tipos de arquivos, ou de qual servidor está sendo obtido. Veja meu post sobre Invasão de Privacidade para Limite de Velocidade, presente no serviço Oi Velox para entender melhor. Resumindo: o teste pode apresentar excelente resultado, mas seus acessos ao YouTube ainda parecerão lentos, e a operadora alegará que a culpa é do canal de streaming.
    NDR - 


  • Vazão/Velocidade Instantânea
    Para iludir o usuário de que a velocidade do seu plano está sendo respeitada, as operadoras geralmente deixam um limite de velocidade maior que o contratado, no inicio das transferências. Este critério será respeitado por todas as operadoras, exceto que por motivos que interessam somente às operadoras. Nesse caso, os resultados não precisam ser questionados, exceto a falta de ética das empresas.
    NDR - 

  • Perda de Pacotes
    Para provar os resultados deste critério, é preciso identificar quem perdeu os pacotes. Se foi o lado que enviava dados ou o lado que recebia. E quem é quem. Não sou especialista em TCP/IP, mas acredito que para identificar que a operadora é a culpada em um alto índice de perda de pacotes, é preciso avaliar outros critérios, como ruído na linha ADSL (não previsto na análise da Anatel). Ainda assim, é provável que estes resultados sejam confiáveis, graças à naturalidade do principal meio de comunicação nos testes: TCP/IP (que garante entrega de pacotes). De certo modo, este teste é desnecessário, para não dizer idiota.
    NDR - 

  • Tempo/Número de tentativas para estabelecimento de conectividade IP
    Outro teste que é difícil de considerar os resultados. Com qual IP será feito o teste? Os da CGI.Br? Ou uma série de servidores espalhados no mundo? Fica difícil de entender os resultados sem melhor clareza no processo e a consequência na melhoria do serviço.
    NDR - 
Qualidade mascarada
Pela forma que os testes serão realizados, fica difícil acreditar nos resultados. Isto pode apresentar uma qualidade mascarada, favorecendo as prestadoras e mantendo a baixa qualidade do serviço prestado. O serviço de banda larga deveria ser fiscalizado de outra forma. O certo é que agentes e técnicos da Anatel deveriam conferir e fiscalizar pessoalmente, os roteadores, backbones e backhauls utilizados na rede brasileira.

Fiscalização presencial
Proibir o uso de regras inteligentes de limites de velocidade, quotas e traffic shaping deveria ser o método utilizado pela Anatel para impulsionar a melhoria nos serviços. Fiscalizar as configurações utilizadas pelas operadoras, que respeitem os planos contratados.

A Anatel deveria fazer escola com a Anvisa, e aprender e entender o que é exigir qualidade de serviço prestado. Mudar o nome para Anvitel já seria um bom começo.

Um comentário:

Unknown disse...

Trabalho para a Atento do Brasil, a serviço da Telefonica, e posso afirmar: SIM, o teste fará surtir efeitos!
Nos nossos callcenters, todos os clientes que ligam com problemas não chegam a 01%. E boa parte das ligações em si, são rechamadas, ou seja, o cliente que liga mais de uma vez no dia.
Porem, eu também acho pouco 160, deveria ser uns 1000, pelo menos....

Contato

Email:bruno.borges(at)gmail.com

LinkedIn: www.linkedin.com/in/brunocborges
Twitter: www.twitter.com/brunoborges
Comprei e Não Vou
Rio de Janeiro, RJ Brasil
Oracle
São Paulo, SP Brasil