José Ribamar Smolka Ramos
Telecomunicações
Artigos e Mensagens


WirelessBrasil

Março 2012               Índice Geral


09/03/12

• Debate sobre o "processo de escolha" da EAQ - Entidade Aferidora da Qualidade da banda larga

de J. R. Smolka smolka@terra.com.br por yahoogrupos.com.br
para "wirelessbr@yahoogrupos.com.br" <wirelessbr@yahoogrupos.com.br>,
"Celld-group@yahoogrupos.com.br" <Celld-group@yahoogrupos.com.br>
data 4 de março de 2012 17:49
assunto [Celld-group] É duro entender esse povo...

Por favor, alguém me ajude a entender o que querem esses auto-intitulados "guardiões" do bem-estar do consumidor de serviços de telecomunicação.

Primeiro foi um chororô só quando a Oi exerceu seu direito (legítimo e legal) de contestar oficialmente os regulamentos de qualidade do SMP e do SCM. O pessoal embrulhou-se na bandeira nacional e passou a deitar falação de como os regulamentos eram uma "conquista" da sociedade civil e dos consumidores, de como eles eram bons e perfeitos exatamente como estavam, e de como era um absurdo que a Oi tivesse o desplante de contestá-los. Como se ela tivesse a obrigação de deixar que colem nela um cartaz dizendo "me chute" e ainda por cima agradecer pelos chutes recebidos. Faz sentido para voces? Para mim não.

Depois, com o início do funcionamento do GIPAQ, começou também a esquizofrenia (patologia mental caracterizada pelo alheamento da realidade objetiva e vivência de uma realidade interior delirante e/ou paranóide). Os regulamentos "perfeitos" estipulam que deve haver a contratação, com ônus para os fiscalizados (não consigo entender isso), de uma entidade aferidora da qualidade - EAQ - responsável pela execução das medições oficiais para avaliação do desempenho das redes. Os regulamentos dizem que as permissionárias SMP e SCM deveriam fazer a seleção, sem impor condições a este respeito. E aí, ao ver que alguns dos concorrentes ao posto de EAQ não eram do seu agrado, os mesmos defensores da perfeição dos regulamentos passaram a atacar o processo anteriormente "perfeito", dizendo que a seleção deveria seguir as mesmas regras de licitação pública - o que não pode ser imposto a entidades privadas. E ainda foram à justiça para exigir, em nome de uma suposta "exigência de transparência", que a concorrente ABR Telecom (empresa criada pelas operadoras para gerir o processo de portabilidade numérica) fosse excluída de um certame privado *antes* que o julgamento das propostas ocorresse, somente por pressupor a sua falta de isenção.

Este aspecto dos regulamentos estava visível, desde o início, para todos que quisessem lê-los. Se estes que agora criticam o processo acham que está errado, porque não aproveitaram a janela de oportunidade dada pela Anatel para opinar sobre a revisão dos pontos que eles achassem incorretos? Eu tenho um palpite do porque: era mais importante manter a fachada de resistência à iniciativa da Oi do que mexer no texto. Até porque eles acreditam que, se for feita pressão suficiente - na imprensa ou pela via judicial, a visão deles pode ser imposta sempre que assim quiserem.

Seja por que motivo for, não foi a ABR Telecom a selecionada para o papel de EAQ, e sim a PriceWaterhouseCoopers, que entrou na disputa em parceria com a SamKnows. Mas isso não satisfez aos críticos. O que está óbvio para mim é que eles só se darão por satisfeitos quando for escolhido o NIC.br, braço técnico do CGI.br, para este papel. E passaram a criticar tanto a empresa selecionada quanto o método de seleção.

Ao ver deles a Price cometeu o tremendo pecado de ter publicado, tanto durante a fase de consulta pública dos regulamentos de qualidade do SMP e SCM, quanto na consulta pública sobre o questionamento feito pela Oi ao texto destes mesmos regulamentos, manifestações que são "obviamente encomendados pelas operadoras". O tom geral da reação pode ser observado nesta reportagem e também nesta reportagem, que chega ao cúmulo de dizer que as medições que a EAQ selecionada fará serão "oficiais" - assim mesmo, com aspas! Sendo assim, ela é um "deles", e não deve ser permitida no papel de EAQ, por pressuposta - e não provada (como se isto importasse a eles) - falta de isenção. Eu tenho uma coisa a dizer a estes senhores e senhoras que reclamam: confio mais na isenção da Price do que na dos senhores(as).

