ডাউনলোডের সময় উচ্চ বিলম্ব


9

এই সাইটে অন্য পোস্টিংয়ের মতো আমার ব্যবসায়িক সংযোগ 5 এমবিপিএসেও আমার একই সমস্যা রয়েছে । যত তাড়াতাড়ি কোনও কম্পিউটার ডাউনলোড শুরু করে আমাদের আইএসপি (বেল) সরবরাহিত ডিএফজির অতীত প্রথম হপটিতে বিলম্বিত করে চার্টটি বন্ধ করে দেয়। এই প্রথম হপটি সম্ভবত আমাদের একই বিল্ডিংয়ে রয়েছে এবং এটি নিয়মিত 1 মিমি, একটি ডাউনলোড শুরু করুন, যেমন উইন্ডোজ আপডেট এবং এটি 200-1000 মিমি অবধি লাফায়।

আপনি সর্বাধিক উপলব্ধ ব্যান্ডউইদথের কাছে পৌঁছে গেছেন এমন সমস্ত সমর্থন সহ ফোনে ঘন্টা সময় ব্যয় করেছি, আপনার বিলম্বিত হওয়ার জন্য এটি স্বাভাবিক। তবে আমার পড়া আমাকে বলে যে তারা টিসিপি দিয়ে কিছু ভঙ্গ করছে। আমি একটি হোম শ সংযোগ এবং এমনকি একটি রজার্স এলটিইতে চলছে ডাউনলোডগুলি চালিয়েছি এবং আমার অ্যাকাউন্টের সর্বাধিক এমবিপিএসে পৌঁছেছি তবে বিলম্বটি ছাদে যায় না।

আমি কি ঠিক বুঝতে পেরেছি যে 2 টি শেষ পয়েন্টের মধ্যে উপলব্ধ ব্যান্ডউইথের উপর ভিত্তি করে বেল টিসিপির অন্তর্নির্মিত প্রযুক্তিগুলিকে তার হারটি পরিচালনা করার জন্য টিসিপির অন্তর্নির্মিত প্রযুক্তিগুলি ভাঙ্গার জন্য কিছু করছে?


কোন উত্তর কি আপনাকে সাহায্য করেছে? যদি তা হয় তবে আপনার উত্তরটি গ্রহণ করা উচিত যাতে উত্তরটি সন্ধান চিরকালের জন্য পপিং না হয়ে থাকে। বিকল্পভাবে, আপনি নিজের উত্তর সরবরাহ করতে এবং গ্রহণ করতে পারেন।
রন মউপিন

উত্তর:


12

বেল আপনাকে সত্য কথা বলছে। আপনি যখন 5 এমবিপিএস সংযোগের জন্য 5 এমবিপিএস (বা আরও) ধাক্কা দেওয়ার চেষ্টা করেন, তখন সমস্ত কিছু ফাইলগুলি একটি ঝরঝরে সামান্য অর্ডারে (পড়ুন: সারি করুন) উত্তরটি অবশ্য এখন সারির শেষে। টিসিপি এখানে যা যা করা উচিত ঠিক তা করছে - প্রেরক অনুমোদিত প্রাপ্ত উইন্ডোটি পূরণ করছে।

প্রভাবগুলি হ্রাস করতে আপনার লাইনের (কিউওএস, ডাব্লুআরইডি, ইত্যাদি) পক্ষে আপনি কিছু করতে পারেন তবে প্রেরক এবং রিসিভার ব্যান্ডউইথের মধ্যে যখন বড় পার্থক্য রয়েছে তখন আপনি এটি দেখতে যাচ্ছেন। আমি এটির সাথে বছরের পর বছর ধরে বাস করেছি (টি 1, 6 এমবিপিএস ডিএস 3, এমনকি 10 এমবিপিএস কেবলমোডেম) আপনি আইএসপিকে তাদের পক্ষের কাতারের আকার হ্রাস করতে বলেছিলেন, তবে তারা এটি করার সম্ভাবনা পাবে না, কারণ এটি প্যাকেটের ঝরে পড়বে ।


