डाउनलोड के दौरान उच्च विलंबता

Question

मैं अपने व्यवसाय कनेक्शन 5Mbps पर इस साइट पर एक और पोस्टिंग के रूप में एक ही मुद्दा रहा हूँ । जैसे ही कोई भी कंप्यूटर पहली डाउनलोड पर विलंबता शुरू करता है, हमारे ISP (बेल) द्वारा प्रदान किया गया हमारा DFG चार्ट बंद हो जाता है। यह पहला हॉप हमारे उसी भवन में होने की संभावना है और लगातार 1ms है, एक डाउनलोड शुरू करें, जैसे कि विंडोज़ अपडेट, और यह 200-1000ms तक कूदता है।

मैंने फोन पर घंटों का समर्थन करते हुए कहा है कि आप अधिकतम उपलब्ध बैंडविड्थ तक पहुंच गए हैं, यह आपकी विलंबता के लिए सामान्य है। लेकिन मेरा पढ़ना बताता है कि वे टीसीपी के साथ कुछ तोड़ रहे हैं। मैंने होम शॉ कनेक्शन और यहां तक ​​कि रोजर्स एलटीई पर डाउनलोड चलाने और अपने खाते के लिए अधिकतम एमबीपीएस तक पहुंचने के लिए परीक्षण चलाए हैं, लेकिन विलंबता छत से नहीं गुजरती है।

क्या मैं अपनी समझ में सही हूं कि बेल 2% अंक के बीच उपलब्ध बैंडविड्थ के आधार पर अपनी दर को प्रबंधित करने के लिए टीसीपी की अंतर्निहित तकनीकों को तोड़ने के लिए कुछ कर रहा है?

Comments

क्या किसी उत्तर ने आपकी मदद की? यदि हां, तो आपको उत्तर को स्वीकार करना चाहिए ताकि प्रश्न हमेशा के लिए पॉपअप न हो जाए, उत्तर की तलाश में है। वैकल्पिक रूप से, आप अपना स्वयं का उत्तर प्रदान कर सकते हैं और स्वीकार कर सकते हैं।

— रॉन Maupin

Answer 1

बेल आपको सच बता रहा है। जब आप 5Mbps कनेक्शन में 5Mbps (या अधिक) पुश करने की कोशिश करते हैं, तो सब कुछ एक साफ छोटे क्रम में फाइल करता है (पढ़ें: कतार।) आपका पिंग बिना किसी देरी के बाहर हो जाता है क्योंकि कोई बैकलॉग नहीं है। हालाँकि, उत्तर अब कतार के अंत में है। टीसीपी बिल्कुल वही कर रहा है जो यहां माना जाता है - प्रेषक अनुमत प्राप्त विंडो को भर रहा है।

प्रभाव को कम करने में मदद करने के लिए आप लाइन (QoS, WRED, आदि) के अपने पक्ष में कर सकते हैं, लेकिन जब आप प्रेषक और रिसीवर बैंडविड्थ के बीच एक बड़ा अंतर देखते हैं, तो यह इस तरह का होता है। मैं वर्षों से इसके साथ रहता हूं (T1, 6Mbps DS3, यहां तक ​​कि 10Mbps केबलमोडम) आप आईएसपी को उनकी तरफ से कतार का आकार कम करने के लिए कह सकते हैं, लेकिन वे ऐसा करने की संभावना नहीं रखते हैं, क्योंकि इससे पैकेट में गिरावट आएगी। ।

Comments

200-1000ms (85-420 पैकेट, 1500B @ 5Mbps) en.wikipedia.org/wiki/Bufferbloat डोमेन में है, क्योंकि टीसीपी सही ढंग से और तेजी से सेट विंडो आकार में होने वाले पैकेट नुकसान पर निर्भर करता है, इसे कम करने के लिए इसे जीतना चाहिए। शायद 10 पैकेट (25ms)। मैं पूरी तरह से सहमत हूं कि ऑपरेटर अपने उत्पाद में इसे बदलने की संभावना नहीं है, जब तक कि बहुत सारे ग्राहक शिकायत न करें, व्यापार कनेक्शन के लिए क्यूओएस उत्पाद को ऑर्डर करने के लिए आसान होने की संभावना है, इसमें सैनर बफर मान होना चाहिए और उन्हें ग्राहकों की मांगों के लिए आदेश योग्य होना चाहिए। दिलचस्प है कि Google का QUIC वैकल्पिक रूप से संचरण दर को धीमा कर सकता है जब विलंबता शुरू हो रही है।

