レイテンシー別の通信試行限度回数
1ms=500回試行
10ms＝50回試行
100ms＝5回試行
5回で65KBだと？325KB/s=2.6Mbps
5回で130KBだと？650KB/s=5.2Mbps
5回で260KBだと？ 1300KB/s=10.4Mbps
これだとパケロスがあろうがなかろうが、
果てしなくウィンドウサイズ増やせば帯域増える気がするんだが・・
あ、「帯域」は決まってるよな 100Mbpsなら日本でも欧州でも100Mbpsだし
100Mbpsの理論最大値は125MB/s= 1ms以下の場合
つまり125MBを500で割ると0.25MB=250KBのパケットを送信しているだけ
「これ以上は不可能」なので
上限は1ACKにつき250KBパケットかな＜これ以上増やしても何の意味もない。
つまり100ms遅延環境下(日米間距離)では100Mbps回線同士でも
上限が10Mbps近傍になる。
実際ほとんど20Mbpsはでなかったはず。
120ms
120ms
65KBパケ伝送
120ms
120ms
ここで TCP ウィンドウのサイズをこの BDP 値 (625KB) に設定するわけですが、
Linux 2.6 での TCP ウィンドウのデフォルト・サイズは 110KB であるため、
接続に使用される帯域幅は以下に示すように 2.2MBps に制限されてしまいます。
スループット ＝ ウィンドウのサイズ ÷ RTT
110KB / 0.050 = 2.2MBps
110KB ÷ 0.050 ＝ 2.2MBps
この値の代わりに上で算出した 625KB というウィンドウ・サイズを使用した場合、
以下のように 12.5MBps という非常に大きなスループットを得ることができます。
625KB / 0.050 = 31.25MBps
625KB ÷ 0.050 ＝ 12.5MBps
これは非常に大きな違いで、ソケットのスループットが劇的に大きくなります。
これでソケットの最適なバッファー・サイズの算出方法がわかりました。
では、どうすればこのように変更できるでしょうか。
感想 日米間伝送では実測値で最大1600KB/sくらいはでた。
つまり250KBのパケットを6.4回送信できた。
2000KB/s=8回以上は不可能。
これが100msレイテンシー間での理論限界か。
最大8回で(120msx8=960msで1秒埋まる)、実際は6.4回送信できた
「効率80%」
感想：：
確かにこれくらいが限界値のような気がする。
80%まで来ているのでどうやらがんばっても無理のようです。〜〜無駄な努力
レイテンシー120msの通信網では 100〜1Gbpsでは16Mbpsが理論限度？(確かめた)
これ以上はTCPに頼らない独自の何とかシステムが必要 富士通が開発してるらしいが・・
通信アプリケーションで標準的に利用されているTCPプロトコルでは、
データ損失（パケットロス）が発生した場合にデータを再送するため、
無線接続時や回線が混雑している場合など品質の良くない通信環境では、
データ再送による遅延によって転送性能が大幅に低下する点が課題とされてきた。
という手法をつかうしかないね。 どうぞ開発してください。
↑TCPのパケットにエラー訂正仕込むとか＝そんでゴミパケットを有効パケットにする TCP ACK遅延をすっ飛ばして応答タイムラグを減らすとかしてんだろうな
でも独自方式だと使い勝手悪いかな・・
Storage-Service-TOP