4
200-1000ms (85-420 প্যাকেট, 1500B @ 5Mbps) হয় en.wikipedia.org/wiki/Bufferbloat , ডোমেন হিসাবে বিভিন্ন TCP সঠিকভাবে এবং দ্রুত সেট উইন্ডোর মাপ করতে ঘটছে প্যাকেটের ক্ষয়ক্ষতি উপর নির্ভর করে, এটা করা উচিত তা কমাতে নেট জয় হতে পারে 10 প্যাকেট (25 মিমি)। আমি পুরোপুরি একমত যে অপারেটর তাদের পণ্যগুলিতে এটি পরিবর্তন করার সম্ভাবনা কম, যদি না প্রচুর গ্রাহক অভিযোগ করে, সম্ভবত ব্যবসায়ের সংযোগে কিউএস পণ্য অর্ডার করা সহজ, এটির স্যানার বাফার মান থাকতে হবে এবং তারা গ্রাহকের দাবিতে অগ্রণী হতে হবে। মজার বিষয় হ'ল গুগলের কুইক বিকল্পভাবে প্রেরণের হারকে ধীর করতে পারে যখন বিলম্ব হতে শুরু করে la
ytti

ধন্যবাদ রিকি, আপনি যা বলছেন তা আমি শুনতে পেয়েছি তবে আরও পড়ার পরে, টিসিপির ফ্লো কন্ট্রোলটি ব্যাকলোগটি দেখতে পাবে না এবং উইন্ডোটি যে হারটি গ্রহণ করতে পারে তার সাথে সামঞ্জস্য করতে পারে? এইভাবে ক্লায়েন্ট বা রাউটারগুলি (বেলস নেটওয়ার্কে হপ 2) ওভারলোড হচ্ছে না? আমার কাছে এটি আপনার বাফারব্লোটের রেফারেন্সের মতো বলে মনে হচ্ছে যা আমি পড়েছি যা দৃশ্যের বর্ণনা দেয়।
স্টানপালস

3
টিসিপি প্যাকেট ড্রপ (বা ইসিএন।) ব্যতীত কোনও বাধা সনাক্ত করতে পারে না If আরএফসি 1323 টাইমস্ট্যাম্পগুলি সাহায্য করতে পারে তবে আমি উইন্ডোজকে "এসএসএস" ব্যবহারের অনুমতি দেওয়ার ক্ষেত্রে উল্লেখযোগ্য সমস্যা দেখেছি। (এটি প্রাথমিক টিএস = 0 প্রেরণ করে টিএসকে "আলোচনার" চেষ্টা করে)
রিকি বিম

4

এই দিনগুলিতে বেশিরভাগ "QoS" এর ফর্মগুলিতে AQM টি অন্তর্ভুক্ত নয় কারণ বিক্রেতারা ক্ষতি না করেই স্বয়ংক্রিয়ভাবে আরইডি কনফিগার করতে খুব কঠিন মনে হয়েছিল। এটি আজকে আপনি প্রচুর সাধারণ ডিভাইসে যে ভয়ঙ্কর বিলম্ব দেখেন তাতে উল্লেখযোগ্যভাবে কেবল মোডেম এবং ওয়্যারলেস হয়। সুতরাং কেবল "কিউস চালু করার" পরামর্শ দেওয়া ... সাহায্য করে না। প্রকৃতপক্ষে নেট্জিয়ারের কমপক্ষে একটি পণ্যগুলিতে, "কিউএস" এর জন্য রেট সীমাবদ্ধ করা সক্রিয়ভাবে অত্যন্ত খারাপ ফলাফলের দিকে নিয়ে যায় ....

সম্প্রতি একটি নতুন ফেয়ার কুইউটিং + এ কিউএম অ্যালগরিদম উপস্থিত হয়েছে যা অত্যন্ত ভালভাবে কাজ করছে বলে মনে হচ্ছে এবং আরও ভাল, রেট সীমা নির্ধারণের পাশাপাশি প্রায় কোনও কনফিগারেশন প্রয়োজন নেই। এটিকে fq_codel বলা হয় এবং এটি এখন বেশিরভাগ লিনাক্স-এ বিস্তৃত এবং BSD তেও পোর্ট করা হয়েছে। এটি ওপেনর্ট বাধা ব্রেকার, সারোয়ার্ট এবং গারগোলে ডিফল্ট "কিউওএস" এর অংশ, এসিসি নামে একটি উদ্ভাবনী স্বয়ংক্রিয় রেট সামঞ্জস্যকরণ প্রকল্পের সাথে এসফক্রেড নামে একটি (বেশ ভাল) পূর্ববর্তী সংস্করণ ব্যবহার করে।

