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

Carlos Ribeiro cribeiro at telbrax.com.br
Fri Sep 12 14:22:43 -03 2014


Eduardo,

O engraçado é que eu concordo com você, mas do que você imagina. Só acho
que você não entendeu a intenção do meu post original. Não quero procurar
chifre em cabeça de cavalo, mas fiquei curioso com um comportamento que a
meu ver não é normal. Estou investigando por pura curiosidade mesmo.

Vamos lá então voltar ao objetivo original: fiz testes repetidos com uma
conexão TCP, e em todos os testes, a conexão começa com 1 Mbps por 10s; de
repente, pula para 10 Mbps nos 10s finais do teste. O gráfico ASCII é esse
aqui:

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

20 Mbps -----------------------------------------

10 Mbps ----------------------*=*=*=*=*=*=*=*=*=*
                             /
 0 kbps *=*=*=*=*=*=*=*=*=*=*--------------------

--------+-------------------+-------------------+
TEMPO   0                   1                   2
 (s)    0-1-2-3-4-5-6-7-8-9-0-1-2-3-4-5-6-7-8-9-0


A melhor explicação até agora é que isso seria efeito de um cache
transparente. Faz sentido. Só que neste caso haveria um erro no SIMET, que
deveria usar a opção "no cache" (supondo que o SIMET faz um teste com HTTP).

Então é só isso, curiosidade, e vontade de aprender sempre...

*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 11 de setembro de 2014 18:35, Eduardo Rigler <erigler at gmail.com>
escreveu:

> Continuo discordando de ti, e vou além, acho que o nobre colega está
> procurando chifre em cabeça de cavalo ou por uma solução no lugar errado.
>
> []'s
>
> Em 11 de setembro de 2014 10:43, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
> > Eduardo,
> >
> > Só para deixar claro, eu não acredito piamente no SIMET. Só que no caso
> do
> > SIMET eu sei EXATAMENTE onde o servidor está, e qual é a topologia desde
> a
> > rede da NET até o ponto de teste. Nossa operação de rede fica em BH e
> > operamos dois PIXs aqui, sabemos exatamente onde o roteador da NET entra
> na
> > rede, e por isso confio no teste para referência: eu sei qual parte da
> rede
> > está sendo medida.
> >
> > Além disso o applet do SIMET também mostra o teste "em tempo real" e é
> > possível ver a variação das medidas de forma muito clara. É bem
> > conveniente.
> >
> > Já o teste "oficial" da NET (Brasil Banda Larga) é completamente opaco.
> Não
> > sei onde fica o servidor, pode muito bem estar dentro da rede da NET (e
>> > mede menos coisa que o SIMET, que tem que obrigatoriamente sair de dentro
> > da rede para um PTT). O teste também não mostra o relatório de progresso,
> > você pode até baixar um CSV mas não tem a mesma transparência e
> > conveniência.
> >
> > Resumindo mal e porcamente, acho que o teste é válido sim, especialmente
> se
> > você souber o que está medindo.
> >
> > Agora, o que eu continuo sem saber é porque o teste de TCP dá um
> resultado
> > tão estranho. Se for interferência de cache, tem uma falha na metodologia
> > do SIMET que precisa ser corrigida.
> >
> > *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 11 de setembro de 2014 10:28, Eduardo Rigler <erigler at gmail.com>
> > escreveu:
> >
> > > 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
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



More information about the gter mailing list