[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
2001/01/16 15:34 from Shinra
Title: [teenbbs:1005] Re:997)Ethernet版改訂 

No.   : 1005
Sender: Shinra
URL   : 
Title : Re:997)Ethernet版改訂


>合著さんの FTP で調べました。
ありがとうございました。

>60 kbyte/s ぐらいになりました。
>取りこぼしはないようなので、十分な速度が出ていると思います。

合著さんのFTPでは rcvbuf コマンドで受信バッファサイズが変更できます。
24Kくらいにして試してみてください。だいぶ違うと思います。

>  あと、この仕様だとタイマに設定されている周波数(HZ)と、たぶんカウント
>しているアドレスが取得できると嬉しいですね。

そうですね。でも、まるで不正確なタイマですよ(笑)
次の割り込みまでに処理が終わってませんから。

>  ところで、今さらですが、teen の動作からして、報告する TCP_WINDOW は
>アプリケーションの 受信バッファの残りと teen の内部バッファの
>残りで、小さい方にするというのはどうでしょうか。
>  tcp と ip が分かれなくて、邪道って感じですが。

たしかに邪道です(^^; というより、PPP版の存在がありますので、リンク層によってTCPの
実装が変わってしまいます。おそらく効果のある解だとは思いますが。
TCPの送信側は、相手から通知される受信ウィンドウ以外に、輻輳回避のための送信
ウィンドウを管理しています。パケットが喪失してACKが返ってこないことをきっかけに
送信ウィンドウを調整してフローコントロールする仕組みになっているので、通信路より
遅いマシンでパケットが喪失するのも、折り込み済みなのでしょう。

TEEN内部の処理の効率を上げるのが最善なのでしょう。
あるいは、連続して返すACKをひとつにまとめたら、送信時間が減って速くなるのかも。
RTTが増えてしまいますが。

#VAみたいな遅いマシンで使えるのか心配になってきた。
[レスを書く]