投稿

CPU の定格クロックを取得する(IA-32,Intel 64 限定)

Intel CPU の場合 cpuid 命令で取得できる諸情報のうち processor brand string という CPU のブランド名を取得する命令を使うことによって,このブランド名文字列の末尾にある文字列を見れば良い。

実のところ /proc/cpuinfo の model name の行を見るのと同じだが,Linux 以外でも使えるなど色々あって /proc を舐めたくないときがあります(本当?) #include <cstdint> #include <cstdio> #include <string> #include <iostream> #include <algorithm> // CPU 周波数を processor brand string に記述されている周波数から取得する int main(int argc, char* argv[]) { struct reg{ uint32_t eax,ebx,ecx,edx; } r; std::string processor_brand_string = {}; // brand string を取得して processor_brand_string へ格納 __asm__ volatile("cpuid" : "=a"(r.eax), "=b"(r.ebx), "=c"(r.ecx), "=d"(r.edx) : "a"(0x80000002), "c"(0x0)); processor_brand_string.append(reinterpret_cast(&r), 16); __asm__ volatile("cpuid" : "=a"(r.eax), "=b"(r.ebx), "=c"(r.ecx), "=d"(r.edx) …

journalctl の使い方 Tips

そろそろ多くの環境が systemd になったかと思います。
systemd 環境では syslog や logrotate が systemd-journald で管理されるようになっており,journalctl を使うと便利にログを眺められます。

私は systemd 環境を主に使い出して 6 年ぐらいになるのですが途中にオプション増えたりコマンド増えたり色々ありました。そんなわけで,journalctl コマンドを使うときの便利なオプションとかのメモ,いってみよー

ブート ID の一覧と特定の起動時のログの表示$ journalctl --list-boot -5 f5b4ff9349204d31b7c89cae00a765e5 Fri 2018-06-01 12:32:20 JST—Fri 2018-06-01 12:33:43 JST -4 1baea4095c424e6b8f50f3eff1af2161 Fri 2018-06-01 12:34:21 JST—Fri 2018-06-01 12:35:17 JST -3 dfb54ab05bd14c05ae83f4a767492293 Fri 2018-06-01 12:38:43 JST—Fri 2018-06-01 12:40:28 JST -2 336d9d0421ce44d59aadcaf2de634e92 Fri 2018-06-01 12:50:57 JST—Tue 2018-06-05 10:15:33 JST -1 676a0fbbf09948bcbb18e5f61d27f51b Tue 2018-06-05 11:28:20 JST—Tue 2018-06-05 13:55:23 JST 0 92feec044ea94d88a6f95548df223f80 Wed 2018-06-06 00:51:40 JST—Wed 2018-06-06 00:57:37 JST これまで logging した boot ID の一覧を出してくれます。これで,「あ,一昨日起動したときのログが見たいなー。一昨日起動したのは二回前の起動のときかー」ってなったら,
$ journalctl -b -2 とすればいいわけです。ちなみに,単に今起動している分のログだけ見たい場合…

Linux カーネルおさんぽマップ〜時計編〜

イメージ
本稿では,Linux カーネルで扱える時計のうち,PTP(Precision Time Protocol)という IEEE 1588 で策定されている高精度な時計をクロックソース[1]にする場合について追っていこうと思います。
Linux における時刻同期:NTP と PTP Linux や Windows,macOS といった現在の OS のシステムクロックは,一般的にはインターネットを通じて NTP(Network Time Protocol)が同期するようになっています。
NTP を使っていればインターネットに接続されている際には大きく時刻がズレることはなく,たまにネットワーク接続が失われていてもクォーツ時計は安物の振り子式ほど時間はズレません。

では,NTP は設計としてどのくらいの誤差が考えられているのでしょうか。NTP の設計者 David L. Mills 博士は自身が実装した PDP-11 向けの OS「Fuzzball」上の実験でそれを示しており,答えは数十ミリ秒です[2]。現代のマシンと OS ならば数ミリ秒までは迫れるかもしれません。ちなみにこの論文が発表された翌年には NTP version 2 が RFC から発行されています[3]。(現在は version 4。)

NTP は日常的な利用には十分な精度があります。しかし,マイクロ秒やナノ秒といった単位での高精度さが目的ではありません。日本の NTP のサーバーとして有名な NICT(情報通信研究機構)は日本標準時の決定をしており原子時計も所有していますが,インターネットを介して NICT などのサーバーにアクセスしている時点でミリ秒やひどいときは数秒の遅れが発生するでしょう。LAN に NTP サーバーがあったとしても,アルゴリズムとして数ミリ秒の遅延を許容しています。そこで高精度な時刻同期のために存在するのが PTP です。
PTP とは PTP とは,ネットワークデバイス内の時計を高精度に同期する仕組みです。グランドマスタークロックと呼ばれる時計をマスターとして設置し,LAN の NIC たちがそれを元に同期するといったような仕組みになります。これによって,パケットのタイムスタンプをハードウェアで高精度に打つことが可能になったり,この PTP をクロックソースとしてシステムクロックを…

Atom のマシンと Xeon のマシンで 10 Gbit Ethernet の帯域測定

イメージ
タイトル通りです。

Intel 82599ES 10-Gigabit SFI/SFP+ を搭載した二台のマシンを DA ケーブルで直結し,iperf3 で測定を行なってみました。

マシンの性能は次の通り。
Atom のマシン

Xeon のマシン

搭載されているメモリ量,メモリ速度は同じ,NIC も同じ。
CPU の性能が大幅に異なります。
さて,それでは測定結果をみてみましょう。

まずは Atom が client(送信側),Xeon が server(受信側)の場合。
上から帯域,congestion windowのサイズ,リトライ回数で,x 軸が時間軸です。帯域はほぼ 9.40 Gbits/sec 前後をキープしており,期待に近い結果が得られていると思います。リトライ回数は全てゼロ。

次に Xeon が client(送信側),Atom が server(受信側)の結果です。
悲惨ですね。まず目に見えてリトライ回数が多いです。ワーストケースで 98 回もリトライしていました。また,congestion window のサイズも変化しまくり,約 1.2 MB にまでなる場合も。従って,帯域もラインレートからほど遠い 6.43 Gbits/sec を叩き出しています。おうちで宅内の LAN に使うのなら 1000 BASE-T よりはよっぽど速いのでコストパフォーマンスが良いかもしれませんが,10 Gigabit ギリギリの速度が欲しいときには Atom だとダメそうですね。


というわけで簡単な計測とその結果でしたが,Xeon と Atom の二つの CPU の差がネットワークの速度にも大きく影響していることがよくわかる結果となりました。
ただし,ハードウェアオフローディングなどがよく効くハードウェアだとまた別の結果が出るかもしれないので,一概に CPU が常に帯域に影響するとは言えないと思いますが,少なくともタワー型のちょっとしたサーヴァーや家庭用 NAS なんかだと CPU の影響が結構効いてくるかもしれませんね。



宣伝:

この測定は私のアルバイト先である IIJ Innovation Institute(IIJ 技術研究所)で行ないました。IIJ-II では 100 GbE のネットワークに関する実験や高精度時刻同期,その他様々な実験・研究を行なっています。学生のアルバ…

BitVisor の UEFI 向けのブートローダーを読む(2nd stage)

この記事は BitVisor Advent Calender 2017,20 日目の記事(大遅刻)です。

UEFI 向けのローダーでも読んで記事書くかーって思ってたら先にやられてしまってウンウン唸ってましたが, 彼の記事の続きを勝手に書けば良いことに気がつきました。

では元気よく,UEFI の 1st stage loader から entry_func に飛んだ後を追っていきましょう。
いきなり find と grep を使っても良いのですが,折角手掛りがあるのでまずリンカスクリプト, bitvisor.lds を読んでみます。1st stage loader を読む記事に因ると,bitvisor.elf を 0x10000 だけ読んで,paddr (おそらく物理アドレス,physical address の略でしょう)に読んで,そこからエントリポイントを計算して,entry_func に飛んでるらしいです。

