[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
2000/11/24 22:49 from neko
Title: [teenbbs:882] Re:880)Re:teene
No. : 882
Sender: neko
URL :
Title : Re:880)Re:teene
> もしそのときのtcpdumpのログが残っていれば頂ければ幸いです。
うーん、もう少し条件などをそろえて、まともなデータをとったら
にします。
> tcp_send で n バイト送ろうとすると、まず nバイト送るので、nが512の倍数でない
> ときはそれより小さいパケットが最後に1個発生します。
ソフトの方で最適化するが吉ってことですね。しかし TCPPRM で設定する
rbuf, sbuf と teen の 内部バッファ( packet_driver のバッファ？)に
それぞれいつ移されるのか解りにくいです。
現状では、送信は tcp_send で
アプリ -> sbuf -> 送信(ヘッダを付けて packet_driver に渡す)
って感じでしょうか。とりあえず、 sbuf, rbuf は 512 の倍数でとり、
tcp_send も 512 の倍数で呼びましょうということですね。
> ためておいたn個のパケットを一気に処理する上、そのn個それぞれにackを返すので
> 返されるn個のackに書き込むwindowサイズはどんどん減っていきます。
> n個のパケットを処理している間に tcp_recv が割り込むことはできません。
ack を返す前に読みだせるようにはできないでしょうか。
teene は受信してから、 0.1 秒後にack を出しているように見えますが、
ackを出す前に、tcp_recv があったら sum check をして読み出せるといい
と思います。
良く見たら、明らかに WATTCP は複数のセグメントに対して(14個とか)、
1つの ack で返事してました。前回の終わりから、連続したシーケンスを
受け取った場合、最後の ack を出せばよいようです。遅れて古い ack が
来ると、経路の遅延を大きく見積もってしまうのではないかと思います
受信の時はこれがもっとも効いていそうです。
Windowサイズ云々は関係なさそうです。
この時、wattcp も teene も Window サイズは最大 16k でした。
[レスを書く]