仙石浩明の日記

2006年3月31日

ネイティブ IPv6

昨日に引き続き、これも tech ML で流した IPv6 ネタですが...

KLab のイントラのサーバである kamiya で、

ping6 -I eth0 ff02::1

を実行してみると、20台程度のマシンが反応します。うち、半分くらいは、 私が IPv6 をインストールしたマシンだったりします。 Linux や WindowsXP は標準で IPv6 をサポートしてますし、 Windows2000 も IPv6 Technology Preview を使えば IPv6 が使えます。興味がある人は試してみては? 今まで鳴かず飛ばずだった IPv6 ですが、なんとなく いろいろ使えそうな予感がします。 いろいろな仕掛けを IPv6 へ移行中...

# ついでに言うと stone も、IPv6 をサポートしています

六本木LAN の kamiya からフツーに IP で、私の自宅サーバ asao.gcd.org へ ping を打って、

kamiya:/home/sengoku % ping -t 64 asao.gcd.org
PING asao.gcd.org (60.32.85.216) from 10.10.0.2 : 56(84) bytes of data.
64 bytes from gcd.org (60.32.85.216): icmp_seq=1 ttl=50 time=6.55 ms

asao.gcd.org 側で見ると、

asao.gcd.org:/root # tcpdump -v -i ppp0 icmp
tcpdump: listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
09:34:55.115600 IP (tos 0x0, ttl  50, id 0, offset 0, flags [DF], length: 84) 161.90.128.210.bf.2iij.net > asaogw.gcd.org: icmp 64: echo request seq 256

64 に設定した ttl が 50 まで減っています。つまり 14 hop あるということ ですね。ping パケットは

六本木LAN → PPPoE (IPv6網) → IIJ (6 hop) ─┐
                                             ↓
                                           MFEED
                                             │
  自宅LAN ← PPPoE (IPv6網) ← OCN (7 hop) ←┘

と延々と旅をしてますし、しかも IPv6網は PPPoE でトンネリングして しまっているので、IPv6網での物理的な hop 数はカウントされていません。 実質的には合計で 20 ~ 22 hop 程度はあると考えるべきでしょう。

一方 IPv6 で asao.gcd.org へ ping を打つと、

asao.gcd.org:/root # tcpdump -v -i br0 icmp6
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
09:37:10.664278 kamiya.v6.klab.org > asao.v6.gcd.org: icmp6: echo request seq 256 (len 64, hlim 60)

hlim が 60 までしか減ってません。つまりわずか 4 hop ですね。

六本木LAN → IPv6網 → 自宅LAN

しかも途中に PPPoE のような邪魔なものは入っていないので、 mtu は 1500 のままです。

Filed under: IPv6,システム構築・運用 — hiroaki_sengoku @ 08:38
2006年3月31日

中途半端のススメ

仕事をやりかけのまま中断する。 たくさんの仕事がやりかけのまま溜まっていることになる。

やりかけのまま中断しているものは、いつでも再開できるように、

書きかけのメールなら、
メーラで開きっぱなしでいつでも送信できるように
書きかけの文書なら、
いつでも続きが書けるようにアプリケーションで開きっぱなしに
開発途中のプログラムなら、
いつでもデバッグできるようにデバッグ環境を立ち上げっぱなしに
アイディアを練るときは、
いつでも思いついたことをメモできるように書きかけのメモを身近に
チャットしようとして返事がないときは、
チャットウィンドウを開きっぱなしにしておく
WWW で調べものをするときは、
とりあえず検索して関係のありそうなページを開くだけ開いておく

効用1: 隙間時間を有効に活用できる

一つの仕事を一気に完了させようとしなければ、 とりあえず始めるだけ始めるということでよしとするなら、 隙間時間でも始めることはできる。 あるいは、やりかけの仕事を少しだけ進めることなら、 隙間時間でも活用できる。 また、待ちが多い仕事は多重化することによって、 同時に進行させることができる。

効用2: 心理面

一つの仕事を、ゼロから始めるのは敷居が高い。 やりかけている仕事の続き、ということだと敷居が低い。 一つの仕事を完了させようとすると、 細かいところまで神経を配る必要があって大変。 細部は後で考えればいいやと割り切れば気が楽。 逆に、ほとんど完成していて細部の仕上げだけの仕事は どんどん片付けられるので気分的に楽。