E, à falta de algo mais substantivo para reclamar, vem agora dizer que o software apresentado pela Price/SamKnows na seleção não faz a medição de todos os parâmetros exigidos. Isto foi alegado inclusive pelo próprio membro do CGI.br (que é um órgão estatal, criado pela Portaria Interministerial nº 147 de 31/05/1995 e posteriormente ratificado pelo Decreto nº 4.829 de 03/09/2003) e Diretor Presidente do NIC.br (que na minha interpretação enquadra-se na categoria ONG), Sr Demi Getschko nesta reportagem:  “a versão do Speedtest a que tivemos acesso não mede parâmetros importantes e definidos pela Anatel para se avaliar a qualidade da banda larga”.

Antes de falar do software (Speedtest) eu quero uma explicação. O NIC.br define-se, segundo o art. 1º do seu estatuto, como uma "pessoa jurídica de direito privado, da modalidade associação, sem fins lucrativos ou de fins não econômicos" (grifo meu). Entretanto, observando as prestações de contas publicadas  (embora só exista balanço patrimonial a partir de 2008, e este balanço só passou a ser auditado a partir de 2009) ele apresentou lucros (que eles chamam eufemisticamente de superávits :-)  )  em todos os exercícios da sua existência, desde 2006 até 2010 de, respectivamente,  R$ 34,65M, 41,16M, 55,01M, 67,13M e 80,83M. Desempenho notável! Pergunto eu: para onde foram estes lucros, ops... desculpem... superávits? Ficam simplesmente em caixa? São mantidos em aplicações financeiras? Para onde vai esta dinheirama? Até aqui somam R$ 278,78M (sem contar, ainda, com o exercício 2011).

Agosa sobre o Speedtest. Ponto 1: ele provavelmente foi apresentado como o "chassis" básico da aplicação que tem de ser implementada, de acordo com os regulamentos. Isto não quer dizer que ele será implementado do jeito que está, e que não haverão modificações ou adaptações. Ponto 2: os parâmetros de desempenho de rede para o SMP são apenas as velocidades (instantânea e média) de upload e download. Indo até o site da aplicação e executando o teste básico inicial vemos exatamente isso. Ponto 3: Para o SCM pede-se, alem das mediçoes do SMP, também medições de delay, jitter e perda de pacotes. Ao final da execução do teste básico existe um ícone no lado direito da tela chamando a atenção para o site pingtest.net. Lá é executado o teste que mede estes três indicadores adicionais para o SCM. Faz sentido ser assim? Para mim faz, porque para os usuários do SMP o segundo teste é opcional. Informativo, sim, porém sem obrigações por parte das operadoras.

Então, do que exatamente estão reclamando? Que a metodologia usada nestes testes não é igual ao do SIMET, operado pelo NIC.br? Não vejo problema nisso. Aliás, para mim o SIMET faz algo que não faz sentido do ponto de vista da rede (só dos equipamentos nas pontas - o servidor e o computador do usuário):  medir as velocidades de upload e download usando TCP *e* UDP. Além disso, nestas medições existe - pelo menos nas vezes que usei - uma tendência estranha dos últimos 5 a 10 valores da série de medidas instantâneas apresentarem desempenho muito pior que as demais. Porque?

Resumo da ópera. Para aqueles que estão choramingando porque foi selecionada a Price e não o NIC.br aqui vai meu conselho: vão chorar na cama, que é lugar quente. Ou ainda, se for aqui em Salvador - BA, vão chorar lá no Campo Grande, no pé do caboclo. Antigamente (até cerca de 10 anos atrás) ainda era mais fácil, porque no Campo Grande também ficava o palácio arquiepiscopal, e os inconformados podiam aproveitar e queixar-se ao Bispo :-) .

[ ]'s
J. R. Smolka

-------------------------------------

Msg de Rubens
para Celld-group@yahoogrupos.com.br
cc "wirelessbr@yahoogrupos.com.br" <wirelessbr@yahoogrupos.com.br>
data 4 de março de 2012 20:50
assunto [wireless.br] Re: [Celld-group] É duro entender esse povo...

> Os
> regulamentos "perfeitos" estipulam que deve haver a contratação, com ônus
> para os fiscalizados (não consigo entender isso),

