カテゴリー「Intel Galileo」の記事

Intel GalileoでCoreMark

Intel Galileoで、以前LPCXpressoで動かしたCoreMark(CPUコアのベンチマークテスト)を試してみました。比較として、Raspberry Piでも。さて、結果はいかに。

IMG_0349


GalileoへのCoreMarkの移植

GalileoのArduino形式スケッチにCoreMarkを移植する際に工夫した点は以下です:

  • 表示に使うprintfは、下地で動いているるLinuxのprintfがリンクできることを発見(773mbarさんのIntel Galileoでprintfを使うを参照)
  • CoreMark本体(Cのコード)はArduinoのLibraryとしてリンク

スケッチのイメージは以下の通りです:

#include <stdio.h>
#include <coremark.h>

void setup() {
  stdout = freopen("/dev/ttyGS0", "w", stdout);
}

void loop() {
  printf("Run CoreMark\n");
  mainCoreMark();
  printf("CoreMark End \n\n");    
}

5行目のコードで、printfの出力をUSBで接続したPCのIDEのシリアルモニターに出力できます。CoreMarkの本体をloopの中で呼んでいるのは、CPU使用率を100%張り付きにして温度変化を調べるためです。CoreMarkの実行結果は以下の通り:

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 112070000
Total time (secs): 112.070000
Iterations/Sec   : 446.149728
Iterations       : 50000
Compiler version : 4.7.2
Compiler flags   : #pragma O3, Otime
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xa14c
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 446.149728 / 4.7.2 #pragma O3, Otime / STACK

スコアは、446で以外と伸びていません。LPC1769 120MHzで191出ていましたので、Pentiumクラス400MHz動作のQuark X1000ならもっと数字が伸びてもよいと思うのですが。CoreMarkの設定方法が正しくないのか・・

CoreMarkを連続して動作させると、以下の通りCPU使用率は100%に張り付き、スケッチのCPU使用率が98%になります。

CPU:  98% usr   1% sys   0% nic   0% idle   0% io   0% irq   0% sirq
Load average: 1.00 1.00 0.87 2/44 1416
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1333  1330 root     R    18300   8%  98% /sketch/sketch.elf /dev/pts/0 /dev/ttyS0
 1416  1385 root     R     1268   1%   1% top
 1383  1304 root     S     3316   1%   1% {sshd} sshd: root@pts/1
  200     2 root     SW       0   0%   0% [kworker/0:1]
 1304     1 root     S     3256   1%   0% /usr/sbin/sshd
 1385  1383 root     S     1968   1%   0% -sh
 1328     1 root     S     1852   1%   0% {clloader.sh} /bin/sh /etc/init.d/clloader.
 1296     1 messageb S     1464   1%   0% /usr/bin/dbus-daemon --system
 1319     1 root     S     1264   1%   0% /sbin/syslogd -n -O /var/log/messages
 1325     1 root     S     1264   1%   0% /sbin/getty 115200 ttyS1
 1326     1 root     S     1264   1%   0% /sbin/getty 38400 tty1
 1276     1 root     S     1264   1%   0% udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i
 1322     1 root     S     1260   1%   0% /sbin/klogd -n
 1330  1328 root     S      836   0%   0% /opt/cln/galileo/clloader --escape --binary
    1     0 root     S      796   0%   0% init [5]
 1327     1 root     S      768   0%   0% /opt/cln/galileo/galileo_sketch_reset -v
    6     2 root     SW       0   0%   0% [kworker/u:0]
  936     2 root     SW<      0   0%   0% [loop0]
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
  529     2 root     SW       0   0%   0% [mmcqd/0]
  752     2 root     SW<      0   0%   0% [kworker/0:1H]
   10     2 root     SW       0   0%   0% [kdevtmpfs]
   12     2 root     SW       0   0%   0% [kworker/u:1]
    5     2 root     SW<      0   0%   0% [kworker/0:0H]
   11     2 root     SW<      0   0%   0% [netns]
  119     2 root     SW       0   0%   0% [bdi-default]
  121     2 root     SW<      0   0%   0% [kblockd]
    2     0 root     SW       0   0%   0% [kthreadd]
    4     2 root     SW       0   0%   0% [kworker/0:0]
  384     2 root     SW       0   0%   0% [fsnotify_mark]
  396     2 root     SW<      0   0%   0% [crypto]