効用3: 同時に考えよう

無意識の思考の活用。 仕事をやりかけのまま寝かせておくと、 いい考えを思いつくことが多々ある。 書きかけの文章を寝かせておくと、 適切な言い回しを思いつくことが多々ある。

4/3追記: 同じような趣旨の日記を見つけた。
 結城浩の日記
 複数の仕事をすることについて
 勉強日記の書き方

Filed under: 自己啓発 — hiroaki_sengoku @ 07:16
2006年3月30日

glibc 2.3 での IPv6

一年以上前に tech ML で取り上げたネタなのですが、現在よく使われている Linux ディストリビューションでも glibc 2.3.2 あたりが使われることもある ようなので紹介します。


KLab のイントラのサーバには、IPv6 なアドレスも割り当ててあります。 例えば、

% host kamiya.v6.klab.org
kamiya.v6.klab.org has IPv6 address 2001:c90:c1c:100e:2e0:81ff:feab:cdef

% host 2001:c90:c1c:100e:2e0:81ff:feab:cdef
f.e.d.c.b.a.e.f.f.f.1.8.0.e.2.0.e.0.0.1.c.1.c.0.0.9.c.0.1.0.0.2.ip6.arpa domain name pointer kamiya.v6.klab.org.

のような感じ。kamiya というホスト名は KLab が六本木ヒルズへ移転してくる 前は、神谷町にオフィスがあったことにちなんでいます。イントラのサーバ群に は地名がつけられているマシンが多く、もちろん roppongi というホスト名の マシンもあります。

で、当時は Linux サーバの多くは glibc 2.2 を使っていたのですが、一部の マシンは glibc 2.3 にバージョンアップしていました。ところが、glibc 2.3 な マシンから ping6 を打ってみると異様に遅い...

% time ping6 -c 3 kamiya.v6.klab.org
PING kamiya.v6.klab.org(kamiya.v6.klab.org) 56 data bytes
64 bytes from kamiya.v6.klab.org: icmp_seq=1 ttl=64 time=1.10 ms
64 bytes from kamiya.v6.klab.org: icmp_seq=2 ttl=64 time=0.563 ms
64 bytes from kamiya.v6.klab.org: icmp_seq=3 ttl=64 time=0.363 ms

--- kamiya.v6.klab.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 20022ms
rtt min/avg/max/mdev = 0.338/0.475/0.569/0.102 ms
0.006u 0.004s 0:40.04 0.0%      0+0k 0+0io 0pf+0w

3 発 ping を打つだけなのに 40 秒もかかっています。-n オプションを 指定して、逆引きを抑制すると、

% time ping6 -nc 3 kamiya.v6.klab.org
PING kamiya.v6.klab.org(2001:c90:c1c:100e:2e0:81ff:feab:cdef) 56 data bytes
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=2 ttl=64 time=0.354 ms
64 bytes from 2001:c90:c1c:100e:2e0:81ff:feab:cdef: icmp_seq=3 ttl=64 time=0.273 ms

--- kamiya.v6.klab.org ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.273/0.536/0.981/0.316 ms
0.003u 0.004s 0:02.02 0.0%      0+0k 0+0io 0pf+0w

などとフツーに 2 秒程度で終わるので、DNS の逆引きに問題があることが 分かります。一回の逆引きに 10 秒ほどかかっているようです。 てっきりネームサーバの設定の問題かと思ったのですが、host コマンドや dnsqr コマンドを使う限り、このような遅れは生じません。ping6 をはじめ、 glibc の getnameinfo(3) を使う場合だけ遅延が発生します。

後で気づいたのですが、この問題が起きるのは glibc 2.3 だけで glibc 2.2 では起きません (つまり kamiya とかでは正常に ping6 できる)。また、 当然ながら glibc 2.3 でも IP の逆引きは正常で、問題なのは IPv6 の逆引き だけです。

# 後述するように問題があるのは glibc 2.3.3 までで 2.3.4 は問題ありません こーいうときは tcpdump が基本だよね、つーことでパケットダンプしてみると、 getnameinfo(3) の場合は、

\[x20010c900c1c100e02e081fffeabcdef/128].ip6.arpa.

というクエリがまず飛び、10 秒ほどたってタイムアウトした後に

