アールテクニカ地下ガレージ

アールテクニカ株式会社の製品開発・研究開発・日々の活動です

トップ > Raspberry Pi > Raspberry Pi 3とリアルタイムカーネル(4)[評価編]

Raspberry Pi 3とリアルタイムカーネル(4)[評価編]

Raspberry Pi やってみた ガジェット
Author

コイデマサヒロ

 

前回までにRT Preempt、XenomaiというリアルタイムカーネルをRaspberry Pi3(以下RPi3)に導入しました。(RT Preempt編、Xenomai編、おまけ編)今回はその評価をしてみます。厳密な評価ではありませんが、それぞれのカーネルの特徴を知ることはできると思います。

 

 

検証で利用したカーネルのバージョン

以下の3つのバージョンを使い検証しました。

  • RT Preempt：4.4.15
  • Xenomai：4.1.21
  • ノーマル：4.4.13

 

CPU動作の設定変更

Raspberry PiのCPUのクロック数は1.2GHzですが、常にこのクロック数で動いてるわけではありません。消費電力や発熱を抑えるため通常はクロック数を下げて動作し、負荷が高くなるとクロック数が上がります。テストでは、CPU負荷をかけるためフルの1.2GHzで動作しているはずですが、念のためCPU可変にならないように予め設定しました。具体的には、CPU GovernorのモードをPerformanceにしています。cpufrequtilsというツールを使います。詳細な設定方法は検索してみてください。

Xenomaiの場合は、クロック数が変わらないようになっているため変更の必要はありません。

 

テストツールの準備

基本的にターミナルで作業を行います。準備までならSSH経由のリモート接続でもかまいませんが、テスト自体は本体側で行います。 

テストツール(re-tests)のソースをダウンロードします。Xenomaiは、導入時に同じテストツールがインストールされていますのでそれを使います。(詳しくは後で説明)

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git

ダウンロードしたフォルダに移動します。

$ cd rt-tests

ビルドします。

$ make all

標準的な開発環境がインストールされていれば問題なくビルドできるでしょう。インストールもできますが、今回はインストールせず、ビルドした場所で実行させます。いろいろなツール(コマンド)がビルドされますが、今回使うのは、cyclictest です。

cyclictestは、 http://sweng.web.fc2.com/ja/linux/ubuntu/cyclictest.html

の説明を引用させていただくと、

このコマンドは、nanosleepを定期的に繰り返し、「スリープから起きる理想的な時刻」と「実際に起きた時刻」の差分(遅延時間)を計算します。 つまり、差分が小さいほど、タイマーの精度が良いことになります。

ということです。わかりやすいですね。 さらに詳しい説明は、ツールの本家のサイトを参照してください。

https://rt.wiki.kernel.org/index.php/Cyclictest

 

テスト方法 

今回はこのようなオプションでテストを行いました。

$ sudo ./cyclictest -p 90 -m -c 0 -i 200 -n -v 100 -q -l 5000 >log.txt

