osx10.9 で UnixBench

ここのところ、RasPi2 でいろいろ遊んでいますが、そういえば母艦である osx 機で UnixBench を計測していないことに気がつきました。で、その結果。

 

UnixBench にパッチを当てる情報は、以下を参考にしました。

Patch for UnixBench 5.1.3 on Mac OS X Mavericks (10.9)
https://gist.github.com/barusan/11033924

blog
http://www.baru-san.net/archives/267

ありがたく、使わせていただきます。

wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/byte-unixbench/UnixBench5.1.3.tgz
git clone https://gist.github.com/11033924.git
tar xvf UnixBench5.1.3.tgz
cd UnixBench/
patch -p1 < ../11033924/UnixBench5.1.3.mavericks.patch
make
./Run

な感じで計測。

========================================================================
   BYTE UNIX Benchmarks (Version 5.1.3)

   System: HOPE.local: Darwin
   OS: Darwin -- 13.4.0 -- Darwin Kernel Version 13.4.0: ....::
::
   CPU 7: Intel(R) Core(TM) ...::
::

------------------------------------------------------------------------
Benchmark Run: 日  7 12 2015 16:14:49 - 16:42:55
8 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       34704465.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     6360.0 MWIPS (9.8 s, 7 samples)
Execl Throughput                                903.5 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        800480.2 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          219592.2 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2163139.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             1281398.1 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 103377.8 lps   (10.0 s, 7 samples)
Process Creation                               4573.6 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   5948.9 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1956.7 lpm   (60.0 s, 2 samples)
System Call Overhead                        1350215.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   34704465.0   2973.8
Double-Precision Whetstone                       55.0       6360.0   1156.4
Execl Throughput                                 43.0        903.5    210.1
File Copy 1024 bufsize 2000 maxblocks          3960.0     800480.2   2021.4
File Copy 256 bufsize 500 maxblocks            1655.0     219592.2   1326.8
File Copy 4096 bufsize 8000 maxblocks          5800.0    2163139.0   3729.6
Pipe Throughput                               12440.0    1281398.1   1030.1
Pipe-based Context Switching                   4000.0     103377.8    258.4
Process Creation                                126.0       4573.6    363.0
Shell Scripts (1 concurrent)                     42.4       5948.9   1403.0
Shell Scripts (8 concurrent)                      6.0       1956.7   3261.2
System Call Overhead                          15000.0    1350215.3    900.1
                                                                   ========
System Benchmarks Index Score                                        1092.0

------------------------------------------------------------------------
Benchmark Run: 日  7 12 2015 16:42:55 - 17:11:05
8 CPUs in system; running 8 parallel copies of tests

Dhrystone 2 using register variables      151501922.0 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    47934.1 MWIPS (9.8 s, 7 samples)
Execl Throughput                               4391.2 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1785300.9 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          417942.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       5208018.8 KBps  (30.0 s, 2 samples)
Pipe Throughput                             3024743.9 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 737487.3 lps   (10.0 s, 7 samples)
Process Creation                              17603.0 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  17545.1 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   2572.0 lpm   (60.1 s, 2 samples)
System Call Overhead                        3138596.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  151501922.0  12982.2
Double-Precision Whetstone                       55.0      47934.1   8715.3
Execl Throughput                                 43.0       4391.2   1021.2
File Copy 1024 bufsize 2000 maxblocks          3960.0    1785300.9   4508.3
File Copy 256 bufsize 500 maxblocks            1655.0     417942.6   2525.3
File Copy 4096 bufsize 8000 maxblocks          5800.0    5208018.8   8979.3
Pipe Throughput                               12440.0    3024743.9   2431.5
Pipe-based Context Switching                   4000.0     737487.3   1843.7
Process Creation                                126.0      17603.0   1397.1
Shell Scripts (1 concurrent)                     42.4      17545.1   4138.0
Shell Scripts (8 concurrent)                      6.0       2572.0   4286.7
System Call Overhead                          15000.0    3138596.8   2092.4
                                                                   ========
System Benchmarks Index Score                                        3440.0

osx 10.9.5 ですが、体感的にはもっと速い感じ。まぁ、とりあえずの指針としてきます。

たとえば、sakuraVPS の2G Plan の CPU3 RAM 2GB HDD200GB で2000くらいは出ます。

 

