Os Efeitos da Latência no Throughput

posted in Networking on by

Ainda me lembro quando em 2009 me foi passada a responsabilidade de validar um link de internet via satélite de 16Mbps. Naquela altura era buéeee xe!

O meu espanto foi que por mais speedtests e downloads que eu fizesse simplesmente não consegui saturar o link e lá ia eu reclamar com o provedor.

Até que um jovem muito paciente me explicou: “É satélite Mário, a latência é muito alta, tens que fazer vários downloads ou utilizar um acelerador”

E assim, pela primeira vez fiquei a saber que links de elevada latência como é o caso de satélite (ping ~ 500-600ms) têm influência não só em comunicação realtime como voz/video em que a outra pessoa parece que está bêbada, mas também têm influência no throughput: a velocidade.

Passemos à verificação…

Para testar, utilizei 2 servidores virtuais Linux Lubuntu iguais (clonados) e o iperf3.

O iperf3 é um utilitário excelente para testar throughput, perdas, delay, jitter, etc. Está repleto de opções e permite alterar tamanho de buffer, tamanho de pacotes, protocolo TCP/UDP, número de conexões… demais!

As VM foram conectadas directamente a uma Virtualbox Host-only Network.

Nota Importate: Em todos os casos o delay apresentado é round-trip, ou seja, de ida e volta.

Delay ~ 0

Para o primeiro teste consideramos o delay aproximado a 0 como pode ser visto abaixo.

---------------------------------------------------------
mario@lubuntu3:~$ ping -c10 -i0.2 lubuntu2
 PING lubuntu2 (192.168.56.2) 56(84) bytes of data.
 --- lubuntu2 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1811ms
 rtt min/avg/max/mdev = 0.370/0.613/0.716/0.103 ms

mario@lubuntu2:~$  ping -c10 -i0.2 lubuntu3
 PING lubuntu3 (192.168.56.3) 56(84) bytes of data.
 --- lubuntu3 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1821ms
 rtt min/avg/max/mdev = 0.522/0.647/0.751/0.075 ms
---------------------------------------------------------

Validado que está o delay entre os hosts, habilitamos o servidor iperf na VM lubuntu3. Este será o servidor e portanto fará o download de dados do cliente a menos que seja configurada a opção –reverse.

-----------------------------------------------------------
 mario@lubuntu3:~$ iperf3 --server
 -----------------------------------------------------------
 Server listening on 5201
 -----------------------------------------------------------

O teste com uma sessão TCP de 30 segundos e configurações padrão apresenta excelentes resultados:

mario@lubuntu2:~$ iperf3  --time 30 --interval 0 --omit 1 --client  lubuntu3
 Connecting to host lubuntu3, port 5201
 [  4] local 192.168.56.2 port 51230 connected to 192.168.56.3 port 5201
 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
 [  4]   0.00-30.00  sec  8.58 GBytes  2.46 Gbits/sec  61531    191 KBytes
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec  8.58 GBytes  2.46 Gbits/sec  61531             sender
 [  4]   0.00-30.00  sec  8.59 GBytes  2.46 Gbits/sec                  receiver
 iperf Done.

O que vemos no resultado são 2.46 Gbps reportados tanto pelo cliente como pelo servidor para tráfego no sentido lubuntu2>lubuntu3 (cliente>servidor)

Para o sentido inverso:

mario@lubuntu2:~$ iperf3  --time 30 --interval 0 --omit 1 --client  lubuntu3 --reverse
 Connecting to host lubuntu3, port 5201
 Reverse mode, remote host lubuntu3 is sending
 [  4] local 192.168.56.2 port 51234 connected to 192.168.56.3 port 5201
 [ ID] Interval           Transfer     Bandwidth
 [  4]   0.00-30.00  sec  8.09 GBytes  2.32 Gbits/sec
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec  8.09 GBytes  2.32 Gbits/sec  53872             sender
 [  4]   0.00-30.00  sec  8.09 GBytes  2.32 Gbits/sec                  receiver
 iperf Done.
 ---------------------------------------------------

