ダウンロード中の長い待ち時間


9

私のビジネス接続5Mbpsで、このサイトの別の投稿と同じ問題が発生しています。コンピューターがダウンロードを開始するとすぐに、ISP(Bell)が提供するDFGを通過する最初のホップの待機時間がグラフから消えます。この最初のホップはおそらく同じ建物内にあり、常に1ミリ秒です。Windowsの更新などのダウンロードを開始すると、200〜1000ミリ秒にジャンプします。

私は電話で何時間も費やしましたが、サポートが利用可能な最大帯域幅に達したと言っていますが、待ち時間が急増するのは正常です。しかし、私の読書は彼らがTCPで何かを壊していることを私に伝えます。自宅のShaw接続と、ダウンロードを実行していてアカウントの最大Mbpsに達しているRogers LTEでさえテストを実行しましたが、レイテンシが屋根を通りません。

Bellが2つのエンドポイント間の利用可能な帯域幅に基づいてレートを管理するためにTCPの組み込みテクノロジーを破壊するために何かをしていると私は理解していますか?


何か回答がありましたか?もしそうなら、質問が永遠にポップアップし続けないように答えを受け入れ、答えを探します。または、独自の回答を提供して受け入れることもできます。
Ron Maupin

回答:


12

ベルはあなたに真実を語っています。5Mbps(またはそれ以上)を5Mbps接続にプッシュしようとすると、すべてのファイルがきちんとした小さな順序(読み取り:キュー)に入れられます。バックログがないため、pingはすぐに実行されます。ただし、応答はキューの最後にあります。TCPはここで想定されていることを正確に実行しています。送信者は許可された受信ウィンドウを埋めています。

影響を減らすために、回線の側(QoS、WREDなど)で実行できることがいくつかありますが、これは、送信側と受信側の帯域幅に大きな違いがある場合に目にする種類のことです。私は何年もそれと一緒に住んでいます(T1、6Mbps DS3、さらには10Mbpsケーブルモデム)ISPに彼らの側でキューサイズを減らすように依頼することができますが、パケットドロップが発生するため、そうする可能性は低いです。


4
200-1000ms(85-420パケット、1500B @ 5Mbps)は en.wikipedia.org/wiki/Bufferbloatドメインにあります。TCPはウィンドウサイズを正しく迅速に設定するために発生するパケット損失に依存するため、それを減らすには正味の勝利である必要があります。多分10パケット(25ms)。多くの顧客が不満を述べない限り、オペレーターが製品でこれを変更する可能性は低く、QoS製品をビジネス接続に注文するほうが簡単であり、より適切なバッファー値があり、顧客の要求に注文できるはずであることに、私は完全に同意します。興味深いことに、GoogleのQUICは、レイテンシが増加し始めると、オプションで送信速度を遅くすることができます。
ytti、2013

ありがとうリッキー、私はあなたが言っていることを聞きますが、さらに読んだ後、TCPのフロー制御はバックログを見て、受信機が処理できるレートにウィンドウを調整すべきではありませんか?したがって、途中でクライアントまたはルーター(Bellsネットワーク上のホップ2)に過負荷をかけていませんか?私には、シナリオを正確に説明しているbufferbloatへの参照も読んだようです。
Stunpals 2013

3
TCPはパケットドロップ(またはECN)なしではボトルネックを検出できません。ルーターキューが十分に深く、受信ウィンドウが十分に大きい場合、巨大なバックログを作成できます。RFC1323タイムスタンプが役立つかもしれませんが、ウィンドウでTSを「使用」できるようにする重大な問題を見てきました。(最初のTS = 0を送信することでTSを「交渉」しようとします)
リッキービーム

4

最近のほとんどの「QoS」形式にはAQMが含まれていません。ベンダーが害を及ぼすことなく自動的にREDを構成するのは難しいと判断したためです。これは、今日の多くの一般的なデバイス、特にケーブルモデムやワイヤレスで見られる恐ろしい遅延につながります。したがって、単に「QOSをオンにする」ことを推奨するだけでは効果がありません。実際、少なくとも1つのNetgear製品では、「QoS」のレートリミッターをオンにすると、結果が大幅に悪化します。

最近、新しいフェアキューイング+ AQMアルゴリズムが登場しました。これは、非常にうまく機能し、レートリミッターを設定する以外にほとんど構成を必要としないようです。これはfq_codelと呼ばれ、現在ほとんどのLinuxで広く利用可能で、BSDにも移植されています。これは、openwrtバリアブレーカー、cerrowt、およびgargoyleのデフォルトの「QoS」の一部であり、ACCと呼ばれる革新的な自動レート調整スキームを備えたsfqredと呼ばれる(かなり良い)以前のバージョンを使用しています。

したがって、これに基づいてボックスを不正なリンクの前で非難し、QoSレートリミッター(プロバイダーのインバウンド設定とアウトバウンド設定のわずかに下に設定して制御できるようにする)+ fq_codelをオンにして、それを使用するすべての人にはるかに優れたパフォーマンスを得ることができます。驚くほど良いことを意味します。以下のietfデモ、ietfのiccrgワーキンググループへのレポートなどを参照してください。

bufferbloat問題とその修正の詳細については、以下を参照してください。

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

私たちは(もちろん)数か月前にこの新しいものに関する素晴らしい研究を発表したCablelabsと同様に、さまざまなISP CPEベンダーに注意を払うように説得しようとしています。これには、特にケーブルモデムの現在の誤動作に関する詳細も含まれています。

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


1

あなたが見ているものは完全に典型的です。多くのサービスプロバイダーは、サービス拒否攻撃で使用されることがあるICMP(従来のpingおよびtracerouteを含む)の優先度を下げるために、レート制限やQoSメカニズムを使用します。

リンクは輻輳していませんが、トラフィックがキューに入れられていないため、優先度を下げても何も影響を受けません。これらの期間中、ICMPパケットはすぐに転送され、まったく遅延されないため、遅延は低いままです。

リンクが混雑している場合、優先度の高いキューほど注目されます。キューイングメカニズムによっては、優先度の低いキューからのパケットごとに、優先度の高いキューから複数のパケットを転送したり、優先度の高いキューに何もない場合にのみ転送したりすることもあります。いずれの場合でも、優先度の低いキューに降格されたパケットは、通常、輻輳のないリンクよりも長く保持され、レイテンシが増加します。


1
YLearnに返信いただきありがとうございます。ICMPの優先順位を取得しましたが、他のトラフィックが影響を受けることがわかります。ICMPは問題を説明するためだけのものでした。私がリッキーに伝えようとしていたとき、私のコメントでは、フロー制御がTCPが機能する理由です。フロー制御が正しく機能していなかった場合、レシーバーよりも高い帯域幅を持つ送信者は、オフラインDOSになります。それが、ダイヤルアップが1000Mbps接続で通信できる理由です。ファイル転送中に物事が適切な標準のレイテンシで実行されている場合、適切なレベルを維持し、屋根を通り抜けないのではないでしょうか。
Stunpals 2013

1

おそらくバッファブロートに苦しんでいて、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それをして(明らかに、ソースコードを読んだ後)ルートとして、それを実行します。

あなたのユースケースについては、私がお勧めします

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.