nanosleepを5000回試行し、そのデータを log.txtというファイルに書き出します。Xenomaiの場合は既にインストールされているツールを使う以外は同様です(rootでログインするのをお忘れずに）。

$ /usr/xenomai/demo/cyclictest -p 90 -m -c 0 -i 200 -n -v 100 -q -l 5000 >log.txt

Xenomaiは専用のライブラリを使うと性能が引き出せるという話を導入編でしました。このテストツールはそのライブラリを使うようになっていますので、Xenomaiの性能を引き出した状態でテストができます。

 また、cyclictestを実行する前に、ターミナルを４つ開いてそれぞれで、

$ cat /dev/zero > /dev/null

を実行させます。4つ実行するのはすべてのCPUコアに負荷をかけるためです。テストは一つのCPUコアしか使いませんが、どのコアが使われるか分からないため念のため４つのコアに負荷をかけます。終了するときは Ctrl+Cです。

 

【補足】

cyclictestを使って、下記のようなテストを行う場合も多いです。

$ sudo ./cyclictest -m -t -p 80 -n -i 500 -l 100000

実行すると以下の様な結果が得られます。

# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 4.44 4.18 2.65 5/216 1319

T: 0 ( 1315) P:80 I:500 C: 100000 Min:      5 Act:    7 Avg:   12 Max:      95
T: 1 ( 1316) P:80 I:1000 C:  49953 Min:      5 Act:   14 Avg:   16 Max:     150
T: 2 ( 1317) P:80 I:1500 C:  33261 Min:      5 Act:   15 Avg:   17 Max:     145
T: 3 ( 1318) P:80 I:2000 C:  24926 Min:      6 Act:   13 Avg:   11 Max:      82

テストを100000試行して最小値、平均、最大値といった結果的のみです。通常はMax値だけみて判断されてしまうので、今回のようにカーネルを比べる場合には少々不向きです。今回は、それぞれのカーネルの特徴がわかるような検証をします。

 

テスト結果

$ cyclictest -p 90 -m -c 0 -i 200 -n -v 100 -q -l 5000

を実行すると5000回分のデータが得られます。これらを集計しグラフにしました。

横軸の単位は差分の時間(レイテンシー)、us(マイクロ秒)です。縦軸は個数です。例えばレイテンシーが20usのデータがいくつあったかということです。

何度かテストを繰り返すとわかりますが、値はかなりバラつきが出ます。傾向としては変わりませんが、数値的なデータはひとつの目安とお考えください。

 

ノーマルカーネルの場合

f:id:atkoide:20160817182435p:plain

最小値：5us、最大値：78us、平均 12us
(40us以上のデータは他のカーネルと合わせるため省いています）

まずはこれがノーマルカーネルのグラフです。これを基準として他のカーネルをみていきます。

 

RT Preemptの場合

f:id:atkoide:20160817182443p:plain

最小値：7us、最大値：36us、平均値：13us

8us前後がボリュームゾーンです。グラフの形としてはノーマルカーネルと似たような感じの傾向と言えそうです。平均値で見るとノーマルカーネルと似た感じですが、山の幅は小さめ(＝値のバラつきが小さい)で安定度は高そうです。

 

Xenomaiの場合

f:id:atkoide:20160817182451p:plain

最小値：0us、最大値：31us、平均値：5us

ノーマル、RT-Preemptとも異なったグラフの形になりました。平均値を見てもかなりレイテンシーは小さくおさえられる感じです。ただ、山の幅はそこそこあるため安定性としては微妙かもしれません。

 

３つのカーネルを比べてみる

f:id:atkoide:20160817182459p:plain

ノーマル：最小値：5us、最大値：78us、平均 12us
RT Preempt：最小値：7us、最大値：36us、平均値：13us
Xenomai：最小値：0us、最大値：31us、平均値：5us、

3つのグラフを重ねてみました。それぞれの特徴がひと目で分かりますね。

 RT Preemptは、ノーマルの幅を左側に縮めた感じです。両者のレイテンシーの平均としては大きな違いは無いのですが、ボリュームゾーンとしては、RT Preeemptの方が小さめです。さらに山の幅が狭い(値のバラつきが少ない)のでRT Preemptの方が安定性も良さそうです。

 Xenomaiのグラフの形は他とは違います。レイテンシーはかなり小さく抑えられそうですが、山の幅が広いため安定性は高いとはいえないかもしれません。

 3つを比べてみると、多少安定性が悪くてもとにかくレイテンシーを低く抑えたいならXenomai、多少レイテンシーが大きくなっても安定性を重視するならRT Preemptということになりそうです。

しかし、Xenomaiの性能を引き出すためには専用のAPIを使う必要があります。つまり自前でソフトを作ったり、Xenomai対応をうたうソフトを使うならXenomaiという選択肢は良いのですが、既存のソフトウェアを使うのであれば、RT Preemptの一択といえます。（ちなみにXenomaiのAPIを使わないでcyclictestを実行してみたところRT Preemptと同じような傾向になりました。）

 

最後に

他にもいろいろな評価の仕方はあるようですが、今回の方法でもそれぞれの傾向などを客観的に知ることはできたと思います。

当初の目的としてRPi3を音楽制作用デバイスとした場合、リアルタイムカーネルは有用かということでした。使うソフト側の事情(CPU負荷やメモリ使用量など）もあるので、客観的なデータを出すのは難しいのですが、RT Preemptを使えばノーマルカーネルよりレイテンシーを抑えることはできます。 

ただし、今回の検証でレイテンシーの幅がかなりあることはデータからもわかりました。これは、レイテンシーを抑えることができるものの、たまにプチノイズが乗ってしまうということです。例えば、ソフトシンセを鳴らしながらデータを打ち込む、という使い方であれば十分使えます。音源として使うという場合は、ライブなら妥協できるかもしれませんが、レコーディングでは使えません。使い方次第、条件次第ということですね。

 つまり、RPi3へのリアルタイムカーネルの導入は音楽制作用として有用（ただし条件付き）といえそうです。いずれこのあたりも客観的な評価をしてみたいと思います。

 
 
Author

コイデマサヒロ

ディレクター、プロデューサー、ギタリスト。mimiCopyをはじめ弊社リリースの全てソフトウェア製品の企画を担当。ネイティブアプリ開発がメインでOS問わず対応可。dubバンドのギタリストとしても活動中。

スポンサーリンク