投稿

2018の投稿を表示しています

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 のネットワークに関する実験や高精度時刻同期,その他様々な実験・研究を行なっています。学生のアルバ…