সুতরাং আপনি আপনার দুর্ব্যবহার লিঙ্কের সামনে এই ভিত্তিতে একটি বাক্স স্ল্যাম করতে পারেন, তাদের 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


1

আপনি যা দেখছেন তা সম্পূর্ণরূপে সাধারণ। অনেক পরিষেবা সরবরাহকারী সীমাবদ্ধতা নির্ধারণ করে এবং / অথবা আইসিএমপির অগ্রাধিকারকে হ্রাস করার জন্য একটি QoS প্রক্রিয়া ব্যবহার করবে (যার মধ্যে traditionalতিহ্যবাহী পিং এবং ট্রেস্রোয়েট অন্তর্ভুক্ত রয়েছে) কারণ এটি কখনও কখনও পরিষেবা আক্রমণ অস্বীকার করার ক্ষেত্রে ব্যবহৃত হয়।

কোনও লিঙ্ক জঞ্জাল না থাকা অবস্থায়, ট্র্যাফিকের সারিবদ্ধ হওয়ার কারণে নিম্ন অগ্রাধিকার কোনও কিছুই প্রভাবিত করে না। এই পিরিয়ডগুলির মধ্যে আপনার অলসতা কম থাকে কারণ আইসিএমপি প্যাকেটগুলি তাত্ক্ষণিকভাবে ফরোয়ার্ড করা হবে এবং দেরি হবে না।

লিঙ্কটি যখন ভিড় হয় তখন উচ্চ অগ্রাধিকারের সারিগুলি আরও মনোযোগ দেয় attention সারিবদ্ধ পদ্ধতির উপর নির্ভর করে, এটি প্রতিটি প্যাকেটের জন্য উচ্চ অগ্রাধিকার সারি থেকে একাধিক প্যাকেটকে নিম্ন অগ্রাধিকার সারি থেকে ফরোয়ার্ড করতে পারে এমনকি উচ্চতর অগ্রাধিকার সারিতে কিছুই না থাকলে কেবল ফরোয়ার্ড হতে পারে। যাই হোক না কেন, নিম্ন অগ্রাধিকারের কাতারে সজ্জিত একটি প্যাকেটটি সাধারণত কোনও ভিড় না থাকা লিঙ্কের তুলনায় দীর্ঘকাল ধরে ধরে রাখা হবে, বিলম্বিতা বাড়াবে।


1
আপনার উত্তরের জন্য YLearn ধন্যবাদ। আমি আইসিএমপির অগ্রাধিকার পাই তবে আমরা অন্যান্য ট্র্যাফিক ক্ষতিগ্রস্থ দেখতে পাচ্ছি এবং আইসিএমপি কেবল ইস্যুটি তুলে ধরার জন্য ছিল। আমি যখন রিকিকে জানাতে চেষ্টা করছিলাম, আমার মন্তব্যে ফ্লো কন্ট্রোলটি হ'ল কেন টিসিপি কাজ করে, ফ্লো কন্ট্রোল সঠিকভাবে কাজ না করলে রিসিভারের চেয়ে উচ্চতর ব্যান্ডউইথ সহ কোনও প্রেরক তাকে অফলাইনে ডস নেবে। কেন ডায়াল-আপ 1000 এমবিপিএস সংযোগের সাথে যোগাযোগ করতে পারে? আমি কি ভুল চিন্তাভাবনা করছি, যদি ফাইল স্থানান্তরকালে জিনিসগুলি যথাযথ মানসম্পন্ন বিলম্বিত হয়ে চলেছে তবে একটি পুনঃসংযোগযোগ্য স্তর বজায় রাখে এবং ছাদ দিয়ে না যায়?
স্টানপালস

1

আপনি সম্ভবত বাফারলোটে ভুগছেন এবং আপনি এ কিউএম (অ্যাক্টিভ ক্যু ম্যানেজমেন্ট) চান want আমি লিনাক্সের জন্য একটি স্ক্রিপ্ট লিখেছি যা এটি বেশ সহজ করে তোলে:

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


নোট করুন যে linux-lowlatencyসমস্ত প্যাকেজ প্রক্রিয়া করার জন্য সিস্টেমটি চালিয়ে যাওয়ার জন্য আপনার কার্নেল চালানোর প্রয়োজন হতে পারে ।
মিক্কো রেন্টালাইনেন


আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.