ベンチマーク計測中の htop は以下のような感じ。

  1  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Tasks: 252 total, 0 running
  2  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Load average: 7.85 5.22 3.26 
  3  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Uptime: 01:03:57
  4  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  5  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  6  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  7  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  8  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  Mem[||||||||||||                                        3711/32768MB]
  Swp[                                                        0/1024MB]

がんばってますね。

ちなみに、osx10.9.5 の公開しているソースは、

http://www.opensource.apple.com/release/os-x-1095/

たとえば、bash とかは、以下にあり、

http://www.opensource.apple.com/source/bash/bash-92/

まだやったことはないんですが、xcode を使ってビルドできるようです。

Source_Browser

ExtFSのマウント指定

osx に、Pragon ExtFS を入れている場合、マウントのタイプに指定するオプションは、以下のようです。

iSCSI デバイスをReadOnly でマウントしたかった時にタイプ指定が不明だったのでめも。ext2,3,4 の判別は Pragon ExtFS がやってくれる模様。

$ sudo mkdir /Volumes/berryboot
$ sudo mount -r -t ufsd_ExtFS /dev/disk3s1 /Volumes/berryboot

                           ^^^^^^^

osxreadonly

扱えるタイプは、以下。NTFS や ext2,3,4 は Paragon のに依存しています。osx 標準じゃありませんので。

$ ll /System/Library/Filesystems/
total 8
drwxr-xr-x  6 root  wheel  204 12 20  2014 AppleShare
drwxr-xr-x  7 root  wheel  238 12 20  2014 NetFSPlugins
drwxr-xr-x  4 root  wheel  136  5 30  2014 acfs.fs
lrwxr-xr-x  1 root  wheel   49 12 20  2014 afpfs.fs -> /System/Library/Filesystems/AppleShare/afpfs.kext
drwxr-xr-x  3 root  wheel  102  6  4  2014 cd9660.fs
drwxr-xr-x  3 root  wheel  102  6  4  2014 cddafs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 exfat.fs
drwxr-xr-x  5 root  wheel  170  8 25  2013 ftp.fs
drwxr-xr-x  5 root  wheel  170 12 20  2014 hfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 msdos.fs
drwxr-xr-x  3 root  wheel  102  8 25  2013 nfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 ntfs.fs
drwxr-xr-x  3 root  wheel  102  6  4  2014 smbfs.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 udf.fs
drwxr-xr-x  3 root  wheel  102 11 12  2014 ufsd_ExtFS.fs
drwxr-xr-x  3 root  wheel  102  9  9  2013 ufsd_NTFS.fs
drwxr-xr-x  4 root  wheel  136 12 20  2014 webdav.fs

 

ちなみに、Finderがマウント解除するときに、/Volumes/以下に作ったディレクトリも削除してくれるようです。

NFS Boot に成功した

とりあえず、NFS Boot は本当にできるのか試してみました。結果、できました。
実際やってみると、いろいろとはまるところがありましたが、おおむね以下の手順。忘れないうちにメモしておきます。

▼環境

NFS Server・・・・osx 10.9.5

Boot OS・・・・・ 2015-05-05-raspbian-wheezy

 

▼操作の流れ

・NFS サーバでシェアする用意

・arm 用の img のルートファイルシステムを NFS へコピー(大体は第2パーティションにあり。Fedora とは3番目)

・SDCard の FATフォーマットの boot の cmdline.txt へ nfs boot する設定と、IP の設定

 

▼osx の NFS Server 側

NFSの設定を入れて、nfsd を再起動。操作はroot でやっています。オンラインマニュアルはここ

—- /etc/exports
/nfs/fedora22 -rw -mapall=root:wheel -network 192.168.1.0 -mask 255.255.255.0

exports ファイルがあればnfsd が起動しますが、手動で操作したい場合は

# nfsd start | stop

NFS で提供しているパスの確認。

# showmount -e localhost
Exports list on localhost:
/nfs/fedora22                       192.168.1.0
::

最初fedora22 入れようとして、失敗して、RASPIAN 入れたので名前があれですが。

それで、boot したい img をコピー。以下は、centos6.x で、osx の NFS をマウントして、rsync しています。centos6はバーチャルボックスでosx を同じネットワークセグメントにいます。

