[GTER] Performance TCP estranha com acesso banda larga da NET

Thu Sep 11 10:49:23 -03 2014

Eu só uso o Speedtest e mesmo assim sabedor que a "velocidade" informada 
é somente referencial.

Mas, existe como medir a "velocidade" do acesso a Internet de forma precisa?

Até onde entendo, toda medição fornece única e exclusivamente uma 
referência para análise. O resultado não pode ser considerado verdade 
absoluta.

Cordial cumprimento.

On 09/11/2014 10:28, Eduardo Rigler wrote:
> Sou assinante do Virtua há vários anos e é notória a performance
> ruim/instabilidade de sinal em algumas regiões do país ou mesmo dentro de
> uma mesma cidade. Ao menos aqui em Curitiba (ou mais especificamente na
> minha região) nunca houveram problemas graves com instabilidade ou de
> performance que não fossem solucionados rapidamente pela NET com ou mesmo
> sem a necessidade de abertura de chamado.
>
> Sem desmerecer a ferramenta (SIMET) de forma alguma, mas muito me admira o
> pessoal mais entendido no tema se basear e crer piamente em um site que
> mede a velocidade da internet e não na "vida real".
>
> Esses dias mesmo houve uma thread bem extensa na lista [caiu] (salvo
> engano) relacionada à performance e confiabilidade de resultado do SIMET em
> algumas regiões.
>
> Particularmente não uso SIMET, Speedtest ou afins pra um teste mais à
> sério, no máximo como referência. Em um mesmo dia/horário já vi variações
> gritantes de resultado mesmo em links dedicados.
>
>
> []'s
>
>
> Em 11 de setembro de 2014 08:44, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
>> Fernando (ou seria Frediani? como você prefere?),
>>
>> Eu acho que você tem razão e o problema parece ser de cache mesmo.
>>
>> Neste caso, a equipe do SIMET talvez possa explicar o motivo desse cache
>> estar interferindo no teste, porque basta sinalizar o "no cache" no header
>> HTTP para evitar que este entre em ação e prejudique o teste. Imagino que
>> tenha alguém na lista :-)
>>
>> *Carlos Ribeiro*
>> *Sócio*
>> Cel: +55 (31) 9303-3366
>> Tel: +55 (31) 3305-5620
>> Geral: +55 (31) 3305-5600
>> cribeiro at telbrax.com.br
>> www.telbrax.com.br
>>
>> Em 10 de setembro de 2014 17:08, Fernando Frediani <fhfrediani at gmail.com>
>> escreveu:
>>
>>> Oi Carlos,
>>>
>>> Eu ja vi algo parecido recentemente quando troquei de provedor porém não
>>> foi exatamente com medição de tráfego, mas com downloads em geral.
>>> Quando inicio um download a velocidade inicial é relativamente baixa se
>>> comparada a minha velocidade máxima, de repente depois de alguns segundos
>>> ela sobe e vai para o máximo e volta ou não a variar algum tempo depois.
>>> O que eu acredito que cause isso é o Servidor de Cache no meu provedor,
>>> pois dependendo da configuração deste quando você inicia um download,
>>> especialmente de um arquivo grande, ele vai começar a baixar parte do
>>> arquivo pro servidor cache primeiro e não te enviar nada, só depois ele
>> vai
>>> enviar, ai sim na velocidade máxima o que causa a estranheza no medidor
>> de
>>> velocidade.
>>> Fiz o teste inclusive usando o wget com a opção --no-cache e ai sim a
>>> velocidade fica sempre próxima a máxima de maneira constante.
>>>
>>> As duas incógnitas pra mim no seu caso são: 1 - Se a NET ai está usando
>>> servidor de cache com proxy transparente (acredito que não) e 2 - De que
>>> maneira a medição do SIMET é feita e se um servidor de cache no meio pode
>>> influenciar isso.
>>>
>>> Abraços.
>>> Fernando Frediani
>>>
>>>
>>> On 10/09/2014 11:23, Carlos Ribeiro wrote:
>>>
>>>> Pessoal,
>>>>
>>>> Estou com um problema em casa, onde tenho um acesso banda larga NET
>> (antes
>>>> que me perguntem, a Telbrax não tem acesso banda larga em BH, não é
>> nosso
>>>> negócio...). O resultado do teste é curioso e eu queria saber se alguém
>> já
>>>> viu algo parecido.
>>>>
>>>> Como a lista não aceita anexos, vou compartilhar as figuras na Internet
>>>> para quem quiser ver, e vou postar um simples "gráfico ASCII" aqui para
>>>> facilitar a discussão. Espero que não chegue muito "mastigado" na lista.
>>>>
>>>> Os links dos testes são:
>>>>
>>>> 1) http://i.imgur.com/DJabik7.png
>>>> 2) http://i.imgur.com/TE8VvWu.png
>>>>
>>>> O acesso é de 10 Mbps. Teste com o SIMET e os resultados são ruins, mas
>>>> meu
>>>> gráfico de conexão TCP, em dois testes diferentes, apareceu igualzinho:
>>>>
>>>> -----------------------------------------------------------------
>>>>
>>>> 20 Mbps ---------------------------------------------------------
>>>>
>>>> 10 Mbps ----------------------------*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
>>>>                                      /
>>>>    0 kbps *=*=*=*=*=*=*=*=*=*=*=*=*=*------------------------------
>>>>
>>>> -----------------------------------------------------------------
>>>>
>>>> Metade do teste apareceu com sendo _um pouco_ acima da linha de "0 kbps"
>>>> (o
>>>> número durante a medida parece como sendo EXATAMENTE 1 Mbps); depois, do
>>>> nada, uns 10 segundos depois do começo, a velocidade subiu para os 10
>> Mbps
>>>> "normais".
>>>>
>>>> Isso não bate com nada que eu já tenha visto de experiência em TCP, pelo
>>>> contrário. A conexão começa com 1 Mbps e só dispara depois de um certo
>>>> tempo.
>>>>
>>>> Minha interpretação técnica é que isso seja algum tipo de shaping, que
>>>> "prejudica" conexões curtas e favorece conexões longas. Mas pode ser só
>>>> algum defeito ou bug pelo caminho. Resumindo, alguém já viu esse tipo de
>>>> fenômeno? Qual seria o raciocínio por trás disso? Eu não acha que faça
>>>> nenhum sentido, já vi o contrário (aceitar burst mas limitar conexões
>>>> longas). Mas assim...
>>>>
>>>> *Carlos Ribeiro*
>>>> *Sócio*
>>>> Cel: +55 (31) 9303-3366
>>>> Tel: +55 (31) 3305-5620
>>>> Geral: +55 (31) 3305-5600
>>>> cribeiro at telbrax.com.br
>>>> www.telbrax.com.br
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
> !DSPAM:1,5411a53a50991409612112!
>
>

-- 

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com