— यति

धन्यवाद रिकी, मैंने सुना है कि आप क्या कह रहे हैं, लेकिन अधिक पढ़ने के बाद, टीसीपी के फ्लो कंट्रोल को बैकलॉग नहीं देखना चाहिए और खिड़की को उस दर को समायोजित करना चाहिए जिसे रिसीवर संभाल सकता है? इस प्रकार रास्ते में क्लाइंट (राउटर) (होप 2 ऑन बेल्स नेटवर्क) को ओवरलोड नहीं कर रहे हैं? मेरे लिए यह बफरब्लॉट के आपके संदर्भ जैसा लगता है कि मैंने भी पढ़ा है जो वास्तव में परिदृश्य का वर्णन करता है।

— स्टनपल्स

पैकेट ड्रॉप्स (या ईसीएन) के बिना टीसीपी किसी भी अड़चन का पता नहीं लगा सकता है। यदि राउटर कतारें पर्याप्त गहरी हैं और आपकी प्राप्त खिड़की काफी बड़ी है, तो आप एक विशाल बैकलॉग बना सकते हैं। RFC1323 टाइमस्टैम्प मदद कर सकता है, लेकिन मैंने महत्वपूर्ण समस्याओं को विंडोज़ को "टीएस" का उपयोग करने की अनुमति दी है। (यह एक प्रारंभिक टीएस = 0 भेजकर टीएस को "बातचीत" करने का प्रयास करता है)

— रिकी बीम

Answer 2

इन दिनों "क्यूओएस" के अधिकांश रूपों में एक्यूएम शामिल नहीं है क्योंकि विक्रेताओं को नुकसान पहुंचाने के बिना लाल स्वचालित रूप से कॉन्फ़िगर करने के लिए बहुत मुश्किल पाया गया। यह आज आपको कई सामान्य उपकरणों, विशेष रूप से केबल मोडेम और वायरलेस पर दिखाई देने वाली भयावह देरी की ओर जाता है। तो केवल "क्यूस चालू करने की सिफारिश" ... मदद नहीं करता है। वास्तव में नेटगियर के कम से कम एक उत्पाद पर, "क्यूओएस" के लिए रेट लिमिटर को चालू करने से काफी हद तक खराब हो जाता है ...।

हाल ही में एक नई निष्पक्ष कतार + AQM एल्गोरिथ्म दिखाई दिया है जो बहुत अच्छी तरह से काम करने के लिए प्रकट होता है, और बेहतर, दर सीमक सेट करने के अलावा लगभग कोई कॉन्फ़िगरेशन की आवश्यकता होती है। इसे fq_codel कहा जाता है, और यह अब अधिकांश लिनक्स में व्यापक रूप से उपलब्ध है और इसे बीएसडी में भी पोर्ट किया गया है। यह ओपनराइट बैरियर ब्रेकर, सेरोवार्ट में डिफ़ॉल्ट "क्यूओएस" का हिस्सा है, और गारग्लो एक (बहुत अच्छा) पूर्व संस्करण का उपयोग करता है जिसे एसीसी नामक एक अभिनव स्वचालित दर समायोजन योजना के साथ sfqred कहा जाता है।

तो आप अपने दुर्व्यवहार लिंक के सामने इसके आधार पर एक बॉक्स को स्लैम कर सकते हैं, उनके QoS रेट लिमिटर को चालू कर सकते हैं (अपने प्रदाता इनबाउंड और आउटबाउंड सेटिंग्स से थोड़ा नीचे सेट करें ताकि आप नियंत्रण लें) + fq_codel, और इसका उपयोग करके हर किसी के लिए बेहतर प्रदर्शन प्राप्त करें । मेरा मतलब है astoundingly बेहतर: देखने IETF IETF, आदि पर नीचे डेमो, iccrg कार्यदल करने के लिए रिपोर्ट

बफरब्लोट समस्या और इसके लिए सुधार पर अधिक विस्तार के लिए, देखें:

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