[root@cent66 etc]# df -hT
Filesystem                   Type     Size  Used Avail Use% Mounted on
::
hope.junkhack:/exports       nfs      466G  390G   76G  84% /nfs
hope.junkhack:/nfs/fedora22  nfs      466G  390G   76G  84% /mnt/fedora22

hope.junkhack は名前解決できるようにしてあります。ちなみに、fstab はこんな感じのデフォルト。

—- /etc/fstab
::
hope.junkhack:/exports    /nfs        nfs        defaults    0 0
hope.junkhack:/nfs/fedora22    /mnt/fedora22    nfs        defaults    0 0

で、RASPIAN のイメージをマウント。

[root@cent66 RASPBIAN]# kpartx -av 2015-05-05-raspbian-wheezy.img
add map loop0p1 (253:2): 0 114688 linear /dev/loop0 8192
add map loop0p2 (253:3): 0 6277120 linear /dev/loop0 122880

[root@cent66 RASPBIAN]# mount /dev/mapper/loop0p2 /mnt/raspi/

[root@cent66 RASPBIAN]# df -h
Filesystem                    Size  Used Avail Use% Mounted on
::
hope.junkhack:/exports        466G  388G   78G  84% /nfs
hope.junkhack:/nfs/fedora22   466G  388G   78G  84% /mnt/fedora22
/dev/mapper/loop0p2           3.0G  2.4G  451M  85% /mnt/raspi
[root@cent66 RASPBIAN]#

で、コピー。

[root@cent66 RASPBIAN]# rsync -av /mnt/raspi/ /mnt/fedora22/
sending incremental file list
./
bin/
bin/bash
bin/bunzip2

::

var/spool/cron/crontabs/
var/spool/rsyslog/
var/tmp/

sent 2304687346 bytes  received 1293752 bytes  4274293.05 bytes/sec
total size is 2299569061  speedup is 1.00
[root@cent66 RASPBIAN]#

 

で、NFS でブートするときに fstab の中がそのままだと、SD カードのパーティションをchroot してしまうのでコメントアウト。

[root@cent66 etc]# vim fstab

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

NFS側のイメージ展開は以上で終わり。

 

▼Boot するcmdline.txt の中に以下を追加

root=/dev/nfs rootfstype=nfs nfsroot=192.168.1.17:/nfs/fedora22,udp,vers=3,nolock ip=192.168.1.24:192.168.1.17:192.168.1.1:255.255.255.0:rpi:eth0:off

nolock のオプションは必要ないかもしれません。とりあえず、これで動いてはいます。IPのところは以下の書式。

ip=<raspberrypi_ip>:<nfs_server_ip>:<default_gateway>:<mask>:rpi:eth0:off

シリアルコンソールのブートログは、

[    4.638898] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

[    4.674857] IP-Config: Complete:

[    4.680180]      device=eth0, hwaddr=b8:27:eb:97:45:fb, ipaddr=192.168.1.24, mask=255.255.255.0, gw=192.168.1.1

[    4.694694]      host=rpi, domain=, nis-domain=(none)

[    4.701878]      bootserver=192.168.1.17, rootserver=192.168.1.17, rootpath=

[    4.719859] VFS: Mounted root (nfs filesystem) readonly on device 0:14.

[    4.729328] devtmpfs: mounted

[    4.735147] Freeing unused kernel memory: 400K (80786000 - 807ea000)

[    5.132474] random: nonblocking pool is initialized

[    6.228285] udevd[177]: starting version 175



Raspbian GNU/Linux 7 pi ttyAMA0



pi login: 

となっています。

NFS Boot させたあと、uname したら、

root@pi:~# uname -a

Linux pi 4.0.7-v7+ #801 SMP PREEMPT Tue Jun 30 18:38:23 BST 2015 armv7l GNU/Linux

root@pi:~#

げ、fedora の initramfs からブートしてます。SDCard の boot は、初回にスクリプトで作ったやつだった。。。。

root@pi:/boot# ll *.img

-rwxr-xr-x 1 root root 39176850 Jul  4 17:40 initramfs-0-rescue-18b4f0b4546f49828e1ef5e652cc7b9a.img

-rwxr-xr-x 1 root root 16475761 Jul  4 17:36 initramfs-4.0.6-300.fc22.armv7hl+lpae.img

-rwxr-xr-x 1 root root  3987856 Jul  2 23:35 kernel7.img

-rwxr-xr-x 1 root root  4016696 Jul  2 23:35 kernel.img

