コグノスケ

休日を利用して、横浜市桜木町の帆船日本丸とメモリアルホールを見てきました。今回は帆が畳まれていましたが、日によって張っている時もあるそうです。総帆展帆の姿は直に見たいなー。
スタンプラリーをすると飲み物をくれるっていうから、一応探したんですが全然見当たらない。大した景品でもないし、トリッキーな配置だったというよりは展示物をスルーしまくった俺が悪かったんかな。

ホテルに居るとテレビくらいしか見るものが無いわけですが、そのテレビも最近は靖国の話ばかり。靖国なんて行ったって行かなくたってどっちでも良いじゃないか。それより教育問題とか、消費税（増税）の話とか、もっと大事なことを取り上げて下さい。

今日は寝てばかりだったので、昨日の話。
8月17日の日記でFedora Core 5がハングアップする話をしましたが、回避できました。仕事中（？）に全く関係ないことやっててすみません。

回避方法は、通信ができなくなったら一度適当なessidに変更することです。もし単に通信を復活させたいだけならば、essidを一旦変えて戻せば復活します。あ、その前にifdownが要るかもしれません。
今後はとりあえずこれで乗り切ります。

SeaMonkeyだといけじ氏のサイトで右クリックすると、スクロールバーが2個出るというどうでもいいことに気づきました。惜しむらくは、いけじはここ見てないから伝わらないことか。まあ詮無いことさ。

IKeJI soft by SeaMonkey

ドコモのセキュリティが厳しくなって、持ち込んだPCをネットワークに繋いではならんという決まりができたらしい。けど、前に来た時と同じように研究所からお借りしたThinkpad X31をルータにして、以下のように構成したので問題なし。たぶん。
[自分のPC] <-- Wireless --> [X31] <-- Wired --> [Internet]

X31に入ってたFedora Core 5は無線LAN（ipw2100）をあっさり認識してくれましたが、すぐ接続が切れるし、切れた後二度と繋がらない。そして再認識させようとrmmod ipw2100ってやった瞬間にカーネルがBUGで死ぬ…。これがFedoraクオリティ。

研究所の方にYRP野比駅まで送ってもらいました。ついでに傘まで貸していただいた。横須賀中央駅についた途端に滝の様な雨が降ってきて…傘がなかったらどうなっていたのやら。車は丸目インテのマニュアルでした。

横須賀一日目です。二週間滞在の予定です。
たぶん向こうとしてはさっさと来て仕事してほしいのが本音だと思うのですが…、TXの通勤ラッシュが嫌だったので、無理言って昼ごろの到着にさせてもらいました。

ところでYRPではゲスト用（インターンとか短期の出張用かな？）カードを2日で発行してくれます。早いですよね。対して筑波大学はというと、カードの発行に1ヶ月かかる、なんて平然と言ってんだもん…。カード発行してくれないカードキーシステムなんて金の無駄だ。

ドコモミーティング、仕事内容がちょっと変わったので、今週末までは忙しくなりそうです。

明日から横須賀に出張です。
前回の出張は、ドラムバッグ（こんな感じ）を使いました。底板がなくなっていて、横須賀まで持って行くのに苦労しましたよ。底板がないまま持ち上げると、中央部分の重さを支えきれず三日月状に変形してしまうのです。それが歩く度に足にまとわりついてきて、もー邪魔で邪魔で。あれは参ったな。

今回はスーツケースがある（つーか、今日買った）ので安心です。引っ張って歩けるって素晴らしい！プラスチック製は高いから、ナイロン製にしちゃったんですが、雨が心配です…。

研究室でCDを使った簡易分光器の話をしたら、榮樂氏が興味津々なご様子。家に帰ってから、久しぶりに押し入れから引っ張り出してきました。あらためて見るとしょぼさが際だってます。でもまあ、こういう類の工作は作ってるときが一番ノリノリで楽しいのさ。
以下は簡易分光器の写真です。クリックすると拡大します。

簡易分光器

もう一つ。この分光器で見えるスペクトルを頑張って撮影しました。左が蛍光灯で、右が太陽光です。あまり上手く写りませんでした…。
蛍光灯はHgの輝線スペクトルかなんかが出てるなあ、って感じ。太陽光はもやーっとした感じです。以下の写真はクリックすると拡大します。

