測定環境
次の環境でApple M1 macOSをクライアントとして使用した場合に、暗号通信を含め10Gbpsの性能を発揮できるかどうか、またその負荷を測定した。
クライアント
- Apple M1 4Pコア 4Eコア 16GB RAM / macOS Monterey
- 10Gbps NIC 搭載 / Ethernet / MTU 1500
- Rosettaインストール済み
サーバー
- Intel Core i7 4790S 3.2GHz 4cores 8threads 16GB RAM / Linux CentOS 7.8
- 10Gbps NIC搭載 / Ethernet (SFP+SRポート) / MTU 9000
パスMTUは1500バイトである。クライアント(macOS)で次のスループット性能とCPU負荷を対象に評価を行った。
- 基礎的な通信性能と負荷
- 暗号処理の性能と負荷 (ARM AES, AES-NI on Rosetta)
- ファイルコピー（暗号通信、暗号通信無し）の性能と負荷
基礎通信性能測定
まず、macOSからLinuxへTCP通信を実行して環境の回線キャパシティである10Gbpsの通信がそもそも可能かどうか確認を行った。測定はiperf3を使用して60秒間TCP通信を行い、通信スループットとCPU負荷を確認した。
user@usernoMac-mini ~ % iperf3 -c 192.168.100.14 -t 60 Connecting to host 192.168.100.14, port 5201 [ 5] local 192.168.100.20 port 49159 connected to 192.168.100.14 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 1.08 GBytes 9.27 Gbits/sec [ 5] 1.00-2.00 sec 1.10 GBytes 9.41 Gbits/sec ...(中略) [ 5] 58.00-59.00 sec 1.10 GBytes 9.41 Gbits/sec [ 5] 59.00-60.00 sec 1.10 GBytes 9.41 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-60.00 sec 65.6 GBytes 9.40 Gbits/sec sender [ 5] 0.00-60.00 sec 65.6 GBytes 9.40 Gbits/sec receiver iperf Done.
イーサネットフレームやIP/TCPヘッダによるオーバーヘッドは3%強であるため、9.40Gbpsという結果は概ね回線キャパシティを十分利用できているとみられる。この際、アクティビティモニタで確認した最大のCPU負荷は16.6%であった。
暗号性能測定 (ARM AES 及び AES-NI on Rosetta)
次の条件でmacOS上で３種類の暗号ブロックモード（CBCとCTRはメッセージ認証なし）の性能を実測した。
- Crypto++を使用
- バッファ to バッファで暗号処理（バッファ上での暗号処理でない）
- ゲストマシン上で8GBのデータの暗号化処理を行い、時間を計測してスループットを計算
- CPU負荷はアクティビティモニタを視認して確認された最大値を記載
- ARM AESの性能を測定する場合は、Apple M1環境でビルドした測定プログラムを使用
- Rosetta環境でのAES-NIの性能を測定する場合は、Intel版 macOSでビルドした測定プログラムを使用
| 暗号命令セット | ブロックモード | スループット | CPU負荷 |
| ARM AES (native) | AES256 CBC | 4.85Gbps | 100% |
| ARM AES (native) | AES256 CTR | 12.6Gbps | 100% |
| ARM AES (native) | AES256 GCM | 11.0Gbps | 100% |
| AES-NI on Rosetta | AES256 CBC | 3.50Gbps | 100% |
| AES-NI on Rosetta | AES256 CTR | 10.4Gbps | 100% |
| AES-NI on Rosetta | AES256 GCM | 9.29Gbps | 100% |
※CPU負荷は１コアあたり100%。トータルで800%。
Rosetta実行環境上では、AES-NIの各命令がARM用のAES命令等にエンコード及びデコードされる追加の負荷を考えると、この変換に伴うオーバヘッドにより性能の低下が生じると想定される。測定結果をもとに低下率を計算すると次のような低下率となっており、CBCブロックモードでより大きなオーバーヘッドがみられるものの、概ね想定した結果となった。
- AES256 CBC 低下率 28%
- AES256 CTR 低下率 18%
- AES256 GCM 低下率 16%
Archaea tools (HCP tools) コピー性能測定 (Rosetta)
次の条件でArchaea toolsによるリモートコピーをクライアント(macOS)から実行した場合の、アプリケーションペイロード（ファイルのデータ）の転送性能を測定した。
- hcpコマンドを使用
- メモリ to メモリコピー動作で測定（ディスクI/Oの影響を除外。通信プロトコルの性能を計測）
- 8GBの一つのファイルを転送する動作を行い、アプリケーション統計のペイロード速度を確認
- 平文通信と暗号通信（AES256/GCM）を測定（CPU負荷の比較。暗号処理の負荷への影響を確認）
| 実行環境 | ブロックモード | スループット | CPU負荷 |
| Rosetta | – (平文) | 9.31Gbps | 110% |
| Rosetta | AES256 GCM | 9.26Gbps | 220% |
| Native | – (平文) | 9.31Gbps | 100% |
| Native | AES256 GCM | 9.26Gbps | 200% |
平文通信でも暗号通信でも概ね基礎通信性能にアプリケーションプロトコルのオーバーヘッド（アプリヘッダ情報など）とみられる程度の性能低下で収まった（iperf3の測定結果9.40Gbpsから最大1.5%程度の低下率）。また、Rosetta環境での暗号通信では、暗号処理(AES256/GCM)自体が9.29Gbpsで頭打ちとなるため、それに制限された結果(9.26Gbps)となっている。平文通信時のCPU負荷から基礎通信性能で確認された負荷を除いた負荷がアプリケーションの負荷である（90%強）。また、暗号通信時の負荷との差が概ね暗号処理にかかっている負荷と想定される。今回のケースでは、主にクライアントから送信するデータに対して暗号化を行い、この処理はTCP接続と対で行われる。転送スループットは、先に測定した暗号処理性能の限界まで達しているので、先に測定した暗号性能の結果に記載の負荷だけ上昇すると考えられる（厳密には受信側でも、一定間隔で受信する送達確認データなどを復号するため、その負荷も積みあがる）が、概ねこれに近い結果となった。Native環境下での性能は、Rosetta環境での性能と比較して転送スループットはほぼ同等の結果でCPU負荷が若干低減される結果となった。この低減は、Rosetta環境でのx86_64命令の変換オーバーヘッドが無くなったことが要因と推定される。