Yukiharu YABUKI の tDiary
このtDiaryを検索します。
2009-02-26 [長年日記]
_ Debian GNU/Linux Lenny の記事
初心者にも扱いやすくなった Debian GNU/Linux 5.0 (lenny)(http://sourceforge.jp/magazine/09/02/25/0352241)この記事は、私がDebian GNU/Linux Lenny に感じている意見に似ている。
_ 最近のアセンブラやコンパイラーの進歩について行けてなかった。
昔のままで錆び付いていた、知識を新しくする機会があったのでメモ。何をもって「ガチ」とするか。
- Cのコードの挙動をチェックするために、gcc -Sでアセンブラの出力を見るのは、gccがどれだけ頑張っているかを確認するのは良い。
objdump -d と、どのように配置されているか確認にするのに readelf コマンドにて確認しておかないと、「実際」どのようになっているかが確定できない。see also(http://www.mnet.ne.jp/~tnomura/gcc.html)
アセンブラでも最近のものは、入力したものを「そのまま」出力はしない。パイプラインの関係で依存性がないと判断された命令は順序を変更される可能性がある。そのためgcc -Sの結果だけ見ても実際を反映していない場合がある。また、linkされるので実際のコードがどこへ配置されるかも、メモリ破壊が関係するバグを発見する場合に重要だ。
逆アセンブラで実際の動きを確認するという点では、可能であれば gdb でソースコードデバッグだけでなく逆アセンブラを確認するのも有効だ。組み込み機器の場合なら gdb がつねにつかえるとは限らないけど。
_ Key Value Store 勉強会
(http://kzk9.net/blog/2009/02/keyvalue_store.html)全国で、多数の勉強会ができてますけど、ここはdeepな勉強会だな。
_ 遅延Ack
Delayed ACKは、RFC1122(http://tools.ietf.org/html/rfc1122)の 4.2.3.2 When to Send an ACK Segment で
A host that is receiving a stream of TCP data segments can increase efficiency in both the Internet and the hosts by sending fewer than one ACK (acknowledgment) segment per data segment received; this is known as a "delayed ACK" [TCP:5]. A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment. DISCUSSION: A delayed ACK gives the application an opportunity to update the window and perhaps to send an immediate response. In particular, in the case of character-mode remote login, a delayed ACK can reduce the number of segments sent by the server by a factor of 3 (ACK, window update, and echo character all combined in one segment). In addition, on some large multi-user hosts, a delayed ACK can substantially reduce protocol processing overhead by reducing the total number of packets to be processed [TCP:5]. However, excessive delays on ACK's can disturb the round-trip timing and packet "clocking" algorithms [TCP:7].と
- TCP/IP Illustrated, Volume 1だと 19章のTCPインタラクティブ・データ・フローのp301 「19.3 遅延確認応答」を見ることになると思う、で20章のTCPバルク・データ・フローで、相手のウィンドウがいっぱいになるまでだったり、実装によっては2つのセグメント分のデータを受信したらackを返す場合もあるが、複数の送信に対して個々にACKを返さない場合があるというのはわかると思う。
- (http://tiki.is.os-omicron.org/tiki.cgi?c=v&p=TCP%2F%C3%D9%B1%E4ACK)