Alta latência durante downloads

9

Estou com o mesmo problema na minha conexão comercial de 5 Mbps que em outra postagem neste site. Assim que qualquer computador inicia um download, a latência no primeiro salto após o DFG fornecido pelo nosso ISP (Bell) fica fora do gráfico. Esse primeiro salto provavelmente ocorre em nosso mesmo prédio e dura 1ms constantemente, inicia um download, por exemplo, atualização do Windows e salta para 200-1000ms.

Passei horas no telefone com suporte, dizendo que você alcançou a largura de banda máxima disponível; é normal que sua latência aumente. Mas minha leitura me diz que eles estão quebrando algo com o TCP. Eu executei testes em uma conexão Shaw doméstica e até mesmo em um Rogers LTE executando downloads e atingindo o Mbps máximo para minha conta, mas a latência não passa do limite.

Estou certo de que Bell está fazendo algo para interromper as tecnologias internas da TCP para gerenciar sua taxa com base na largura de banda disponível entre os dois pontos finais?

Stunpals
fonte
Alguma resposta o ajudou? Nesse caso, você deve aceitar a resposta para que a pergunta não apareça para sempre, procurando uma resposta. Como alternativa, você pode fornecer e aceitar sua própria resposta.
Ron Maupin

Respostas:

12

Bell está dizendo a verdade. Quando você tenta colocar 5Mbps (ou mais) em uma conexão de 5Mbps, tudo é arquivado em uma ordem pequena e simples (leia-se: fila.) Seu ping sai sem demora porque não há atrasos. A resposta, no entanto, está agora no final da fila. O TCP está fazendo exatamente o que deveria fazer aqui - o remetente está preenchendo a janela de recebimento permitida.

Há coisas que você pode fazer do seu lado da linha (QoS, WRED etc.) para ajudar a reduzir os efeitos, mas esse é o tipo de coisa que você verá quando houver uma grande diferença entre a largura de banda do remetente e do receptor. Eu moro com ele há anos (T1, 6Mbps DS3 e até 10Mbps de cabo) Você pode pedir ao ISP para reduzir o tamanho da fila do lado deles, mas é pouco provável que o façam, pois isso resultará em queda de pacotes .

Ricky Beam
fonte
4
200-1000ms (85-420 pacotes, 1500B @ 5Mbps) está no domínio en.wikipedia.org/wiki/Bufferbloat , pois o TCP depende da perda de pacotes para definir corretamente e rapidamente o tamanho da janela, deve ser ganho líquido para reduzi-lo a talvez 10 pacotes (25ms). Concordo plenamente que é improvável que o operador altere isso em seu produto, a menos que muitos clientes se queixem, provavelmente mais fácil pedir apenas um produto de QoS para a conexão comercial, ele deve ter valores de buffer mais saudáveis ​​e solicitáveis ​​às demandas dos clientes. Curiosamente, o QUIC do Google pode opcionalmente diminuir a taxa de transmissão quando a latência começa a subir.
ytti
Obrigado Ricky, eu ouvi o que você está dizendo, mas depois de mais leituras, o Flow Control do TCP não deve ver a lista de pendências e ajustar a janela à taxa que o receptor pode suportar? Assim, não sobrecarregando o cliente ou roteador (s) (salto 2 na rede Bells) ao longo do caminho? Para mim, parece que sua referência ao bufferbloat que também li descreve o cenário exatamente.
Stunpals
3
O TCP não pode detectar nenhum gargalo sem a queda de pacotes (ou ECN.) Se as filas do roteador forem profundas o suficiente e sua janela de recebimento for grande o suficiente, você poderá criar um grande atraso. Os carimbos de data e hora RFC1323 podem ajudar, mas vi problemas significativos ao permitir que o Windows "use" o TS. (ele tenta "negociar" o TS enviando um TS inicial = 0)
Ricky Beam
4

A maioria das formas de "QoS" hoje em dia não inclui o AQM, pois os fornecedores acham muito difícil configurar o RED automaticamente, sem causar danos. Isso leva a atrasos horrendos que você vê em muitos dispositivos comuns hoje, principalmente modems a cabo e sem fio. Portanto, apenas recomendar "ativar qos" ... não ajuda. De fato, em pelo menos um dos produtos da Netgear, ativar o limitador de taxa para "QoS" leva a resultados muito piores.

