NAKAMURA Minoru の日記 (2012年8月)

先月の日記(2012年07月) 今月の日記(2012年08月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita



8/30 (木)

[Food] 四季懐石 たらふく@武蔵中原

会社の部署の新人歓迎会。 場所はいつもの料理屋「たらふく」(公式食べログ)

この部署の忘年会・新年会・歓送会は概ね「たらふく」です(2010年9月13日2011年1月26日2011年6月17日2011年12月9日2012年3月19日2012年4月27日)


8/29 (水)

DFS: A File System for Virtualized Flash Storage

FAST10 にプリンストン大学の William K. Josephson らの DFS: A File System for Virtualized Flash Storage という論文が投稿されている。 NAND flash 上に構築するファイルシステムの理想形はこうなると考えたプロトタイプである。 DFS という名前だが分散ファイルシステム(Distributed File System)ではなく、 Direct File System の略である。 ZFS、btrfs、ext4 などと同じローカル用のファイルシステムだ。 ただし Fusion-io 社が噛んでいて ioDrive に実装している。 ioDrive 固有の機能も利用していると推測される。 逆に最近 Fusion-io が発表した directFS はこの研究をベースにしていと思われる。

HDD のような磁気ディスクは記録領域がセクタ(伝統的には512バイト)に分割され、アクセスする場合はセクタ番号を使って位置を指定する。 代替セクタのような例外があるが基本的にはセクタ番号が HDD 上の物理的な位置を指している。

一方 SSD は NAND flash の物理特性(同じ領域を二度書きする前に消去が必要)のために、アクセス時に指定する論理セクタ(ブロック)と物理的な位置を示す物理セクタ(ブロック)番号があり、運用時に論理ブロックと物理ブロックのマッピング関係を書き換えながら運用している。 ある論理ブロックへ書き込みが行われた場合、消去済みの物理ブロックのリストから新しい物理ブロックが割り当てられてその論理ブロックへマッピングされる。 同じ論理ブロックへ2回目の書き込みが行われると、次の消去済み物理ブロックへ内容が書き込まれマッピング関係が変更されることになる。 前の物理ブロックは回収されバックグラウンドで消去を受けることになる。 SSD のこのようなマッピング処理やガーベージコレクション処理を行うソフトウェアを Flash Translation Layer (FTL) と呼ぶ。

このような処理がはいるため SSD の論理的な容量と物理的な容量は一致しない。 一般的な SSD の場合、論理容量が 1TB (=1,000,000,000,000 bytes) だが物理容量は 1TiB (=1,099,511,627,776 bytes) だったりして物理容量が論理容量よりも少し多い。 この差分部分は予約領域として、NAND flash が物理的に壊れて書き込めなくなった時の代替領域や、新規割り付けをスムーズに行うための余白として使う。 しかし FTL の組み方によっては論理容量 >> 物理容量にすることも可能だ。

広大な論理アドレス空間を用意してファイルを直接割り付ける

DFS の特徴の 1 つ目は、FTL にあたる Linux カーネルのドライバと ioDrive の Virtualized Flash Storage Layer を使って 273 バイト という非常に大きな論理容量を実現した点だ。 使っているのは ioDrive 1枚なので実際の物理容量は約 160 GB しかない。 そのため非常に sparse な論理アドレス空間ができたことになる。

この空間を使って DFS は非常に贅沢なファイル配置を行う。 1つのファイルは論理アドレス中の連続する 2TB の領域に割り付ける。 仮に1バイトのファイルでも 241 バイト分の論理ブロック空間上の領域が予約される。 こうなるとファイル中のアクセス位置を計算するのは非常に簡単で、i-node 番号から論理アドレス空間中の先頭位置が決まるが、これにファイルのオフセットを足してやれば論理ブロック番号が決まるのだ。

無論、論理ブロック空間の中では実際にデータが書き込まれた位置だけに物理ブロックがマッピングされる。 これは VFSL の役目であり DFS のソースコードは memory mapped file の感覚で読み書きするだけでよい。

シンプルなクラッシュリカバリー

DFS のもう一つの特徴は、従来のファイルシステムが備えていたジャーナル(Journal) を FTL にあたる VFSL にオフロードする点である。

ジャーナルを持つファイルシステムは、ファイルシステムへの書き込み内容を事前にジャーナル領域に書き込む。 ジャーナルへの書き込みが途中で失敗した場合でもファイルシステム本体部には何も書いてないので、処理も元に戻す(ロールバック)ことが可能である。 いったんジャーナルへの書き込みが成功すれば、ジャーナルに書いた内容をファイルシステム本体部に書き込む。 この処理が途中で失敗してもジャーナルに内容が残っているので、ジャーナルをファイルシステム本体部に書き出す処理を再度行えばよい。 このためジャーナルを持つファイルシステムは、電源断などのシステムの故障に強くなる。

一方、ジャーナル方式のデメリットとして同じデータをジャーナルとファイルシステム本体部に二重に書き込む必要がある。 二重に書き込むので大雑把にいってディスクの書き込み性能の半分しか書き込めないことになる。 このようなジャーナル方式以外には ログ構造化ファイルシステム(Log-structured filesystem) なども存在するが、これはディスクがいっぱいになった後に GC 処理が必要等など別のデメリットがある。

一方、DFS は先ほどの (i-node から決まる論理アドレス空間上の開始位置) + (ファイルオフセット) で簡単に計算できる場所に、ジャーナルなしでガンガン書き込みを行う。 ただし VFSL は論理ブロックと物理ブロックのマッピング関係を制御しているので、いわば VFSL のレイヤーで log-structured ができていることになる。 DFS はこの性質を利用して一連のデータ書き込みが途中で失敗した場合、論理ブロックと物理ブロックのマッピングを元に戻すという方法でロールバックを実現する。 この処理は VFSL の本来処理に少し手を加えた程度で済む(はず)。 DFS 層のソースコードにはジャーナルも log-structured も不要になる。

メリット

DFS は広大なアドレス空間に直感的なファイルマッピングを行うことで lookup 処理の簡略化が可能になる。 このため目的とするデータにたどり着くまでに途中で読まなければならないブロックの数が減って高速化できる。

また FTL にあたる VFSL がフラグメンテーションの解決やトランザクションライト機能を提供してくれるため、データ構造や制御構造が簡単になりファイルシステム自体のソースコード行が減る。 これが実行ステップ数の減少につながり高速化に寄与する。

DFS はローカルマシンのストレージ用のファイルシステムだったが、ネットワークストレージが同等をそなえていれば SAN に作るファイルシステムとして DFS を使うことができると思われる。 その場合、ローカルの NAND Flash のレイテンシ << ネットワークのレイテンシだけにより効果が大きくなると思われる。

[Food] 洋食キムラ

本日は沼津出張。 帰りに新横浜駅の駅ビルキュービックプラザの洋食キムラ(キュービックプラザ食べログ)で食べる。 ハンバーグは非常に軟らかい。


ハンバーグセット

8/28 (火)

VMware Player 5.0.0

VMware Workstation 9 と一緒に VMware Player 5 が公開された。 このバージョンから VMware 上で KVM や Hyperv-V など別のハイパーバイザーを動かす Nested VM を正式にサポートしたのと、ゲストの仮想 CPU でパフォーマンスモニタが有効になったのが大きい。 これまで VMware は VTune や OProfile のような HW パフォーマンスモニタ機構を使ったプロファイラが動作しなかったのが、このバージョンから OK になった。 機能を使うには「仮想マシンのプロセッサ設定」を「Intel VT-x/EPT または AMD-V/RVI を仮想化」「仮想 CPU パフォーマンス カウンタの有効化」を ON にする。

ただし新しい機能を有効化するには、ゲスト仮想マシンが Workstation 9 / Player 5 と互換性を持つ必要がある。 そのためか以前の Workstation や Player で作った仮想マシンをそのまま使うと「仮想マシンのプロセッサ設定」にメニューが出てこない。

これは VMware Player 5 でダミーの新しい仮想マシンを作って、その .vmx を修正して古い仮想マシンのディスクイメージ(.vmdk)を追加してやればよい。 私の例では赤字の部分を修正し、.vmdk と関連ファイルを新しい仮想マシンのディレクトリに移してやれば動作した。

.encoding = "Shift_JIS"
config.version = "8"
virtualHW.version = "9"
numvcpus = "2"
vcpu.hotadd = "TRUE"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
memsize = "2048"
mem.hotadd = "TRUE"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "hdd_sda.vmdk"
scsi0:1.present = "TRUE"
scsi0:1.fileName = "hdd_sdb.vmdk"
ide1:0.present = "TRUE"
ide1:0.autodetect = "TRUE"
ide1:0.deviceType = "cdrom-raw"
...

追記

新しい仮想マシンとニコイチしなくても、既存 .vmx の virtualHW.version を 9 に変更するだけでうまくいくようだ。

赤字の部分を変える。

.encoding = "Shift_JIS"
config.version = "8"
virtualHW.version = "9"
numvcpus = "2"
vcpu.hotadd = "TRUE"
...

8/27 (月)

[Prog] gcc で x86 のインラインアセンブラを書くために

gcc でインラインアセンブルを書く場合、レジスタの割り付けをコンパイラ側に委ねて空いているレジスタを自動的に選択させる記述方法がある。 しかし i386 & x86-64 では、同一のレジスタでも %al、%ah、%ax、%eax、%rax のようにアクセスする命令によって記法が変わる。 インラインアセンブラはこれを自動的に変換はしてくれない。

例えば以下のような関数は %rax を一時変数として使うインラインアセンブラだが、命令に応じて %rax を %eax や %al に書き換えている。

int add(unsigned long r1, unsigned long r2)
{
    asm volatile(
         "xorl  %%eax, %%eax\n\t" // xorq %rax,%rax よりも xorl %eax, %eax の方がコード長が短い
         "addq  %%rsi, %%rax\n\t" // 64 ビット演算なので %rax
         "addq  %%rdi, %%rax\n\t" // 64 ビット演算なので %rax
         "setz  %%al\n\t"         // SETcc はレジスタの下位 8 ビットだけ
         "retq\n\t"
             : : : "rax");
    // 
}

上記はレジスタを決めうちのハードコーディングである。 これをレジスタの自動割り当てすると以下のように書ける、、、ように思える。

int add(unsigned long r1, unsigned long r2)
{
    int ret;
    asm volatile(
         "xorl  %0, %0\n\t" // xorl %rax,%rax と展開されてエラー
         "addq  %1, %0\n\t" // addq %rsi, %rax なので OK
         "addq  %2, %0\n\t" // addq %rsi, %rax なので OK
         "setz  %0\n\t"     // setz %rax なのでエラー
             : "=r"(ret) : "r" (r1), "r" (r2) : );
    return ret;
}

しかしこれはエラーとなる。 命令の指定するオペランド長とレジスタ長が異なるためである。 エラーを消すためには命令に合わせてレジスタを %rax (64ビット)、%eax (32ビット)、%ax (16ビット)、%al (8ビット)、%ah(%ax の上位8ビット)のようにコンバートする必要がある。

これにはインラインアセンブラのオペランド指定にオペランド長を示すプレフィックスを入れる。 x86-64 の場合には以下のようになる。 詳細は gcc ソースコードの $(GCC)/gcc/config/i386/386.md ファイルに記述されている。

%b0下位8ビット
%w016ビット
%k032ビット
%064ビット
%h0上位8ビット(%ah, %bh, %ch, %dh だけ)

命令のオペランド長を示す差フィックス b (8 ビット)、w (16 ビット)、l (32 ビット)、q (64 ビット) と異なるので注意。 また i386 (32 ビットモードの場合) では %k0 は不要で、ただの %0 でよい。

正しくは以下のようになる。

int add(unsigned long r1, unsigned long r2)
{
    int ret;
    asm volatile(
         "xorl  %k0, %k0\n\t" // xorl %eax, %eax と展開されて OK 
         "addq  %1, %0\n\t"
         "addq  %2, %0\n\t"
         "setz  %b0\n\t"      // setz %al と展開されて OK
             : "=r"(ret) : "r" (r1), "r" (r2) : );
    return ret;
}

GCC 3.1 からは %0、%1 の代わりに %[name] のような名前を付けることができるが、 その場合も以下のプレフィックスを付ける。

int add(unsigned long r1, unsigned long r2)
{
    int ret;
    asm volatile(
         "xorl  %k[result], %k[result]\n\t"
         "addq  %[op1], %[result]\n\t"
         "addq  %[op2], %[result]\n\t"
         "setz  %b[result]\n\t"
             : [result] "=r"(ret) : [op1] "r" (r1), [op2] "r" (r2) : );
    return ret;
}

8/26 (日)

[Movie] トータルリコール

川崎チネチッタで鑑賞。

[Food] すみれ@ラゾーナ川崎店

ラゾーナ川崎のフードコートにあった「すみれ」が本日閉店。 2007年頃に出店してきたが(2007年7月22日の日記)


フードコート内の屋台

味噌ラーメン

追記:8/29

新横浜ラーメン博物館に「すみれ」が戻ってくるらしい(公式ページの「すみれ」紹介)

もともと新横浜ラーメン博物館には「すみれ」があったが 8 年前に退店。 数年してすみれ・純連系の味噌ラーメンの店「らーめんの駅」が出来た(2009年5月7日)。 ところが「らーめんの駅」は先月退店。 一番人気の店がラー博からなくなったと訝しがったが、こういうことだったのね。


8/22 (水)

[Prog] gcc の特定関数のインライン展開を抑止する

gcc は memcpymemsetmemcmp など特定の関数をビルトイン関数と認識してインライン展開してしまう。 例えば以下のコードを x86-64/Linux で gcc 4.4.6 でコンパイルすると memcmp は展開されてしまう。

int memcmp_use(const void* s1, const void* s2)
{
    return memcmp(s1, s2, 8) != 0;
}
memcmp_use:
        movq    %rdi, %rax
        movl    $8, %ecx
        movq    %rsi, %rdi
        movq    %rax, %rsi
        repz cmpsb
        setne   %al
        movzbl  %al, %eax
        ret

このようなインライン展開を抑止するには -fno-builtin-functionname を指定すればよい。 functionname には指定したビルドイン関数の名前を指定する。 例えば -fno-builtin-memcmp と指定してコンパイルすると以下のように memcmp をコールするコードとなる。

memcmp_use:
        subq    $8, %rsp
        movl    $8, %edx
        call    memcmp
        testl   %eax, %eax
        setne   %al
        addq    $8, %rsp
        movzbl  %al, %eax
        ret

[Prog] addr2line で .so ファイル内のアドレスを解決する

binutils の addr2line は実行アドレスからバイナリ内のデバッグ情報を参照し、ソースファイル名と行番号を表示してくれる便利なツールである。 例えば a.out の 0x4004c4 のアドレスにあるコードの元となったソースファイル名と行番号は以下のようにして検出できる。

$ addr2line -e a.out 0x4004c4
/home/nminoru/test.c:4

この方法は a.out には適用できるが動的ライブラリはメモリ上のどの位置にマップされるか動的に変わるため、addr2line では簡単な解決ができない。

例えば a.out が libdummy.so を動的にリンクし、その時の 0x7f763d8a65cc というアドレスが得られたとする。 このアドレスを addr2line に指定してもうまくいかない。

$ addr2line -e a.out 0x7f763d8a65cc
??:0n
$ addr2line -e libdummy.so  0x7f763d8a65cc
??:0

これを解決するためには libdummy.so が a.out の実行プロセスのメモリ空間上のどの位置にマップされたかを知る必要がある。 Linux の場合、/proc/<pid>/maps を見ると 0x7f763d8a65cc は以下のセグメントに含まれていることが分かる。 このセグメントの先頭アドレスは 0x7f763d8a6000 となる。

7f763d8a6000-7f763d8a7000 r-xp 00000000 fd:02 2228769                    /home/nminoru/libdummy.so

そこでセグメント内のオフセットを 0x7f763d8a65cc - 0x7f763d8a6000 = 0x5cc と計算する。 この 0x5cc を使って addr2line を実行すると、対応したデバッグ情報が得られる。

$ addr2line -e libdummy.so 0x5cc

[Prog] gcc のコンパイルオプションを埋め込む

実行ファイルだけが残っている場合、それがどのようなコンパイルオプションでコンパイルされたか知りたいことがある。 gcc では -frecord-gcc-switches オプションを指定すると、オブジェクト中にコンパイルオプションが埋め込まれることになる。

$ gcc -ggdb -O3 -frecord-gcc-switches hoge.c

確認するには .GCC.command.line セクションの内容を表示する。

$ readelf -p .GCC.command.line a.out 

String dump of section '.GCC.command.line':
  [     0]  hoge.c
  [     7]  -mtune=generic
  [    16]  -ggdb
  [    1c]  -O3
  [    20]  -frecord-gcc-switches

このオプションは gcc の 4.3.0 以降に存在する。


8/19 (日)

芝オクトーバーフェスト

東京タワーの下で芝オクトーバーフェストが開催されたので行って見る。

頻繁に開催されるオクトーバフェストは開催団体が同じせいか出場店も似通っている。 アルコールは飲まないので、割と飽きてきた。

とはいえソーセージを食べる。

[Food] Tapas Blanco@秋葉原トリム店

タパスブランコ 秋葉原トリム店(ぐるなび食べログ)で晩飯。 6月12日7月15日と来ている。


アリオリポテト

バレンシア風パエリア

バレンシア風パエリアはひよこ豆と鶏肉を使うそうな。 これが元祖らしい。 ただ6月12日に食べた海鮮パエリアが出し汁が利いて一番美味しかった。

アリオリポテトはポテトのマヨネーズあえですね。


8/18 (土)

川崎へ帰京

徳山駅からのぞみに乗って川崎へ帰京しました。

徳山駅に貼ってあった変なポスター。

[Food] サンティノ@日吉

日吉でいったん降りてイタリアンレストランのサンティノ(ホットペッパー食べログ)で晩飯を食べる。


サラダ


アルミホイールを外すと

白身魚とトマトをバジリコソースで蒸し焼きにしたもの

ゴルゴンゾーラと生ハムのフィットチーネ

8/16 (木)

福川へ

福川へ盆参りに行く。


周南にある風車は今日も回っていない

山陽本線の電車に開閉ボタンが

8/15 (水)

角島

須方氏と角島(つのしま)大橋(角島ナビwikipeida)を見に行く。 角島は山口県の北西部にある離島で、2000年に角島大橋が出来て本州と繋がった。 景色だけ見ると日本とは思えぬ場所である。

とはいえ角島は本州の田舎山口県のさらに田舎。 防府から 40km 以上ある。


山口県の名物黄色いガードレール

風に吹かれる何か

到着。 橋の近くに記念碑がある。 橋の観光スポットになっており多数の人が押しかけている。

角島の海にかかる橋を本州側から堪能する。 美しい。

橋を渡って角島側へ。


灯台
これは登ることもできるが有料

港に特産物を売る店がある

島側から大橋を望む

角島を堪能して下関の南部に移動する。


イカが描かれた体育館

お洒落なトンネル

元祖瓦そばのたかせへ

お昼は山口県を代表する郷土料理瓦そばを食べにたかせへ行く。 しかし茹るような暑さの中、店先に並ぶほどの行列が出来ている。 命が惜しいので撤退した。 アイルビーカムバック。

瓦そばの由来。

[Food] 弘々家@下関

結局、お昼は須方氏の弟氏のお薦めの店広島風お好み焼きの店弘々家(ぐるなび食べログ)で食べます。


店先


スペシャルねぎともちちーず

巌流島

関門海峡に浮かぶ無人島巌流島に渡ります。 正式な島の名前は船島です。 巌流島へ往復する連絡船が何社が出ています。

黄色の船に乗りましたが多分これは半没水型双胴船でしょう。


桟橋

気温は高いものの船外は潮風を受けるので気になりません。


関門橋

海峡ゆめタワー

島が見えました

巌流島は、、、ぶっちゃけ何もない小さな島です。

テクテク歩きますが、糞暑いので死にそうです。

宮本武蔵と佐々木小次郎が戦ったという伝説を記念した銅像が建っています。

宮本武蔵が乗ってきたであろう伝馬船のレプリカがあります。 この船を見ていると、武蔵が遅れてきたとしたら船が流されたからだと分かります。 ていうか関門海峡を素人が渡るのは無理ではないかしら?

佐々木巌流之碑だそうです。 伝説上の人物ですが、この地であればサーバントとして召還できると思われます。

こちらは船島の本来の神社です。


何だか変な絵馬が

痛絵馬!!
らき☆すたですね。

迎えの船で帰ります。

海響館

最後に下関市立しものせき水族館海響館(公式)へ。 海響館は1999年の台風18号による施設破損の影響で旧水族館が閉鎖され、その代替として建てられた比較的新しい水族館。 6〜7年前に来た時は開設当初だったのか、近海物の魚しか居ない侘しい水族館だったが、今は魚も増えて充実してきたようだ。

巌流島から戻った時点で入館停止の午後5時だったのだが、6時からの夜の水族館を待って入場する。 その間近場の喫茶店ぽい店で時間を潰す。


湯布院長寿畑 豆腐アイス

確かにちょっと豆腐っぽい

夜の部を待っていた人は多いようだ。

室内にあるペンギンの水槽は底部が人が通れるようにくり貫いてあります。 泳いでいるペンギンのお腹が見えるのです。

こっちは室外にあるフンボルトペンギンの特別保護区。 フンボルトペンギンの生息地であるグアノ地帯(2月27日の日記)を模した場所が作られている。 無論、グアノの鼻が曲がるような臭いは再現されていない。


個体管理のために翼のところにタグがあります

室内展示室へ移動。 まずクリオネがお出迎えをしてくれます。


クリオネ

近海ものの部門です。


エイ

ウミウシ

海のギャングスターうつぼ。


うつぼ

うつぼ

一匹だけですがマンボウがいます。 でかい!!


マンボウ

いろいろな種類のフグがいます。

シーラカンスの展示。


シーラカンス(剥製)

深海魚たちです。


ラブカ

シロナガスクジラの全身骨格標本です。 ノルウェーのトロムソ大学付属博物館からの借り物だそうです。

[Food] らーめん ろくの家@宇部

らーめんのろくの家(食べログ)で夕食を。


看板

六黒ラーメン

今日見つけた美しい国

さすが山口県。 いまでも安倍晋三のポスターがここかしこに貼られています。


8/14 (火)

[Food] cafe Glebe

畔上氏と再会。

防府の銀座(という名前の寂れた商店街)の中にある cafe Glebe(公式食べログぐるなび) というお店で昼飯を食べてゆく。


店構え

牛すじカレー

カプチーノ

山口県立山口博物館

ドライブで山口市に。 山口県立山口博物館では大鉄道展というのをやっているので観に行くことに。 案の定、夏休みの真ん中で子供たちが大量にいる。


ゆるキャラ「なっとくん」

大鉄道展のほとんどは鉄道関係の展示物と模型の展示。 あと子供が乗れるリニアモーターカーがある。 乗れるのは子供だけのようだった。






常設展もある。

天体部門では隕石の展示がある。




山口県内の現生動物の剥製展示。



化石種の展示。 本物の化石は少ない。






発明部門。



マンガ倉庫

山口市にマンガ倉庫(公式)というドンキホーテとまんだらけを足して2で割ったような店が出来ていた。


エイリアンの実物大?模型

[Movie] アベンジャーズ

防府の駅前イオン(旧ニチイ&パル→サティ)のワーナーマイカルで先行上映の「アベンジャーズ」を鑑賞する。 畔上氏は 3D 酔いをする。


8/12 (日)

防府に帰省

新幹線の自由席で帰省。 新横浜から大阪止まりののぞみに乗っている間は座れたのだが、以降立ちっ放しになる。


8/11 (土)

[Movie] プロメテウス

川崎チネチッタで「プロメテウス」の先々行上映を観る。 「決して触れてはならない謎。それは想像を絶する<人類の起源>の真実だった!」というコピーに惹かれて観に行ったが、エイリアンの前日譚だと知ってショックを受ける。

これは観に行ったことを後悔した。

SoftBank Ultra SPEED 回線 & 007z

山口県への帰省に備え WiMAX を買いに行ったのだが、2年縛り契約で端末を1円購入し今月1ヶ月だけ使ってすぐに解約するとなると、解約料を含めて1万6千円近くかかるとなる。

一方、その場で SoftBank の Ultra SPEED 回線を使った無線 Wi-Fi ルータの場合、廉価の端末(007z)を購入し、フラットデータし放題を1ヶ月だけ使って、次月以降は 0 円寝かせをすると 9千円程度で納まると聞き、時間もないのでそれで契約してしまった。


8/7 (火)

今日のゴーヤ

会社の菜園のゴーヤを撮ってみた。 もうすぐ収穫。


8/5 (日)

[Movie] メリダとおそろしの森

川崎の東宝シネマズで「メリダとおそろしの森」を鑑賞。 原題は "Brave" なので随分改題されている。

久しくディズニー映画を観なかったので、かの会社の流儀に戸惑う。 普通の映画は「No More 映画ドロボー」が終わると本編がはじまるのだが(No More 映画ドロボーはフィルムの先頭に必ず焼き付けられている)、映画ドロボーの後にディズニー映画の宣伝が続くのでびっくり。 さらに全然予備知識を入れずに見たので、短編『ニセものバズがやってきた』『月と少年』が同時上映だと知らず、別の劇場に入ったのかと勘違いして焦った。

本編の「メリダとおそろしの森」はディズニーのフェアリーテールを目指したらしい。 感想はここには書かないけど楽しめた。


8/1 (水)

Netperf でヒストグラム

Netperfiperf などと並ぶネットワークのパフォーマンス測定ツールである。 Netperf はネットワーク負荷のパターンをいろいろ指定可能だが、指定方法によってレイテンシーの平均値以外に、最大値、最小値、50パーセンタイル値(いわゆる中央値、median)、90パーセンタイル値、99パーセンタイル値などがとれる。 xxパーセンタイル値とは測定値を小さい順に並べて xx % 目に出てくる値のことである。

この機能は netperf の man の -j オプションにおける記述に記載されている。

Instruct netperf to calculate additional statistics on timing when running an omni test. Display of said statistics will depend on the presence of the corresponding output selectors in the output selection. These are MIN_LATENCY, MAX_LATENCY, P50_LATENCY, P90_LATENCY, P99_LATENCY, MEAN_LATENCY and STDDEV_LATENCY.

しかしこの機能を呼び出すことが存外難しい。 手順をここにメモしておく。 バージョン 2.6.0 で確認した。

サーバの設定

まず計測サーバとなる netserver を起動する。 一般的には引数なしで立ち上げるとデーモン動作する。

$ netserver

これだけでサーバを起動できない場合には、ポート番号とサーバアドレスを指定する。 ポート番号は -p の数値。 サーバアドレスはクライアントから通信の待ち合わせを行う IP アドレスを-L name,family で指定する。 name は名前または IP アドレスだが、family には IPv4 なら 4 を指定する。

$ netserver -L 192.168.100.2,4 -p 13000 

クライアントによる計測開始

Netperf は -t オプションにより複数のテストセットを切り替えられる。 この中でヒストグラムの測定が可能なのは omni テストだけなので -t omni を指定する。 またヒストグラムを設定する場合は -j オプションも指定する。

以下は指定例である。

$ netperf -j -t omni -l 10 -H 192.168.105.2 -4 -p 13000 -- -O /tmp/foo
  • -- より前がグローバルオプションで、後にあるのがテスト(この場合 omni テスト)固有オプションである。
  • -l は計測時間を秒数で指定。
  • -H はサーバのホスト名または IP アドレスを指定。
  • -p はサーバのポート番号を指定
  • -4 は IPv4 での接続を指定。

/tmp/foo は事前しておいた設定ファイルである。 各行の1つづつヒストグラムの設定項目を記述する。 Netperf のソースコード中の nettest_omni.c の中にある netperf_output_name 列挙子である。

MIN_LATENCY
MAX_LATENCY
P50_LATENCY
P90_LATENCY

同時に指定できるのは 4 つまでである。 これはソースコード中の NETPERF_MAX_BLOCKS マクロにハードコーディングされており、動かせない。

#define NETPERF_MAX_BLOCKS 4

Omni テストのオプションは -o 設定ファイル(CSV)、-k 設定ファイル(KEYVAL)、-O 設定ファイル(HUMAN) の 3 種類のいずれかを選べる。 表示方法に差があるが、いずれもヒストグラム表示が可能。


先月の日記(2012年07月) 今月の日記(2012年08月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita


Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp