Высокая задержка при загрузке

У меня та же проблема с моей бизнес-связью 5 Мбит / с, что и при другой публикации на этом сайте. Как только любой компьютер начинает загрузку, задержка первого скачка после нашего DFG, предоставляемого нашим провайдером (Bell), выходит за пределы графика. Этот первый прыжок, скорее всего, находится в том же здании и составляет 1 мс постоянно, начните загрузку, например, обновление Windows, и он скачет до 200-1000 мс.

Я часами разговаривал по телефону со службой поддержки, и все говорили, что вы достигли максимально возможной пропускной способности, поэтому время задержки может возрасти. Но мое чтение говорит мне, что они что-то ломают с TCP. Я провел тесты на домашнем соединении Shaw и даже на Rogers LTE, выполняющем загрузку и достигающем максимальной скорости передачи данных для моей учетной записи, но задержка не выходит за рамки.

Правильно ли я понимаю, что Белл что-то делает, чтобы сломать встроенные технологии TCP для управления скоростью на основе доступной пропускной способности между двумя конечными точками?

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

Есть некоторые вещи, которые вы можете сделать на своей стороне линии (QoS, WRED и т. Д.), Чтобы помочь уменьшить эффекты, но это именно то, что вы увидите, когда есть большая разница между полосой пропускания отправителя и получателя. Я жил с этим в течение многих лет (T1, 6 Мбит / с DS3, даже 10 Мбит / с кабельный модем). Вы можете попросить интернет-провайдера уменьшить размер очереди на их стороне, но они вряд ли это сделают, так как это приведет к отбрасыванию пакетов. ,

Большинство форм «QoS» в наши дни не включают AQM, поскольку поставщики считают слишком сложным автоматическое конфигурирование RED, не причиняя вреда. Это приводит к ужасным задержкам, которые вы видите на многих распространенных сегодня устройствах, особенно кабельных модемах и беспроводных сетях. Так что простая рекомендация "включить qos" ... не помогает. Фактически, по крайней мере, по одному из продуктов Netgear включение ограничителя скорости для «QoS» приводит к значительно худшим результатам ....

Недавно появился новый алгоритм честной очереди + AQM, который, кажется, работает очень хорошо, а лучше, почти не требует настройки, кроме настройки ограничителя скорости. Он называется fq_codel, и теперь он широко доступен в большинстве Linux, а также перенесен на BSD. Это часть стандартного «QoS» в openwrt барьерном прерывателе, cerowrt и gargoyle использует (довольно хорошую) более раннюю версию под названием sfqred с инновационной схемой автоматической настройки скорости под названием ACC.

Таким образом, вы можете сбросить флажок на основе этого перед своей ненадлежащей связью, включить их ограничитель скорости QoS (установите чуть ниже настроек входящих и исходящих вызовов ваших провайдеров, чтобы вы могли контролировать) + fq_codel, и получить гораздо лучшую производительность для всех, кто его использует , Я имею в виду поразительно лучше: см. Демонстрацию IETF ниже, отчет рабочей группы ICCRG в IETF и т. Д.

Для получения более подробной информации о проблеме bufferbloat и ее устранении см .:

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

Мы (конечно) пытаемся убедить различных поставщиков услуг Интернет-провайдеров CPE обратить внимание, как и Cablelabs, который опубликовал замечательное исследование этого нового материала несколько месяцев назад, который также содержит некоторые подробности о текущем неправильном поведении кабельных модемов, в частности.

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

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

Пока ссылка не перегружена, пониженный приоритет ни на что не влияет, так как в очереди нет трафика. В течение этих периодов ваша задержка остается низкой, поскольку ICMP-пакеты будут пересылаться немедленно и вообще не задерживаться.

Когда ссылка перегружена, очереди с более высоким приоритетом привлекают больше внимания. В зависимости от механизма очередей он может пересылать несколько пакетов из очереди с более высоким приоритетом для каждого пакета из очереди с более низким приоритетом или даже пересылать только тогда, когда в очереди с более высоким приоритетом ничего нет. В любом случае пакет, отправленный в очередь с более низким приоритетом, обычно будет задерживаться дольше, чем в канале без перегрузки, увеличивая задержку.

Вы, вероятно, страдаете от bufferbloat и хотите 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он и запускаете его как root (очевидно, после прочтения исходного кода).

Для вашего случая использования я бы предложил

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