Eu também não entendo e não concordo. A minha leitura (pessoal) do que aconteceu é que a Anatel não quis contratar do bolso dela o processo, e ao transferir esse ônus para os fiscalizados, teve que concordar com que os fiscalizados escolhessem a solução, ou eles poderiam questionar
(judicialmente inclusive) ter que arcar com o ônus e não ter feito a
escolha.

> Seja por que motivo for, não foi a ABR Telecom a selecionada para o papel
> de EAQ, e sim a PriceWaterhouseCoopers, que entrou na disputa em parceria
> com a SamKnows.

Sendo que a ABR Telecom também seria via parceria com a SamKnows (mas como diz a Wikipedia, "carece de fontes" pois eu não achei as referências disso, mas espero que alguém da lista possa completá-las).

> Mas isso não satisfez aos críticos. O que está óbvio para
> mim é que eles só se darão por satisfeitos quando for escolhido o NIC.br,
> braço técnico do CGI.br, para este papel. E passaram a criticar tanto a
> empresa selecionada quanto o método de seleção.

Também tenho essa impressão, e tenho uma teoria sobre isso: me parece que estes acreditavam, possivelmente com razão, que o NIC.br poderia ser contratado pelo próprio fiscalizado e ainda sim gerar um resultado sem viés, e não acreditavam nisso no caso das opções sob a esfera de influência das teles, a PwC Recovery e a ABR Telecom.

E em sendo isso, o erro não é da escolha, mas da modelagem. Um processo não pode ser criado para funcionar apenas se condições de contorno específicas estiverem presentes. A escolha foi apenas uma consequência natural da modelagem.

> falta de isenção. Eu tenho uma coisa a dizer a estes senhores e senhoras que
> reclamam: confio mais na isenção da Price do que na dos senhores(as).

Algo a lembrar é que não se trata da PwC auditores ("Assurance") no processo, mas a PwC "Corporate Finance Recovery", que é de consultoria. A estrutura descentralizada na PwC dá independência para a PwC CFR Brasil no processo, inclusive.

> E, à falta de algo mais substantivo para reclamar, vem agora dizer que o
> software apresentado pela Price/SamKnows na seleção não faz a medição de
> todos os parâmetros exigidos.

Porque não faz mesmo, mas por ter sido apontada uma solução temporária para atender o prazo especificado. Não me parece que o Speedtest tenha qualquer correlação com a solução definitiva, pois o que já vi das duas soluções me pareceu muito diferente. E nesse sentido, mesma a possibilidade de rodar depois o Pingtest não me parece suficiente, já
que o objetivo dessa fase com medições mas sem metas era educar os clientes nos parâmetros que são apurados.

> Agora sobre o Speedtest. Ponto 1: ele provavelmente foi apresentado como o
> "chassis" básico da aplicação que tem de ser implementada, de acordo com os
> regulamentos. Isto não quer dizer que ele será implementado do jeito que
> está, e que não haverão modificações ou adaptações. Ponto 2: os parâmetros
> de desempenho de rede para o SMP são apenas as velocidades (instantânea e
> média) de upload e download. Indo até o site da aplicação e executando o
> teste básico inicial vemos exatamente isso. Ponto 3: Para o SCM pede-se,
> alem das medições do SMP, também medições de delay, jitter e perda de
> pacotes. Ao final da execução do teste básico existe um ícone no lado
> direito da tela chamando a atenção para o site pingtest.net. Lá é executado
> o teste que mede estes três indicadores adicionais para o SCM. Faz sentido
> ser assim? Para mim faz, porque para os usuários do SMP o segundo teste é
> opcional. Informativo, sim, porém sem obrigações por parte das operadoras.

Bastaria ter pedido para a Ookla(desenvolvedor do Speedtest e Pingtest) uma customização onde ambos os testes fossem feitos. Mas as telas que vi sugerem que esse fornecedor possa não ter sido especificamente contactado sobre o processo da EAQ, e as relações já existentes entre as teles e a Ookla e não algo específico tenha sido usado para essa fase.


> Então, do que exatamente estão reclamando? Que a metodologia usada nestes
> testes não é igual ao do SIMET, operado pelo NIC.br? Não vejo problema
> nisso. Aliás, para mim o SIMET faz algo que não faz sentido do ponto de
> vista da rede (só dos equipamentos nas pontas - o servidor e o computador do
> usuário): medir as velocidades de upload e download usando TCP *e* UDP.
> Além disso, nestas medições existe - pelo menos nas vezes que usei - uma
> tendência estranha dos últimos 5 a 10 valores da série de medidas
> instantâneas apresentarem desempenho muito pior que as demais. Porque?


