NanoPi R4S (2) パフォーマンス測定編

Back Issue

NanoPi R4S (1) 導入編
NanoPi R4S (2) パフォーマンス測定編（本稿）

テスト環境セットアップ

　前回の投稿ではNanoPi R4SというSingle-Board Computer（SBC）がどういうマシンかということについて、ハードウェアの側面とソフトウェアの側面から実機を使わない主にカタログスペック的な観点から説明した。今回はArmbian 21.02.1のリリースを受けて実際のパフォーマンスを測定してみたい。前バージョンArmbian 20.11.1は筆者の環境では起動すらしなかったが、今回のArmbian 21.02.1については問題なく起動することができた。LAN側のEthernetを接続すると本体上面のWAN側LEDが点灯するという軽微な問題はあるが実用上の支障は無い。

　今回のベンチマークでは2種類のハードウェアと2種類のOSイメージとで計3種類の環境を作成し測定している。これらの環境で測定できるのは主に以下の2点である。

1. 同一ハードウェア＝NanoPi R4Sにおける異なるLinux Kernelでの性能の違い
2. Cortex-A72ベースシステムとCortex-A53ベースシステムでの性能の違い

今回の測定ではNanoPi R4Sと比較のためのNanoPi Neo2の2種類のSBCを用いている。これらのSBCを所有している人は多くないと思われるが、類似の環境は存在し概ね同じ傾向の結果を得られるだろうと予想できる。具体的にはRaspberry Pi 3とRaspberry Pi 4にはNanoPi Neo2・NanoPi R4Sと同様にCortex-A53ベース・Cortex-A72ベースという違いがある。

		NanoPi R4S		NanoPi Neo2
SoC		Rockchip RK3399		Allwinner H5
OS Image		FriendlyCore 20201226 Ubuntu Core 20.04 LTS	Armbian 21.02.1 Ubuntu 20.04 LTS
Linux Kernel		4.19.111 (BSP)	5.10.12 (Mainline)
CPU	big core	Cortex-A72 1.8 GHz x 2		Cortex-A53 816 MHz x 4
	little core	Cortex A53 1.4 GHz x 4
GPU		Mali-T860MP4 81.6 GFLOPS @ 600 MHz		Mali-450MP4
Memory		LPDDR4 x32 4 GB		DDR3 x16 512 MB

　NanoPi R4SではArmbian 21.02.1とFriendlyELEC純正FriendlyCoreで測定している。いずれもUbuntu 20.04 LTSをベースにしているため機能的な差異はほぼ無いがLinux Kernelの違いが性能に影響を与える可能性がある。
　FriendlyCore OSイメージはUbuntu 20.04ベースのUbuntu CoreユーザースペースにRockchipのBoard Support Package（BSP）Kernelという組み合わせとなっている。RockchipのBSP Kernelは2018年のLTS KernelであるLinux Kernel 4.19.111である。対するArmbian 21.02は通常のUbuntu 20.04のユーザースペースに2020年のLTS KernelであるLinux Kernel 5.10という組み合わせとなっている。

　ちなみに、FriendlyCoreはUbuntu Coreベースなので構成が通常のUbuntuとは微妙に異なり、例えば起動後に/bootの中身や設定ファイルなどの配置が通常のUbuntuとは異なる。ただし、パッケージのリポジトリ－＝バイナリーは同じなので性能的な差異は無いと考えられる。この辺りは用途の違いにもよるし本稿の趣旨と異なるため割愛する。
　対するArmbianはコミュニティー自体が謳う通りDebian/Ubuntuベースの汎用のOSであるが、デバイスに応じてLinuxカーネルのコンパイル時のコンフィグがSoCに合わせてカスタマイズされているほか、Swapが省略されていたりAPTもRecommendsやSuggestsが除外されているなど、SBC/組込への一定の配慮がなされている。

　上述の通り、今回はNanoPi R4Sの比較用としてNanoPi Neo2を用意した。ただし、結論から言えばあまり比較対象として有効に用いることができなかった。
　比較用にNanoPi Neo2 を用いた主な理由は以下の通りである（これらに加えて筆者が既に所持していたから、という理由もある）。