このときのCPU温度は72℃で、Lチカ(CPU使用率2%)の時と変わりません。ということは、GalileoのCPUはアイドル状態でも全く電力制御が動いていないということになります。今一な動作ですが、下地のLinuxカーネルのチューニングの問題でしょうか。Raspberry Piだと、変化は少ないですが、アイドル状態からフル負荷に上げると、CPU温度が44℃程度から50℃台に上昇するため、こちらは電力制御が若干行われていると思われます。


Raspberry PiのCoreMark

おまけとして、Raspberry PiのCoreMark結果を以下に示します:

2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 36340000
Total time (secs): 36.340000
Iterations/Sec   : 1375.894331
Iterations       : 50000
Compiler version : 4.6.3
Compiler flags   : #pragma O3, Otime
Memory location  : STACK
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xa14c
Correct operation validated. See readme.txt for run and reporting rules.
CoreMark 1.0 : 1375.894331 / 4.6.3 #pragma O3, Otime / STACK

Raspberry PiはCoreMark値 1375とGalileoのトリプルスコアで圧勝。クロック周波数差(700MHz vs 400MHz)を考慮しても、Raspberry PiのARMコアの方がスコアが高いです。使ったコードは同じで、両方ともLinux配下で動かしていますから条件は同じだと思います。


まとめ

こうして比較してみると、(GalileoでのCoreMarkの動かし方の是非がありますが)GalileoのQuark X1000 CPUの性能は今一な感じです。

  CPU clock CoreMark値
Intel Galileo 400 MHz 446.14
Raspberry Pi 700 MHz 1375.89


参考文献

Intel Galileoのインプレッション

Blog名更新後の初エントリ(久しぶり・・)は、Intel Galileoです。昨年スイッチサイエンスさんに予約して、1月15日に無事届きました。ArduinoとLinuxの共存やIntelの組み込み(IoT)向けプロセッサQuark SoC X1000搭載など、なかなか興味深い製品で、発売即ゲットしてしまいました。

まだ、LチカとLinux環境にちょっと触った程度ですが、気がついたことを書いてみます。

 

パッケージ構成

本体とACアダプタ(各国対応のプラグ付き)というシンプルな構成。

量産品発売前のレビュー記事(マイナビさんとか)だと、マスコット人形・箱を開けたときのオルゴール・USBケーブル・基板スタンド用アダプタが添付とありましたが、量産版では削除されています。USBケーブルや基板スタンドは手持ち品があるので、Arduino(DIY)の精神としては余計なものは付けないほうが私的には好ましいです。でも、オルゴールは聴いてみたかった・・・ 電源は、5V/2AのACアダプターで(USBからの給電は不可。ボードが壊れると、恐ろしいことがマニュアルに書いてあります)、2Aの手持ち品もあるのですが、こちらは添付の純正品を使っています。

IMG_0326

(左側はMFTのIntelブースでもらったポストイット)

 

ハードウェア構成

Arduinoシールド互換とするために、5V GPIO/PWM, ADCが乗っていますが、Quark SoC X1000の機能は使わず、I2C経由の外付けのチップで対応しています。GPIOはQuarkにも搭載されているようにデータシート上見えますが、敢えて外付けチップ経由になっています。恐らく、5V/PWM対応がQuark内臓のGPIOではできないためと思われますが、GPIOが100KHz動作のI2C経由なので、GPIOのトグル周期は230Hz程度とオリジナルのArduinoより遅そうです(比べた訳ではないですが)。そのため、表示用のLCDも従来の4bitパラレルよりI2Cで直接接続した方が効率がよいかも知れません。

CPUが熱くなるとマイナビさんのレビュー記事にありますが、Linux環境を起動して温度センサーの値を調べてみるとこんな感じ:

□CPU温度の確認
# cat /sys/class/thermal/thermal_zone0/temp

  • Quark SoC X1000 : 69℃~72℃程度
  • RaspberryPi : 44℃程度

確かに、この手の組み込みチップとしては熱いと思います。マイナビさんのレビューでは、電源のチップ周りが熱くなるという記述もありましたが、自分の固体はCPU以外は殆ど熱くならないので量産版では改善されたのかも。

オンボードに8MB Flashが搭載されており、通常はこのFlashからLinuxをブートしてLinux上でArduinoスケッチを動かします。スケッチ用には、Quark SoCオンチップの512KB SRAMの約半分が割り当てられているみたい。512KB SRAM以外にもLinuxを動かす256MB DDR3 DRAMが搭載されています。


