Você pode reduzir o RTT aumentando a largura de banda em um link?

Aumentar a largura de banda em um link de, digamos, 1mb para 30mb reduz o RTT?

Eu encontrei uma resposta dizendo não. Alguém pode me explicar?

Além disso, quais são os melhores mecanismos para reduzir a RTT?

Aumentar a largura de banda em um link de, digamos, 1mb a 30mb reduz o RTT?

Em suma, sim; você está alterando o atraso de serialização ; a 1 Mbps, o atraso de serialização não é trivial.

Compare o atraso de serialização para um pacote de 1500 bytes em 1 Mbps e 30 Mbps:

1500 Bytes * 8 bits/Byte / 1,000,000 bits/second    = 12 milliseconds (at 1Mbps)
1500 Bytes * 8 bits/Byte / 30,000,000 bits/second   = 0.4 milliseconds (at 30Mbps)

Lembre-se também de que esses são números unidirecionais; você deve dobrá-los quando considerar o RTT. Se você se importa com uma diferença de 11,6 milissegundos em cada direção, a 1500 bytes, é outra questão, mas estritamente falando, você pode influenciar o RTT com a velocidade do link.

Aumentar a largura de banda em um link de, digamos, 1mb a 30mb reduz o RTT?

Não, aumentar a largura de banda não reduz o RTT estritamente falando. Eu digo "falando estritamente" porque depende do que você está medindo!

Cenário 1: A camada física

Dada a seguinte topologia simples e fácil de seguir, uma conexão Ethernet de cobre executando a 1 Mbps com uma MTU de 1500 bytes entre dois dispositivos com um cabo de 10 metros, possui o mesmo RTT (o tempo necessário para um pacote de solicitação de eco ICMP) para viajar do dispositivo 1 ao dispositivo 2 e a mensagem de resposta de eco ICMP para viajar do dispositivo 2 para o dispositivo 1) como uma conexão Ethernet de cobre de 10/30/50 / 100mbps entre eles com uma MTU de 1500 bytes no mesmo cabo de 10 metros.

Isso ocorre porque o "atraso" do sinal no cabo de cobre está relacionado à sua constante dialética ( permissividade relativa ). Veja essas duas páginas da Wikipedia para obter informações adicionais sobre a física que estão fora do escopo aqui.

Essencialmente, o "tempo de vôo" dos sinais elétricos no cabo de cobre é a mesma velocidade para uma conexão de 10 Mbps e 1000 Mbps ao usar o mesmo cabo Cat5e de comprimento e grau. A diferença é que, com uma conexão de 10 Mbps, os dados são codificados no fio com menos frequência do que uma conexão de 100 Mbps, para que haja lacunas menores entre os bits de dados à medida que são colocados no fio (isso é chamado de atraso de serialização ). Esses dois artigos da Wikipedia expandem ainda mais esses conceitos: Bit time e Slot time .

Cenário 2: Camada 4 e superior (exemplo de TCP)

Dado o seguinte exemplo de topologia, uma conexão Ethernet de cobre rodando a 1 Mbps com uma MTU de 1500 bytes entre dois dispositivos com um cabo de 10 metros. Se você tiver uma quantidade X de dados que pretendemos ser de 100 megabytes de dados para transportar entre o dispositivo 1 e o dispositivo 2, isso levará mais tempo do que com uma conexão Ethernet de cobre de 30 ou 100 Mbps com uma MTU de 1500 bytes em um medidor de 10 metros cabo de cobre entre os mesmos dois dispositivos. Isso ocorre porque leva mais tempo para codificar e transmitir os dados no fio e a placa de rede receptora será igualmente lenta na recepção e decodificação dos sinais.

Aqui, a RTT de "dados reais", que talvez seja um único arquivo de 100 MB, levará mais tempo, porque com os protocolos de nível superior introduzidos, você não apenas precisa transferir os dados, mas também pode trocar pacotes SYNs, ACKs e PUSH usando tempos de bits adicionais antes na camada de aplicação, uma mensagem pode ser enviada do dispositivo 2 para o dispositivo 1 dizendo "Recebi todos os dados agora".

Além disso, quais são os melhores mecanismos para reduzir a RTT.

Resposta curta: não muito

Resposta longa:

Para trazer isso para um exemplo da vida real, expandindo os exemplos acima; Se você estiver fazendo "ping" entre dois dispositivos conectados juntos por meio de vários roteadores intermediários e / ou comutadores, o RTT é um produto da distância física e do tempo que leva para que os sinais viajem para longe e para trás por todos esses dispositivos (basicamente ) Se a QoS estiver configurada nesses dispositivos, também poderá aumentar o atraso de ponta a ponta e complicar ainda mais o modelo.