• SoCベンダーの公式情報によるとNanoPi Neo2のAllwinner H5はCortex-A53 1.5 GHz 4-core、対するNanoPi R4SのRockchip RK3399はCortex-A72 2.0 GHz 2-core + Cortex-A53 1.5 GHz 4-coreとなっている。言い換えるとH5はRK3399のLITTLE側の構成に似ている。スマートフォンのようなワークロードでは大して意識することではないが、仮想化などで複数OSを動かしたり、アプリケーションを特定CPUコアに割り当てるような場合には、どの程度の性能が期待できるか役立つ場合がある
  
  
• ドキュメントを参考にする限りAllwinnerの暗号エンジンはRockchipのものより強力そうである。つまりNanoPi R4SとNanoPi Neo2の比較は、高速CPU+低速アクセラレーターと低速CPU+高速アクセラレーターの違いとして見ることができ、特定用途でNanoPi Neo2の方が優れた結果を得られることを期待できた

しかし、詳細は後述するが、今回の測定では上記のような検証はできなかった。今後、検証が行えた場合は追加でレポートしたいと思う。

　ところで、NanoPi Neo2について御存知であれば公式のスペックと上記のスペックとの違いに違和感を持たれたのではないかと思う。
　FriendlyELECサイトによるとCortex-A53 1.5 GHz Quad-coreのはずだが、Armbianでは816 MHz・FriendlyELEC純正イメージでも1008 MHzでしかでない。もし1.5 GHzで動作していればNanoPi R4Sのbig.LITTLEのLittle側Cortex-A53 1.5 GHz Quad-coreと同等のスペックとなり比較が容易だったのだが、実際はその約1/2の816 MHzなので比較のしようがなかった。
　実は、これほど極端な例は珍しいにしても中国ベンダー製SoCではカタログに記載の機能・性能が達成できない例が珍しくない。例えば2年ほど前にSBC市場を席巻したAmlogic S905も当初は公称2.0 GHzだったが実際は最大1.5 GHzまでだったし（2.0 GHzを設定可能だが、2.0 GHzで設定しても実際には1.5 GHzで動作する）、RK3399もメーカーのカタログスペックではCortex-A72 2.0 GHz + Cortex-A53 1.5 GHzのはずだが、実際にはCortex-A72 1.8 GHz + Cortex-A53 1.4 GHzとなっている。

Unix Bench

$ wget https://github.com/kdlucas/byte-unixbench/archive/v5.1.3.tar.gz
$ tar -zxvf v5.1.3.tar.gz
$ ./Run -c 1 -c 6

		NanoPi R4S		NanoPi Neo2
SoC		Rockchip RK3399		Allwinner H5
OS Image		FriendlyCore 20201226 Ubuntu Core 20.04 LTS	Armbian 21.02.1 Ubuntu 20.04 LTS
Linux Kernel		4.19.111 (BSP)	5.10.12 (Mainline)
Benchmark Results
Unix Bench Single-core Index score		400.8 (-c 1)	550.6 (-c 1)	247.3 (-c 1)
Unix Bench Multi-cores Index scores		710.0 (-c 2)  +77.1 %	1042.1 (-c 2) +89.3 %	702.8 (-c 4) +184.2 %
		855.2 (-c 4) +113.4 %	1325.4 (-c 4) +140.7 %
		1007.3 (-c 6) +151.3 %	1565.6 (-c 6) +184.3 %

　Unix Benchは定番のDhrystone（Integer）・Whetstone（Floating Point）・ファイルコピーなど多岐に渡る様々なベンチマークを総合したものでSBCの性能の測定にはよく使用される。いずれも古いベンチマークなのでハードウェアの特徴を見るには有益だが現代のワークロードには必ずしも合わないうえ、命令セットが異なると結果の比較が不可能なので注意が必要である。恐らく組込でよく使われる理由としては、現代の組込プロセッサーで実行可能なほど軽量なうえ、IPCの目安が一言で分かるからだろう。
　Unix Benchではベンチマークの実行に使用するコア数をオプションで指定することができ、NanoPi Neo2ではCortex-A53 x4の対称なコアのため4コアでのマルチコア性能がシングルコア性能 x コア数に近い結果となっているが、RK3399はCortex-A72 x2 + Cortex-A53 x4の非対称なコア構成のためマルチコア性能がシングルコア性能 x コア数に近い数字にはならない。そのためRK3399の場合1-coreと2-coreとでは+77～89％も性能が向上しているにも関わらず、1-coreと4-coreとでは+113～140％（2-core比で+20～27％）しか向上していない。