蛍光灯のスペクトル   太陽光のスペクトル

写真は全て携帯で撮ったのですが、かなりザラザラになってしまいました。N902iSって感度が高いのか？とりあえず、F506iのように激しく手ぶれしないからOK牧場。

劇場版ドラえもん（とその原作の大長編ドラえもん）って何作あるんだろうと思って、頑張って調べて、以下のような表を作ったが、実はWikipediaや劇場版ドラえもんの公式サイトに同じことがもっと詳しく書いてあった。くやしい。

気を取り直して表を見ると、子供の時に「なんでドラえもんの映画っていつもやってるんだ。」なんてぼんやりと思っていた疑問が気のせいではなく、本当に毎年新作が出ているだけだったことに気づきました。これほど定期的に上映しているとは知りませんでした。
ということは毎年一本は映画の原作考えるってこと？すげー。藤子・F・不二雄さんは偉大ですね。

01. (1980年)のび太の恐竜
02. (1981年)のび太の宇宙開拓史
03. (1982年)のび太の大魔境
04. (1983年)のび太の海底鬼岩城
05. (1984年)のび太の魔界大冒険
06. (1985年)のび太の宇宙小戦争
07. (1986年)のび太と鉄人兵団
08. (1987年)のび太と竜の騎士
    (1988年)のび太のパラレル西遊記（漫画の原作なし）
09. (1989年)のび太の日本誕生
10. (1990年)のび太とアニマル惑星
11. (1991年)のび太のドラビアンナイト
12. (1992年)のび太と雲の王国
13. (1993年)のび太とブリキの迷宮（ラビリンス）
14. (1994年)のび太と夢幻三剣士
15. (1995年)のび太の創世日記
16. (1996年)のび太と銀河超特急（エクスプレス）
17. (1997年)のび太のねじ巻き都市（シティー）冒険記
18. (1998年)のび太の南海大冒険
19. (1999年)のび太の宇宙漂流記
20. (2000年)のび太の太陽王伝説
21. (2001年)のび太と翼の勇者たち
22. (2002年)のび太とロボット王国
23. (2003年)のび太とふしぎ風使い
24. (2004年)のび太のワンニャン時空伝

カネボウフーズのフワリンカというお菓子が、去年の8月くらいに発売されました。ガムとソフトキャンディの2タイプあって、食べると体から良いにおいがするそうです。ガムならバラ、ソフトキャンディならバニラの香りです。
こりゃ面白そう、とコンビニを探したんですがあるのはガムばかりで、ソフトキャンディがありませんでした。ガムを試したけど、自分自身の匂いの変化は感じないので、効果があるんだかないんだか良くわからなくて、がっかりでした。

そんなこんなで、一年ほど忘れていたんですが、今日桜のドラッグ寺島でフワリンカのソフトキャンディを偶然発見。寺島ナイスじゃ。
去年を思い出して嬉しくなって、つい4つも買ってしまいました。ガムのときの過ちを生かして、今度は誰かと会うときに食べようと思います。

ここのところ大抵、夜はドコモ関連のお仕事をせかせかやっています。気づいたら朝になっていて、昼夜逆転生活enjoy中だぜー。締め切りは14日なんですが、もう絶対に間に合わないので寝ます。おやすみ。

塚田氏の髪染めを手伝いました。なにぶん初めてなもので、染まり方がむらになってないと良いんですが…。染髪料を混合したあと、白からどんどん紫色に変色していく様がちょっとキモかった。

染めている合間に、Windows Live Messenger iアプリ版を試しました。FOMA 900i以降に対応しているそうです。ちーっとばかり打つのが面倒くさいですが、携帯音楽プレーヤやゲームと違って音が出ないから、電車の中で使っても迷惑にならないのが良い点です。
アプリの性質上、頻繁に通信するので、Messengerを今後も使うぜって方はパケホーダイをお勧めします。後で請求書見て驚いても知らんぞ。

夜はトリックスター＋を塚田氏とプレイしたあと、二人でゆきむら亭でラーメンを食しました。塚田氏は明日コミケに行くんだと言っていました。

timeBeginPeriod() APIの挙動

昔書いた記事の供養です。2006/04/15加筆修正したもので、現在もこの情報が正しいかどうかは不明です。

