NAKAMURA Minoru の日記 (2008年2月)

先月の日記(2008年01月) 今月の日記(2008年02月)
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
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita



2/22 (金)

[CPU][Linux] IA-64/Linux の時刻の精度

IA-64/Linux の時刻は Interval Timer Clock (ITC) を使ってカウントしている。 ITC はシステムバスを分周したサイクルカウンタで、ITC はプロセッサ毎に存在している。 起動時がゼロで以降は実時間に即してカウントアップし続ける。 Linux のシステム時刻も起動時に EFI から貰うが、以降は ITC を使って時刻を計算することになる。

SMP 時には IA-64/Linux は最初の起動させる CPU-0 の ITC を基準にしている。 2番目以降のプロセッサの ITC は CPU-0 に同期させられる。 ITCの 同期はソフトウェア的な手段を用いるので完全に同一にはならないが、実用上問題のない精度には調整される。 いったん ITC が同期させられると、同じシステムバスを分周しているので進み方は同じ(はず)だ。

でここまでが前振り。

時刻の精度

Linux は xtime というデータ構造で管理している。 1秒間に 100 回タイマー割り込みを起こすなら、各タイマー割り込み毎に xtime を 1/100 秒ずつ加算している。 gettimeofday などでユーザが時刻を取得しようとすると xtime が参照されるのだが、それだけだと時刻としての精度が不足するので、 タイマー割り込みの間は別手段で補正をかけている。

struct timespec {
        time_t  tv_sec;         /* seconds */
        long    tv_nsec;        /* nanoseconds */
};

extern struct timespec xtime;

IA-64/Linux の場合、タイマー割り込みの精度は 1/1024 秒(HZ=1024) と 1/250 秒 (HZ=250)が良く使われる。 1/1024 と中途半端なのは IA-64 は整数除算がないので、シフトで代用できる値が選ばれたと思われる。 仕事で使っている RedHat Enterprise Linux (RHEL) 4 は 1/1024 になっているので、どちらかというと前者が興味の対象である。

問題が二つある

  1. xtime に1/1024 秒を追加できるのか?
  2. 1/1024 秒毎に正確にタイマー割り込みが起こせるか?

まず1だが、 悲しいことに 1/1024 秒を 10 進数数値に変換することができない。 1秒をナノであらわした 1000,000,000 を元に (1000,000,000 + HZ/2) / HZを計算した 976,563 を使う。 1024回タイマー割り込みが起こった後は xtime は 1,000,000,512 ナノ秒になり 512 ナノ秒ほど余分に進むことになる。

一方、 2の方はファームウェアから通知されたITC 周波数(itc_freq)をベースに (itc_freq + HZ/2) / HZ を計算している。 この値は itc_freq によって変ってくる。

  • Madison の 1.3GHz を載せたマシンでは itc_freq は正確に 1,300,000,000 をさしていた。 タイマー割り込みを ITC で 1,269,531 カウント毎に起こすことになる。 タイマー割り込みを 1024 回起こすとITC は 1,299,999,744 ポイント進んでいるはず。 これは 120 ナノ秒の遅れに相当する。
  • Montecito の 1.4GHz を載せたマシンでは itc_freq は 350,009,688 をさしていた。 タイマー割り込みを 1024 回起こすと ITC は 350,009,344 ポイント進んでいる。 これは 980 ナノ秒の遅れに相当する。

タイマー割り込みは 1 秒間に 1,024回起こすことになっているが、実際には微妙にずれが生じている。 そして 1,024 回タイマー割り込みが起きた時の xtime は 512 ナノ秒ほど進んだ値を加算している。

結局…

IA-64/Linux はソフト的な丸め誤差の関係でシステム時刻が1秒間に 1マイクロ秒から100ナノ秒ぐらいの間でずれていっている。 1秒に1マイクロ秒だと1日で誤差が0.0864秒にもなる。 そうなると二つの事象の時間差を計測するのに、ITC で計測して itc_freq で割った「時間」と gettimeoday を計測して差をとった「時間」ではズレが生じることになる。 今まで気づかなかったが結構痛いな…
# 実際には ITC も正確ではないのでハード的な誤差も生じている。


2/9 (土)

キーボードの打鍵数

職場にいる間に自分の端末の前でどのぐらいキーボードを打っているのかを調査しているのだが、一日に4万回から8万回ほど打鍵していると判明。 その日に会議がどのぐらい入るかで全然変るのよね。


2/7 (木)

[CPU] Itanium の Hyper-threading

Montecito (Itanium2 プロセッサの9000台) システムの Hyper-threading を有効にした場合の動作をチェックしている。 Itanium の hyper-threading は Switch on Event Multi-Threading (SoEMT) で、主に以下の3つの契機で発生する。

  • L3 キャッシュミスの発生時
  • 一定時間毎
  • hint@pause 命令実行時

この中で「一定時間毎」の一定時間がどの程度なのかがはっきり記述されていない。 パフォーマンスモニタで計測していると無負荷時には平均して約1,000サイクルに1度の割合でスイッチが起きているのが分かる。 ただスレッドが動き続けた場合の最長時間はどうやって調べればよいものか?


2/6 (水)

[Linux] 同一サブネットに2枚以上の NIC が刺さっている場合の動作

Linux の Address Resolution Protocol (ARP) は少々癖があるらしい。 同一サブネット内に複数の NIC を挿すホストと通信する場合、意図したインターフェイスにパケットが送れない危険性があるそうだ。

  • 1台の Linux マシンが同一のサブネットに複数の NIC で繋がっているとする。 当然、それぞれのカードには複数の IP アドレスが割り振られる。 仮に 192.168.0.1 (eth0) と 192.168.0.2 (eth1) とする。
  • 同じサブネット内のクライアント 192.168.0.3 が、 192.168.0.1 の IP アドレスを持つ NIC カードを探して ARP リクエストを出す。
  • Linux は 192.168.0.3 からの ARP リクエストに対して、 eth1 と eth2 の両方からレスポンスを返す。
  • 192.168.0.3 は帰ってきた2つのレスポンスの中から、 TCP/IP スタックの実装に応じて 192.1680.0.1 を決める。 もし eth1 の方を 192.1680.0.1 と決めると、 192.1680.0.1 宛のパケットを eth1 に送ってしまう。
  • 南無三。

従って負荷分散のために NIC の2枚挿しをしていても、うまく動かないことがあるもよう。

これを防ぐには /proc 経由でネットワークで /proc/sys/net/ipv4/conf/***/{arp_announce,arp_ignore} の値を調整する。 *** はインターフェイス名か all を入れる。

/proc/sys/net/ipv4/conf/***/arp_announce
ARP リクエストを投げる場合に自己申告する送信元 IP アドレスを設定する。
0 (default) を指定するとはホスト内の全ての IP アドレスが使える。
1 を指定すると送信先のサブネットでないローカルアドレスは使わない。
2 を指定すると送信先サブネットにとって一番良いと思われる IP アドレスを使う。 送信先となるサブネットに属している中でプライマリーIPアドレスが適用される。
/proc/sys/net/ipv4/conf/***/arp_ignore
ARP リクエストに対するレスポンスの返し方を変更する。
0 (default) では各インターフェイスはホストマシンの全ての IP アドレスに対して ARP レスポンスを返してしまう。
1 を指定するとターゲットとなる IP アドレスの割り振られたインターフェイスだけが ARP レスポンスを返すようになる。

net.ipv4.conf.all.arp_announce = 1 or 2、 net.ipv4.conf.all.arp_ignore = 1 の設定が良いようだ。

sysctl.conf に書くと毎回の設定が省略できる。

sysctl.conf:
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
コメントを書き込む
[1] [シンガポール在住] 2011-02-25 01:00:16
この情報、本当に助かりました!
[2] [hiro] 2011-05-07 11:49:08
proxy_arp の設定や ip alias を用いてNWを構築しているなかで妙な現象が現れて困惑していたところ、こちらのページにたどり着き、一発で解決しました!

助かりました〜

2/1 (金)

[Food] エチオピア料理「クイーンシーバ」@目黒 (公式ぐるなび)

吉川さんの発案で、森さん・前田さん・私で目黒にエチオピア料理を食べに行くことに。 お店のクイーンシーバは目黒駅と代官山駅の中間ぐらいにあり、結構歩くことになります。


お店の入り口
地下にあります

階段

店内の装飾はとってもアフリカン

エチオピア料理の代表はインジェラという「テフ」という穀物から作るパンらしい。 これがエチオピアの主食で、これに具材を載せて丸めて食べるそうな。 早い話が「ナンにカレー」のエチオピア版ですな。

実際に食べたインジェラはモチモチ度の足らない蒸しパンのような触感。 独特の酸味があると事前に聞いていたが、上に載せて食べるカイワットやヤベグワットがほどほどに辛いので気にならない。


サモサというレンズ豆のエチオピア風焼春巻きだそうです

サラダ

オードブル

チキンと山羊のカバブ

奥:カイワット(辛いビーフシチュー)
手前右:ヤベグワット(辛いラムのシチュー)
手前左:ミスール(レンズ豆のシチュー)

下がインジェラで上がダボ
これを左隣の写真のソースを載せて食べる

追加で頼んだダチョウのカバブ

味はたいへん美味。
だけどインジェラ以外は「インド料理」と言うわれて出されると、分かんないだろうなぁ…

P.S.

酒が飲めない私は良く分からないがアフリカビールやいろいろ珍しいカクテルがあるそうだ。

コメントを書き込む
[1] [ぶぅ] 2008-02-05 17:59:41
エチオピア料理はサンノゼの近くで食べたことあります。あれはそば粉か何かで作ってるのかと思いましたが、テフという穀物があるのですね。
素早く食べないと、包んだ具の汁がインジェラをとおして手に染み付くので大変でした。
[2] [nminoru] 2008-02-06 12:46:20
ぶぅさん、こんにちは。

確かにインジェラは汁気のあるものを包むのは難しいですね。
↓こういう具ならいいのでしょうが。
http://ja.wikipedia.org/wiki/%E7%94%BB%E5%83%8F:Alicha_1.jpg
[3] [ぶぅ] 2008-02-06 13:49:03
いや〜ダメでした。サンノゼ(というよりキャンベルでしたが)の店のインジェラは、写真で見る限りnminoruさんの行かれた店より肌理が粗くて穴が大きめなのです。

先月の日記(2008年01月) 今月の日記(2008年02月)
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
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | Google+
slideshare | github | Qiita


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