ソフトウェア構成

専用IDEを使ってスケッチを作成します。Macにインストールする際の注意点としてアプリケーションフォルダーにDLしたファイルを置くだけですが、appファイル名にスペースを入れてはいけません。私は、当初Arduino用のIDEと区別したかったため、”Arduino Galileo”とスペースありの名前で登録したのですが、一番最初に行うファームウェアのアップデートでエラーが発生し、はまりました(エラーメッセージでググったところ、Intelのサポートフォーラムで解決策が見つかった次第)。

オンボードのFlashから起動した場合、電源を落とすとスケッチも消えてしまい、再アップロードが必要です(スケッチはSRAMに直接書き込まれる模様)。もう一つの起動方法として、MicroSDカードにIntelが提供しているLinuxイメージを書き込んでブートすることができます。この場合、スケッチはMicroSDカードの/sketch/sketch.elfに書き込まれるため、電源を切っても再投入時自動実行されます。

オンボードFlashからブートした場合、Linuxのコマンド操作を行うためにはピンジャックのシリアルケーブルをPCに接続する必要があるようです。このピンジャック3.3V TTLでなく、RS232C (±12V?)で信号が出ているため、直接FT232等のUSB-シリアル変換に接続できません。自作も面倒なので、スイッチサイエンスさんからアクセサリとして接続ケーブルが発売されるのを待ちます。MicroSDカードからLinuxをブートした場合は、宅内ルーターからDHCP経由で割り当てられたIPアドレスを調べることによってssh経由でLinuxにアクセスできるため(ひとりブログさんの記事を参照)、この方法でLinuxに触っています。

MicroSDからブートした場合、Arduinoのスケッチ(sketch.elf)はLinuxの一プロセスとして実行されているように見えます。(下記ps出力の41行目)

root@clanton:/# ps
  PID USER       VSZ STAT COMMAND
    1 root       796 S    init [5]
    2 root         0 SW   [kthreadd]
    3 root         0 SW   [ksoftirqd/0]
    4 root         0 SW   [kworker/0:0]
    5 root         0 SW<  [kworker/0:0H]
    6 root         0 SW   [kworker/u:0]
    7 root         0 SW<  [kworker/u:0H]
    8 root         0 SW<  [cpuset]
    9 root         0 SW<  [khelper]
   10 root         0 SW   [kdevtmpfs]
   11 root         0 SW<  [netns]
   12 root         0 SW   [kworker/u:1]
  119 root         0 SW   [bdi-default]
  121 root         0 SW<  [kblockd]
  200 root         0 SW   [kworker/0:1]
  329 root         0 SW   [kswapd0]
  384 root         0 SW   [fsnotify_mark]
  396 root         0 SW<  [crypto]
  526 root         0 SW<  [deferwq]
  529 root         0 SW   [mmcqd/0]
  777 root         0 SW<  [kworker/0:1H]
  937 root         0 SW<  [loop0]
  938 root         0 SW   [kjournald]
 1002 root         0 SW   [khubd]
 1058 root         0 SW   [irq/61-0-0020]
 1100 root         0 SW   [spi0]
 1103 root         0 SW   [spi1]
 1133 root         0 SW<  [cfg80211]
 1277 root      1264 S    udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
 1297 messageb  1464 S    /usr/bin/dbus-daemon --system
 1305 root      3256 S    /usr/sbin/sshd
 1320 root      1264 S    /sbin/syslogd -n -O /var/log/messages
 1322 root      1260 S    /sbin/klogd -n
 1326 root      1264 S    /sbin/getty 115200 ttyS1
 1327 root      1264 S    /sbin/getty 38400 tty1
 1328 root       768 S    /opt/cln/galileo/galileo_sketch_reset -v
 1329 root      1856 S    {clloader.sh} /bin/sh /etc/init.d/clloader.sh
 1443 root       876 S    /opt/cln/galileo/clloader --escape --binary --zmodem --di
 1452 root     18292 S    /sketch/sketch.elf /dev/pts/0 /dev/ttyS0
 1455 root      3316 R    {sshd} sshd: root@pts/1
 1457 root      1944 S    -sh
 1463 root      1264 R    ps

MicroSD用に提供されているLinuxの機能はミニマムです。コマンドファイルは以下のようにBusyBoxを使って小型化されており最小限。gccやパッケージアップデートの機能もありません。そのため、RaspberryPiのようにLinux環境での開発は難しく、当面はArduino環境での開発が主体になりそうです。

