Bandwidth * Atraso do produto

3

Estou tentando calcular o produto de atraso de largura de banda entre vários hosts e lendo este artigo do wiki , estou confuso.

Do artigo;

Residential ADSL2+: 20 Mbit/s (from DSLAM to residential modem), 50 ms RTT

B×D = 20×106 b/s × 50×10-3 s = 106 b, or 1 Mb, or 125 kB.

Uma das conexões das quais estou testando, para um host de teste, é uma conexão ADSL2 +. Tem uma taxa de sincronização downstream de "11006 kbps", estou estimando que 10000 Kbps é um rendimento máximo teórico razoável. Quando "pingando" o host de teste da linha ADSL2 +, recebo um RTT de 29 ms. O host de teste é conectado à "Internet" com uma conexão Ethernet de 100Mbps.

Agora, aqui está a parte confusa ; Realizando um teste de velocidade contra o servidor (ele está executando uma cópia do aplicativo de teste de velocidade de speedtest.net) eu recebo 9,23 Mbps para o downstream. De acordo com esse artigo da Wiki, 10000000bps * 0,029s = 290000bps (290 Kbps), o que é muito menos do que meus 9,23 Mbps.

Eu perdi algo óbvio ou o artigo está errado?

    
por jwbensley 04.07.2012 / 22:03

1 resposta

4

I'm trying to calculate the bandwidth delay product between various hosts... Have I missed something obvious, or is the article wrong?

Você só está sentindo falta das unidades; quando você multiplica bps por segundos, você recebe bits como as unidades:

10Mbps * .029s = 2900000.0 bits (362500 bytes)

O ponto do artigo é que ele destaca o que sua janela TCP (escalonada) precisa ter a fim de evitar atrasos devido a uma "rede longa e gorda". Citando RFC 1072 :

Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88]. However, there is still a fundamental TCP performance bottleneck for one transmission regime: paths with high bandwidth and long round-trip delays. The significant parameter is the product of bandwidth (bits per second) and round-trip delay (RTT in seconds); this product is the number of bits it takes to "fill the pipe", i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when this product is large, e.g., significantly exceeds 10**5 bits. We will refer to an Internet path operating in this region as a "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)").

Neste caso específico, o TCP precisa fornecer um tamanho de janela dimensionado de aproximadamente 362KB. Implementações TCP modernas (aquelas que implementam corretamente RFC 1323 ) não sofrem de problemas relacionados a LFNs.

    
por 04.07.2012 / 22:18