　総合成績を一見するとNanoPi R4S + Armbianの組み合わせがNanoPi R4S + FriendlyCoreの組み合わせを大幅（+50％弱ほど）に上回っており、NanoPi Neo2 + Armbianの組み合わせが善戦しているように見えるが、詳細を見ると実際はそうでもないことが分かる。
　以下はシングルコアの成績の詳細を表にまとめたもので、NanoPi R4S+ FriendlyCoreの結果＝100％として何％違いがあるかを示している。多くの項目でNanoPi R4S + Armbianの組み合わせとNanoPi R4S + FriendlyCoreの組み合わせは同等の成績を出しており、ファイルコピー・プロセス生成・システムコールのみ大差がついている。また、NanoPi Neo2 + Armbianの組み合わせは同じくファイルコピー・プロセス生成・システムコールで善戦しているものの、素のCPU性能による部分が大きい整数演算（Dhrystone）と浮動小数点演算（Whetstone）などではやはり大差がついている。確かにLinux Kernelの差で多少の性能改善はするものの、（当たり前だが）ハードウェア的な優位性を覆すほどの改善が見られるわけではないことが分かる。

	NanoPi R4S		NanoPi Neo2
SoC	Rockchip RK3399		Allwinner H5
OS Image	FriendlyCore 20201226 Ubuntu Core 20.04 LTS	Armbian 21.02.1 Ubuntu 20.04 LTS
Dhrystone 2 using register variables	15689169.2	15457666.6 (-1.47 %)	4049177.8 (-74.19 %)
Double-Precision Whetstone	3159.3	3164 (+ 0.15 %)	1031.8 (-67.34 %)
Execl Throughput	1235.9	1775.6 (+ 43.69 %)	635.2 (-48.60 %)
File Copy 1024 bufsize 2000 maxblocks	136595	353712.9 (+158.95 %)	129941.4 (-4.87 %)
File Copy 256 bufsize 500 maxblocks	42122	125397.8 (+197.70 %)	41873.2 (-0.59 %)
File Copy 4096 bufsize 8000 maxblocks	358439.2	848741.5 (+136.79 %)	284041.3 (-20.76 %)
Pipe Throughput	376939.1	501045.7 (+32.92 %)	209519 (-44.42 %)
Pipe-based Context Switching	78081.8	41778.6 (-46.49 %)	37026.3 (-52.58 %)
Process Creation	1613.1	2276.8 (+41.14 %)	1799.3 (+ 11.54 %)
Shell Scripts (1 concurrent)	2664	2260.8 (-15.14 %)	1498.3 (-43.76 %)
Shell Scripts (8 concurrent)	725.7	1066 (+46.89 %)	431.2 (-40.58 %)
System Call Overhead	371994.6	519052.7 (+39.53 %)	354650.5 (-4.66 %)

　筆者は今回のNanoPi R4S + Armbianの組み合わせとNanoPi R4S + FriendlyCoreの組み合わせとの差異は実用上は違いが無いないと考える。同じRockchip RK3399を搭載したハードウェアでもKobol Helios64のようなNASではファイルコピー性能の向上は恩恵がありそうだが、NanoPi R4Sのハードウェア構成はNASよりも、ルーター・VPNゲートウェイ・ファイヤーウォール等のネットワークアプライアンスとしての利用の方が主眼に思える。これらのネットワークアプライアンスではストレージにアクセスするのはシステムやサービス起動時がほとんどで稼働中はほとんどディスクにアクセスしないため（もちろんログなどは記録するので皆無ではないが…）、Linux Kernelによる改善点で実用性が大きく向上するとは考え難い。

OpenSSL speed (AES-128-CBC, AES-256-CBC)

openssl speed -elapsed aes-128-cbc
openssl speed -elapsed -evp aes-128-cbc
openssl speed -elapsed aes-256-cbc
openssl speed -elapsed -evp aes-256-cbc

		NanoPi R4S		NanoPi Neo2