bitvisor.lds リンカスクリプト 2 行目,phys = 0x00100000; となっており,11 行目, .entry : AT (phys + (code - head)) { をみるとこのアドレスは bitvisor.elf の .entry というセクションになってるらしいので,このセクションを探せば良さそう。ついでに,このスクリプトから bitvisor.elf がメモリに置かれるときの仮想アドレスの開始位置もわかります。

core/entry.s.entry セクションをみると,まず multiboot のヘッダが書いてあって,次に 32-bit のコードが始まってます。test 命令の結果,もしリアルモードであるならば,jc によってリアルモード用の初期化コードに飛んでますが,今回は割愛。
で,その後,32-bit なら jnc 命令で分岐せず multiboot のためのコードにジャンプ,ロングモードなら uefi64_entry に分岐しているわけですが,この分岐のやりかたが結構トリッキーというか,あんまりちゃんとなんでこれでいいのかわかってないなあと思ったら, BitVisor本体のブート仕様 2 年前のえいらくさんの記事にしっかり書いてあった……。やだ,もしかしてこの記事を書く必要なかった……?
でももう書き始めちゃったのでこ…

Chinachu を SELinux 有効にして使う

https://github.com/Chinachu/docker-mirakurun-chinachu

Chinachu の docker コンテナの README から抜粋
- SELinuxの無効化推奨 無効化推奨,じゃあないんだよ!有効化しろよ!ということで,SELinux を enforcing するまでの道程です。

まず最初に,ディストリビューション。Chinachu は Debian や Ubuntu での導入記事を多く見受けますが,今回は REHL/Fedora/CentOS 系統を使います。
SELinux のデフォルトのポリシーが充実してるのがその理由。
次に,Chinachu はコンテナ化したものを用います。Chinacu は npm のモジュールをローカルにインストールしたり ffmpeg をビルドしたり,パッケージ以外から導入するものが多すぎなので,それに対してラベル付けたりポリシーを書いたりするのがダルいからです。

私は Fedora 27 で設定を行い,この記事を書いてます。

では前置きはここまでにして,以下手順

1. SELinux 有効化
CentOS の場合は先にパッケージを入れておきましょう。
# yum -y install selinux-policy-targeted setools とはいっても Red Hat 系のディストリビューションはデフォルトで有効のはずです。CentOS はパッケージいれてから再起動が必要ですが。

デ フ ォ ル ト で 有 効 の は ず で す が

もし無効化してたなら,とりあえず /etc/selinux/config の中で SELINUX=permissive にして再起動しときましょう。
なお,現状だと,docker のストレージに btrfs を使っていて,それで docker pull をすると,SELinux が enforcing のときだとコケるっぽいです。解決中。まあ pull のときだけ permissive にしてサービス動かしだしてから enforcing でも困らん気がする。

2. ラベリング

docker-compose.yml の volumes を次のように設定していると仮定します。
services:
    mirakurun:
        (…

Facebook の特定の公開ページの投稿を全部クロールする(ひなビタ♪)

ひなビタ♪ Advent Calender 用の記事です。

やほやほっ,おるみんです!

みなさんは日向美ビタースイーツ♪というバンドをご存知でしょうか。
架空の地方の商店街,日向美商店街を舞台とする,町興しをテーマに少女たちが奮闘したり日常を過ごしたりするガールズバンドです。
最近はひなビタ♪の舞台のモデル,鳥取県倉吉市ともコラボを積極的にしているみたいですよ。

私の地元と近い場所だったり,鄙びた商店街という舞台だったり,自分自身の体験や実感と重なったりするところも多くて思わずハマっちゃいました☆[1]

さて,このひなビタ♪なのですが,音楽 CD や KONAMI のアーケードリズムゲームなどへの展開は勿論,小説や SNS での投稿といったマルチメディア展開をしています。
主なストーリーラインや彼女たちの音楽制作の様子といったものが Facebook を中心に展開される,非常に珍しいコンテンツと言えるでしょう。

しかし,Facebook でコンテンツを追うのは大変です。
試しにひなビタ♪のページを PC のブラウザで自動スクロールさせて古いポストを開かせようとしたところ,メモリ不足により半分くらいスクロールしたところでタブが死にました。
iPhone のアプリの場合,最後までスクロールできましたが,バッテリーが 30% くらい持ってかれた上に,スクロールをしていたのが家への帰路でしたが,数十分〜一時間くらいずっとスクロールする破目になりました。もうしません。

そこで,次のようなものを作りました。

orumin/hinabitter_read: ひなビタ♪の Facebook 投稿を快適に読みたい https://github.com/orumin/hinabitter_read 使い方は README.md の通りです。
アクセストークンを取得するコールバックは,
facebookのタイムラインへpythonから投稿する - Qiita 
をパク……参考にしました。

とりあえずこれで,2017/12/09 現在 2.4MB にもなるテキストファイルが取得できます。
今回は力足らずここまでなのですが,できれば近いうちに画像や投稿のシェアについてもちゃんと取得するようにした上で,整形して EPUB かなんかにして Kindle にメールで送り付けてシュッと読めるようにした…