root@clanton:/# ls -la /sbin
drwxr-sr-x    2 root     root          2048 Sep 30  2013 .
drwxr-xr-x   18 root     root          1024 Jan  1 00:57 ..
lrwxrwxrwx    1 root     root            12 Sep 30  2013 acpid -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 arp -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 blkid -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 blockdev -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 bootchartd -> /bin/busybox
-rwxr-xr-x    1 root     root         12668 Sep 30  2013 bootlogd
lrwxrwxrwx    1 root     root            12 Sep 30  2013 depmod -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 fdisk -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 findfs -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 fsck -> /bin/busybox
-rwxr-xr-x    1 root     root          3944 Sep 30  2013 fstab-decode
lrwxrwxrwx    1 root     root            12 Sep 30  2013 getty -> /bin/busybox
lrwxrwxrwx    1 root     root            19 Sep 30  2013 halt -> /sbin/halt.sysvinit
-rwxr-xr-x    1 root     root         12168 Sep 30  2013 halt.sysvinit
lrwxrwxrwx    1 root     root            12 Sep 30  2013 hwclock -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 ifconfig -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 ifdown -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 ifup -> /bin/busybox
lrwxrwxrwx    1 root     root            19 Sep 30  2013 init -> /sbin/init.sysvinit
-rwxr-xr-x    1 root     root         31268 Sep 30  2013 init.sysvinit
lrwxrwxrwx    1 root     root            12 Sep 30  2013 insmod -> /bin/busybox
-rwxr-xr-x    1 root     root         78556 Sep 30  2013 iwconfig
lrwxrwxrwx    1 root     root             8 Sep 30  2013 iwgetid -> iwconfig
lrwxrwxrwx    1 root     root             8 Sep 30  2013 iwlist -> iwconfig
lrwxrwxrwx    1 root     root             8 Sep 30  2013 iwpriv -> iwconfig
lrwxrwxrwx    1 root     root             8 Sep 30  2013 iwspy -> iwconfig
-rwxr-xr-x    1 root     root         14972 Sep 30  2013 killall5
lrwxrwxrwx    1 root     root            12 Sep 30  2013 klogd -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 loadkmap -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 logread -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 losetup -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 lsmod -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 mdev -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 modprobe -> /bin/busybox
-rwxr-xr-x    1 root     root          3456 Sep 30  2013 nologin
lrwxrwxrwx    1 root     root            12 Sep 30  2013 pivot_root -> /bin/busybox
lrwxrwxrwx    1 root     root            23 Sep 30  2013 poweroff -> /sbin/poweroff.sysvinit
lrwxrwxrwx    1 root     root            13 Sep 30  2013 poweroff.sysvinit -> halt.sysvinit
lrwxrwxrwx    1 root     root            21 Sep 30  2013 reboot -> /sbin/reboot.sysvinit
lrwxrwxrwx    1 root     root            13 Sep 30  2013 reboot.sysvinit -> halt.sysvinit
lrwxrwxrwx    1 root     root            12 Sep 30  2013 rmmod -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 route -> /bin/busybox
lrwxrwxrwx    1 root     root            23 Sep 30  2013 runlevel -> /sbin/runlevel.sysvinit
-rwxr-xr-x    1 root     root          3472 Sep 30  2013 runlevel.sysvinit
lrwxrwxrwx    1 root     root            12 Sep 30  2013 setconsole -> /bin/busybox
lrwxrwxrwx    1 root     root            23 Sep 30  2013 shutdown -> /sbin/shutdown.sysvinit
-rwxr-xr-x    1 root     root         18260 Sep 30  2013 shutdown.sysvinit
lrwxrwxrwx    1 root     root            12 Sep 30  2013 start-stop-daemon -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 sulogin -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 switch_root -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 sysctl -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 syslogd -> /bin/busybox
lrwxrwxrwx    1 root     root             4 Sep 30  2013 telinit -> init
lrwxrwxrwx    1 root     root            12 Sep 30  2013 udhcpc -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Sep 30  2013 vconfig -> /bin/busybox
lrwxrwxrwx    1 root     root            17 Sep 30  2013 vigr -> /sbin/vigr.shadow
lrwxrwxrwx    1 root     root            11 Sep 30  2013 vigr.shadow -> vipw.shadow
lrwxrwxrwx    1 root     root            17 Sep 30  2013 vipw -> /sbin/vipw.shadow
-rwxr-xr-x    1 root     root         39808 Sep 30  2013 vipw.shadow
lrwxrwxrwx    1 root     root            12 Sep 30  2013 zcip -> /bin/busybox


