Latensi tinggi selama pengunduhan

Saya mengalami masalah yang sama pada koneksi bisnis saya 5Mbps seperti pada posting lain di situs ini. Segera setelah komputer mana pun memulai unduhan, latensi pada lompatan pertama melewati DFG kami yang disediakan oleh ISP kami (Bell) berbunyi grafik. Hop pertama ini kemungkinan ada di gedung kami yang sama dan berjarak 1 ms terus-menerus, mulai unduh, mis. Pembaruan windows, dan lompatan ke 200-1000 ms.

Saya telah menghabiskan berjam-jam di telepon dengan dukungan semua mengatakan Anda telah mencapai bandwidth max yang tersedia, itu normal untuk latensi Anda untuk lonjakan. Tapi bacaan saya mengatakan mereka melanggar sesuatu dengan TCP. Saya telah menjalankan tes pada koneksi Shaw di rumah dan bahkan pada LTE Rogers yang menjalankan unduhan dan mencapai max Mbps untuk akun saya tetapi latensi tidak berjalan lancar.

Apakah saya benar dalam pemahaman saya bahwa Bell melakukan sesuatu untuk memecah teknologi built-in TCP untuk mengelola laju berdasarkan bandwidth yang tersedia antara 2 titik akhir?

Bell mengatakan yang sebenarnya. Ketika Anda mencoba untuk mendorong 5Mbps (atau lebih) ke dalam koneksi 5Mbps, semua file menjadi sedikit urutan rapi (baca: antrian.) Ping Anda keluar tanpa penundaan karena tidak ada jaminan simpanan. Namun, jawabannya sekarang ada di akhir antrian. TCP melakukan apa yang seharusnya ada di sini - pengirim mengisi jendela terima yang diizinkan.

Ada hal-hal yang dapat Anda lakukan di sisi Anda (QoS, WRED, dll.) Untuk membantu mengurangi efek, tetapi ini adalah hal yang akan Anda lihat ketika ada perbedaan besar antara bandwidth pengirim dan penerima. Saya telah hidup dengannya selama bertahun - tahun (T1, 6Mbps DS3, bahkan 10Mbps cablemodem) Anda dapat meminta ISP untuk mengurangi ukuran antrian di sisi mereka, tetapi mereka tidak akan melakukannya, karena akan menghasilkan paket drop .

Sebagian besar bentuk "QoS" hari ini tidak termasuk AQM karena vendor merasa terlalu sulit untuk mengkonfigurasi RED secara otomatis tanpa membahayakan. Hal ini menyebabkan keterlambatan mengerikan yang Anda lihat pada banyak perangkat umum saat ini, terutama modem kabel dan nirkabel. Jadi hanya merekomendasikan "menyalakan qo" ... tidak membantu. Bahkan pada setidaknya satu dari produk Netgear, menyalakan pembatas tingkat untuk "QoS" menyebabkan hasil yang jauh lebih buruk ....

Baru-baru ini muncul antrian baru + algoritma AQM yang tampaknya berfungsi dengan sangat baik, dan lebih baik, hampir tidak memerlukan konfigurasi selain mengatur pembatas laju. Ini disebut fq_codel, dan sekarang tersedia secara luas di sebagian besar Linux dan telah porting ke BSD juga. Ini adalah bagian dari "QoS" default di penghalang penghalang openwrt, cerowrt, dan gargoyle menggunakan versi sebelumnya (cukup bagus) yang disebut sfqred dengan skema penyesuaian otomatis inovatif yang disebut ACC.

Jadi Anda dapat membanting kotak berdasarkan ini di depan tautan Anda yang salah, nyalakan pembatas tingkat QoS mereka (atur sedikit di bawah pengaturan masuk dan keluar penyedia Anda sehingga Anda mengambil kendali) + fq_codel, dan dapatkan kinerja yang jauh lebih baik untuk semua orang yang menggunakannya . Maksud saya secara mengejutkan lebih baik: lihat demo ietf di bawah ini, laporan ke kelompok kerja iccrg di ietf, dll.

Untuk detail lebih lanjut tentang masalah bufferbloat dan perbaikannya, lihat:

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

Kami (tentu saja) berusaha meyakinkan berbagai vendor ISP CPE untuk memperhatikan, seperti halnya cablelab, yang menerbitkan penelitian yang bagus tentang hal-hal baru ini beberapa bulan yang lalu, yang juga berisi beberapa detail tentang perilaku buruk saat ini pada modem kabel khususnya.

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

Apa yang Anda lihat sepenuhnya tipikal. Banyak penyedia layanan akan menilai batas dan / atau menggunakan mekanisme QoS untuk menurunkan prioritas ICMP (yang mencakup ping dan traceroute tradisional) karena telah digunakan dalam penolakan serangan layanan pada waktu-waktu tertentu.

Meskipun tautan tidak macet, prioritas yang diturunkan tidak memengaruhi apa pun karena tidak ada lalu lintas yang antri. Selama periode ini, latensi Anda tetap rendah karena paket ICMP akan diteruskan segera dan tidak akan ditunda sama sekali.

Ketika tautannya padat, antrian dengan prioritas lebih tinggi mendapat perhatian lebih. Bergantung pada mekanisme antrian, itu mungkin meneruskan beberapa paket dari antrian prioritas yang lebih tinggi untuk setiap paket dari antrian prioritas yang lebih rendah atau bahkan meneruskan hanya ketika tidak ada dalam antrian prioritas yang lebih tinggi. Bagaimanapun, paket yang diturunkan ke antrian dengan prioritas lebih rendah umumnya akan ditahan lebih lama dari pada tautan tanpa kemacetan, sehingga meningkatkan latensi.

Anda mungkin menderita bufferbloat dan Anda menginginkan AQM (Active Queue Management). Saya telah menulis skrip untuk Linux yang membuatnya sangat mudah:

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

Anda cukup menyimpan skrip sebagai traffic-shapingdan chmod a+xmenjalankannya sebagai root (setelah membaca kode sumber, jelas).

Untuk kasus penggunaan Anda, saya sarankan

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