SoC		Rockchip RK3399		Allwinner H5
OS Image		FriendlyCore 20201226 Ubuntu Core 20.04 LTS	Armbian 21.02.1 Ubuntu 20.04 LTS
Linux Kernel		4.19.111 (BSP)	5.10.12 (Mainline)
Benchmark Results
OpenSSL w/o '-evp' AES-128-CBC 1KB		92054.87k	92261.03k	25189.72 KB/s
OpenSSL w '-evp' AES-128-CBC 1KB		1282523.14k	1282453.50k	547143.68 KB/s
OpenSSL w/o '-evp' AES-256-CBC 1KB		68269.74k	68371.80k	25242.28 KB/s
OpenSSL w '-evp' AES-256-CBC 1KB		981640.87k	981023.06k	379278.68 KB/s

　OpenSSLベンチマークではOpenSSL 1.0.xなど古いバージョンでは8KBまで、OpenSSL 1.1.xなど新しいバージョンでは16KBまで測定されるため、一般的には8KB/16KBの結果で比較を行う場合が多いように思われるが、ここでは用途を鑑み1024 Byteでの値を示している。

　例えばWebサーバーなどを想定している場合、HTTPSで通信するのでアプリケーション層/Layer-5のSSLトンネルに入る前に暗号化/出た後に復号化され、データはLayer-4で分割/結合される。このため8/16KBを超えるようなデータ（例えば10 MB）であってもそのままアプリケーション層で暗号化/復号化され、その下のLayer-4で分割される。つまり、HTTPSのワークロードでは8KBや16KBでの測定は目的と用途が合致している。
　しかしNanoPi R4SやNanoPi Neo2などはハードウェアの特性上、IPsecやOpenVPNを用いたVPNゲートウェイとしての用途が考えられる。IPsecでは分割後のLayer-3でペイロードが暗号化/復号化されるし、OpenVPNのSSL-VPNではLayer-2仮想NIC経由で再度Layer-5からSSLトンネルを通るためやはり分割後に暗号化/復号化される。つまり、IPsecやOpenVPNのようなワークロードでは最大で1500 Byte前後で暗号化/復号化されるため1024 Byteの測定値が現実に近い数字になると考えられる。
　ちなみに、IPsecのようにLayer-3でペイロードが暗号化/復号化されるということはLinux Kernel内のカーネルモジュールで暗号化されるはずで、ユーザースペースで動作するOpenSSLのベンチマークは必ずしも実態に即していないので注意が必要である。

　コマンドのオプションの'-evp'フラグはEVPインターフェースでのハードウェア暗号エンジン使用の有無を示している。
　ただし、'-evp'フラグで有効化されている暗号エンジンはプロセッサーベンダープロプライエタリーのハードウェア暗号エンジンではなくArmv8 Crypto Extension命令である（Intel CPUの場合では'-evp'の指定によりAES-NI命令が有効化される）。これはArmv8-A Advanced SIMDのオプション命令でプロセッサーベンダーがArmからライセンスを購入することで有効化している（ちなみにRaspberry Pi 3/4では使用できない）。
　プロセッサーベンダープロプライエタリーのハードウェア暗号エンジンが使用されていないことはLinux KernelモジュールをLoad/Unloadして結果を比較することで確認できる。

　Rockchip RK3399もAllwinner H5プロセッサーベンダープロプライエタリーのハードウェア暗号エンジンを搭載しており、メインラインLinux Kernelで（カーネルスペースでは）使用できる。しかし、OpenSSLからは使用できなかった。
　これはどうやらUbuntu 20.04標準のOpenSSLバイナリーがAF_ALG暗号エンジンが有効化されてビルドされていないようだ。このことは残念ではある。CryptodevやAF_ALGのアーキテクチャーや設定方法などについては組込SBCベンダーのGateworksのWikiやDIY NASメーカーのKobolのWikiに詳しい。使用している他社製SoCの部分を読み替えればRockchipやAllwinnerのSoCにも応用できる。
　AF_ALGインターフェースを用いた暗号エンジンの利用については別の記事で比較検討する予定である。

　NanoPi Neo2の場合AES-128-CBCで暗号エンジン使用で547143680KB/s（4.07 Gbps）の速度がでている。VPNということは双方向通信だし通信以外の処理も発生するから多少は劣化するだろうが暗号化/復号化の性能だけを見れば1 Gbpsの双方向通信ぐらいは可能そうに思える。NanoPi R4Sではさらに高速である。
　ただし、上述の通り暗号化/復号化にCPUの暗号エンジンを使用している点に注意が必要である。例えばVPNゲートウェイを構築する場合、暗号化/復号化に加えて異なるネットワーク間でパケットを転送するフォワーディング処理が必要となるが、フォワーディングはCPUを食うため両方の処理を合わせて1 Gbps出るかについては怪しい。暗号化/復号化をハードウェアアクセラレーターにオフロードすることを検討したいところである。