f.e.d.c.b.a.e.f.f.f.1.8.0.e.2.0.e.0.0.1.c.1.c.0.0.9.c.0.1.0.0.2.ip6.arpa.

というクエリが飛ぶことが分かりました。前者は見慣れない形式だったのですが、 「Binary Label」ないし「Bit-String」などと呼ばれる形式のようです (ちなみ に後者は nibble 形式)。「Binary Label」は、ドメイン名の一形式として RFC1035 で規定され、DNS での使い方が RFC2673 で決められたにもかかわらず、 ネームサーバでサポートされなかったために、RFC3363 で IPv6 の逆引きの方法 としては、使うのを断念されてしまった不幸な形式のようです。

とはいえ、「DNS で、どーして上位バイトが先にくるんだ~ 実装のこと何も 考えてないな~」と脊髄反射的に拒否したくなる、頭悪い (brain damaged) 形式なので、断念されて幸い、ということもできますね。

2002年8月に RFC3363 で正式に断念された形式なら、そのまま人々の記憶から 忘れ去られて欲しかったのですが、何を血迷ったか、glibc 2.3 は IPv6 の 逆引きで、まず「Bit-String」クエリを試し、タイムアウトしたら「nibble」 クエリを送信するという実装になっています (glibc の resolv は BIND 由来 だから?)。

少なくとも 2004年8月3日に公開された glibc 2.3.3 では Bit-String が デフォルトのままですね。一刻も早く Bit-String が使われなくなることを 願ってやみません。

願ってるだけではアレ (^^;) なので、ソースを見てみると、 glibc-2.3.3/resolv/nss_dns/dns-host.c (2003年10月26日) では

case AF_INET6:
  /* XXX Maybe we need an option to select whether to use the nibble
     or the bitfield form.  The RFC requires the bitfield form so
     we use it.  */

って書いてありますね (Maybe って書くくらいならオプション指定できるように しろよ...)。これが glibc-2.3.4/resolv/nss_dns/dns-host.c (2004年10月25日) だと