CPU発熱の考察

Arduinoのスケッチはloopの部分で無限ループを廻すので、そのためCPU使用率が高いのではないかと思い、調べてみました。Lチカスケッチを動かした状態でtopコマンドを動かすとCPU使用率は以下の通り。全体のCPU使用率が3%で、sketch.elfのCPU使用率は0%です。ですので、スケッチの無限ループによるCPU使用率の高騰はないです。

Mem: 42132K used, 191680K free, 0K shrd, 1868K buff, 27688K cached
CPU:   0% usr   1% sys   0% nic  97% idle   0% io   0% irq   0% sirq
Load average: 0.00 0.02 0.05 2/45 1478
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
 1478  1464 root     R     1268   1%   1% top
 1455  1305 root     S     3316   1%   1% {sshd} sshd: root@pts/1
  200     2 root     SW       0   0%   0% [kworker/0:1]
 1452  1443 root     S    18292   8%   0% /sketch/sketch.elf /dev/pts/0 /dev/ttyS0
 1305     1 root     S     3256   1%   0% /usr/sbin/sshd
 1464  1457 root     S     1944   1%   0% bash
 1457  1455 root     S     1944   1%   0% -sh
 1329     1 root     S     1856   1%   0% {clloader.sh} /bin/sh /etc/init.d/clloader.
 1297     1 messageb S     1464   1%   0% /usr/bin/dbus-daemon --system
 1320     1 root     S     1264   1%   0% /sbin/syslogd -n -O /var/log/messages
 1326     1 root     S     1264   1%   0% /sbin/getty 115200 ttyS1
 1327     1 root     S     1264   1%   0% /sbin/getty 38400 tty1
 1277     1 root     S     1264   1%   0% udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i
 1322     1 root     S     1260   1%   0% /sbin/klogd -n
 1443  1329 root     S      876   0%   0% /opt/cln/galileo/clloader --escape --binary
    1     0 root     S      796   0%   0% init [5]
 1328     1 root     S      768   0%   0% /opt/cln/galileo/galileo_sketch_reset -v
  937     2 root     SW<      0   0%   0% [loop0]
    6     2 root     SW       0   0%   0% [kworker/u:0]
    3     2 root     SW       0   0%   0% [ksoftirqd/0]
  529     2 root     SW       0   0%   0% [mmcqd/0]
  777     2 root     SW<      0   0%   0% [kworker/0:1H]
   10     2 root     SW       0   0%   0% [kdevtmpfs]
   12     2 root     SW       0   0%   0% [kworker/u:1]
  938     2 root     SW       0   0%   0% [kjournald]
    2     0 root     SW       0   0%   0% [kthreadd]
    5     2 root     SW<      0   0%   0% [kworker/0:0H]
  119     2 root     SW       0   0%   0% [bdi-default]
  121     2 root     SW<      0   0%   0% [kblockd]
    4     2 root     SW       0   0%   0% [kworker/0:0]
  396     2 root     SW<      0   0%   0% [crypto]

じゃあなぜ熱いのかと言うと、パワー・マネジメント機能がちゃんと動いていない、もともと消費電力が高めということかと思います。

Quark SoC X1000のデータシートを見ると、Power Management Stateとして以下をサポートしています:

  • S0: Full On
  • S3: Suspend to RAM (Standby)
  • S4: S4 - Suspend to Disk (Hibernate)

S3以降はCPUが完全に停止してしまうためスケッチ実行中に遷移することはないと思います。ですので、通常S0ステートで動き続ける訳ですが、AtomのようにS0を細分化してS0内に省電力モードを設けるような機能はQuarkにはありません。

Sステート以外に、ACPIアイドルステートして以下があります:

  • C0: Active mode, processor executing code
  • C1: AutoHALT state
  • C2: Stop Grant state

PCのACPIでは、アイドル時OSがHALT命令を発行してCPUをC1ステートに落とすようなことやってませんでしたっけ?だとすると、GalileoのLinuxはACPIが動いておらず、アイドル時もCPUクロック周りがフル回転していることになります。

70℃程度でCPUが壊れることはないと思いますが、消費電力や発熱的には組み込みやIoT向けには今一な感じがします。

 

参考文献

2017年10月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
無料ブログはココログ