Por alguma razão o teste no sentido inverso (servidor>cliente, lubuntu3>lubuntu2) é sempre reportado menor, 2,32Gbps.

Delay +10ms

A seguir, adicionamos um delay assim “de leve”, 10ms.

mario@lubuntu3:~$ ping -c10 -i0.2  lubuntu2
 PING lubuntu2 (192.168.56.2) 56(84) bytes of data.
 64 bytes from lubuntu2 (192.168.56.2): icmp_seq=1 ttl=64 time=11.2 ms
...
 64 bytes from lubuntu2 (192.168.56.2): icmp_seq=10 ttl=64 time=11.0 ms
 --- lubuntu2 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1810ms
 rtt min/avg/max/mdev = 10.836/11.303/11.980/0.323 ms

mario@lubuntu2:~$  ping -c10 -i0.2  lubuntu3
 PING lubuntu3 (192.168.56.3) 56(84) bytes of data.
 64 bytes from lubuntu3 (192.168.56.3): icmp_seq=1 ttl=64 time=11.1 ms
...
 64 bytes from lubuntu3 (192.168.56.3): icmp_seq=10 ttl=64 time=11.3 ms
 --- lubuntu3 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1808ms
 rtt min/avg/max/mdev = 10.679/11.137/11.714/0.309 ms

Os resultados do teste TCP já permitem ver uma considerável baixa de velocidade.

