netperfでCORE 3GのUDP転送テスト＠1:3x？～1:5x頃。
プラスエリアだが、350kbpsオーバーで安定。時々下がるがすぐ復帰する。
やはりこれはTCPに絡んだ処理で躓いてるとしか思えないな。
ところで、UDPってACKとかないからか、送信元で転送終わってるのにだらだらとパケットが流れ続けてくるんだが…。
ちなみにTCPは40～50kbps…orz

netspeedでも計測してみた。
どうやらnetperfのWindows版サーバがUDP待ちうけできてなかったらしい。Wiresharkで見たらDestination port unreachableが大量に返ってきてた。
まあ、それでもUDPの場合はスループットテストできるわけだが。

パラメータはパケットサイズ1024byte、送信データ量2048KiBで実行。
で、結果は…
UDP：ほぼ370～380kbps近くに張り付いていた。ただし、受信パケット数は約432KiB。21％しか届いてねぇｗｗ（有線LANだと92.8％）
TCP：40～60kbps。当然受信パケット数は100％。

なんとなく速度低下の原因がわかってきた気がするな。
やはりprin輻輳（正確には輻輳寸前？）ってのは本当で（嘘だろといったのは誰だったっけ…サーセンｗｗ）、UDPの場合は能力オーバーした分は遠慮せず破棄しまくって送信できる分だけ送信するので見かけ上スループットが出るのだろう。
TCPはそういうわけにはいかない（捨てたらその分再送要求されて結局無駄な転送が発生するので）ため、輻輳制御（ACKによる）を利用してスループットを絞る。
要するにタイムアウトにならない程度に遅いタイミングでACKを返し続ければ送信ウィンドウが増えないので遅いままというわけだ。
実際にWiresharkで通信状況をみると、1～2パケットごとにACKが返っている。これでは遅いのは当たり前だ。
だが、TCPの輻輳制御はセッションごとなので、セッションを多数張ればその分だけスループットが増える。

-----------------------------------

20:13~20:22 自宅

mg1
p273.70 a55.5
p61.76 a41.4

mg4
p329.55 a161.3
p353.65 a174.0

fg10（約1.5MiB版）
p383.62 a271.5648
p385.38 a205.864961

fg10の2回目、98％ぐらいまで安定して350kbpsオーバーだったんだが、力尽きたのか数秒間スループットが0kbpsに。
ところで、今回ミスってLAN接続したまま計測してしまったのだが、より高速なネットワークが使えるのにわざわざ低速なほうを使うのはどうしてなんだろうか？直近に有効化されたネットワーク接続を使うのか？