Windows APIに、マルチメディアタイマーの最小分解能を指定するtimeBeginPeriod() という関数があります。使ってみたところ、こやつはかなり挙動不審です。本ページに気づいた点をまとめました。またタイマーと分解能について、解説を加筆いたしました。ご参考になれば幸いです。

※当方の環境はWindows 2000 SP4 with VC++ 6.0 SP5です。Windows 9x系はカーネル等が根本的に異なるため、この限りではありません。

Windowsのタイマー

Windowsには2種類のタイマーがあります。

• SetTimer() APIによる標準タイマー
• timeSetEvent() APIによるマルチメディアタイマー

です。同様に、システム時刻の取得にもいくつかの手法があります。

• time() ライブラリ関数
• GetTickCount() APIによるシステム稼働時間（msオーダ）
• timeGetTime() APIによる最大1msの分解能を持つカウンタ
• QueryPerformanceCounter() APIで取得できる3MHz程度の高分解能カウンタ

などがあります。カウンタの値が現在時刻など特定の意味を持つとは限らず、差分として用いることにだけ意味があるカウンタ（高分解能カウンタがそう）もあります。自分のシステムで、現在時刻と一致したからといって他のシステムでも同じとは限りません。ここではそれぞれのAPIの詳細を述べることはしません。

分解能について

先ほど述べたtimeGetTime() APIで得られる値はms単位ですが、分解能を変更することができます。分解能というのはなんでしょうか？もう少し説明しましょう。アナログ（デジタルでも構いませんが）時計を思い浮かべてください。

このとき分解能は時計の針が一度にどれだけ進むかに相当します。分解能を細かくすると、1秒に一度1/60度だけ進む律儀な時計になり、分解能を荒くすると、5秒に一度1/12(= 5/60) 度だけ進むルーズな時計になります。

分解能の適正な値は用途によって異なります。普段の生活では腕時計（1秒の分解能）で十分ですが、短距離走のタイムを計るときに腕時計は使いません。短距離走は1秒以下のタイムで勝負が決しますが、1秒以下の値を指せない腕時計では秒以下のタイムが計れないからです。用途に合った分解能を持つ時計、例えばストップウォッチ（分解能10ms程度）を用います。

同様にコンピュータのタイマーも用途に合った分解能を用います。常に最も分解能の細かいカウンタを用いても良いですが、ストップウォッチが高価なように高分解能のカウンタには制約がある場合があります。例えばWindowsの高分解能カウンターは非常に大きな値を返すため、少し処理が複雑です。適材適所が良いでしょう。

高分解能にこだわる理由

分解能が荒いとゲーム製作で非常に難儀します。60fpsにおいて、1フレームが消費する時間は16.67msです。Windows 2000では初期値の分解能が10msのため、16ms待ちたくてSleep(16) としても20ms待ってしまいます。Sleep(n) がきちんとn[ms] で返ってこなければ60fpsより低い、あるいは高いフレーム数になってしまいます。

高分解能カウンタをスピンウェイト（全力でポーリングして監視する方法）は最も正確ですが、ゲームの処理を終えて時間が余ったとしても、時間の経過を待つ作業でCPU資源を浪費するため、省電力などの観点から見てもあまりよろしくありません。時間が過ぎるのを待つだけの処理なのですから、Sleep() 関数を呼び他のプロセスに実行権を譲りCPU負荷を減らすのが道理です。

timeBeginPeriod() の不思議な挙動

冒頭で述べたとおりtimeGetTime() の分解能は最大で1msですが、Windows 2000では分解能の初期値は10msです。変更するにはtimeBeginPeriod() APIを用います。timeBeginPeriod() を呼び出せば、当然分解能が変更されます。

実験していると不思議なことが2つあって、1つ目はtimeBeginPeriod() を呼び出す前から、分解能の初期値が1msになっていることで、2つ目は副スレッドからtimeBeginPeriod() を呼び出してもtimeBeginPeriod() が機能していないようにみえることです。

調べるとMSN Messenger 6.1が起動していると最小分解能が変化することがわかりました。あるプロセスでtimeBeginPeriod() を呼ぶと他のプロセスに影響するのではないでしょうか？

実験結果 - 他プロセスとの関係

自作のtimeBeginPeriod() を呼ぶプログラムで実験すると、timeBeginPeriod() は最も細かい分解能を「システム全体に」適用することがわかります。