root@pi:/boot#

たぶん、RASPIAN のimg の boot からやれば、良いはず。まだ試していませんが。

df はこんな感じで、ルートがnfs になっています。76Gも空きがあるー(osx 側のディスクですが)

root@pi:~# df -hT

Filesystem                 Type      Size  Used Avail Use% Mounted on

192.168.1.17:/nfs/fedora22 nfs       466G  390G   76G  84% /

devtmpfs                   devtmpfs  459M     0  459M   0% /dev

tmpfs                      tmpfs      93M  216K   93M   1% /run

tmpfs                      tmpfs     5.0M     0  5.0M   0% /run/lock

tmpfs                      tmpfs     186M     0  186M   0% /run/shm

/dev/mmcblk0p1             vfat      200M   98M  102M  50% /boot

このままだと、モジュールを読み込んでいないので使えませんが、、、

root@pi:~# lsmod

Module                  Size  Used by

root@pi:~# ll /lib/modules/

total 8

drwxr-xr-x 14 root root 476 May  6 22:22 3.18.11+

drwxr-xr-x 14 root root 476 May  6 22:22 3.18.11-v7+

root@pi:~#

Boot の img を RASPBIAN のに入れ替えて、リブート

[root@pi ~ 07/25 20:40:51]# ll /boot/*.img

-rwxr-xr-x 1 root root 3930004 Apr 27 13:40 /boot/kernel7.img

-rwxr-xr-x 1 root root 3974884 Apr 27 13:40 /boot/kernel.img

これでkernel も ローダブルモジュールもOK な感じ。

[root@pi ~ 07/25 20:41:40]# uname -a

Linux pi 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux

[root@pi ~ 07/25 20:44:14]# lsmod

Module                  Size  Used by

cfg80211              386508  0

rfkill                 16651  1 cfg80211

rpcsec_gss_krb5        20958  0

nfsd                  263569  2

snd_bcm2835            18649  0

snd_pcm                73475  1 snd_bcm2835

snd_seq                53078  0

snd_seq_device          5628  1 snd_seq

snd_timer              17784  2 snd_pcm,snd_seq

snd                    51038  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device

8192cu                528365  0

joydev                  8879  0

evdev                   9950  2

uio_pdrv_genirq         2958  0

uio                     8119  1 uio_pdrv_genirq

NFS Boot の IOPS

fio の手順が載っていたので、以下でNFS Boot の IO性能を計測。

母艦のosx の DISK は SSD です。Samsung MZ-7TD500BW 840 SSD