　同一ハードウェアでのLinux Kernelバージョンの違いによる性能の違いであるが、カーネルバージョンの違いによる性能の差異はハードウェアやソフトウェア次第では大きな差が生じることもあるが（参考）、今回の測定では有意な差は見られなかった。

まとめ

　冒頭でも述べた通り、今回のテストでは以下の2点の検証を行った。

1. 同一ハードウェア＝NanoPi R4Sにおける異なるLinux Kernelでの性能の違い
2. Cortex-A72ベースシステムとCortex-A53ベースシステムでの性能の違い

　まず1点目のLinux Kernelバージョンについてであるが、上述の通りLinux Kernelバージョンの違いについては差は限定的であった。そのため性能を目的として新しいLinux Kernelをインストールする意味は薄いかもしれない。
　本稿では性能に注目したためこのような結果となったが、しかし、Linux Kernelには様々な機能が追加されているため、必要な機能が目的で新しいLinux Kernelを導入することは考えられる。例えばNanoPi R4Sの用途としてVPNゲートウェイが考えられるが、VPNプロトコルにWireGuardを使用するのであればLinux Kernel 5.6以降が必要となるためFriendlyCore（Linux Kernel 4.19）よりもArmbian 21.02.1（Linux Kernel 5.10）の方が適していると考えられる。

　次に2点目のCPUコアの違いについてであるが、NanoPi R4SとNanoPi Neo2との違いが小さかったことは意外であったが順当な結果と言える。その意味でも暗号エンジンを有効化できなかったことは残念だった。

　スマートフォンなどに使用されるArm系組込SoCはコモディティ化して本来の使われ方が忘れられがちだが、もともと組込SoCではアクセラレーターを使う前提でCPUは非力な仕様の製品が少なくない。例えば10年以上前は主流のネットワークプロセッサーだった旧Motorola/旧Freescale（現NXP）のPowerQUICC/QorIQなどもCPUはPCより数段劣るものだったが専用のパケットエンジンと暗号エンジンでルーターやVPNゲートウェイなどに広く使われた。
　上述の通り、NanoPi R4S（RK3399）とNanoPi Neo2（H5）とではCPU性能はRK3399に分があるが暗号エンジンではH5の方が優位に見えるため、アクセラレーターを用いるケースではCPUで劣るはずのH5が優位な場合があることを検証することができると考えたが、Armbian/Ubuntu標準の構成では暗号エンジンをOpenSSLから使用することができず、意図したような結果は得られなかった。この点については今後レポートできればと思う。
　UbuntuのOpenSSLパッケージでAF_ALGが有効化されていない理由は不明だが推測は可能である。そもそも (1) Ubuntuが主に使用されているx86-64プロセッサーには暗号エンジンが搭載されていない (2) 組込プロセッサーの一部でAF_ALGインターフェース対応の暗号エンジンを搭載したデバイスがあるが効果は限定的だからである。そもそも、暗号エンジンに限らないがアクセラレーターを有効化することが常に有効とは限らない。アクセラレーターが有効なのは (1) CPU-アクセラレーター間のオーバーヘッドを加味してもその方が速い場合（例：GPGPU） (2) CPUのワークロードをアクセラレーターにオフロードすることでCPUの空き時間を増やせる場合に限られる。先にも挙げたKobolのWikiではMarvellのSoCでMarvell CECA暗号エンジンをCryptodev・AF_ALGから利用した場合をベンチマークで測定しているが、一部の条件を除いてCPU時間がカーネルスペースでもユーザースペースでも増えるうえにスループットも大きくは向上していないケースが多く、このような場合ではアクセラレーターを用いることは逆効果となりかねない。PC/スマートフォンのCPUでは128-bit/256-bit SIMD演算を2 GHz～（INT32/FP32・128-bit 4-way SIMD・2 GHzで8 GFLOPS）とか超高速に演算できるわけで、よほど高性能なアクセラレーターでなければ逆効果となるのは想像に難くない。GPUなどを除く多くのアクセラレーターでは500 MHzとかがざらであることを考えれば想像に難くないだろう。