あるプロセスがtimeBeginPeriod() を呼び出し最小分解能を指定した後、他のプロセスがtimeBeginPeriod() を使用すると最小分解能はその値に上書きされます。後に起動したプロセスが終了しても最小分解能は元に戻りません。最小分解能を1msに設定して、その後5msに設定しても分解能が変化しません。

例外として10ms以上の値を指定すると、他のプロセスに最小分解能を上書きされなくなります。しかし最小分解能は10ms固定になります。

もしtimeEndPeriod() を呼ばずに終了する「行儀の悪い」プログラムがあったときは、プロセスが終了すればtimeEndPeriod() を呼んだときと同様に分解能の変更が無効化されます。

全くtimeBeginPeriod() を呼び出さないプロセスの場合は、他プロセスがtimeBeginPeriod() の呼び出しの影響を受け分解能が変化しますが、timeBeginPeriod() 呼んでいた他のプロセスが全て終了すると初期値の10msに戻ります。

実験結果 - マルチスレッド環境における振る舞い

プロセスに複数のスレッドがある場合、メインスレッドからtimeBeginPeriod() を呼ばないと効果がないようです。関数の帰り値は分解能の変更に成功したと報告しますが、最小分解能は変化しません。

ちなみにこの現象は、後述するプログラムでは確認できません。ごめんなさい。

実験結果 - timeEndPeriod() APIの効力

同一プロセス、同一スレッド内でtimeEndPeriod() を呼び出した場合「だけ」最小分解能の指定が解除されます。この条件下ではネストした指定も可能です。例えばbegin(3) begin(2) begin(1) end(2) end(1) とすると、内側にある1msの設定と2msの設定が解除されて、3msの設定に戻ります。

しかし他にtimeBeginPeriod() を利用するプロセスが1つでも存在すると、timeEndPeriod() は機能しません。

結論

最小分解能が変化すると困る場合は、指定できる最も細かい分解能（timeGetDevCaps() APIで取得できます）以外の値は指定しないほうが良いでしょう。途中で他のプロセスに影響されて変わってしまうかもしれません。

Windowsでどこまで計れるか？

脱線話ですが、Windows上で得られる最高の分解能が気になる方もいるかと思います。

おそらくWindows 2000において最も細かい分解能を持つのは高分解能カウンタです。周波数は約3.5MHzで、分解能に直せば300ns程度です。ただしここまで細かい間隔だと、CPUが十分に速くないと取りこぼしてしまいそうです。

近年のOSはカーネルが任意の地点で実行権を取り上げて他のプロセスに渡せる（プリエンプティブ）ため、Windowsは正確なリアルタイム処理には向きません。UNIXなども同様の理由でリアルタイム処理には用いません。しかし最近は組み込み機器向けにリアルタイム処理に対応したLinuxが登場しています。

それとですね……書いた後で気づきましたが、PSX Alternative! にも当ページと同様の実験が紹介されていました。実験方法は違います（向こうはSleep(1) にかかる時間を見ている）が、やはり同様にtimeBeginPeriod() はおかしいと指摘していました。

検証方法

検証方法と用いたプログラムは以下の通りです。

ビジーループしてtimeGetTime() で取得できるカウンターの差分が最小分解能と一致しているか確かめます。最小分解能は高々1msであること、ループに1ms以上かからないことを仮定しています。

// mmtimer.c

#include <stdio.h>
#include <windows.h>

int main()
{
  unsigned long mmt, mmt_b;

  timeBeginPeriod(1);
  mmt = mmt_b = 0;
  while (true) {
    mmt = timeGetTime();
    if (mmt != mmt_b)
      printf("%d ms\n", mmt - mmt_b);

    mmt_b = mmt;
  }

  timeEndPeriod(1);
  return 0;
}

結果は以下のとおりです。

%./mmtimer↓
・
・
1 ms↓
1 ms↓
1 ms↓
1 ms↓
1 ms↓
・
・

値の変化が1msであることがわかると思います。

おまけ

昔書いたメモを発掘したので、これも供養しておきます。

LARGE_INTEGER freq;
LARGE_INTEGER st, ed;

QueryPerformanceFrequency(&freq);

QueryPerformanceCounter(&st);
Sleep(100);
QueryPerformanceCounter(&ed);

簡単なAPIではありますが、動作チェックはしていませんのでご注意ください。