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

9

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

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

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

Stunpals
источник
Вам помог какой-нибудь ответ? если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:

12

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

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

Рики Бим
источник
4
200–1000 мс (85–420 пакетов, 1500 Б при 5 Мбит / с) находится в домене en.wikipedia.org/wiki/Bufferbloat , поскольку TCP зависит от потери пакетов при правильной и быстрой установке размера окна, поэтому необходимо уменьшить выигрыш, чтобы уменьшить его до возможно 10 пакетов (25 мс). Я полностью согласен с тем, что оператор вряд ли изменит это в своем продукте, если не будет жалуется множество клиентов, вероятно, проще будет просто заказать продукт QoS для бизнес-связи, он должен иметь более разумные буферные значения, и они должны соответствовать требованиям клиентов. Интересно, что QUIC от Google по желанию может замедлить скорость передачи, когда задержка начинает увеличиваться.
Ytti
Спасибо, Рикки, я слышу, что вы говорите, но после прочтения, разве TCP Control Flow не может увидеть отставание и настроить окно в соответствии со скоростью, которую может обработать получатель? Таким образом, не перегружая клиент или маршрутизатор (ы) (переход 2 в сети Bells) по пути? Мне кажется, что ваша ссылка на bufferbloat, которую я также прочитал, точно описывает сценарий.
Stunpals
3
TCP не может обнаружить узкие места без отбрасывания пакетов (или ECN). Если очереди маршрутизатора достаточно глубоки и у вас достаточно большое окно приема, вы можете создать огромное отставание. Временные метки RFC1323 могут помочь, но я видел значительные проблемы, позволяющие окнам «использовать» TS. (он пытается "договориться" о TS, отправив начальный TS = 0)
Рикки Бим
4

Большинство форм «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

Дейв Тахт
источник
1

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

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

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

YLearn
источник
1
Спасибо YLearn за ваш ответ. Я получаю приоритет ICMP, но мы видим, что другой трафик затронут, и ICMP был просто для иллюстрации проблемы. Как я пытался донести до Рикки, в моем комментарии «Контроль потока» - это то, почему TCP работает, поскольку любой отправитель с большей пропускной способностью, чем получатель, переводил бы его в автономный режим DOS, если управление потоком работало неправильно. Вот почему коммутируемый доступ может общаться с соединением 1000 Мбит / с? Неправильно ли я думаю, что если во время передачи файлов все работает с должной задержкой, поддерживающей резонансный уровень, а не зашкаливающей?
Stunpals
1

Вы, вероятно, страдаете от 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
Микко Ранталайнен
источник
Смотрите также: bufferbloat.net/projects/codel/wiki/…
Микко Ранталайнен,
Обратите внимание, что вам может потребоваться запустить linux-lowlatencyядро, чтобы система выполняла задачу обработки всех пакетов.
Микко Ранталайнен
Смотрите также: apenwarr.ca/log/20110110
Микко Ранталайнен
См. Также: jfcarter.net/~jimc/documents/voip-qos-1609.html
Микко Ранталайнен,