Висока затримка під час завантаження

У мене є той самий випуск у моєму бізнес-підключенні 5 Мбіт / с, як і в іншій публікації на цьому сайті. Як тільки будь-який комп’ютер запускає затримку завантаження під час першого переходу через наш DFG, наданий нашим Інтернет-провайдером (Bell), виходить із діаграми. Цей перший скачок, ймовірно, в нашій самій будівлі і становить 1 мс постійно, почніть завантаження, наприклад, оновлення Windows, і він підскакує до 200-1000 мс.

Я проводив години по телефону з підтримкою, все говорив, що ви досягли максимальної доступної пропускної здатності, це нормально, коли ваша затримка зростає. Але моє читання говорить про те, що вони щось порушують з TCP. Я провів тести на домашньому з’єднанні Shaw і навіть на Rogers LTE, який виконує завантаження та досягає максимального Мбіт / с для мого облікового запису, але затримка не проходить через дах.

Чи правильно я розумію, що Белл робить щось для того, щоб зламати вбудовані технології TCP для управління його швидкістю на основі наявної пропускної здатності між двома кінцевими точками?

Белл говорить тобі правду. Коли ви намагаєтесь підштовхнути 5 Мбіт / с (або більше) до з'єднання 5 Мбіт / с, все перетворюється в акуратний маленький порядок (читайте: черга.) Ваш ping вимикається негайно, оскільки немає відставання. Однак відповідь зараз знаходиться в кінці черги. TCP робить саме те, що тут потрібно - відправник заповнює вікно дозволеного прийому.

З вашої сторони лінії ви можете виконати речі (QoS, WRED тощо), щоб зменшити ефекти, але це таке, що ви побачите, коли велика різниця між пропускною здатністю відправника та приймача. Я жив з цим роками (T1, 6Mbps DS3, навіть 10Mbps кабельний модем) Ви можете попросити провайдера зменшити розмір черги на їх стороні, але вони, швидше за все, не зроблять це, оскільки це призведе до падіння пакетів .

У більшості форм "QoS" в наші дні не входить AQM, оскільки постачальникам було важко автоматично налаштувати RED, не завдаючи шкоди. Це призводить до жахливих затримок, які спостерігаються на багатьох поширених сьогодні пристроях, зокрема кабельних модемах та бездротових. Тому просто рекомендувати "ввімкнути qos" ... не допомагає. Насправді принаймні один із продуктів Netgear включення обмежувача ставок для "QoS" призводить до значно гірших результатів ....

Нещодавно з'явився новий чесний черговий + алгоритм AQM, який, здається, працює надзвичайно добре, а ще краще, що не вимагає майже ніякої конфігурації, крім встановлення обмежувача швидкості. Він називається fq_codel, і зараз він широко доступний у більшості Linux, а також переноситься на BSD. Це частина типового "QoS" у openwrt бар'єрному вимикачі, cerowrt і gargoyle використовує (досить непогану) більш ранню версію під назвою sfqred з інноваційною схемою автоматичного регулювання швидкості під назвою ACC.

Таким чином, ви можете заграти в поле перед цим посиланням, яке не поводиться, увімкнути їх обмежувач швидкості QoS (встановіть трохи нижче налаштувань вхідних та вихідних даних ваших провайдерів, щоб ви взяли під контроль) + fq_codel, і отримаєте набагато кращі показники для всіх, хто його використовує . Я маю на увазі приголомшливо краще: дивіться демонстрацію ietf нижче, звіт робочої групи iccrg в ietf тощо.

Детальніше про проблему із буферним блоком та виправлення для нього див.

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

Ми (звичайно) намагаємось переконати різних постачальників ISP CPE звернути увагу, як і кабельні лабораторії, які опублікували чудове дослідження цього нового матеріалу за кілька місяців тому, що також містить деяку деталь щодо поточної недоброзичливої ​​поведінки кабельних модемів, зокрема.

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

Те, що ви бачите, цілком типове. Багато постачальників послуг встановлюють обмеження та / або використовують механізм QoS, щоб знизити пріоритет ICMP (який включає традиційний ping та traceroute), оскільки він використовувався у випадках відмови в атаках на послуги.

Хоча посилання не перевантажена, понижений пріоритет нічого не впливає, оскільки трафік не ставиться в чергу. У ці періоди ваша затримка залишається низькою, тому що пакети ICMP будуть передані негайно і зовсім не затримуються.

Коли посилання перевантажено, черги з вищим пріоритетом приділяють більше уваги. Залежно від механізму черги, він може пересилати кілька пакетів з черги вищого пріоритету для кожного пакету з черги з нижчим пріоритетом або навіть вперед лише тоді, коли в черзі з вищим пріоритетом немає нічого. У будь-якому випадку, пакет, відведений до черги з нижчим пріоритетом, як правило, буде утримуватися довше, ніж на посиланні без перевантажень, збільшуючи затримку.

Ви, мабуть, страждаєте від буферного блоку і вам потрібно AQM (Активне керування чергою). Я написав сценарій для Linux, що робить це досить просто:

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

Ви просто зберігаєте сценарій як traffic-shapingі chmod a+xйого і запускаєте його як корінь (очевидно, прочитавши вихідний код).

Для вашого випадку використання я пропоную

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