cd /usr/local/src/
sudo apt-get install -y libaio-dev
git clone -b fio-2.2.5 git://git.kernel.dk/fio.git
cd fio
./configure && make && sudo make install
cd ..
wget http://www.winkey.jp/downloads/visit.php/fio-crystaldiskmark
fio fio-crystaldiskmark | perl -ne ‘
print "$1 : " if(/(.+): \(groupid=/);
print "$1 " if(/bw=([\d. ]+[KM]?B\/s)/);
print "[ $1 IOPS]\n" if(/iops=(\d+)/)’

4K の読み書きが SDCard よりだんぜん速いです。

Seq-Read : 9555.8KB/s [ 9 IOPS]
Seq-Write : 10250KB/s [ 10 IOPS]
Rand-Read-512K : 9145.4KB/s [ 17 IOPS]
Rand-Write-512K : 10085KB/s [ 19 IOPS]
Rand-Read-4K : 3624.8KB/s [ 906 IOPS]
Rand-Write-4K : 3300.5KB/s [ 825 IOPS]
Rand-Read-4K-QD32 : 8885.1KB/s [ 2221 IOPS]
Rand-Write-4K-QD32 : 10492KB/s [ 2622 IOPS]

なるほどー。いいかも。

 

参考

discypus.jp/wiki/

fio – Flexible I/O Tester (2015-02-22)

NFS Boot でタイムマシーンから復元

osx 上の nfs で RasPi をブートしているので、タイムマシンからインストール直後に復元できるかやってみました。

 

まず、インストール直後、pi の電源を落とした状態で、タイムマシーンでバックアップを取得。対象は、nfs 直下のところだけにしています。

Time_Machine

現在の、パッケージ数の状態

[root@pi modules 07/26 06:19:54]# dpkg -l | wc -l
875
[root@pi modules 07/26 06:19:57]# 

nginx でも入れてみます。

[root@pi ~ 07/26 07:33:55]# dpkg -l | wc -l
878
[root@pi ~ 07/26 07:33:56]# 

パッケージ数が増えました。

で、設定やら、バージョンやらつついた後に、やっぱりやーめた(よくある事)、ということで初期状態に戻します。

 

pi はあらかじめ、シャットダウンしておきます。

タイムマシーンに入ります。

1

dev を除外して、すべて選択。

2

で、ブート。

[root@pi / 07/26 08:21:25]# dpkg -l | wc -l
875
[root@pi / 07/26 08:21:29]# 

便利ー!

FreeNAS + iSCSIやNFS 環境 でもスナップショットを使えばできるとは思いますが、この手軽さにはかないません。

オンラインバックアップが正常に動作するかは、sync している状態次第だと思うので、どうなるかわかりませんが。nfs のオプションにsync つけておけばいいのかしらね。

 

とりあえず、部屋が暑くてもうPCからは離脱。満喫か、温泉でも行ってきますかねー。空が夏!

espeink で試すことメモ

編集後記

いくつか、勘違いしていたことがわかりました。

まず、espeink のソースは10月以降に新しくなっていないこと。新しくなっていたのは、フォーラムのスレッドにあるように、esphttpd のソースでした。espeink も esphttpd の両方とも原作者は、sprite_tm さんですので勘違いしていたようです。

 

あと、 includes/ 以下には、c_types.h はなく、そして何もしなくてもSDK v1.0.1 ではコンパイルできました。

なので、今作っている開発ボード上でESP13 (SDK1.0.1を使い)でまずは動作しそうかを検討し、いけそうならPCB設計をESP13 用に書き直して、まずは実験再開です。

espeink のソースは検索するかぎり、誰も手をつけていなさそうなので、最新のSDK で通すにはメモリ関連をはじめ、そこそこ手をつけないと動作しなさそうです。

 

海外の方から、英語で書いてないから良くわかんないけど、結局SDK は何にしてるのとコメントがありました。まぁ、こっちも今検証している段階だから、なんとも言えないのですが、まずはSDK1.0.1 でやる方針で、最終目標は、ESP13 + SDK 最新で動作するようフィックスしたいんですけどね。

 

github に英語版の手順を作っておこうかしらね。git の使い方の練習にもなるし。

 

ということで、現在のまとめ。

・SDK1.0.1 でとりあえずやる

・ESP13 で現在のソースが動作するか検証

・いけそうなら、PCBをESP13 に書き換えて、プリント基板発注

・どうしてもだめなら、ESP12 版のPCB を作り検証

・まずは、esphttpd の動作を検証するため、単体で動作を確認(初回APにアクセスする部分の挙動が不明なので)

・パッチを作っているひと発見。http://www.chaoscode.eu/data/espeink/ このパッチは何しているか検討。

 

という長期決戦です。

 

 

——- 以下、記事を書いたときのもの

作者のサイトで質問していましたが、Alden さんがコンパイルのヒントを書いておいてくれたようです。

http://spritesmods.com/?art=einkdisplay&page=7

どうやら、SDK は、2015年の4月中旬のものということなので、esp_iot_sdk_v1.0.1_15_04_24.zip だと思います。検証でもコンパイルエラーは出ませんでした。変更するところは、以下のようです。

— includes/c_types.h

#if 0 の部分と #endif の行 11 と 26 のようです。

 

esptool は C 製のesptool-ck を使うと。

webpages.espfs のところを、find. | を挿入せよと。

 

今コードを見ていないので、次回チャレンジするときはこの部分を注意してやってみます。

http://www.esp8266.com/viewtopic.php?f=34&t=5748

ここで、作者がコメントしていました。質問者は、SDK1.4 だとerror が出るよと。作者はリポジトリをFix しておいたから以下のコマンドで使って更新して再度やってみたらと。この投稿が9月30 日のようです。自分が試したときは9月28 日以前でした。

git pull

git submodule update

 

とりあえず、もう一度コンパイルしてみます。

そして、うまく行けば本格的にプロジェクト再開です。

 

▼こんど試すときのメモ

・sdk1.0.1 でソース変更してやってみる

・sdk1.4 最新にして、リポジトリを最新のにしてからコンパイル