mario@lubuntu2:~$ iperf3  --time 30 --interval 0 --omit 1 --client  lubuntu3
 Connecting to host lubuntu3, port 5201
 [  4] local 192.168.56.2 port 51238 connected to 192.168.56.3 port 5201
 [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
 [  4]   0.00-30.00  sec  1.29 GBytes   370 Mbits/sec  446    547 KBytes
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec  1.29 GBytes   370 Mbits/sec  446             sender
 [  4]   0.00-30.00  sec  1.30 GBytes   371 Mbits/sec                  receiver
 iperf Done.

mario@lubuntu2:~$ iperf3  --time 30 --interval 0 --omit 1 --client  lubuntu3 --reverse
 Connecting to host lubuntu3, port 5201
 Reverse mode, remote host lubuntu3 is sending
 [  4] local 192.168.56.2 port 51242 connected to 192.168.56.3 port 5201
 [ ID] Interval           Transfer     Bandwidth
 [  4]   0.00-30.00  sec   853 MBytes   238 Mbits/sec
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec   854 MBytes   239 Mbits/sec  463             sender
 [  4]   0.00-30.00  sec   853 MBytes   239 Mbits/sec                  receiver
 iperf Done.

Com um delay ~10ms temos 370Mbps (cliente>servidor) e 239Mbps (servidor>cliente).

 

Delay = 30ms

Para o teste seguinte adicionamos 29ms para ter em média 30ms. O equivalente a um link inter-provincial de fibra óptica.

 --- lubuntu2 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1812ms
 rtt min/avg/max/mdev = 29.754/30.038/30.187/0.219 ms

 --- lubuntu3 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1811ms
 rtt min/avg/max/mdev = 29.556/29.994/30.331/0.330 ms

O resultado dos testes TCP:

mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec  1.13 GBytes   323 Mbits/sec   90             sender
 [  4]   0.00-30.00  sec  1.13 GBytes   324 Mbits/sec                  receiver
 iperf Done.

mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3 -R
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec   304 MBytes  84.9 Mbits/sec  181             sender
 [  4]   0.00-30.00  sec   304 MBytes  85.1 Mbits/sec                  receiver
 iperf Done.

Mais uma vez, redução: 323Mbps e 85Mbps.

Delay 150ms

 --- lubuntu3 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1804ms
 rtt min/avg/max/mdev = 149.677/150.130/150.410/0.382 ms

Resultado testes TCP

 mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec   487 MBytes   136 Mbits/sec  467             sender
 [  4]   0.00-30.00  sec   489 MBytes   137 Mbits/sec                  receiver
 iperf Done.

mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3 -R
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec   115 MBytes  32.2 Mbits/sec  630             sender
 [  4]   0.00-30.00  sec   115 MBytes  32.1 Mbits/sec                  receiver
 iperf Done.

Delay 550ms

Chegamos então aos 550ms, um valor equivalente a uma ligação via satélite geoestacionário.

 --- lubuntu3 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 1811ms
 rtt min/avg/max/mdev = 549.841/550.164/550.638/0.846 ms

TCP Test

 mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec   124 MBytes  34.7 Mbits/sec    0             sender
 [  4]   0.00-30.00  sec   123 MBytes  34.5 Mbits/sec                  receiver
 iperf Done.

mario@lubuntu2:~$ iperf3 -t 30 -i 0 -O 1 -c  lubuntu3 -R
 - - - - - - - - - - - - - - - - - - - - - - - - -
 [ ID] Interval           Transfer     Bandwidth       Retr
 [  4]   0.00-30.00  sec  39.4 MBytes  11.0 Mbits/sec  390             sender
 [  4]   0.00-30.00  sec  37.2 MBytes  10.4 Mbits/sec                  receiver
 iperf Done.

Claramente, não se pode esperar grandes velocidades de um link de satélite a menos que se utilize alguma forma de optimização TCP ou caching – 34,5 Mbps e 10,7 Mbps.

Sumário

Nada melhor que um gráfico excel para sumarizar tantos números.

Throughput vs. Latência 1

Para melhor perceber o impacto, segue de novo o gráfico sem o 1º teste com latência inferior a 1ms.

Throughput vs. Latência 2

Se não estava convencido antes, com este gráfico está certamente. Infelizmente não encontrei qualquer relação linear entre a baixa de throughput e a subida da latência nem da relação entre os sentidos do tráfego (a diferença entre o upload e o download). Assunto para um próximo post talvez… não era o objectivo entrar nas “matemáticas”

Mas porquê?

Por que a latência influencia na velocidade de transferência num sentido? Porque um download ou upload TCP a comunicação nunca é realmente em um único sentido.

TCP é um protocolo considerado fiável (reliable) e para tal, o lado que recebe os dados precisa de enviar regularmente pacotes confirmando a recepção de pacotes anteriores. Quem envia precisa de receber estas confirmações (chamados acknowledgements). Se considerarmos que os links raramente são perfeitos (têm perdas) os efeitos destas imperfeições têm um impacto maior quanto maior for a latência da ligação, pois os hosts perdem mais tempo a tentar entender-se e à espera das tão importantes confirmações.

Há solução?

Como visto em um artigo passado, a menos que a sua latência seja causada por algum equipamento barato ou saturação, não há como reduzir a latência. Mas há formas de tornar a vida um pouco melhor:

  • Caching
  • Optimização/Aceleração TCP
  • Paralelização de sessões TCP para uma mesma transferência

Já ouviu falar do Cisco WAAS, CacheFlow e Riverbed?? É aí que eles entram.

————

Host Tuning Background Information
http://fasterdata.es.net/host-tuning/background/

Minimizing Latency in Satellite Networks
http://www.satellitetoday.com/telecom/2009/09/01/minimizing-latency-in-satellite-networks/

Host Tuning
http://fasterdata.es.net/host-tuning/

Network Tuning
http://fasterdata.es.net/network-tuning/

TCP Throughput Calculator
https://www.switch.ch/network/tools/tcp_throughput/

IPerf3 Download
https://iperf.fr/iperf-download.php

IPerf2/3 Basic Commands
https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/

http://software.internet2.edu/owamp/

 

3 Comments → Os Efeitos da Latência no Throughput

  1. Mauro Pedro

    Boas Mario,
    Muito bom artigo é a primeira vez que me apercebo desse site. Keep up the good work.
    Mauro Aldair Pedro.

    Reply ↓

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *