Hohe Latenz beim Herunterladen

Ich habe das gleiche Problem mit meiner Geschäftsverbindung mit 5 Mbit / s wie in einem anderen Beitrag auf dieser Website. Sobald ein Computer einen Download startet, verschwindet die Latenz beim ersten Sprung nach unserer DFG, die von unserem ISP (Bell) bereitgestellt wird. Dieser erste Sprung befindet sich wahrscheinlich in demselben Gebäude und dauert 1 ms. Starten Sie einen Download, z. B. ein Windows-Update, und er springt auf 200-1000 ms.

Ich habe stundenlang mit Support telefoniert und alle gesagt, dass Sie die maximal verfügbare Bandbreite erreicht haben. Es ist normal, dass Ihre Latenz ansteigt. Aber meine Lektüre sagt mir, dass sie etwas mit TCP brechen. Ich habe Tests auf einer Heim-Shaw-Verbindung und sogar auf einem Rogers LTE durchgeführt, auf dem Downloads ausgeführt wurden und die maximale Mbit / s für mein Konto erreicht wurden, aber die Latenz geht nicht über das Dach.

Habe ich recht, wenn ich verstehe, dass Bell etwas unternimmt, um die integrierten Technologien von TCP zu brechen und die Rate basierend auf der verfügbaren Bandbreite zwischen den beiden Endpunkten zu verwalten?

Bell sagt dir die Wahrheit. Wenn Sie versuchen, 5 Mbit / s (oder mehr) in eine 5-Mbit / s-Verbindung zu übertragen, werden alle Dateien in einer ordentlichen kleinen Reihenfolge (sprich: Warteschlange) abgelegt. Ihr Ping wird ohne Verzögerung gelöscht, da kein Rückstand vorliegt. Die Antwort befindet sich jetzt jedoch am Ende der Warteschlange. TCP macht genau das, was es hier tun soll - der Absender füllt das erlaubte Empfangsfenster.

Es gibt Dinge, die Sie auf Ihrer Seite der Leitung tun können (QoS, WRED usw.), um die Auswirkungen zu verringern, aber so etwas werden Sie sehen, wenn es einen großen Unterschied zwischen Sender- und Empfängerbandbreite gibt. Ich habe jahrelang damit gelebt (T1, 6 Mbit / s DS3, sogar 10 Mbit / s Kabelmodem). Sie könnten den ISP bitten, die Warteschlangengröße auf seiner Seite zu reduzieren, aber es ist unwahrscheinlich, dass sie dies tun, da dies zu Paketverlusten führen wird .

Die meisten Formen von "QoS" enthalten heutzutage kein AQM, da es für Anbieter zu schwierig war, RED automatisch zu konfigurieren, ohne Schaden zu verursachen. Dies führt zu den entsetzlichen Verzögerungen, die heutzutage bei vielen gängigen Geräten auftreten, insbesondere bei Kabelmodems und drahtlosen Geräten. Es hilft also nicht, nur "Qos einschalten" zu empfehlen. Tatsächlich führt das Einschalten des Ratenbegrenzers für "QoS" bei mindestens einem der Netgear-Produkte zu erheblich schlechteren Ergebnissen.

Kürzlich ist ein neuer fairer Warteschlangen- + AQM-Algorithmus erschienen, der anscheinend sehr gut funktioniert und besser fast keine Konfiguration außer dem Einstellen des Ratenbegrenzers erfordert. Es heißt fq_codel und ist mittlerweile in den meisten Linux-Versionen weit verbreitet und wurde auch auf BSD portiert. Es ist Teil der Standard- "QoS" in OpenWRT Barrier Breaker, Cerowrt und Gargoyle. Es verwendet eine (ziemlich gute) frühere Version namens sfqred mit einem innovativen automatischen Ratenanpassungsschema namens ACC.

Sie können also eine darauf basierende Box vor Ihrem fehlerhaften Link zuschlagen, den QoS-Ratenbegrenzer (der nur geringfügig unter den Einstellungen für eingehende und ausgehende Nachrichten Ihres Anbieters liegt, damit Sie die Kontrolle übernehmen) + fq_codel aktivieren und für alle Benutzer eine viel bessere Leistung erzielen . Ich meine erstaunlich besser: siehe die ietf-Demo unten, den Bericht an die iccrg-Arbeitsgruppe am ietf usw.

Weitere Informationen zum Bufferbloat-Problem und den Korrekturen dafür finden Sie unter:

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

Wir versuchen (natürlich), verschiedene ISP-CPE-Anbieter davon zu überzeugen, aufmerksam zu sein, ebenso wie Cablelabs, die vor einigen Monaten eine wunderbare Studie über dieses neue Material veröffentlicht haben, die auch einige Details zum aktuellen Fehlverhalten von Kabelmodems enthält.

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

Was Sie sehen, ist völlig typisch. Viele Dienstanbieter werden das Limit bewerten und / oder einen QoS-Mechanismus verwenden, um die Priorität von ICMP (einschließlich herkömmlichem Ping und Traceroute) zu senken, wie es zeitweise bei Denial-of-Service-Angriffen verwendet wurde.

Während eine Verbindung nicht überlastet ist, wirkt sich die verringerte Priorität auf nichts aus, da kein Datenverkehr in die Warteschlange gestellt wird. Während dieser Zeit bleibt Ihre Latenz gering, da die ICMP-Pakete sofort weitergeleitet und nicht verzögert werden.

Wenn die Verbindung überlastet ist, erhalten Warteschlangen mit höherer Priorität mehr Aufmerksamkeit. Abhängig vom Warteschlangenmechanismus werden möglicherweise mehrere Pakete aus einer Warteschlange mit höherer Priorität für jedes Paket aus einer Warteschlange mit niedrigerer Priorität oder sogar nur dann weitergeleitet, wenn sich in einer Warteschlange mit höherer Priorität nichts befindet. In jedem Fall wird ein Paket, das in eine Warteschlange mit niedrigerer Priorität verwiesen wird, im Allgemeinen länger zurückgehalten als auf einer Verbindung ohne Überlastung, was die Latenz erhöht.

Sie leiden wahrscheinlich unter Bufferbloat und möchten AQM (Active Queue Management). Ich habe ein Skript für Linux geschrieben, das dies ziemlich einfach macht:

#!/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

Sie speichern das Skript einfach als traffic-shapingund chmod a+xund führen es als root aus (natürlich nach dem Lesen des Quellcodes).

Für Ihren Anwendungsfall würde ich vorschlagen

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