Recentemente, um novo algoritmo de enfileiramento justo + AQM parece funcionar extremamente bem, e melhor, requer quase nenhuma configuração além de definir o limitador de taxa. Ele se chama fq_codel, e agora está amplamente disponível na maioria dos Linuxs e também foi portado para o BSD. Ele faz parte do "QoS" padrão no disjuntor de barreira openwrt, cerowrt e gargoyle usa uma (muito boa) versão anterior chamada sfqred com um inovador esquema de ajuste automático de taxa chamado ACC.

Assim, você pode bater uma caixa com base nisso na frente do seu link com comportamento inadequado, ativar o limitador de taxa de QoS (definido um pouco abaixo das configurações de entrada e saída dos provedores para que você assuma o controle) + fq_codel e obter um desempenho muito melhor para todos que o usam . Quero dizer incrivelmente melhor: veja a demonstração da ietf abaixo, o relatório para o grupo de trabalho iccrg na ietf, etc.

Para obter mais detalhes sobre o problema do bufferbloat e as correções, consulte:

http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos

Estamos (é claro) tentando convencer vários fornecedores de ISP CPE a prestarem atenção, assim como o cablelabs, que publicou um estudo maravilhoso sobre esse novo material há alguns meses, que também contém alguns detalhes sobre o mau comportamento atual dos modems a cabo em particular.

http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf

Dave Taht
fonte
1

O que você está vendo é inteiramente típico. Muitos provedores de serviços classificarão o limite e / ou usarão um mecanismo de QoS para diminuir a prioridade do ICMP (que inclui ping e traceroute tradicionais), pois ele às vezes é usado em ataques de negação de serviço.

Embora um link não esteja congestionado, a prioridade reduzida não afeta nada, pois não há tráfego na fila. Durante esses períodos, sua latência permanece baixa porque os pacotes ICMP serão encaminhados imediatamente e não sofrerão atrasos.

Quando o link está congestionado, as filas de prioridade mais alta recebem mais atenção. Dependendo do mecanismo de enfileiramento, ele pode encaminhar vários pacotes de uma fila de prioridade mais alta para cada pacote de uma fila de prioridade mais baixa ou até encaminhar apenas quando não houver nada em uma fila de prioridade mais alta. De qualquer forma, um pacote relegado para uma fila de prioridade mais baixa geralmente será retido por mais tempo do que em um link sem congestionamento, aumentando a latência.

YLearn
fonte
11
Obrigado YLearn pela sua resposta. Eu recebo a prioridade do ICMP, mas podemos ver outro tráfego afetado e o ICMP foi apenas para ilustrar o problema. Enquanto eu tentava transmitir a Ricky, no meu comentário o Flow Control é o motivo pelo qual o TCP funciona, pois qualquer remetente com uma largura de banda maior que o receptor o levaria para o DOS offline se o Flow Control não estivesse funcionando corretamente. É por isso que uma conexão discada pode se comunicar com uma conexão de 1000 Mbps? Estou pensando errado, se as coisas estão funcionando com a latência adequada dos padrões durante a transferência de arquivos, mantêm um nível resonalble e não passam do limite?
Stunpals
1

Você provavelmente está sofrendo de bufferbloat e deseja o AQM (Active Queue Management). Eu escrevi um script para Linux que facilita bastante isso:

#!/bin/bash
# Traffic shaping script (AQM, fq_codel+tbf)
# Copyright 2018 Mikko Rantalainen <[email protected]>
# License: MIT (X11)
# Usage:
#   21/0.8 Mbps connection (ADSL2): DOWNLINK_RATE=21.7Mbit UPLINK_RATE=0.8Mbit TBF_LATENCY=500ms bin/traffic-shaping start
#   100/100 Mbps connection: ./traffic-shaping
#   1/1 GBps connection: DOWNLINK_RATE=1Gbit UPLINK_RATE=1Gbit TBF_LATENCY=10ms bin/traffic-shaping start
# Note that using low TBF_LATENCY will require powerful CPU.
#   

set -e

DEV="${DEV:=$(ip route | grep "^default " | grep -Po "(?<=dev )[^ ]+")}"

# ingress:
DOWNLINK_RATE="${DOWNLINK_RATE:=104000kbit}" # or e.g. "21.5Mbit"
# egress:
UPLINK_RATE="${UPLINK_RATE:=105000kbit}"

CODEL_INTERVAL="${CODEL_INTERVAL:=100ms}" # usually 100ms, high speed links with low latency may need lower values
CODEL_TARGET="${CODEL_TARGET:=5ms}" # unit "us" is also available, usually 5%-10% of CODEL_INTERVAL
CODEL_LIMIT="${CODEL_LIMIT:=1001}" # decrease to reduce latency, too low values will limit throughput
CODEL_FLOWS="${CODEL_FLOWS:=1024}"