Duas possíveis razões: para controles de banda que levam em conta um maior tempo de utilização, é quando ele tenta ajustar a média para a meta de controle de banda. O outro é o efeito de "buffer bloat" (http://www.bufferbloat.net/); se o jitter apresentar forte variação nas mesmas medições, pode ser a causa.

> Resumo da ópera. Para aqueles que estão choramingando porque foi
> selecionada a Price e não o NIC.br aqui vai meu conselho:

O que mais me preocupa não é a solução da SamKnows, pois com alguns nuances todas as soluções podem ser customizadas para medir os parâmetros da EAQ, mas o modelo em si, o qual tem a PwC CFR como um dos componentes.

Rubens

-------------------------------

de J. R. Smolka smolka@terra.com.br por yahoogrupos.com.br
responder a wirelessbr@yahoogrupos.com.br
para wirelessbr@yahoogrupos.com.br
data 5 de março de 2012 08:53
assunto Re: [wireless.br] É duro entender esse povo...

Oi Bruno,

Vamos por partes...

Eu nao li as condicoes tecnicas para a medicao de qualidade de SMP e SMC, mas uma coisa sim me chama a atencao...Em que ponto de referencia essa medida sera realizada? Do computador do usuario para um servidor interno da operadora (como eh feito hoje quando se liga para reclamar da conexao)? Assim fica facil cumprir meta ne :)

Os regulamentos do SCM e do SMP divergem e concordam a respeito dos pontos de realização da medição.

Divergem na ponta do cliente de medição: no caso SCM a EAQ deve selecionar, dentro de cada região de medição (basicamente a estratificação é por UF/código de área), uma amostra dos assinantes - supostamente com significância estatística, representando a distribuição geográfica, de tecnologias de acesso e de bandas contratadas - que deverão ter um equipamento de medição dedicado instalado nas suas casas/escritórios (não há diferenciação entre usuários domésticos e corporativos); no caso SMP isto está aberto para ser definido pela EAQ e pelo GIPAQ (o mais provável é que funcione do modo atual - acesso web a um site onde o cliente de medição é executado na Java virtual machine)

Concordam (ambos são vagos) na ponta do servidor de medição: ambos dizem que a medição deverá ser feita entre a casa/escritório do usuário e o PTT. Só não explicam como deve ser selecionado, para cada caso, o PTT apropriado e (o Sr. Demi Getschko também andou opinando sobre isto) se o servidor de medição deve estar localizado dentro ou fora da esfera de controle do AS da permissionária SCM/SMP. Isto também está para ser definido pela EAQ e pelo GIPAQ. Minha opinião é: se a permissionária só pode atuar, técnica ou administrativamente, dentro dos limites físicos e lógicos do seu próprio AS, então que sentido tem estender o percurso dos pacotes da aplicação de medição além desta fronteira? Se o resultado der ruim, usando do próprio raciocínio daqueles que suspeitam sempre da malevolência das operadoras, elas sempre irão dizer que a causa do mau desempenho está fora da sua alçada de intervenção, e vai ser difícil provar o contrário. Portanto é burrice colocar o servidor muito além da fronteira do AS da operadora. Minha sugstão: coloquem os servidores de medição no próprio site físico dos PTTs, em um AS pertencente à EAQ com peering estabelecido com todos os ASs das permissionárias conectadas ao PTT, mas a apenas um hop de distância física dos border gateways das operadoras. Não é exatamente assim que estão instalados os servidores do SIMET?

Agora, se o objetivo é criar uma situação insolúvel e manter uma ambiente de eterno atrito (e, com isso, desgastar a imagem pública das permissionárias SCM/SMP), então é simples: coloque os servidores de medição bem longe dos border gateways delas.

Que horas serao realizados os testes? Que dias da semana? Quais serao os criterios estatisticos de atendimento as metas?