Não há muito o que você possa fazer aqui além (em uma situação puramente hipotética em que dinheiro não é objeto e política não importa, etc.); Instale uma conexão de fibra que seja executada diretamente do dispositivo 1 para o dispositivo 2, cortando todos os comutadores e roteadores entre eles. Esse seria um cenário ideal. Realisticamente, você pode atualizar links de cobre ou sem fio para fibra (não que a fibra seja muito mais rápida [ i ], [ ii ]) e tentar tornar o caminho da conexão o mais direto possível, para que os dados passem pela menor quantidade de dispositivos intermediários e diferentes conexões físicas. O ajuste de QoS e a engenharia de tráfego (roteamento baseado em restrições) também podem ajudar em distâncias maiores com muitos saltos no meio.

Se você deseja transferir dados entre os pontos com o que considera "um RTT muito alto", pode ver tecnologias como o TCP SACK, que já está em uso em muitos lugares, mas se você ler sobre isso, ele fornecerá um ponto de partida, pois existem outras tecnologias semelhantes que você pode analisar. Isso inclui tecnologias como aceleradores e compressores WAN, embora isso se desvie do escopo deste tópico. Você deve considerar com a transferência de dados em um link com alta RTT o BDP (produto de atraso de largura de banda, [ iii ]) - ao usar algo como TCP, isso sempre o impedirá.

[i] O tempo de "vôo" sobre um meio dielétrico de cobre é muito semelhante a um guia de ondas de fibra

[ii] No entanto, isso pode mudar, espera-se que novas pesquisas e tecnologias aumentem a velocidade da luz em uma fibra da média de 0,6 * c para cerca de 1,0 * c, http://www.orc.soton.ac.uk/ speedoflight.html

[iii] http://www.kehlet.cx/articles/99.html - exemplo de BDP

O que mais afeta diretamente o RTT é a velocidade da sinalização. Veja a progressão da Ethernet ao longo dos tempos: 10M, 100M, 1G, 10G, 40G e 100G. Cada versão a seguir (exceto 40G) é 10x mais rápida que a anterior; o tempo para transmitir um único bit é 1/10 do comprimento. O tempo para transmitir um quadro completo (1500B) cai em um fator de 10.

Portanto, a resposta para sua pergunta depende da camada de link. Se a alteração na largura de banda não tiver alteração correspondente na velocidade do link, ela terá um efeito mínimo no RTT - porque o policiamento de tráfego não é feito por bit . Por exemplo, minha conexão metro-e do escritório é fisicamente 1G, mas é configurada para 100M nas duas extremidades. Os bits fluem a velocidades de 1G; os quadros Ethernet serão atrasados ​​conforme necessário para manter a média (acima de 1s, 10s etc.) igual ou inferior a 100M. Em termos simples, um único quadro transmite na velocidade do link.

Se você está falando sobre DSL, é provável que a mudança na largura de banda também seja uma alteração na velocidade do link. Mas não sempre. A velocidade de sincronização normalmente será maior que a taxa de perfil. Minha linha DSL sincroniza em 8M para baixo, 1M para cima, mas o perfil a limita a 6 / 512k. Vi linhas Uverse sincronizarem até 60M, mas ainda têm um perfil de 25M.

Ninguém mencionou o carregamento do link.

Em links vazios, então não há muita diferença entre 1Mb e 30Mb - a codificação pode ser feita em 1/30 do tempo, mas isso é insignificante se a distância for o fator dominante.

No entanto, se o link de 1Mb estiver muito carregado (sobrecarregado?), Você verá tempos de ping aumentados (e flutuantes).

A mesma carga de tráfego em um link de 30 Mb representa apenas alguns% de sua capacidade e, portanto, os tempos de ping serão mais rápidos e consistentes.

O protocolo de medição ativa bidirecional (TWAMP) define um método flexível para medir o desempenho IP de ida e volta entre dois dispositivos em uma rede que suporta o padrão.

A resposta real é que é complicado.

A latência é composta de vários componentes.

1. Tempo gasto viajando pelo meio físico
2. Tempo gasto em filas
3. Tempo gasto serializando e desserializando dados
4. Tempo gasto no processamento

O tempo gasto viajando pelo meio físico só pode ser alterado com a escolha de um meio físico diferente.

O tempo gasto nas filas geralmente será reduzido com links mais rápidos. Assim será o tempo gasto serializando e desserializando dados.

Os efeitos no processamento podem ser complicados. Se a etapa de processamento permanecer a mesma, geralmente levará menos tempo a uma taxa de dados mais rápida. No entanto, técnicas projetadas para extrair mais largura de banda de links existentes também podem introduzir atrasos adicionais no processamento. Um exemplo clássico disso é a intercalação DSL.