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

Thu Sep 11 18:36:48 -03 2014

Exatamente.

Meu melhor teste tanto para equipamento como para qualidade/velocidade no
link é colocar um monte de conexões simultâneas concorrentes e ver como ele
se comporta. Uma conexão TCP simples nunca será referência, mas cada um é
cada um :-)

[]'s

Em 11 de setembro de 2014 10:49, Leonardo da Silva Fiuza Pina <
leonardo.pina at lbr.com.br> escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>