case AF_INET6:
  /* Only lookup with the byte string format if the user wants it.  */
  if (__builtin_expect (_res.options & RES_USEBSTRING, 0))
    {
      qp = stpcpy (qbuf, "\\[x");
      ...

に修正されています! つまりデフォルトでは nibble 形式に変更されたんです ね。めでたしめでたし。さっさと glibc 2.3.4 (2005年1月26日) に上げよっと。

...と書いてる間に自宅マシンで 2.3.4 を make して install してみました。 無事、getnameinfo(3) が遅延なく IPv6 の逆引きができるようになりました。 メール書いているうちに自己完結してしまったわけですが、まあ何かの参考に なるかも知れないし、IPv6 に興味を持ってくれる人が増えるといいな、 ということで tech に投げておきます。

#12237                                                          仙石 浩明
https://www.gcd.org/sengoku/             Hiroaki Sengoku <sengoku@gcd.org>
2006年3月30日

IPv6 (1)

バックボーンには導入が進むものの、 一般ユーザには一向に普及する兆しのない IPv6。 可能性があるとすれば、安価なブルータの普及が鍵だろうと思う。

ADSL や FTTH によって安価にインターネットへ常時接続できるようになり、 また一家に複数の PC を持つことが普通になってルータも普及してきた。 このルータに、IPv6 ブリッジ機能が標準で搭載されるようになれば、 IPv6 への移行は格段に容易になるに違いない。 つまりユーザが意識しなくても NAT の内側の LAN 上の PC で IPv6 が使えるようになる。

実際、NTT東日本のフレッツドットネット対応を謳って、 IPv6 ブリッジ機能を持つ安価なルータが多数販売されている。

IPv6対応(フレッツドットネット対応=IPv6ブリッジ機能付き) ルータ一覧

IPv6 が IP に比べて優れた点があるとは思わないが、 IP の「やり直し」という意味はあるだろう。 IP アドレスの割当問題しかり、 無防備な PC の氾濫しかり。

IP が提案された当時、現在のような普及状況は誰も予測していなかったわけで、 今、やり直すことができるのなら、もっと効率的なアドレス割当ができるだろう。

IP スタックが OS に標準搭載されるのが一般的になり始めた頃、 現在のようなウィルス蔓延の可能性を、 アプリケーション開発者の大半が意識できていなかったわけで、 今、やり直すことができるのなら、IP 通信を受付けることの危険性を 認識した上での開発ができるだろう。

Filed under: IPv6,システム構築・運用 — hiroaki_sengoku @ 13:13
2006年3月29日

分からない時は、『分からない』と言おう (3) tweets

「分からない」と言えることが重要だと私が感じるようになったのは、 実は中学・高校時代に遡ります。 中学の時も、高校の時も、それぞれ同級生に、 とても優秀な友人がいました。 そしてどちらに対しても、とても敵わないと思ったものでした。

例えば、何かの説明を彼にしようとして、 頭の中で説明の筋道を考えた上で彼に話しはじめると、 まだ 10 のうち 1 ほども説明していないのに、 「分かった」と言われてしまったことがしばしばでした。 まだ説明は序の口にも到達していないような状況だったので、 話はこれから面白くなるのにと思いつつ、 佳境の部分を端折って説明しようとしたら、 先回りして 「要するに○○ということだろう!」 と要点だけ言われてしまいました。

異常に早く「分かった」と言う彼でしたが、 「分からない」も連発していました。 当時の私には、 彼ほど優秀な人がなぜ「分からない」と言うのかとても謎でした。 私にとっては、 「なるほどなるほど」と相槌を打ちたくなるような話 (別の友人が話した話題だったり、 数学の証明だったり、 コンピュータの仕組みの説明だったり、 SF の設定だったりしましたが) に対しても、 彼は「分からない」と言うのです。

なにぶん 20年以上も前のことなので詳細は覚えていないのですが、 どこが分からないのか問い詰めていったら、 実は私も分かっていなかったことが判明して、 「なるほど!」と腑に落ちたことだけは覚えています。

いかに簡単に、 分かったつもりになってしまうか痛感した瞬間でした。

分かったつもりになっているだけなのか、 ちゃんと分かっているのか、 なかなか判別できるようにはなれなかったのですが、 彼と同じ内容について見聞きした後、 彼が分からない、 というかどうか聞くのが楽しみになりました。

自分は分かったと思っても、 彼が分からない、と言った時は、 慌てて自己の思考過程を振り返り、 どこに論理の飛躍があるのか一生懸命考えたものです。 どう考えても自明なことのように思われるのに、 彼が「分からない」と言った時は、 それはそれは彼が立派に見えたものです。

そんなわけで私は、 「分からない」と言える人を尊敬してしまうようになったので、 「『分からない』と言うことが恥ずかしい」 と思っている人に対して違和感を覚えるのです。

Filed under: 自己啓発 — hiroaki_sengoku @ 09:36
2006年3月29日

OS

OS って何だろう。

言うまでもなく OS といえば、 コンピュータのリソースを管理するものであり、 またハードウェアの仕様の差を吸収して、 異なるハードウェア上で同一のプログラムを 走らせることができるようにするソフトウェアである。

ただ、OS といっても、 ほとんどカーネルと呼んだほうがいいような場合もあるし、 ミドルウェアの機能をまで含んで、 アプリケーションの操作性を統一するようなものまである。 さらには Windows における Internet Explorer のように、 従来はアプリケーションと思われていたものまで OS としてしまう場合すらある。

わたしが初めて使った OS (と呼べるかどうかは微妙だが) は、 CP/M だった。自作 PC (今風に言う自作 PC ではなく、 回路の設計から半田付けまですべて自分で作る PC である。 CPUなどはもちろん LSI を使うが、 ほかは汎用 TTL でロジックをくみ上げているので、 今風に言うチップセットは存在しない) 用の BIOS を スクラッチから開発して、市販されていた CP/M を移植した。

低機能な OS をハードウェアレベルから くみ上げるところから始めたということもあって、 OS というとわたしはカーネルに近いレベルを想定してしまう。一方、

システム管理コラム集 実践してみてわかったことシリーズその1

などを読むと、 あらためて人によって OS という言葉から思い浮かべるものが 異なるものだと実感する。 私にとっては Linux の各ディストリビューションごとの差異など あまり気にしなかったりするのだが、 最近の人にとっては、ディストリビューションが違うと、 異なる OS ととらえることもあるのだろう。

ちなみに、私の自宅サーバは、 10年以上前にインストールした Slackware をベースにしている。 ベースにしているといっても、 カーネルや libc をはじめとして ほとんどすべてのプログラムをアップデートしているので、 元のディストリビューションの痕跡は皆無といっていい。 自作ディストリビューションと呼べるかもしれない。 これを私が管理する全ての Linux マシンにコピーして使っている。

会社 (KLab(株)) のサーバは、私の直轄のチームが管理していて、 こちらはさすがに自作ディストリビューションというわけにはいかず、Debian をベースにしているが、 コアの部分は KLab 独自の拡張を加えている。 つまり誰が作っても同じようになる部分は 既存のディストリビューションを使うことによって「手を抜き」、 コアの部分は独自に開発して運用コストを下げたり、 耐故障性能を向上させたり、パフォーマンスを改善したりしている。

Filed under: システム構築・運用 — hiroaki_sengoku @ 08:08
2006年3月28日

分からない時は、『分からない』と言おう (2)

tech ML に、 「分からない時は、『分からない』と言おう」 キャンペーン を書いたら、 E コマース案件を担当している T さんが書き込んできました。

あえて「分からない」が言えないシーン、 心理状態を想像してみると、 直接コミュニケーションをとっている中で、 「ちょっと調べれば分かりそうなことを聞いてしまうことが恥ずかしい、 (話の腰を折るのが悪い)」 というような心理的なブレーキが作用しているような気がします。 でも分かってないまま話を続けさせるのって相手に失礼ですよね (^^;

まあ、そういう心理なのでしょうね。 「自分で調べてから」 というのは正しい態度のようにも思われますが、 多くの場合は調べる前に忘れちゃったりするわけで、 あまりよろしくありません。

そういう意味では 「分からない」 を言いやすい環境作り、 「分からない」 と言われやすいキャラ作りも一考の価値あるかな、 とも思いました。

さすが T さん、 「分からない」 と言えない人のことだけでなく、 その相手のことまで考えています。 何事もいろいろな角度から見ることが必要ですからね。

だけど、 私が言いたいのは 「分からない」ことをどうやって意識させるか、 なので相手のことを考えてしまうと主題が発散してしまいます。 困ったな (^^;)。

つまり、 「分からない」 を言いやすい環境でないと 「分からない」 と言えないでは、 ダメなんです。 「分からない」 と言うのが一番ためらわれる状況でも、 「恥ずかしい」 という気持ちを押え込んで声を出す訓練を積み上げていって欲しいと思っています。

例えば、講演会等で、質疑応答の時間になった時、 誰も質問しなくって、 大きな会場が静まり返る、 という状況はよくありますよね? その静寂を打ち破って質問できるでしょうか? ほとんどの人は、 たとえ質問したいことがあっても、 なかなか声を出せないんじゃないでしょうか?

私が個人的に尊敬している人って、 ほとんど例外なくそういう場でも臆することなく質問できる人なんですよね。 「分からない」 と言える勇気を持つことと、 スキルアップできること、 との間には強い相関があるように思えてなりません。

大人数が参加する講演会場とかで質問するのは、 まあ後々の課題として、 せめて社内の勉強会や tech ML とかでは、 どんどん 「分からない」 と言えるようになってもらいたいです。

Filed under: 自己啓発 — hiroaki_sengoku @ 10:56
2006年3月28日

ジェイムズ・P・ホーガン

昨日、「ガニメデの優しい巨人」の一節を引用したので、 帰宅してから思わず昔読んだ本を取り出して読み出してしまった。

「わたしは、偶然の一致というのを信じない」

という言葉を 44ページ目に発見。20年以上前に読んだ本なのだが、 当時何度も繰り返し読んだので、 いまでも細部の言い回しなどがどんどん思い起こされる。 原著で読んだこともあるのだが、 日本語訳をほとんどそらで語れるほどだったので、 英語で読んでもスラスラ読めた。ちなみに上記セリフは、原著では

“I don't believe in coincidences,”

となっている。英語だと言い回しのバリエーションがないのだろうか、 誰の発言でも全く同じセンテンスになってしまう。 ジェイムズ・P・ホーガンといえば、真っ先に思い出すのが次の一節:

太陽の連続的な高度低下に伴った大気による短波長の顕著な散乱は、六百五十ナノメートル以下の選択的伝達をもたらし、家畜化した羊類を飼う素朴な牧夫たちの心に非合理的な陶酔感の傾向を生み出す

原著では、

Pronounced atmospheric scattering of shorter wavelengths, resulting in selective transmission below 650 nanometers with progressively reducing solar elevation, produces a tendency toward irrational euphoria among primitive herders of domesticated ovines.
Filed under: その他 — hiroaki_sengoku @ 07:02
2006年3月27日

わたしは、偶然の一致というのを信じない

私が好きな SF の主人公のセリフに、こういうものがある:
「わたしは、偶然の一致というのを信じない」
ガニメデの優しい巨人
ジェイムズ・P・ホーガン (著)

ある事象の直後に、本来直接は関係ないはずの別の事象が起きたら、 両者の間に、なんらかの因果関係があるはず、と考えるのが、 「偶然の一致を信じない」人のとるべき態度であるし、 この考え方は、技術者や科学者にとっての鉄則だと思う。

同じ事象を観測していても、偶然の一致を見つけ出せるか、 それとも代わり映えしない観測データと思って見過ごすかが、 大きな分かれ目になりそうだ。

プログラムの動作ログも同じ。同じログを見ていても、 そこからどれだけの内容を汲み取れるかは、 技術者の資質に大きく依存すると思うし、 スキルアップを目指すなら、自分より優れている技術者が、 そのデータから何を引き出すことができて、 自分がどうしてそれを引き出すことができなかったのか、 詳細に省みるべきだろう。

Filed under: 技術者の成長 — hiroaki_sengoku @ 15:45
2006年3月27日

分からない時は、『分からない』と言おう (1)

「分からない時は、『分からない』と言おう」キャンペーン中、という メールを社内ML に出してみました。

この社内ML というのは tech ML という名前なのですが、KLab の技術者だけでなく、KLab と一緒に開発を行なっていただいている協力会社の方も全員参加していて、少しでも技術に関係ありそうなネタなら何でも自由に書いてね、という ML です。もちろん私も、いろんなことを書いています。

たとえばこんな感じで:

日経ベンチャーの Web ページに、「ピックアップBOOKS」という書評のコーナーがあって、いつも参考にさせていただいているのですが、そこで「ソフトウェア開発で伸びる人、伸びない人」という本の紹介を見つけたので、反射神経的に tech ML にメールを流しました。

----- tech ML に投げたメールここから -----
仙石です。

「分からない時は、『分からない』と言おう」キャンペーン中。

ソフトウェア開発で伸びる人、伸びない人 荒井玲子著
技術評論社 技評SE新書 002 2006/2 208pp 882円
http://nv-club.nikkeibp.co.jp/free/RASHINBAN/20060216/106694/

| プライドには、良いプライドと悪いプライドがある。間違ったプライドを持っ
| ている人かどうかは、次の質問をすればすぐにわかる。
|
| (1) 「わかりません」と言えますか?
| (2) 「難しい」と言って放棄していませんか?
| (3) 説明する機会を避けていませんか?
|
| 「わかりません」と言えない人、「そんなことはわかっています」という反応
| には要注意である。プライドの高い人は、尋ねるということ自体を苦手とする
| 傾向がある。

「分からない」と言えない人って、プライドが原因なんですかね?
「分からない」と言う方がカッコイイってことに、どーして気づかないんだろ?

| ひとつの専門性を持ったら、自分の適正に応じて専門領域を広げていくことは
| できる。一芸に秀でることは、他の分野の専門性を理解することに役立つ。そ
| のためには、ひとつの専門領域を極めることが重要である。

これも、その通りですね。


#13265                                                          仙石 浩明
https://www.gcd.org/sengoku/             Hiroaki Sengoku <sengoku@gcd.org>
----- tech ML に投げたメールここまで -----

優秀な技術者とそうでない技術者との境界線って、「分からない」ことが分かるか否か、だけじゃないかなぁと常日頃から思っているので、手を替え品を替え「分からない」と言えることの重要性を説いているわけです。

# 4/20追記: わからないことをわからないということの重要性を
# 書いているページを見つけました。

Filed under: 技術者の成長 — hiroaki_sengoku @ 14:57
2006年3月26日

epoll(3)

epoll 対応によって高速化した stone の新バージョンのベンチマーク。

version req/sec ms/req KB/sec
stone 2.3 (select) 9.96 100.394 2.80
stone 2.3a (epoll) 781.41 1.280 219.58
apache 983.60 1.017 278.36
stone 2.3
stone 2.3 公式リリース版
stone 2.3a
現時点では CVS にのみ登録されている、次のバージョン:
$Id: stone.c,v 2.2.2.12 2006/03/26 07:30:20 hiroaki_sengoku Exp $
apache
stone なしで直接 httpd へアクセスして測定。

select 版に比べ、epoll 版は、転送速度で 100倍近い性能。 apache への直接アクセスに比べたオーバヘッドは、27% 程度。

# 追記: 性能向上の理由は epoll 化とは別のところにあったことが後日判明

測定条件:

senri% stone -rn localhost:80 2345 >& /dev/null
asao% ab -n 1000 -c 10 http://senri:2345/health
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.121.2.4 $> apache-2.0
Document Path:          /health
Document Length:        131 bytes
Concurrency Level:      10
req/sec
Requests per second [#/sec] (mean)
ms/req
Time per request [ms] (mean, across all concurrent requests)
KB/sec
Transfer rate [Kbytes/sec] received
Filed under: stone 開発日記 — hiroaki_sengoku @ 20:29
2006年3月24日

epoll(2)

stone (従来は select を使用) の epoll 対応の続き。

typedef struct _Pair {
  int common;
  struct _Pair *pair;
  ...
  SOCKET sd;  /* socket descriptor */
} Pair;
...
 struct epoll_event ev;
 ev.events = EPOLLONESHOT;
 ev.data.ptr = pair;
 epoll_ctl(ePollFd, EPOLL_CTL_ADD, pair->sd, &ev);

といった感じで、 ePollFd にソケットディスクリプタを Pair 構造体と一緒に登録する。 そして、epoll_wait でイベント発生を待つ。

 struct epoll_event evs[EVSMAX];
 ...
 ret = epoll_wait(ePollFd, evs, EVSMAX, timeout);

配列 evs には、 発生したイベントが epoll_ctl で登録した構造体とともに 格納されるはずだが、

 common = *(int*)evs[i].data.ptr;

などと構造体のデータを取り出そうとすると、 Segmentation violation が発生することがある。 しかも、デバッグ環境では正常に動くのに、 GCD のゲートウェイ上の設定環境で動かすと、 数分程度で Segmentation violation が発生してしまう。

なぜ期待したデータが得られないのかと、 stone のソースコード全体を見直すことに... しかし問題は見つからず。 epoll の仕様に見落としている点があるのかと思って マニュアルを読み直したり、 挙句の果てに、 Linux のカーネルの epoll 周辺のソースコードをながめたりした。

ptr の値が期待したものと異なる場合があるのかと思って、 epoll_ctl で登録したポインタと、 epoll_wait で取り出したポインタの値を表示させてみると、 予想に反してポインタのアドレス自体は正常のようだ。

早朝、このような stone のデバッグをやっていたのだが、 出社の時間が迫っていたので、作業を中断して出かける。

More...
Filed under: stone 開発日記 — hiroaki_sengoku @ 07:15
2006年3月23日

同時に考えよう (1)

意識した思考はとても遅い。 どのくらい遅いかというと、 言葉に出して思考の筋道を話すことができるくらいだから、 推論の 1ステップに数秒かかったりする。 しかも、脳の短期記憶は 7+α しか覚えられないと言われるから、 中間結果を覚えておく容量もとても小さい。 だから、紙に書き出したり、カードを使って考えたりする。 書いたりカードを並べ替えたりしなければならないので、 さらにスピードが遅くなる。

では、なぜ人は、 コンピュータ顔負けのスピードで思考できるかといえば、 無意識に膨大な推論を行えるからだろう。 よく「ひらめき」とか表現されるが、 要は無意識に行った推論の結果が意識にのぼるから、ひらめく。

同時に一つのことしか考えられない、というが これは意識した思考のこと。 意識は (多重人格者でもなければ ^^;) 一つしかないし、 一つの意識では、7+α の短期記憶しかないから 一つのことしか考えられない。

無意識の思考にはこのような制限はない。 いくつでも同時に思考を走らせ、 結果が得られたらそれを意識にのぼらせればよい。

私が初めて、同時に複数の思考が行われたのを意識したのは、 大学入試のときだった。 早稲田大学の数学の試験だったと記憶しているが、 設問を順に解いていったが、 ある設問を考えていく途中で、行き詰ってしまった。 あまり一つの設問に時間をかけすぎるのは得策でないので、 その設問は後回しにすることにして、次の設問に移った。

次の設問を解き終え、 さらにその次の設問を解いている時だっただろうか (なにぶん 20年以上昔の話なので詳細は覚えていない)、 突然、さきほど行き詰った設問の解き方が頭の中にひらめいた。 そのときは別の設問に集中していて、 少なくとも意識からは完全にその設問のことは忘れ去っていたにも かかわらず、である。

そのときの「ひらめき」の体験があまりに鮮明だったために、 今でも覚えているし、 どうやったら無意識の思考をより活性化させることができるか、 考えるようになった。 意識しなくても思考が続くように、 しかも有意な結果が導かれるようにしなければならないのだから、 そんなに容易ではないが、 日頃から深く考え続けているような事に関しては、 ひらめく頻度が高いように感じる。 おそらく無意識で考え続けているのだろう。

アイディアを次から次へとひらめく人は、 無意識の思考が多数同時に進行しているのだと思う。

Filed under: 自己啓発 — hiroaki_sengoku @ 13:05
2006年3月22日

マルチキャスト(2)

VRRP のマルチキャスト (VRRP Advert) を取りこぼすのは、 NIC が悪いのかも、 と思って別NIC を使用するように変更してみたのだが、 相変わらずスタンバイが勝手にアクティブに昇格したがる。

アクティブ側から見ると

Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Received lower prio advert, forcing new election
Mar 22 12:58:36 asao Keepalived_vrrp: VRRP_Instance(VI)
                     Sending gratuitous ARPs on eth1 for 192.168.0.254

スタンバイ側から見ると

Mar 22 12:58:30 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Transition to MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering MASTER STATE
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      setting protocol VIPs.
Mar 22 12:58:31 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Sending gratuitous ARPs on eth1 for 192.168.0.254
Mar 22 12:58:31 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 added

Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Received higher prio advert
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      Entering BACKUP STATE
Mar 22 12:58:36 senri Keepalived_vrrp: VRRP_Instance(VI)
                      removing protocol VIPs.
Mar 22 12:58:36 senri Keepalived_vrrp:
                      Netlink reflector reports IP 192.168.0.254 removed

tcpdump で確認すると、 VRRP Advert パケットはスタンバイ側に届いているのだが、 keepalived がそれを読めないらしい。 勝手にアクティブになるくせに、 5秒程度で Received higher prio advert して おとなしくスタンバイに戻る。

アクティブになったときに、 (自分がゲートウェイになったつもりで) 本当のゲートウェイへのルーティングを削除してしまうと、 外部への通信が途絶してしまうので、 PPPoE が成功したときのみルーティングを変更するようにした。 これで、勝手にアクティブになったとしても PPPoE が失敗する限りは 実質的に何も変わらないようになった。

keepalived を単なる死活確認にしか使っていない (しかも死んでないのに死んだと誤判断することあり) わけで、 モッタイナイお化けがでそうだ (^^;)。

Filed under: システム構築・運用 — hiroaki_sengoku @ 14:58
2006年3月20日

ルールを変えよう

コバヤシマル テストという戦術シミュレーションがある。 Startrek 映画版 2作目の冒頭で登場する、 艦隊士官候補生のための試験であるが、 (敵の火力が圧倒的であるために) 勝つ方法がない。 そして、勝つことができたのは唯一、カークだけで、 勝てるようにシミュレーションプログラムを細工した、という話。

テストには解があることが多いが、 現実問題だと解があることのほうが稀で、 問題の中だけで考えていては解決不可能なことが多い。 もちろん問題を正面からとらえて解決策を考えることも重要であるが、 一歩視点を引いてみて、問題の枠組み自体を変更できないか、 考えてみることも重要。

問題の解決に集中しすぎると、 問題そのものについて考える余裕がなくなってしまう。 いま取り組んでいる問題は、 どのようなルールにしたがっているのか思いをめぐらせてみると、 そのルールを変えるにはどうしたらいいかが見えてくるかもしれない。

Filed under: 自己啓発 — hiroaki_sengoku @ 13:26
« Newer PostsOlder Posts »