Duże opóźnienia podczas pobierania

Mam ten sam problem z połączeniem biznesowym 5 Mb / s, co w innym poście na tej stronie. Gdy tylko dowolny komputer rozpocznie pobieranie, opóźnienie przy pierwszym przeskoczeniu obok naszego DFG dostarczonego przez naszego usługodawcę internetowego (Bell) znika z listy. Ten pierwszy przeskok jest prawdopodobnie w tym samym budynku i trwa 1 ms, zacznij pobieranie, np. Aktualizację systemu Windows, i przeskoczy do 200-1000 ms.

Spędziłem wiele godzin przy telefonie, mówiąc, że osiągnąłeś maksymalną dostępną przepustowość, to normalne, że opóźnienie wzrasta. Ale moje czytanie mówi mi, że coś psują z TCP. Przeprowadziłem testy na domowym połączeniu Shaw, a nawet na Rogers LTE z pobieraniem i osiąganiem maksymalnej prędkości Mbps dla mojego konta, ale opóźnienie nie przechodzi przez dach.

Czy mam rację, że Bell robi coś, co przełamuje wbudowane technologie TCP, aby zarządzać jego szybkością w oparciu o dostępną przepustowość między 2 punktami końcowymi?

Bell mówi prawdę. Gdy próbujesz wcisnąć 5 Mb / s (lub więcej) do połączenia 5 Mb / s, wszystko jest uporządkowane w małej, uporządkowanej kolejności (czytaj: kolejka). Twoje polecenie ping kończy się bezzwłocznie, ponieważ nie ma zaległości. Odpowiedź znajduje się jednak na końcu kolejki. TCP robi dokładnie to, co powinien - nadawca wypełnia dozwolone okno odbioru.

Są rzeczy, które możesz zrobić po swojej stronie linii (QoS, WRED, itp.), Aby zmniejszyć efekty, ale jest to coś, co zobaczysz, gdy będzie duża różnica między przepustowością nadawcy i odbiorcy. Mieszkałem z tym od lat (T1, DS3 6 Mb / s, a nawet 10 Mb / s cablemodem). Możesz poprosić dostawcę usług internetowych o zmniejszenie rozmiaru kolejki po swojej stronie, ale raczej nie zrobią tego, ponieważ spowoduje to spadek pakietów .

Większość form „QoS” w dzisiejszych czasach nie obejmuje AQM, ponieważ dostawcy mieli trudności z automatyczną konfiguracją RED bez wyrządzania szkody. Prowadzi to do przerażających opóźnień, które widzisz na wielu popularnych urządzeniach, zwłaszcza modemach kablowych i bezprzewodowych. Zatem samo zalecenie „włączenia qos” ... nie pomaga. W rzeczywistości w co najmniej jednym z produktów Netgear włączenie ograniczenia prędkości dla „QoS” prowadzi do znacznie gorszych wyników ...

Ostatnio pojawił się nowy algorytm sprawiedliwego kolejkowania + AQM, który wydaje się działać bardzo dobrze i lepiej, nie wymaga prawie żadnej konfiguracji poza ustawieniem ogranicznika prędkości. Nazywa się fq_codel i jest teraz szeroko dostępny w większości Linuksów, a także został przeniesiony do BSD. Jest to część domyślnego „QoS” w łamaczu barier Openwrt, Cerowrt i Gargoyle używa (całkiem niezłej) wcześniejszej wersji o nazwie sfqred z innowacyjnym systemem automatycznego dostosowywania stawek o nazwie ACC.

Możesz więc zatrzasnąć pole oparte na tym przed swoim niewłaściwie działającym linkiem, włączyć ich ogranicznik szybkości QoS (ustawić nieco poniżej ustawień przychodzących i wychodzących dostawców, aby przejąć kontrolę) + fq_codel i uzyskać znacznie lepszą wydajność dla wszystkich korzystających z niego . Mam na myśli zadziwiająco lepiej: zobacz demo ietf poniżej, raport dla grupy roboczej iccrg w ietf itp.

Aby uzyskać więcej szczegółów na temat problemu z buforowaniem buforu i jego napraw, zobacz:

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

Staramy się (oczywiście) przekonać różnych dostawców ISP CPE, aby zwrócili na to uwagę, podobnie jak cablelabs, który kilka miesięcy temu opublikował wspaniałe studium tych nowych rzeczy, które zawiera również pewne szczegóły dotyczące obecnego niewłaściwego zachowania modemów kablowych.

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

To, co widzisz, jest całkowicie typowe. Wielu dostawców usług ograniczy stawki i / lub użyje mechanizmu QoS w celu obniżenia priorytetu ICMP (w tym tradycyjnego pingowania i traceroute), ponieważ był on czasami wykorzystywany w atakach typu „odmowa usługi”.

Chociaż łącze nie jest przeciążone, obniżony priorytet nie wpływa na nic, ponieważ w kolejce nie ma ruchu. W tych okresach opóźnienie pozostaje niskie, ponieważ pakiety ICMP będą natychmiast przekazywane i nie będą w ogóle opóźniane.

Gdy łącze jest przepełnione, kolejki o wyższym priorytecie zyskują większą uwagę. W zależności od mechanizmu kolejkowania może przekazywać wiele pakietów z kolejki o wyższym priorytecie dla każdego pakietu z kolejki o niższym priorytecie lub nawet przekazywać dalej tylko wtedy, gdy w kolejce o wyższym priorytecie nie ma nic. W każdym przypadku pakiet przeniesiony do kolejki o niższym priorytecie będzie na ogół wstrzymywany dłużej niż na łączu bez przeciążenia, co zwiększa opóźnienie.

Prawdopodobnie cierpisz na buforowanie i chcesz AQM (Active Queue Management). Napisałem skrypt dla Linuksa, który sprawia, że ​​jest to dość łatwe:

#!/bin/bash
# Traffic shaping script (AQM, fq_codel+tbf)
# Copyright 2018 Mikko Rantalainen <mikko.rantalainen@gmail.com>
# 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

Po prostu zapisujesz skrypt jako „ traffic-shapingi” chmod a+xi uruchamiasz go jako root (po przeczytaniu kodu źródłowego, oczywiście).

Proponuję dla twojego przypadku użycia

DOWNLINK_RATE=5.0Mbit UPLINK_RATE=5.0Mbit TBF_LATENCY=500ms ./traffic-shaping start