# set burst as high as possible without causing dropped packets at the start of the connections
DOWNLINK_BURST="${DOWNLINK_BURST:=6500}"
UPLINK_BURST="${UPLINK_BURST:=6500}"

TBF_LATENCY="${TBF_LATENCY:=14ms}" # set to lower latency to improve control over bandwidth limiting, UPLINK_BURST bytes must be able to be sent in this time

IFB="$DEV.ingress"

INITCWND="${INITCWND:=20}"
INITRWND="${INITRWND:=20}"

configure_shaping()
{
    # EGRESS (outgoing traffic, "uploads"):

    # setup bandwidth limiting:
    tc qdisc add dev "$DEV" root handle 1: tbf rate "$UPLINK_RATE" burst "$UPLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$DEV" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" noecn


    # INGRESS (incoming traffic, "downloads"):

    # setup bandwidth limiting (ingress limiting needs IFB or Intermediate Functional Block, see https://wiki.linuxfoundation.org/networking/ifb):
    tc qdisc add dev "$DEV" handle ffff: ingress
    ip link add name "$IFB" type ifb
    tc qdisc add dev "$IFB" root handle 1: tbf rate "$DOWNLINK_RATE" burst "$DOWNLINK_BURST" latency "$TBF_LATENCY"

    # setup fq_codel for bandwidth shaping
    tc qdisc add dev "$IFB" parent 1: fq_codel limit "$CODEL_LIMIT" target "$CODEL_TARGET" interval "$CODEL_INTERVAL" flows "$CODEL_FLOWS" ecn
    ip link set dev "$IFB" up

    # connect ingress filtering to actual WAN device
    tc filter add dev "$DEV" parent ffff: protocol all prio 10 u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev "$IFB"

    # configure initcwnd and initrwnd
    ip route change $(ip route | grep ^default) initcwnd "$INITCWND" initrwnd "$INITRWND"
}

remove_shaping()
{
    tc qdisc list | grep -q "ingress" && tc qdisc del dev "$DEV" ingress || true
    tc qdisc list | grep -q "codel" && tc qdisc del dev "$DEV" root || true
    ip link show | grep -q "$IFB" && ip link del "$IFB" || true
}

status()
{
        echo "─── queue discipline configuration: ──────────────────"
        tc qdisc list
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV ingress' to remove ingress filtering"
        echo "   TIP: use e.g. 'sudo tc qdisc del dev $DEV root' to remove egress filtering"
        echo "─── ip link show: ────────────────────────────────────"
        ip link show
        echo "   TIP: use e.g. 'sudo ip link del $IFB' to remove ingress device"
}

color_status()
{
    status | grep --color=auto -E "^|$DEV|$IFB|rate [^ ]+"
}

# handle parameters

ACTION="$1"
shift || true

while [ ! -z "$1" ]
do
    case "$1" in
        -v|--verbose)
            echo "Device: $DEV"
            echo "Downlink rate (ingress): $DOWNLINK_RATE"
            echo "Uplink rate (egress): $UPLINK_RATE"
            set -x
            ;;
        *)
            if [ ! -z "$2" ]; then
                echo "Unknown parameter: '$2'" 1>&2
                exit 1
            fi
            ;;
    esac
    shift
done

case "$ACTION" in
    start)
        remove_shaping
        configure_shaping
        ;;
    stop)
        remove_shaping
        ;;
    status)
        color_status
        ;;
    restart)
        remove_shaping
        configure_shaping
        ;;
    *)
        echo "Unknown action: $1" 1>&2
        echo "Usage: $0 <start|stop|restart|status> [--verbose|-v]" 1>&2
        exit 1
esac

Você simplesmente salva o script como traffic-shapinge chmod a+xo executa como root (depois de ler o código fonte, obviamente).

Para o seu caso de uso, sugiro

DOWNLINK_RATE=5.0Mbit UPLINK_RATE=5.0Mbit TBF_LATENCY=500ms ./traffic-shaping start
Mikko Rantalainen
fonte
Veja também: bufferbloat.net/projects/codel/wiki/…
Mikko Rantalainen
Note que você pode precisar executar o linux-lowlatencykernel para manter o sistema com a tarefa de processar todos os pacotes.
Mikko Rantalainen
Veja também: apenwarr.ca/log/20110110
Mikko Rantalainen 5/19/19
Veja também: jfcarter.net/~jimc/documents/voip-qos-1609.html
Mikko Rantalainen