Esta é uma das partes mais confusas dos regulamentos. Provavelmente como um ranço da medição de desempenho das redes de telefonia fixa e móvel (o chamado "dia do DDDX", que era sempre às quintas-feiras) os regulamentos estabelecem que a medição (de cada amostra de assinantes no caso SCM, indefinido no caso SMP) acontecerá de acordo com um calendário, ainda a definir pela Anatel (provavelmente via GIPAQ). Além disso, embora as medições possam ocorrer a qualquer hora do dia, só serão consideradas para o cálculo dos indicadores as medições feitas na faixa de horário definida nos regulamentos como PMT (período de maior tráfego): 10:00 às 22:00 horas.

Agora, a outra pergunta, quem quer participar deste mais novo filao de servico publico...bem...com certeza vai haver muito grupo interessado em abocanhar mais esta atividade, que sob meu ponto de vista, deveria ser exclusivamente da ANATEL, pois ate onde saiba uma de suas atribuicoes fins nao eh apenas regular, mas tambem fiscalizar...

Quanto à quantidade dos interessados em "abocanhar" este "mais novo filão de serviço público" (segundo seus próprios termos), não foram tantos assim. E já está definido quem será. Agora, quanto à responsabilidade desta atividade ser da própria Anatel, e quanto à estranheza dela ter decidido "terceirizar" isto para os próprios entes fiscalizados, nó concordamos.

Mas, também, depois de tantas "jabuticabas" embutidas nestes regulamentos, que diferença faz mais uma ou menos uma, né?

Enfim mais estranhos fatos que cercam a relacao Estado x empresas privadas no Brasil, vai entender...

Estranhos? Sim. Difíceis de entender? Nem tanto. Embora as explicações divirjam, conforme o gosto ideológico de cada um.

[ ]'s
J. R.
Smolka

------------------------------------------

de J. R. Smolka smolka@terra.com.br por yahoogrupos.com.br
responder a wirelessbr@yahoogrupos.com.br
para wirelessbr@yahoogrupos.com.br,
"Celld-group@yahoogrupos.com.br" <Celld-group@yahoogrupos.com.br>
data 5 de março de 2012 09:38
assunto Re: [wireless.br] Re: [Celld-group] É duro entender esse povo...

Oi Rubens,

Vamos por partes, como de praxe.

Os regulamentos "perfeitos" estipulam que deve haver a contratação, com ônus para os fiscalizados (não consigo entender isso),


Eu também não entendo e não concordo. A minha leitura (pessoal) do que aconteceu é que a Anatel não quis contratar do bolso dela o processo, e ao transferir esse ônus para os fiscalizados, teve que concordar com que os fiscalizados escolhessem a solução, ou eles poderiam questionar (judicialmente inclusive) ter que arcar com o ônus e não ter feito a escolha.
Aspecto curioso este... IMHO os responsáveis pela redação dos regulamentos olharam o que outras agências regulatórias de telecom fazem (grande exemplo o OFCOM, do Reino Unido) e pensaram: nós também gostaríamos de fazer assim, mas nossas fontes de receita (principalmente o FISTEL) são sempre contingenciadas... Então o jeito é fazer os próprios fiscalizados pagarem pelo processo de fiscalização... É legal, é constitucional? Sei lá, vamos em frente mesmo assim... Mas os fiscalizados não vão reclamar disso? Pode ser, então fazemos assim: eles pagam, mas podem escolher quem vai ser a contratada.

Seja por que motivo for, não foi a ABR Telecom a selecionada para o papel de EAQ, e sim a PriceWaterhouseCoopers, que entrou na disputa em parceria com  a SamKnows.


Sendo que a ABR Telecom também seria via parceria com a SamKnows (mas como diz a Wikipedia, "carece de fontes" pois eu não achei as referências disso, mas espero que alguém da lista possa completá-las).
Não seria a primeira vez que algo assim acontece. De qualquer forma, só quem teve ou tem acesso às propostas técnicas apresentadas pode resolver a dúvida

Mas isso não satisfez aos críticos. O que está óbvio para mim é que eles só se darão por satisfeitos quando for escolhido o NIC.br, braço técnico do CGI.br, para este papel. E passaram a criticar tanto a empresa selecionada quanto o método de seleção.


Também tenho essa impressão, e tenho uma teoria sobre isso: me parece que estes acreditavam, possivelmente com razão, que o NIC.br poderia ser contratado pelo próprio fiscalizado e ainda sim gerar um resultado sem viés, e não acreditavam nisso no caso das opções sob a esfera de influência das teles, a PwC Recovery e a ABR Telecom.