हम (निश्चित रूप से) विभिन्न आईएसपी सीपीई विक्रेताओं को ध्यान देने की कोशिश कर रहे हैं, जैसा कि केबललैब्स है, जिसने कुछ महीने पहले इस नए सामान का एक अद्भुत अध्ययन प्रकाशित किया था, जिसमें विशेष रूप से केबल मॉडेम के वर्तमान दुर्व्यवहार पर कुछ विवरण शामिल हैं।

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

Answer 3

आप जो देख रहे हैं वह पूरी तरह से विशिष्ट है। कई सर्विस प्रोवाइडर्स ICMP (जिसमें पारंपरिक पिंग और ट्रेसरआउट शामिल हैं) की प्राथमिकता को कम करने के लिए QoS तंत्र की सीमा और / या उपयोग करेंगे क्योंकि यह कई बार सेवा हमलों से इनकार में उपयोग किया गया है।

हालांकि एक लिंक को कंजेस्ट नहीं किया गया है, लेकिन कम प्राथमिकता कुछ भी प्रभावित नहीं करती है क्योंकि कोई ट्रैफ़िक कतार में नहीं है। इन अवधि के दौरान, आपकी विलंबता कम रहती है क्योंकि ICMP पैकेट तुरंत आगे भेज दिए जाएंगे और इसमें देरी नहीं की जाएगी।

जब लिंक को कंजेस्ट किया जाता है, तो उच्च प्राथमिकता वाली कतारों को अधिक ध्यान दिया जाता है। कतारबद्ध तंत्र के आधार पर, यह प्रत्येक पैकेट के लिए उच्च प्राथमिकता वाली कतार से कम प्राथमिकता वाली कतार से कई पैकेटों को अग्रेषित कर सकता है या केवल तब अग्रेषित कर सकता है जब उच्च प्राथमिकता वाली कतार में कुछ भी न हो। किसी भी मामले में, कम प्राथमिकता वाली कतार में लगाए गए एक पैकेट को आम तौर पर बिना किसी भीड़भाड़ वाले लिंक की तुलना में लंबे समय तक वापस रखा जाएगा, जिससे विलंबता बढ़ जाती है।

Comments

आपके उत्तर के लिए धन्यवाद YLearn मुझे ICMP की प्राथमिकता मिलती है, लेकिन हम अन्य ट्रैफ़िक को प्रभावित देख सकते हैं और ICMP को केवल समस्या का वर्णन करना था। जैसा कि मैं रिकी को अवगत कराने की कोशिश कर रहा था, मेरी टिप्पणी में फ्लो कंट्रोल है, इसलिए टीसीपी काम करता है, क्योंकि रिसीवर की तुलना में अधिक बैंडविड्थ के साथ कोई भी प्रेषक उसे ऑफ़लाइन डॉस ले जाएगा यदि फ्लो कंट्रोल सही काम नहीं कर रहा था। Thats क्यों एक डायल-अप एक 1000Mbps कनेक्शन के साथ संवाद कर सकता है? क्या मैं गलत सोच रहा हूं, अगर चीजें एक फाइल ट्रांसफर के दौरान उचित मानकों की विलंबता के लिए चल रही हैं, तो एक resonalble स्तर बनाए रखें और छत के माध्यम से न जाएं?

— स्टनपाल्स

Answer 4

आप शायद बफरबोल्ट से पीड़ित हैं और आप एक्यूएम (एक्टिव क्यू मैनेजमेंट) चाहते हैं। मैंने लिनक्स के लिए एक स्क्रिप्ट लिखी है जो इसे बहुत आसान बनाती है:

#!/bin/bash
# Traffic shaping script (AQM, fq_codel+tbf)
# Copyright 2018 Mikko Rantalainen <[e-mail]>
# 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

Comments

इसे भी देखें: बफरबेलट.नेट

— मिको रान्टालैनेन

ध्यान दें कि linux-lowlatencyसिस्टम को सभी पैकेजों को संसाधित करने के कार्य को बनाए रखने के लिए आपको कर्नेल को चलाने की आवश्यकता हो सकती है।

— मिकको रेंटालिनेन

इसे भी देखें: apenwarr.ca/log/20110110

— मिकको रैंटलैनेन

इसे भी देखें: jfcarter.net/~jimc/documents/voip-qos-1609.html

— मिकीको रैंटलैनेन