アカウント名:
パスワード:
問:ネットワークの速度が何倍向上したか10進数で答えよ
a) MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。
b) また5%のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。
5%のパケットロスが皆無になると、通信速度が10倍になるってのが、いまひとつピンとこない。
TCPにはパケット喪失・破損に対する復旧手順は存在するが効率が余り宜しくないから。・パケット喪失時の再送条件が確認応答のタイムアウトなので、拡張実装でタイムアウトを最適化しても再送までの待ち時間短縮には限界がある→送信側で1パケット喪失後、1秒でウィンドウサイズを全て消費、2秒後に再送判定だとパケロスの度に1秒無駄になる・パケット破損時に起きる受信側による再送要求が大雑把で、相互にSACKやD-SACKがサポートされないと無駄な再送が起きる→送信側で1パケット破損後、1秒で再送要求が返ってきた場合その1秒間に送信した全パケットがゴミになる・再送が発生してから復旧するまで応答時間が支配的になる→ロストしたパケットは再送要求(判定)を待って再送する。つまりパケットサイズと応答時間で決まる最大速度を超えられない最後のやつとかは再送ベースの通信経路が抱える根本的な問題でTCPの拡張実装ではなかなか回避できない。
パケロス5%なら、他が好条件(帯域幅は無限大、パケットサイズ20Kbit、応答時間4ms、タイムアウト=応答時間、無駄な再送0、再送成功率100%)でも、「実効bps×5%=20Kbit×(1000ms÷4ms)」→「実効bps×5%=5Mbps」→「実効100Mbps」。帯域幅無限でもこれで、普通はパケットサイズ12Kbit以下で応答も10~50とか平気であるしタイムアウトは安全マージンで膨れるし再送にも無駄や失敗が掛かるからまぁそういう事。
タレコミの方式だと予め訂正用のデータで帯域を無駄にする代わりに訂正可能な範囲での破損や喪失(に加えてパケット遅配)を無視できる。訂正可能範囲を超えたら訂正用のデータによる無駄に加えて従来のTCPと同系統の問題で、盛大に速度が落ちる…がその場合は訂正可能範囲をより拡大して訂正用のデータを増やすくらいはするから余り来にしなくても良い・・・かな?
色々間違ってると思うけど、そういう雰囲気の問題でロスが出るから数%のロストで数十%の無駄が出ても不思議じゃない。皆、帯域幅ばかり注目するけど、応答速度って洒落にならない位色々支配してるってのを皆知るべき。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
>無線ネットワークの速度を「10倍向上させる」という新技術 (スコア:0)
問:ネットワークの速度が何倍向上したか10進数で答えよ
a) MIT内のWi-Fiネットワークを使った実験ではパケットロスがなくなり、通信速度も通常1Mbpsのところ16Mbpsまで増加したとしている。
b) また5%のパケットロスが発生していた電車内での通信では、接続速度は0.5Mbpsから13.5Mbpsにまで向上したとしている。
Re: (スコア:0)
5%のパケットロスが皆無になると、通信速度が10倍になるってのが、いまひとつピンとこない。
Re:>無線ネットワークの速度を「10倍向上させる」という新技術 (スコア:0)
TCPにはパケット喪失・破損に対する復旧手順は存在するが効率が余り宜しくないから。
・パケット喪失時の再送条件が確認応答のタイムアウトなので、拡張実装でタイムアウトを最適化しても再送までの待ち時間短縮には限界がある
→送信側で1パケット喪失後、1秒でウィンドウサイズを全て消費、2秒後に再送判定だとパケロスの度に1秒無駄になる
・パケット破損時に起きる受信側による再送要求が大雑把で、相互にSACKやD-SACKがサポートされないと無駄な再送が起きる
→送信側で1パケット破損後、1秒で再送要求が返ってきた場合その1秒間に送信した全パケットがゴミになる
・再送が発生してから復旧するまで応答時間が支配的になる
→ロストしたパケットは再送要求(判定)を待って再送する。つまりパケットサイズと応答時間で決まる最大速度を超えられない
最後のやつとかは再送ベースの通信経路が抱える根本的な問題でTCPの拡張実装ではなかなか回避できない。
パケロス5%なら、他が好条件(帯域幅は無限大、パケットサイズ20Kbit、応答時間4ms、タイムアウト=応答時間、無駄な再送0、再送成功率100%)でも、「実効bps×5%=20Kbit×(1000ms÷4ms)」→「実効bps×5%=5Mbps」→「実効100Mbps」。
帯域幅無限でもこれで、普通はパケットサイズ12Kbit以下で応答も10~50とか平気であるしタイムアウトは安全マージンで膨れるし再送にも無駄や失敗が掛かるからまぁそういう事。
タレコミの方式だと予め訂正用のデータで帯域を無駄にする代わりに訂正可能な範囲での破損や喪失(に加えてパケット遅配)を無視できる。
訂正可能範囲を超えたら訂正用のデータによる無駄に加えて従来のTCPと同系統の問題で、盛大に速度が落ちる…がその場合は訂正可能範囲をより拡大して訂正用のデータを増やすくらいはするから余り来にしなくても良い・・・かな?
色々間違ってると思うけど、そういう雰囲気の問題でロスが出るから数%のロストで数十%の無駄が出ても不思議じゃない。
皆、帯域幅ばかり注目するけど、応答速度って洒落にならない位色々支配してるってのを皆知るべき。