E em sendo isso, o erro não é da escolha, mas da modelagem. Um processo não pode ser criado para funcionar apenas se condições de contorno específicas estiverem presentes. A escolha foi apenas uma consequência natural da modelagem.
Concordo com você. Se queriam um processo de licitação pública, nos moldes da Lei nº 8.666 de 21/06/1993, então a Anatel devia ter puxado a responsabilidade da contratação para si. O que não dá é, extrapolando as exigências do regulamento, exigir que isso se aplique a uma contratação privada.

Falta de isenção. Eu tenho uma coisa a dizer a estes senhores e senhoras que reclamam: confio mais na isenção da Price do que na dos senhores(as).


Algo a lembrar é que não se trata da PwC auditores ("Assurance") no processo, mas a PwC "Corporate Finance Recovery", que é de consultoria. A estrutura descentralizada na PwC dá independência para a PwC CFR Brasil no processo, inclusive.
A confiança que tenho, em princípio, pela idoneidade da PwC - seja da linha de negócio auditoria, seja da linha de negócio consultoria - continua muito maior que minha confiança na lisura de intenções de certos críticos do processo.

E faz sentido que quem se envolva neste processo seja a vertente consultoria da PwC, que entende de montar processos de negócio, e não a de auditoria, que tem um viés quase que totalmente contábil.

E, à falta de algo mais substantivo para reclamar, vem agora dizer que o software apresentado pela Price/SamKnows na seleção não faz a medição de todos os parâmetros exigidos.


Porque não faz mesmo, mas por ter sido apontada uma solução temporária para atender o prazo especificado. Não me parece que o Speedtest tenha qualquer correlação com a solução definitiva, pois o que já vi das duas soluções me pareceu muito diferente. E nesse sentido, mesma a possibilidade de rodar depois o Pingtest não me parece suficiente, já que o objetivo dessa fase com medições mas sem metas era educar os clientes nos parâmetros que são apurados.
Não entendi... Primeiro você disse que não faz, depois dis que reconhece a existência do pingtest, mas não acha que ele seja suficiente - mesmo que seja como solução transitória. O que, exatamente, você acha que deveria ser? Você também é um dos que acham que só a metodologia do SIMET está de acordo com as expectativas?
Agora sobre o Speedtest.

Ponto 1: ele provavelmente foi apresentado como o "chassis" básico da aplicação que tem de ser implementada, de acordo com os regulamentos. Isto não quer dizer que ele será implementado do jeito que está, e que não haverão modificações ou adaptações.

Ponto 2: os parâmetros de desempenho de rede para o SMP são apenas as velocidades (instantânea e média) de upload e download. Indo até o site da aplicação e executando o teste básico inicial vemos exatamente isso.

Ponto 3: Para o SCM pede-se, alem das mediçoes do SMP, também medições de delay, jitter e perda de pacotes. Ao final da execução do teste básico existe um ícone no lado direito da tela chamando a atenção para o site pingtest.net. Lá é executado o teste que mede estes três indicadores adicionais para o SCM. Faz sentido ser assim? Para mim faz, porque para os usuários do SMP o segundo teste é opcional. Informativo, sim, porém sem obrigações por parte das operadoras.


 
Bastaria ter pedido para a Ookla(desenvolvedor do Speedtest eP ingtest) uma customização onde ambos os testes fossem feitos. Mas as telas que vi sugerem que esse fornecedor possa não ter sido especificamente contactado sobre o processo da EAQ, e as relações já existentes entre as teles e a Ookla e não algo específico tenha sido
usado para essa fase.

Como você disse, esta é uma solução transitória, cujo objetivo é apenas criar um maior entendimento pelo usuário do significado das medições feitas. Neste sentido achei até legal o uso do speedtest/pingtest, porque eles permitem, no final, uma "nota" de classificação do seu acesso, e quais aplicações possivelmente funcionarão bem, e quais não, no contexto do resultado obtido. Para esta situação acho que está no quilo certo.

Então, do que exatamente estão reclamando? Que a metodologia usada nestes testes não é igual ao do SIMET, operado pelo NIC.br? Não vejo problema nisso. Aliás, para mim o SIMET faz algo que não faz sentido do ponto de vista da rede (só dos equipamentos nas pontas - o servidor e o computador do usuário):  medir as velocidades de upload e download usando TCP *e* UDP. Além disso, nestas medições existe - pelo menos nas vezes que usei - uma tendência estranha dos últimos 5 a 10 valores da série de medidas instantâneas apresentarem desempenho muito pior que as demais. Porque?

Duas possíveis razões: para controles de banda que levam em conta um maior tempo de utilização, é quando ele tenta ajustar a média para a meta de controle de banda. O outro é o efeito de "buffer bloat" (http://www.bufferbloat.net/); se o jitter apresentar forte variação nas mesmas medições, pode ser a causa.
Peo menos no meu caso o efeito é mais perceptível quando está sendo medida a taxa de transmissão instantânea/média de conexões UDP. As medidas TCP geralmente correm ok. E o jitter não costuma flutuar muito nas medições que fiz até agora.

Resumo da ópera. Para aqueles que estão choramingando porque foi selecionada a Price e não o NIC.br aqui vai meu conselho:


O que mais me preocupa não é a solução da SamKnows, pois com alguns nuances todas as soluções podem ser customizadas para medir os parâmetros da EAQ, mas o modelo em si, o qual tem a PwC CFR como um dos componentes.
Será que você também está inserido no grupo daqueles a quem apresentei o meu conselho? :-)  

[ ]'s
J. R. Smolka

-----------------------------

de J. R. Smolka smolka@terra.com.br por yahoogrupos.com.br
para wirelessbr@yahoogrupos.com.br
data 6 de março de 2012 10:27
assunto Re: [wireless.br] Re: [Celld-group] É duro entender esse povo..

Não entendi... Primeiro você disse que não faz, depois dis que reconhece a existência do pingtest, mas não acha que ele seja suficiente - mesmo que seja como solução transitória. O que, exatamente, você acha que deveria ser? Você também é um dos que acham que só a metodologia do SIMET está de acordo com as expectativas?
 
Eu acho que para atender o regulamento mesmo a solução transitória deveria ter sido uma customização onde os testes do SpeedTest e do PingTest fossem ambos realizados (em SCMs). O PingTest opcional vai deixar o cliente de SCM com baixa percepção de que aqueles parâmetros também fazem parte do regulamento. Talvez algo tão simples quanto isso:
http://speedtest.operadorasmp.com.br
http://speedtest.operadorascm.com.br?pingtest=go

Linkar para o SIMET também funcionaria... porque será que não fizeram isso ? ;-)
Ok. Podemos até discutir sobre a *forma* da exibição das features de medição ao usuário final. Mas isto é muito diferente de ir à imprensa (e a mesma repercutir, sem nem mesmo checar os fatos) para afirmar que o aplicativo *não tem* aquelas features.

Quanto ao link para o SIMET, até podiam. Mas porque colocar azeitona na empada da concorrência, né? ;-)

Peo menos no meu caso o efeito é mais perceptível quando está sendo medida a taxa de transmissão instantânea/média de conexões UDP. As medidas TCP geralmente correm ok. E o jitter não costuma flutuar muito nas medições que fiz até agora.
 
Esse é um clássico sintoma de "Traffic Shaping", e um dos motivos de no SIMET se fazer também medição UDP... 
Traffic shaping poderia, sim, causar sintomas deste tipo. Mas soluções de DPI para o enforcement deste tipo de traffic policing/shaping são mais comuns em operadoras móveis. E os testes que andei fazendo, neste caso, foram via acesso DSL. Ainda acho que não temos todos os dados para contar a história. Gostaria muito de saber os critérios objetivos de teste usados pelo SIMET, mas o NIC.br não publicou isso, pelo menos para o público externo (ou não-acadêmico)

Agora... este tipo de interferência é o que está em jogo no caso do RGQ-SCM e RGQ-SMP? Não. Os parâmetros de desempenho colocados tem a ver exclusivamente com a camada IP, não transporte, não aplicação. Senão começam a aparecer zilhões de coisas, e seria necessário algo ainda mais complexo que o SIMET. Veja, como exemplo disso o ICSI Netalyzer, disponibilizado pela UC Berkeley.

A propósito (porque o Netalyzr faz isso, e porque tem muito significado prático para o usuário final daqui para a frente) deveria ser considerado no modelo da Anatel a avaliação da disponibilidade/desempenho de conexão IPv6, além da IPv4.

[ ]'s

J. R.
Smolka
 

WirelessBrasil                     BLOCO