廉価ゲーミングコンソール代替の廉価PCを考える： 1. 検討編

動機

　第9世代ゲームコンソールが登場したのは2020年後半のことである。これは3年＝36ヶ月以上というムーアの法則でいえば2回分相当で、つまり集積回路の集積度は2倍×2回=4倍を達成できる計算になる。

　そこで、本稿のテーマは廉価ゲーミングコンソール（Xbox Series S）相当の性能を同価格帯のPCで代替できないか検討することとなる。
　2020年時点のPCでもフルスペックのゲーミングコンソールと同等以上の性能を達成することは可能だったが2倍程度の費用が必要だった。つまり本稿の検証内容とは、3年間を経て廉価PCの性能が底上げされて廉価ゲーミングコンソール相当の性能を同価格帯のPCで代替できないか？というものである。

　結論から言えば、机上のスペックに基づくと2024年現在どころか現在の路線のCPU/GPUでは3年先まで達成できそうにない。ただし、ユーザー体験というのは机上のスペックの話だけではないので、その辺りも併せて考えてみたい。

　尚、本稿では可能な限り高いコストパフォーマンスを達成するためAmazon・AliExpressなどのオンラインショップで販売されているAMD APU搭載PCをベースに検討している。

スペックの比較検証

　以下は比較的手頃なAMD製APUと、ローエンドのゲームコンソールとを比較したものである。一見して判るのは、RDNA2以降のAPUではスペックシート上ではXbox Series S相当の理論上の演算性能（GFLOPS）を達成可能だが、その一方でメモリー帯域が低くBytes/FLOPSは悪化し続けている。

		PC 7840HS		PC 7640HS		PC 7735HS/6800H		PC 5700U	Steam Deck	Xbox Series S
Price range		?	> EUR 500	?	?	?	> EUR 350	> EUR 200	EUR 450	EUR 250
SoC codename		Phoenix				Rembrandt		Lucienne	Aerith	Scarlett
CPU	uArch	Zen 4				Zen 3+		Zen 2
	core#	8		6		8		8	4	8
	Base freq	3800		4300		3200		1800	2400
	Turbo freq	5100		5000		4750		4300	3500	3400
GPU	uArch	RDNA3 780M		RDNA3 760M		RDNA2 680M		GCN5 Vega8	RDNA2	RDNA2
	CU	12 CU 768 SP		8 CU 512 SP		12 CU 768 SP		8 CU 512 SP	8 CU 512 SP	20 CU 1280 SP
	Base freq	800		800		400		300	1000
	Turbo freq	2700		2600		2200		1900	1600	1565
	GFLOPS (FP32)	8294		5324		3380		1900	1600	4000
Memory	Type	LPDDR5X-7500	DDR5-5600	LPDDR5X-7500	DDR5-5600	LPDDR5-6400	DDR5-4800	DDR4-3200	LPDDR5	GDDR6
	Config	x32 4ch	x64 2ch	x32 4ch	x64 2ch	x32 4ch	x64 2ch	x64 2ch	x32 4ch	x256
	Capacity	N/A		N/A		N/A		N/A	16 GB	10 GB
	Bandwidth	120.0 GB/s	89.6 GB/s	120.0 GB/s	89.6 GB/s	102.4 GB/s	76.8 GB/s	51.2 GB/s	88 GB/s	225 GB/s
B/F		0.0145	0.0108	0.0225	0.0168	0.0303	0.0227	0.0269	0.0550	0.0563

　あまり話題になることがないが、メモリーの性能とは大まかに「遅延」と「帯域」であり、膨大な数の座標データやテクスチャーなどを扱うGPU性能に関わるのは主に「帯域」の方である。
　ゲーミングコンソールやPC用dGPUで高コストながら広帯域のGDDR系メモリー256～512 bit幅で接続されているのはこのためで、上の表でもゲーミングコンソールではBytes/FLOP（B/F）が0.05以上が確保されている。これに対し、汎用的なPC用メモリーを使うAPUではメモリー帯域により性能が制限される。

　そもそも、Ryzen APUファミリーの場合、Zen世代～Zen3世代（2017～2022年）の5年間に渡ってGCN5系GPU最大8～11CUという構成で停滞してきたが、Zen3+世代"Rembrandt"～Zen4世代"Phoenix"/"Hawk Point"ではRDNA系GPUで理論上の演算性能は大幅に向上する一方でB/Fは大幅に悪化し続けている。DDR5/LPDDR5メモリーの採用によりDDR4/LPDDR4メモリー以上の帯域を確保できているが、AMD Ryzen APUファミリーのiGPUの性能向上がメモリー帯域の向上を上回っているためである。

　以下の表の通り、過去のRyzen APUではBytes/FLOPSが概ね0.02付近で設定されてきたが、RDNA3 iGPU搭載の"Phoenix"世代APUから0.01程度に大幅に悪化している。

Family		Example	GPU uArch	GPU perf (GFLOPS)	DRAM Spec	DRAM Bandwidth (GB/sec)	B/F
Ryzen 2000	Desktop	Ryzen 2400G	GCN5 Vega 11	1760.0	DDR4-2933 x 2ch	46.93	0.0267
	Mobile	Ryzen 2800H		1830.4	DDR4-2400 x 2ch	38.40	0.0210
Ryzen 3000	Desktop	Ryzen 3400G	GCN5 Vega 11	1971.2	DDR4-2933 x 2ch	46.93	0.0238
	Mobile	Ryzen 3780U		1971.2	DDR4-2400 x 2ch	38.40	0.0195
Ryzen 4000	Desktop	Ryzen 4700G	GCN5 Vega 8	2150.4	DDR4-3200 x 2ch	51.20	0.0238
	Mobile	Ryzen 4800H		1792.0	DDR4-3200 x 2ch	51.20	0.0286
Ryzen 5000	Desktop	Ryzen 5700G	GCN5 Vega 8	2048.0	DDR4-3200 x 2ch	51.20	0.0250
	Mobile	Ryzen 5980HX		2150.4	DDR4-3200 x 2ch	51.20	0.0238
Ryzen 6000	Mobile	Ryzen 6980HX	RDNA2 680M	3686.4	DDR5-4800 x 2ch	76.80	0.0208
Ryzen 7000	Mobile	Ryzen 7940HS	RDNA3 780M	8600.0	DDR5-5600 x 2ch	89.60	0.0104
Ryzen 8000	Desktop	Ryzen 8700G		8907.1	DDR5-5200 x 2ch	83.20	0.0093

　ところで、調べていくとRDNA3がスペックシート上の性能と実際の性能とが乖離していることに気付かされる（この辺りの詳細な検証は別記事にする予定である）。
　各メディアによる解説記事を見ると、RDNA3はRDNA2に比してCU内の演算ユニット数が倍増しており、同じCU数なら2倍の理論上の演算性能を発揮することになっている（参考：ASCII.jp・4Gamer）。このため、RDNA2世代のRadeon 680MとRDNA3世代のRadeon 780Mとでは同じ12 CUだが理論上の性能が2倍となっている。ところが、実性能では780Mと680Mとでは2倍も性能差は見られずGPUの動作速度向上とメモリー帯域の向上で説明がつく程度に留まっている。

　以下はレビューサイトNotebookCheckに掲載されている3DMarkのGPU周りのスコアを抜き出したもので、RDNA2世代はGCN5世代・RDNA3世代はRDNA2世代と比較した伸び率を記載してある。

3DMark	Theoretical Performance (GFLOPS)	Time Spy Graphics	Ice Storm Unlimited Graphics	Cloud Gate Graphics	Fire Strike Standard Graphics
7840HS (RDNA3 780M) vs 680M	8294 (+145%)	2642 (+19%)	430970 (+31%)	44721 (+10%)	7526 (+13%)
7640HS (RDNA3 760M) vs 680M	5324 (+58%)	2116 (-4%)	N/A	41767 (+3%)	6142 (-7%)
7735HS (RDNA2 680M) vs Vega8	3380 (+78%)	2221 (+92%)	329446 (+23%)	40724 (+51%)	6660 (+81%)
5700U (GCN5 Vega8)	1900	1156	267505	26945	3677

　Vega8→680MはiGPU単体で理論上+78%の性能向上なのでシステム全体の実測値で+23%～+92%・平均+61％の性能向上ということで順当な結果となっているが、680M→780Mは理論上+145％の性能向上ながら+10％～+31％・平均+18％の性能向上に留まる。確かに性能は向上しているのだが、理論上の性能向上幅からすると疑問が残る数字となっている。

　メモリー帯域の狭さによって性能向上が制限されているのでは？という疑問もあろうが、それは恐らく違う。なぜなら理論上ではGPU性能もメモリー帯域も上のはずのRyzen 7640HS（Zen 4 6コア＋Radeon 760M）はRyzen 7735HS（Zen 3 8コア＋Radeon 680M）に比して0～10％ほど劣っているからである（Ryzen 7640HS vs 7735HS・Radeon 760M vs 680M）。
　恐らく、筆者の想像ではRDNA3には2種類のバージョンが存在し、下位モデルの構造はRDNA2と同等構成の改良版ではないかと想像している。実際、RDNA3＝演算性能がRDNA2の2倍と想定しないならば780M・760Mの理論上の性能は680M比でそれぞれ＋23％・－21％で、メモリーの性能向上も鑑みれば、それぞれ＋10～＋35％・－10～0％というのは概ね順当な数字に思える。

Ryzen 7735HS

　スペックシート上の比較検証と説明は上述の通りだが、実際に実験する検証用マシンとしてRyzen 7735HS搭載機を使用することとする。

　本稿の企画の趣旨からすると、2022年初頭に登場したAPUを採用というのもおかしな話だが、Ryzen 7840HS搭載PCは実際の性能が+10～35％ほど上回る一方で価格もRyzen 7735HS搭載PCの+45％程度・Xbox Series Sの約2倍ほど高価なため趣旨に反すると判断したためである。

　次回はRyzen 7735HS搭載PCのゲームコンソール化を行っていきたい。

OLEDテレビを買った話

　私事で恐縮だが、OLEDテレビを購入したので、備忘録を兼ねて記事に残しておこうと思う。

動機

　筆者は日本を離れた2012年以降テレビを所有していなかった。それは、引越する際に邪魔になるとか、ストリーミングならPCモニターで観られるとかいった理由で優先順位が低かったからだが、とはいえ、ストリーミングを観たりゲームをするにも大画面は魅力的だし、現在住んでいるスイスの国営放送は受信料支払いが義務化されているため観られるようにしておきたい。

　そんなわけで、同時期に入社した同僚と「テレビでも買おうかね」などと会話をしていたところ、ギークな同僚にOLEDテレビを勧められたため新しい体験という意味でもOLEDで検討することとした。

　テレビの話題で言うのもなんだが、率直に言うと筆者の映像への優先度は相対的に低い。筆者はクラシック音楽のファンなのでテレビ/モニターはオペラやバレエを観るためというのが最も重要な用途だが、映像よりもオーディオの方が優先順位が高く、アンプとスピーカーに予算を集中させる方が理に適っている。だからここでは最新・最高性能の2023年モデルではなく、価格のこなれた2021/2022年モデルの中からコストパフォーマンスが高いものを選択することとする。

仕様検討・要求仕様

　筆者のテレビの買い替えサイクルは短くないため、寿命を約10年と仮定して以下のような要求仕様を設定した

サイズ：65インチ

現在店頭に並んでいる大型のOLEDテレビのサイズは48/55/65/77インチが主流だが、この中で単位面積あたりのコストパフォーマンスが高いスイートスポットが65インチである。予算と設置場所が許すのであれば65インチを御勧めしたい。

	画面面積 (cm2)	価格（参考：LG C2, 単位：CHF）	価格/面積 (CHF/cm2)
48インチ	5593.17	950	0.170
55インチ	8343.30	1199	0.144
65インチ	11664.00	1599	0.137
77インチ	16350.95	2499	0.153

パネルタイプ：OLED

上述の専ら「興味」が理由でOLEDとする。ちなみに欧州での65インチテレビの価格はLCDで€800前後～・OLEDで€1500～が相場となっている

解像度・リフレッシュレート：4K 100/120 Hz対応

ゲームでの使用なども考慮し、4K・100/120 Hzに対応していることが望ましい（個人的に優先度は高くないが）。実のところ、後述の通り最新のHDMI 2.1/2.1aが対応しているため、HDMI 2.1/2.1a対応機器を買えば4K 100/120 Hz対応と思われる

HDMI：HDMI 2.1ポート搭載

将来的なコンテンツへの対応を見越して4K 120Hz（YCbCr 4:4:4）サポートにHDMI 2.1が必須

目標価格：約€1000 / CHF1000

65インチのOLEDは€1000を超えるため、目標価格＝近いほど優れているという判断基準

ちなみに、筆者はNVIDIA Shield TV（Android TV端末）を所有しているため、スマートTV機能はあまり重視しておらず、テレビに内蔵のスマート機能がwebOS（LG）やTizen（Samsung）でも問題とならないが、人によってはAndroid TV（Sonyなど）搭載機の方が好まれるかもしれない。

機種選定

　画質・性能・価格を調査した結果LG OLED65CS9LA（CSシリーズ）を選定した（特売でCHF 1199）。日本人としてはSonyかPanasonicを選定したいところではあったのだが、CHF 300（欧州人の感覚で3～4万円ぐらい）以上という価格差は無視できなかった。

Make, Model	HDMI	Refresh Rate	Price
LG OLED65CS9LA	4 HDMI 2.1	100/120 Hz	CHF 1199
Sony XR-65A80K	4 HDMI 2.1	100/120 Hz	CHF 1499
Sony XR-65A75K	4 HDMI 2.1	100/120 Hz	CHF 1499
LG OLED65B19LA	2 HDMI 2.1, 2 HDMI 2.0	100/120 Hz	CHF 1199
LG OLED65C27LA	4 HDMI 2.1	100/120 Hz	CHF 1499
LG OLED65A29LA	4 HDMI 2.0	50/60 Hz	CHF 999

　LG CSシリーズは欧州・豪州限定の廉価版モデルということもあり、メディアへの露出が少なくレビューなども少ないものの驚くほど評価が高い。
　基本的にはLG C1（2021年モデル）とC2（2022年モデル）との中間的な仕様なのだが、一部のメディアが説明する「C1のパネル・外装とC2のプロセッサーを組み合わせた製品」というのはどうやら誤りで、パネルもC2と同じながらもLG OLED Evoパネルの特徴である輝度ブースターが削除されており、画面上の高輝度の部分以外はC2とCSとでは同じ測定値となっているようだ（参考：HiFi.de (Google Translate)・ComputerBild (Google Translate)）。それでいて廉価版（€300ほど安価）なので非常にコストパフォーマンスが高い。

　スペックを比較してみるとC2シリーズの65インチモデル＝OLED65C29LAとCSシリーズの65インチモデル＝OLED65CS9LAのスペックはほぼ同じでOLED65CS9LAは輝度が空欄となっている。上述のComputerBildの測定によると最大輝度は791 cd/m2だそうで、これはA80Kの650 cd/m2を超えC2の850 cd/m2に迫る値である。

使用感

画質

　これまでLCDテレビしか所有したことがなくLCDテレビとの比較になるため当然の結果だが、コントラスト比が高くボケた部分の無い、クッキリとした映像を楽しめる。画質の設定としては筆者は普段は「Standard」モードで使っているが、テレビドラマや映画を観る際は自動的に「FILMMAKER Mode」に切り替わる。
　ただ、Blu-ray等を持っている人はともかくストリーミングサービスのサブスクリプションが一般的な現在では画質がオーバースペックなのでは？という疑問も感じる。恐らく、2023年現在で主流のストリーミングのフォーマットは8 Mbps程度の1080p・30-60fps・8 bit Colorあたりが多いはずで、これが4K・120fps・10/12 bit Color (4:4:4)・HDRとかが普及すれば性能を発揮できるようになるだろう。
　逆にDVD画質など低画質の動画も視聴してみたが、アップスケーリングも優秀だと思う。

音質・AI Sound

　音質全般としては悪くはないが、音に拘る人にはサウンドバーやAVレシーバーの使用を御勧めしたい。例えばオーケストラのコンサートを視聴する場合、楽器の奏者が画面中央付近に見えるわけだが、音が画面下から聴こえている感じが強く違和感がある。

　LGのテレビにも他社製のテレビと同様に音質のモードを変更する機能があるが、筆者の場合はとりあえず音楽では「Standard」モード・ドラマや映画では「AI Sound」に落ち着いた。
　例えばオーケストラの演奏を「AI Sound」で聴くと楽器パート間のバランスが無茶苦茶になってしまい聴いていられないため、変に弄っていない「Standard」が良いと思うのだが、アパートなどの集合住宅や夜間に、かつドラマや映画を視聴する場合ば「AI Sound」にすることで登場人物の声が小さい音量でも聞き取りやすくなる。

スマートTV

　LGのTVはwebOSベースのスマートTV機能が付いているものがあるが、個人的にはAndroid TVの方が良い。ストリーミングアプリが充実しているとは言い難く、Netflix・Amazon Prime・YouTube・Disney+などは対応しているものの、例えば欧米でアニメを観る場合に使われるCrunchyrollなども対応していない。
　使い勝手もイマイチで、筆者はサブスクリプションの購読どころかアプリケーションのインストールすらしていないDisney+や、面白そうなチャンネルが皆無のLG TVの広告が画面中央にデカデカと表示されており、Android TVと比較しても画面が有効活用されていない。

モバイルワーク環境

　筆者は今年4月に日本の実家に一時帰国するため鋭意準備中である。その準備の内容を記録しておこうと思う。そういった性格のため、本稿は4月までの間随時更新されることになると思う。

　旅行用ガジェットについては4年ほど前に「海外旅行ノウハウ（2019年版）」として既に記事化してあり、今回も大きくは変わらない。4年間で技術革新した部分を中心にしたアップデート＋仕事環境に配慮した内容の追加となる。

USB Type-C PD対応チャージャー

　2019年の記事を投稿した当時はGaNパワー半導体は製品が出回り始めたばかりの新らしい技術で、せいぜい30～65W程度のチャージャーしか存在しなかったが、最近では4～5ポート・100W超のチャージャーが登場し、2019年の記事中での構想「1つのチャージャーでラップトップPCとスマートフォンに一括して給電する」が現実的になった。

　とはいえ、マルチポートのチャージャーで「100W」などと謳われていても全ポートで自由に割り当てできるわけではないため注意が必要である。例えば筆者も検討していたBeseus製100Wチャージャーの場合、2ポートあるUSB Type-Cの両方に給電すると45W + 20Wで計65Wでしかない（Amazon.deの説明画像）。45W側でラップトップPCは給電できるが、20W側は給電先のデバイスを選ぶことになる。

　実は今回は後述の通り45～65W + 30～Wの供給能力を必要としていたためKovol製120Wチャージャーを選択した。これはUSB Type-C 2ポート使用時で60W + 60W、USB Type-C 2ポートとUSB Type-A 2ポートの全4ポート使用時でも45W + 45WでUSB Type-Cに給電できる優れものである。
　筆者の場合は独身なのでラップトップPC + 周辺機器（後述）で45W + 30Wあればいいが、家族がいてラップトップPC x 2台の場合でも60W + 60Wもあれば給電できる可能性が高い。

ポータブルモニター

　ポータブルモニター（モバイルディスプレイ、モバイルモニター）は4年前よりも価格がこなれて・選択肢が増え・スペックも魅力的になっている。個人的には「ポータブルモニター」といってもバッテリーは不要で代わりに性能が高いものが欲しかったのだが、4年ほど前に物色した際はバッテリー内蔵型の高価な機種ばかりで辟易した記憶がある。
　あくまでも筆者個人の意見だが、モニターには外部から電源供給すればいいためバッテリーは価格が押し上げ・モニターを重くする上に、モニターとバッテリーとでは製品寿命も異なるから無用の長物でしかない（個人の使い方＝ユースケースによる）。

　最近は製品として成熟してきたせいだろう、高性能で手頃な価格の製品が、販売されている（製造元が中国の謎ブランドばかりなのが癪だが…対して日本のブランド製は価格の割に性能が低い…）。具体的には以下のような選択肢がある：

• 液晶パネルタイプ：LCD / OLED
• 液晶パネルサイズ：13インチクラス / 15-16インチクラス / 17インチクラス
• 液晶パネル解像度：1920x1080クラス / 4K (3840×2160)クラス
• 色域：Adobe RGB / sRGB / 8-bit Color / 10-bit Color
• HDR：対応 / 非対応
• リフレッシュレート：～60 Hz / 144 Hz
• タッチパネル：搭載 / 非搭載
• バッテリー：搭載 / 非搭載

　個人的に気になっているのはInnoView製「‎INVPM004」で、4K対応・HDR対応・色域Adobe RGB対応・タッチ操作対応と驚くほど充実しており、それでいて輝度も300cd/m2と実用的な水準を実現している（下手すると輝度以外はひと昔前のデスクトップ用モニターよりも性能が高い…）。タッチ操作は不要という意見もありそうだが、iOS/Android端末との接続も想定するならあって困らないと思う。USB Type-Cによりモニター接続＝HDMI Alt Modeとタッチパネルをケーブル1本で接続可能なのも魅力的だ（昔はフルサイズのHDMI + USB MiniBというものが多かった）。価格が5万円超なのが玉に瑕だが。

　ここでUSB Type-Cチャージャーの話題に戻るのだが、これらのポータブルモニターの多くは2ポートあるUSB Type-Cのうち一方でホストPCとの接続・もう一方で給電するものが多いのだが、30W以上の給電能力を要求するものが多い。つまりPCと合せると45/65W + 30Wが必要なわけで、多くのUSB Type-Cチャージャーでは非対応なのだが、上述の通り一部の100W超の給電能力のあるチャージャーでは対応しており、PCとポータブルディスプレイと（スマートフォンとタブレットと…）で個別に充電器を持ち運ぶ必要がない。

　ところで、USBチャージャーにしろポータブルモニターにしろ、未知の中華ブランドが多過ぎ判断に困る場合がる。また、一部製品のAmazon.co.jp等でも触れられている通り、一部の製品はブランド名を付け替えただけで複数ブランドから発売されていたりする。
　筆者にはブランド志向や見せびらかすような趣味は無いが、万が一の不要なトラブル（初期不良・早期の故障）を考えるとある程度マシなブランドを選んでおきたいのは当然だろう。昨今「Made in China」だからといって必ずしも粗悪品とは限らない（例えばオーディオのFiiOやS.M.S.Lなどはビルドクォリティーも良く、良くやっていると思う）が、Amazon.co.jpのレビュー等を見ているとトラブルに遭遇するケースはあるようだ。
　これは筆者の判断基準だが、筆者は各ブランドの公式Webサイトを確認するようにしている。酷い場合は公式Webサイトが無かったり、公式Webサイトがあっても年単位で放置されていたりする場合があり、そういったブランドはの製品は買わない。また、公式・Amazon.co.jp等の販売店の表示も比較確認する。もし同じ商品のスペック表記のブレが激しいようなら避けた方が無難だろう。コピー＆ペーストミスならいいが、販売者が自分が何を売っているのか理解できていない可能性がある。

親用にiPadを買った話①

2022/02/16・02/19　いろいろと加筆訂正

　なぜ①かと言うと、筆者＠欧州が両親＠日本の実家用に発注したということで、筆者自身は見てすらいないからである。4月に一時帰国予定の際に②を書く予定である。

動機

　筆者は日本の実家に帰省する度に両親宅のIT・家電環境のアップグレードに取り組んでいるのだが、先日両親がPCを処分して完全にタブレットに乗り換えたと聞いたためiPadを提供することにした。ちなみに両親が使用していたタブレットは数年前の安物Androidタブレットと10年前のiPadである。

　実は筆者自身はApple製品をほぼ使用していない。これはアンチAppleだとかいうことではなく、筆者の運用思想・予算とApple製品の思想が合致しないためであるが、しかし、それは両親用となると話は別である。

　両親には短い間隔で機種変更する（≒新機種に慣れてもらう）モチベーションは無いので理想的には10年間ほど使えるのが望ましい。筆者個人のタブレットならば5年間も使わないから高価な製品は避けるのだが、もし両親が10年間も使用するなら価格が安くなくても十分に元が取れるだろうし、むしろ10年後も通用する高性能であるべきだ。
　Apple製品はJailbreakが困難だったりとセキュリティー面で強みがあるが、これは両親にセキュアな端末を提供するというモチベーションに繋がり易く、実際に筆者が両親用に選定・提供してきた端末はApple製品の割合が大きい。両親の最初のPCはiMacだったし、母はiPodユーザーだったし、以前はiPad Gen 4 (2012)を使ってもらっていた。

背景：昨今のAndroidタブレット

　筆者個人は最近のAndroidタブレットに不満で、両親用にiPadを選択したこともそれが理由のひとつだ。

　例えば、先日PC Watchに『Android搭載タブレットおすすめ10選【2023年上期】』なる記事が掲載されていたので、これを元に「他人に勧められるか」考えてみたい。

　まず、謎ブランドの中華系タブレットは極力避けるべきで、自分が自己責任で使うというならまだしも不特定多数の他人に勧められるようなシロモノではない。
　これはセキュリティーの観点から明らかである。あるメーカーが提供するOSを使用するということは、そのメーカーはOSのカーネルモジュールからアプリケーションまで技術的には端末上のありとあらゆる情報にアクセス可能ということを意味している。これはユーザーの個人情報を盗まれる可能性がある（秘密情報を格納する領域へのアクセスを許可している）ということで、信頼性の低いメーカー製OSは使用すべきではない。
　加えて、もしメーカーが端末自体に悪質な仕掛けを施す可能性を考慮しないとしても、サポート＝セキュリティーアップデート提供を期待できるか？という疑問は考慮されるべきだ。記事中でいうとSamsungは4年間サポートとなっており、恐らくLenovo・Oppo・Xiaomiといった他の大手メーカーも3年以上のセキュリティーアップデートは提供されると思うが、実質ノーブランドの中華系メーカーにセキュリティーアップデートは期待できないだろう。
　余談だが、セキュリティーアップデートというとMicrosoftの毎月第二火曜日の「Patch Tuesday」が有名だが、GoogleもOpen Source版Android（AOSP = Android Open Source Project）にセキュリティーアップデートを毎月5日にリリースしている。このアップデートはソースコードなので、端末メーカーがアップデートを適用したAndroidをビルドして配信しなければ端末に適用されないわけだが、ここでの疑問は「その端末はメーカーが、どの程度の頻度でアップデートを配信するか？」という点で、セキュリティーアップデートというのはメーカー視点では手間ばかり多くてコストパフォーマンスが高くないため、中小企業メーカーであれば行われなくとも不思議はない。
　これらの条件を記事中の端末に当て嵌めると「FFF-TAB8」「T40 Pro」「NPad Plus」は論外で、大手メーカー＝Oppo・Xioami/Redmi・Lenovoあたりはグレーといった感じだろう。

　ところで記事中にあるNEC/Lavieブランドの端末であるが、御存知の通りNEC PCはLenovoが買収済のため、NEC Lavieブランドを冠していてもLenovo製端末のリネームである。記事中の「LAVIE Tab T10 T1075/EAS」は外観が「Lenovo Tab M10 Plus (3rd Gen)」に酷似しているが、「Lenovo Xiaoxin Pad」のリネーム品だからである。
　前項のセキュリティーリスクとは別に、地政学的なリスクとして中国の大手メーカー（Oppp・Xiaomi/Redmi・Lenovo）については、Huaweiと同様に米国政府のエンティティーリストに載る可能性も考えられるわけだが、NEC＝日本のメーカーだからと油断できないことになる。

　上述を踏まえると、潜在的なセキュリティー/地政学的リスク覚悟で中国系メジャーベンダー（Lenovo・Xiaomi・Oppo）か、あるいはSamsungぐらいしか選択肢がない（他の韓国勢・台湾勢はAndroidタブレットをラインナップしていない）が………そもそもAndroidに拘る意味があるかが疑わしい。

　一昔前（具体的にはGoogle Nexus 7が人気だった2013年頃）であれば、Apple製品は高価格・Android端末は安価で高性能といった風潮が強く、あえてAndroid端末を選ぶ理由もあったろうが、昨今の高性能Androidタブレットは価格も高く、もはやiPadに対する優位性を見出し難い。例えば記事中の「Galaxy Tab S8+」は高性能だが価格も119,220円とiPad Proに迫る価格帯である。
　逆に、Apple製品は高価格ながらも、Android端末の価格高騰で相対的に安価になっており、信頼性・性能・価格の観点からいえばiPadの中から性能や予算などに基づいて選択するのがベストと言っても過言ではない。

選定機種：iPad Air Gen 5 (2022)

　あくまでも筆者が自身の価値観に基づいて両親用に選定した（万人向けではない）結果であるが、筆者の選ぶ現行品で最高のタブレットはiPad Air Gen 5 (2022)である。

　実はiPad (2021)・iPad (2022)なども選択肢に上がっていたが、iPad (2021)は残りサポート期間・iPad (2022)はコストパフォーマンスの低さからiPad Air (2022)を選択した。

iPad Gen 9 (2021)

　非常にコストパフォーマンスが高い。2021年の端末ながら搭載しているSoCは2019年のApple A13・USB-C非対応・Apple Pencil 2非対応と、性能は十分ながら、レガシーを引き摺っている感がある。
　コストパフォーマンスが高くても、iPad (2021)を選択しなかった理由のひとつは2021年9月の登場でサポート期間を既に1年半近く消費しているからである。

iPad Gen 10 (2022) - Wired.jpレビュー記事

　先代iPad (2021)で優秀だったコストパフォーマンスが損なわれる一方で、見た目以外の進化が乏しい。2022の端末ながら搭載しているSoCは2020年のApple A14・Apple Pencil 2非対応で、最大の「進化」はUSB-C対応とイヤフォンジャック廃止、それでいて米国現地でさえ+$120ほどの値上げといった調子で、先代iPad (2021)が併売されるという現象が起こっている。

iPad Air Gen 5 (2022) - PC Watchレビュー記事

　絶対的な価格は御世辞にも優れているとは言えないが、性能が高く意外にコストパフォーマンスが高い。搭載SoCがApple M1・搭載メモリー容量もiPadの2倍＝8GBと高性能なほか、USB-C/USB3.1対応・Apple Pencil 2対応と比較的新しい規格に対応している。
　Apple M1は2020年に登場したA14のPC/タブレット用派生プロセッサーで古いが、iPad Air Gen 4がA14搭載・iPad Air Gen 5がA15ではなくM1搭載というのが興味深い。iPad Pro Gen 4 (2021)がM1搭載なので、iPad Airの位置づけが「iPadのハイエンド」から「iPad Proのローエンド」になったのかもしれない。M1は新しいプロセッサーではないが、A14比でCPU Performance CoreやGPUのコア数が2倍となっており、A14・A15よりも性能は高い（消費電力も大きいが…）。
　率直に言うと、筆者の両親が使用する分には過剰な性能なのだが、上述の通り10年間の使用を考慮し性能的な余裕を確保するならば悪くない選択肢に思える。

サポート期間についてであるが、Appleはその機種の発表から5年間以上OSのアップグレード/セキュリティーアップデートを提供しており、Wikipediaの記事によると、実際はOSアップグレードは7年間超・セキュリティーアップデートは9年間超もの長期間に渡り提供されている。「動機」の項で両親用のタブレットとして「理想的には～10年間使えるのが望ましい」と述べたが、まさに理想に近いと言える。

Androidタブレットを物色した結果Chromebookを購入した話

2022/10/29　いろいろと加筆修正

　ASUS Chromebook CZ1 (10.1-inch 1920x1200 タブレット)を入手したので使用感などを併せて書いてみたい。

背景

　筆者はアイルランド在住時（～今年8月）、在宅時はPC以外ではほぼFire HD 8 Gen 7 (2017)でWebをブラウジングしていた。しかし、古くなってきたこともあり（後述）引越の際に処分したため後継機種を探していたのだが、結論から言えばCZ1に乗り換えた。

　先に断っておくと、CZ1自体は2022年10月にわざわざ取り上げるような機種ではない。

　筆者（欧州在住）の場合は主に入手性が理由でCZ1となった（Amazon.deで€180だった）が、日本在住の方であればLenovo IdeaPad Duet (無印)の方がメジャーかもしれない。スペックの詳細は後述するとして、CZ1と同じASUS製のCM3、そしてIdeaPad Duetは多くの部分が共通しており、筆者がここで述べるCZ1に関する内容は他機種でも当て嵌まる部分は多いと思われる。
　CZ1は2021年8月頃に発表された機種だが、2021年3月発表のCM3や2020年6月発表のIdeaPad Duet、さらにはAmazon Fire HD 10の2019年モデル・2021年モデルについてもOSこそ異なるがハードウェアのスペックは共通しており、言ってみれば2019年～の$300クラスの廉価10インチタブレットとしては何ら特筆する部分の無い標準的なスペックといえる。

選定理由：サポートライフサイクル

　そもそもの話だが、Webをブラウジングする程度ならばモダンなWebブラウザーさえあれば端末のOSは関係ないかもしれない。オンライン動画や電子書籍などを閲覧するため幾つかアプリが必要になるとしてもメジャーなOSであれば困ることはないし、ハードウェアについてもゲーマーならともかくWeb・動画・電子書籍の視聴・閲覧程度であれば廉価版タブレットで事足りてしまう。つまりタブレットのような用途ではOSは機種選定の決め手となり難い。

　筆者の場合、機種選定で重要な要素となったのがサポート期間である。

　例えば、Apple iOS/iPadOS端末の場合は5年間に渡ってアップデートが提供されるが、Android端末の場合は端末ベンダーにもよるがアップデートが提供される期間は3年間程度と比較的短いケースが多いように思われる。ここでは話を単純化するため「アップデート」としたが、これはOSのメジャーアップグレード（例：Android 12→Android 13）もあれば、セキュリティーなどの問題を修正するアップデートも含まれる。

　例えばSamsungの場合、同社はサポート期間の延長を2021年・2022年にアナウンスしており、2022年2月以降に発表されたSamsung製の全Android端末のサポート期間を4年間となっている。
　ここでいう「X年間サポート」というのは「X年間はOSのメジャーアップデートを行う」上で「セキュリティーアップデートはX年間経過後もハードウェアが対応していれば続くかもしれない」という意味で、ハードウェア性能の高い上位機種の方がサポート期間が長くなる可能性があるが、それは保証されているわけではない。割り切って低価格でサポート期間の短い機種を短期間で交換していくというのも選択肢のひとつとなっている。

　Amazon Fireタブレットの場合はさらに事情が特殊である。Fireタブレットに搭載されるFire OSはAndroidがベースとなっているが、過去に単一の機種でAndroidがメジャーアップデートされたことはない（Wikipedia Fire OSの項を参照）。
　AmazonはGoogleがオープンソースで提供したAndroidを基にFireOSを開発しているからバージョンは相対的に古めである。筆者の場合で言えば2017年に購入したFire HD 8にはAndroid 5.1ベースのFire OS 5が搭載されていたが、これはGoogleが2015年に発表したAndroidで、2017年当時の最新版はAndroid 8.0だった。筆者はFire HD 8を2017～2022年の5年間ほど使用していたわけであるが、セキュリティーアップデートは2022年でも提供されていたものの、OSのメジャーアップグレードは5年間で1度も行われなかった。言い換えれば、筆者は7年も前のOS=Android 5.1を使い続けていたことになる。
　この状況は現在でも同様で、今年発売されたFire HD 8 Gen 12 (2022)に搭載されているFire OS 8は、Googleが2020年に発表したAndroid 11ベースである。そして過去の例に倣うなら、恐らくこの機種のサポートライフサイクル中にAndroidバージョンが更新されることはない。
　恐らく、このようなFire OSのサポートモデルはAmazon視点では問題ないのだろうが、ユーザー視点で問題無いか否かは別問題となる可能性もある。実際、筆者の場合も2021～22年ともなると一部のアプリが動作しなくなっていた。ちなみに2022年8月時点でのAndroid 5.1のシェアは2.2％ほどとされている。

　このように、Androidタブレットではサポート期間は問題となるが、Chrome OSは異なるライフサイクルを採用しており、長期間のサポートが期待できる。これは、恐らくGoogleのビジネス戦略的な事情もあるのだろうが、Chrome OS端末はAndroidとは異なりOSはGoogleが直接提供しているからである。

　Chrome OS端末に配信されるOSイメージは恐らく機種毎に個別であるが、端末ベンダーはハードウェアとLinuxカーネル・ドライバーなどハードウェア固有の部分を用意するが、その上で動作するChrome OSのユーザーランド部分はGoogleが用意しており、Androidとは異なりアップデートは端末ベンダーではなくGoogleが配信している。
　Chrome OSのサポート期間は端末ベンダーが設定した期間となっており、Googleのサポートページ上で確認できる。それによると筆者の入手したCZ1および同じSoCを搭載するCM3やIdeaPad Duetは2028年6月までのサポートとなっている。恐らくMT8183の製品寿命がその程度という見積なのだろう。2020年製の端末を2028年6月まで（約7-8年間）最新版のChrome OS/Chromeブラウザーを使用し続けられると考えると非常に優秀だと思う。
　より具体的に比較すると、Googleは先日の発表会でPixel Tabletを発表したが、2023年の登場予定で5年間サポートが提供される（～2028年）。もちろん、廉価Chrome OSタブレットとPixel Tabletを単純比較することはできないが、サポート期間という点に限って言えばChrome OSの優秀さが解るのではと思う。

　ちなみに、AndroidほかiOS/Windowsと比較するとChrome OSの普及率が芳しくないことから開発打切を危惧される方もおられるかと思うが、筆者は心配していない。その理由は大きく2つある。
　(1) まず、Chrome OSはコミュニティーが20年以上も開発してきたGentoo LinuxにGoogleがカスタマイズを施したLinuxにChrome Webブラウザーベースのユーザーインターフェースを載せたもので、Androidとは異なりChrome OS独自で開発されている部分は限定的である。(2) この「GoogleがGentooをカスタマイズしたLinux」であるが、通称CrOSと呼ばれており、Google Cloud PlatformでKubernetesコンテナーのホスト＝Container-Optimized OSのベースとなっている。
　言い換えれば、Chrome OS自体はメジャーと呼べないかもしれないが、OS部分はGoogle Cloud Platform（Googleのコアビジネスのひとつ）向けに、ユーザーインターフェース部分はChrome Webブラウザー（Googleのコアビジネスのひとつ）向けにGoogleが開発しているものを組み合わせたものなので、Chrome OS自体の開発コストは小さいはずで、簡単に打ち切られるとは考え難い。

ハードウェア

　ここまでは机上の話をしてきたが、ここからは実機の使用感・運用方法について考えていきたいと思う。

　まず、Android 8インチタブレットから乗り換えた視点でCZ1を使ってみて気になるのはその重量だろう。8インチタブレット（300～400g）より10インチタブレットが重いのは当たり前だが、Chrome OSタブレットの場合はAndroidタブレットとは異なりキーボードやスタイラスによる操作が想定されている＝付属品が多いから重量が増えやすい。10インチクラスのAndroidタブレットやiPad（～500g）と比べてもChrome OSタブレットはやや重く感じられ、CZ1の場合はフル装備で1 kgに達する。とはいえ、CZ1やIdeaPad Duetの場合はケースやタイプカバーをすべて取り外すとAndroidタブレットやiPadと同等まで軽量化でき、CZ1もタブレット単体では約500gとなっている。

　Chrome OSは処理やデータの大部分はクラウド（というかGoogleのWebサービス）で行い、端末上ではChrome Webブラウザーで閲覧するだけというシンクライアント的なコンセプトのはずで、それならばハードウェアのスペックはChrome OSとWebブラウザーを快適に動かせれば良い筈である。とはいえ、Chrome OS端末でも他のPC機種と同様にハードウェアが高性能な方が高速に動作することは事実で、実際、過去に登場したGoogle純正のPixelブランドChromebookはいずれもハードウェアが高スペックである。
　実際にCZ1を使ってみた感想を述べるとすれば、Webブラウジングのような低負荷な使い方では可もなく不可もなく、それなりに快適に動かせるが、高負荷時（筆者の場合はVPNに接続中など）にラグが発生し、操作中に指が引っ掛かるような感じを受けることがある。

　先日PC WatchでLenovo IdeaPad Duet 370のレビュー記事が掲載されており、記事中では、Qualcomm Snapdragon 7c搭載Chrome OS端末の高性能ぶりが示されているので、参考程度にスペックを比較してみる（以下はSnapdragon 7c Gen 1のスペックであるが、Gen 2は1割ほどクロックアップした程度である）。

		Qualcomm Snapdragon 7c (Gen 1)	MediaTek Kompanio 500
SoC	Model	SC7180	MT8183
	CPU (big)	Arm Cortex-A76 x2	Arm Cortex-A73 x4
		2.4 GHz	2.0 GHz
	CPU (LITTLE)	Arm Cortex-A55 x6	Arm Cortex-A53 x4
		2.4 GHz (?)	2.0 GHz (?)
	GPU	Adreno 618	Arm Mali-G72 MP3
		825 MHz (422.4 GFLOPS)	800 MHz (86.2 GFLOPS)
RAM		LPDDR4X x32	LPDDR4X x32
		2133 MHz (17.1 GB/s)	2133 MHz (17.1 GB/s)

　Cortex-A76のシングルスレッド性能はCortex-A73の約1.5倍程度なので、20％高い動作周波数では+80％程度高速になる。また、ハードウェアの高速化に加えLinux KernelやChrome Webブラウザーの高性能化が含まれている可能性もあるので、PC Watchの記事中にあるように2倍高速というのは妥当な結果に思える。

　bigコアの数がMT8183は4コア・Snapdragon 7cは2コアなので、理屈の上ではMT8183の方が高速になるワークロードもありそうだが…タブレット端末ではフォアグラウンド処理に特化した使い方となるのでMT8183の方が高速になるケースは稀だろう。
　差が大きいのはCPUよりもGPUで、Snapdragon 7cはMT8183の約5倍も高速だが、メモリー帯域が狭いのが気になる（スマートフォンなどでもLPDDR4Xメモリーは使用されるがx64コンフィグで約2倍の帯域であることが多い）。ホーム画面操作やWebページのブラウジング程度であればGPU性能が効いてくるかもしれないが、ゲーム向きとは言えず、ChromebookでゲームをしたいならSnapdragon 8cかIntel Core/AMD Ryzen搭載機種を選んだ方が無難だろう。

　以上の通り、MT8183搭載端末は必要最低限の性能といった感じであるが、それら性能面での不満はSnapdragon 7c等の高性能なSoC搭載端末を選択すれば改善されそうである。ただし、前者が$300クラスに対し後者は$500～となるため、その性能差に$200～の価値を見出せるかどうかはユーザー個人次第ではないかと思う。ちなみに筆者なら$500出すならiPadを買うが。

ソフトウェア：Androidタブレットとの使用感の違い

　Androidタブレットから乗り換えることを考えると、気になるのは使用感の違いかもしれない。結論から言えば、Chrome OS端末はWeb・動画・電子書籍の視聴・閲覧専用のシンクライアント的な運用が想定された端末なので、Androidタブレットで可能な別の用途を想定しているのであれば適していない可能性が高い。

　まず、Chrome OSとAndroidの見かけの違いから見ていく。
　例えば設定を変更する場合には設定アプリを起動するわけだが、Chrome OSのUIはほぼChrome Webブラウザーだから、Chrome Webブラウザーとほぼ同様の設定変更画面で行うことになる（大雑把に言えば、Chrome Webブラウザーの設定chrome://settings/にOS用の設定項目を追加した感じ）。ところが、Androidアプリに関する設定だとAndroidの設定画面にリダイレクトされることになる。
　つまりAndroidだとOSの設定やアプリの管理は統合されており、例えばWebブラウザーなどのアプリ固有の設定はアプリ内で行っていたわけだが、Chrome OS (+Android環境)だとOS・Webブラウザーの設定が共通化されておりWebブラウザー以外（Androidアプリ）の設定画面が別に存在することになるので、整頓されていない感触を受ける。
　Chrome OSのOSの設定は設定アプリから、Chrome Webブラウザーの設定はPC版と同じくWebブラウザーの設定メニューから設定を行う（個別に存在する。見た目が酷似しているため当初は共通化されていると誤解していた）。両者の設定画面の外観や使用感は酷似するが、Androidアプリの設定画面はChrome OSの設定画面からリダイレクトされる上にAndroidのままなので使用感が少し異なる。やや整頓されていない感触を受ける（もっとも、たかが設定画面なので頻繁に使用することはないと思うが…）。

　AndroidタブレットではなくChrome OSを使う利点のひとつはフル機能のChrome Webブラウザーが使用可能な点で、Webブラウジング時にもPC用Webサイトが表示されるほか、PC版Chrome Webブラウザーでしか存在しない設定項目があったり、Chrome機能拡張が使用できたりする。

　Chrome OSはAndroidやiOSと比較して用途が極めて限定的に思える。
　例えばAndroid端末をGPSカーナビゲーション代わりに使うことが普通なように、その用途はWeb・動画・電子書籍の視聴・閲覧に限定されないが、Chrome OSで同様のことはできない可能性が高く、どちらかと言うと電子書籍端末（例：Kindle）の高性能版のような印象を受ける。CZ1のようにGPSがそもそも搭載されていない場合もあるし、そもそもChrome OSにおいて標準のアプリケーション（Chrome Webブラウザーと一部の手書きメモアプリ）以外＝Androidアプリは、あくまで補助的なもので、正常に動作しないことも多い。
　より具体的には、Google Keep・YouTube・KindleなどのWeb・動画・電子書籍の視聴・閲覧アプリは正常に動作する。しかしWeb・動画・電子書籍の視聴・閲覧から離れた用途になればなるほど動作が怪しくなる印象であるが、いずれにせよ、Androidアプリについてはインストールできても正常に使用できるとは限らないため、ユーザー側で実際に試す必要がありそうだ。

　もっとも、Web・動画・電子書籍の視聴・閲覧についても、YouTubeやKindleのようにインターネット上のコンテンツを閲覧する場合は運用しやすいが、上述の通り、シンクライアント的な使い方が想定されているせいだろう、PCに保存したePubなどを閲覧する場合は正常に使用可能だが手間がかかるので注意が必要である。
　多くのタブレットタイプのChrome OS端末ではSDカードスロットが非搭載となっているが、そもそも、Chrome OSはUSB OTGモードに対応しておらずPCからUSBデバイスとして接続すてデータを転送することはできない。SoCはAndroidタブレット由来だったりするのでハードウェアの問題ではなくソフトウェア側の問題と思われる。
　筆者の場合、上述の通りFire HD 8の用途のひとつに電子書籍リーダーも含まれていたのだが、これをChrome OS端末で実現してPCに保存されているePub形式やCBZ形式の電子書籍類を転送するには、(1) Google Driveを経由するか、(2) 一時的にUSBメモリースティックにデータを移してPC→USBメモリースティック・USBメモリースティック→Chrome OSタブレットといったように二段階でデータを転送する必要がある。

　筆者がFire HD 8を使用していた時は、MicroSDカードに閲覧したいデータ（主にePubなど）を保存しておき、普段はタブレット内に常時搭載しておいて、必要に応じて、取り外し→PCでデータを追加・削除したり編集していた。PCでの編集作業は多少の手間はかかるが、編集するにもMicroSDカードを直接編集するのでデータの追加・削除は高速だし、数カ月に1回の作業だったため苦ではなかった。
　しかしChrome OSデバイスでは、上述のようにPC→USBメモリースティック・USBメモリースティック→Chrome OSタブレットといったように二段階でデータを転送するとなると手間は単純に2倍になる。
　この問題（？）についての対応策は現時点でも思索中で解決できていないのであるが、MicroSDカードの代わりにUSBメモリーを常時接続する運用にできないかと考えている。USB Type-AであればUSBコネクターサイズのメモリースティックが存在したため邪魔にならなかったのだが（例：Buffalo RUF3シリーズ）、USB Type-Cではコネクターが小さいせいだろうが、筆者の知る限りではUSBコネクターサイズのメモリースティックは存在しない。かと言って親指サイズのUSBメモリースティックをタブレットに常時接続というのも邪魔なので、こういった製品を物色中である。

追記：筆者個人の感想としては、やはりePUB等のローカルのデータを使用する場合（Googleの想定するもの≒シンクライアント的な使い方とは異なる使い方をする場合）、USB接続のメモリーの常時接続を前提に運用した方が快適なので、上述の通りUSB Type-Cコネクターサイズで邪魔にならないUSBメモリーの使用を検討すべきと思う。しかし問題は、メジャーブランドはそのような製品を展開していない点で、筆者の場合はAliExpressから購入した。

おまけ

　Web・動画・電子書籍の視聴・閲覧がメインのChrome OSで唯一クリエイティブに使えるのが、（手書きを含む）メモやドローイングであるが、CZ1標準のスタイラスと液晶では、画面に傷がつかないか心配である。
　CZ1とIdeaPad Duetの画面サイズやフロントカメラの配置は完全に同一で、液晶プロテクターは同じものが使用できる。筆者の場合はIdeaPad Duet用の強化ガラスを入手したがきれいにフィットした。

ワイヤレス ブリッジの導入（その 2）

ワイヤレス ブリッジの導入（その 1）

概要

　前回の記事ではワイヤレス ブリッジの概要と導入する動機および導入方法の概要は説明したが、本稿ではより詳細な導入方法の説明しようと思う。

　当初の予定では数種類のデバイスにOpenWrtをインストールして計測しようと思っていたのだが、接続方法から説明した方が良いと思った（後述）のと、個人的にワイヤレス ブリッジ用にルーターを入手したので、その製品を具体例にスペックの説明なども併せて行いたいと思う。

　実は、前回の記事で説明した通り今回の記事は筆者の転居に際して実際に宅内ネットワークを設定しつつ執筆しているのだが、転居先でアパートの共用Wi-Fiインターネットアクセスに接続したところ、家庭でのWi-Fi接続で一般的なSSID + Passwordによる保護ではなく、ホテルなどで見かけるWebポータル画面からユーザー名 + パスワードでログインして接続する方式だった。

接続方法 1：SSID + Passwordで認証する場合

　家庭用のWi-Fi接続などでよくあるのがSSID + Passwordのペアで認証する場合である。PCやスマートフォンを直接接続するのであればここで説明するまでも無いが、OpenWrtなどのルーターの場合は、通常Wireless LAN用に設定されているインターフェースのひとつをWireless WAN用に設定することによって接続する。

　OpenWrtのワイヤレス ブリッジは、Network > Wirelessからワイヤレス接続インターフェースのひとつ（例：radio0）からScanをクリックして接続先のSSIDを探し、clientモードにしてSSID + Passwordのペアで認証して接続した上でwanあるいはwwan（Wireless WAN）ゾーンに割り当てればいい。{wan,wwan}⇔{lan,wlan}のフォワーディングは初期設定されているから、インターフェースを設定してwan/wwanゾーンに割り当てるだけで設定は完了する。このとき、もしWPA2-PSKなどの認証を設定されているならパスワードも設定できる。

接続方法 2：Captive Portalで認証する場合

　ある程度大きなホテルなどでWi-Fiの認証を行う場合、SSID + Passwordのペアではなく、ポータル画面でのUser ID + Passwordという場合もある。この場合、PCやスマートフォンであればWebブラウザーにリダイレクトされるが、ルーターは標準でポータル画面を処理できないため接続方法 1の手順では認証できない。

　OpenWrtの場合はTravelMateのようなパッケージを利用する必要がある。TravelMateはWebユーザーインターフェースもあり、Web管理アプリからワイヤレス接続インターフェースを有効化してwanに設定し・Captive Portal検出を有効化できる。Captive Portalを検出した場合、接続元のPCやスマートフォンなどにポータル画面を転送してPCやスマートフォンのWebブラウザーから認証できる。
　TravelMateを利用しなくても、Web管理アプリからNetwork > DHCP and DNSのRebind Protectionの無効化で接続できる場合もあるようだ（未確認）。

　TravelMateを利用する場合、接続中に接続方法 1相当の操作を行うため、もし接続方法 1が既に設定されている場合は1つの無線インターフェースが重複して設定されてしまうため接続できない可能性があるので削除してからTravelMateで再度設定した方が良い。
　TravelMateのWebユーザーインターフェースを利用する場合はOpenWrtにログインしてServices > TravelMateから設定する（その中にCaptive Portal Detectionという項目も含まれている）が、Wireless Stationタブから設定方法 1相当の設定を行うことになる。このWireless Stationの設定が完了した状態でPCやスマートフォンのWebブラウザーからWebページ（例：Google.com）にアクセスしようとするとCaptive Portal画面にリダイレクトされる。

余談：Xiaomi AX3600

　今回の引越にあたり、筆者は宅内用ルーターとしてXiaomi AX3600を購入・OpenWrtに入れ替えた。Xiaomi AX3600は2020年に登場した当時のハイエンドルーターのひとつであるが、型落のせいか最新のWi-Fi規格への対応が中途半端なせいかAmazon.deで安売されていたので衝動買いした。

　AX3600に搭載されているのはQualcomm IPQ807x "Hawkeye 2"ファミリーのWiSoC IPQ8071Aで、2022年現在の家庭用ハイエンドルーターに搭載されているIPQ8074/8078は改良版にあたる。
　IPQ8074/8078および下位のIPQ6000 "Cypress"ファミリーは共に対応するWi-Fi規格が新しいため、それら最新WiSoCと比較すると2020年のハイエンドIPQ8071/8072/8076などはWi-Fiスペック的に見劣りする（※5 GHz帯で160 MHz接続数が限定される。IPQ8074/8078ではIEEE802.11ax 4x4 160MHzで接続できるが、IPQ8071/8072/8076はIEEE802.11ax 4x4 80MHzまたはIEEE802.11ax 2x2 160MHzとなり、理論上の転送帯域が1/2になる）が、内部的にはIPQ8074/8078とWi-Fi以外はほぼ同じ・IPQ6000より2倍以上高速である。

　もっとも、IPQ8071/8072/8076搭載ルーターの多くは有線1000BASE-Tと無線IEEE802.11axのみの搭載でオーバースペック感は否めず、その意味ではIPQ6000ファミリーの方がバランスが取れているかもしれない。
　IPQ807x "Hawkeye 2"ファミリーに搭載されているNetwork Subsystem（NSS）はNSS全体で37.5 Mpps・ポートあたり10 Mppsという処理性能で明らかに10GbEを処理するために作られており（参考までに、10 Gbpsの標準1500 Byteフレームでのワイヤーレートが822,368 ppsである）、実際に上位モデルは10GbE MAC 2基をWiSoCに統合している。
　しかし、AX3600などは1GbE x 5 + 5 GHz帯802.11ax 2402 Mbps + 2.4 GHz帯 802.11ax 573.5 Mbpsというスペックで、単純に全部足しても4975.5 MbpsでNSSの処理性能が余る。もちろん、企業などで使われるルーター/APのように複雑なフィルタリングルールなどを設定すればNSSの性能は劣化するし、さらにNSSで処理できないような処理（最も端的な例はOpenVPNだろうか）はCortex-A53上のLinuxで処理されるのだが…家庭用ルーターで行われるようなフォワーディングやブリッジングの多くはNSSで完結してしまうような処理が多くCortex-A53 4 coreは負荷0 %・NSSもオーバースペックなんてことも少なくない。

　寡聞にしてIPQ807x搭載の企業向け高性能ルーター/APなどはMikrotik RB3011シリーズぐらいしか知らないのだが、筆者の知る限りで最もIPQ807xの性能を活かせそうなハードウェア構成なのがQNAP QHora-301Wで、10GBASE-T 2ポートを備えOpenWrtベースのQRouter OSで構成されている。
　上述の通りIPQ807xは10GbE MAC 2基を搭載しているため、これらの10GBASE-T 2ポートはPCIe接続ではなくNSSに接続されており10GBASE-T⇔10GBASE-T間のルーティングや10GBASE-T⇔802.11ax間のブリッジングをNSSで処理可能で、IPQ807x本来の性能が発揮できるはずである…のだが、残念ながらネットでレビューなどを検索してみても10GbEに注目したベンチマークを行っているレビュー記事は皆無である。

ワイヤレス ブリッジの導入（その 1）

はじめに ～ 動機・前提

　前回の投稿から随分と間が空いてしまった。
　実はプライベートで転職活動が佳境に入っており、連日の面接→就労許可取得・引越準備といったイベントが怒涛の如く押し寄せ、ブログ更新どころではなかった。それはそれで、見方を変えれば日本在住では得難い体験ではあるのだが…あまり詳細を説明すると個人情報（勤務先・住所）に関するネタになりかねないため割愛。筆者は現在アイルランド在住だが、今回の転職で国境を跨ぐため、現地のIT事情なども今後ネタにしていきたい。

　ところで、海の東西を問わず内定を受け取ってから新たな勤務先に転職する移行期間は1カ月＋数日間程度しか猶予がない。筆者の場合5週間＝35日間が設定されたが、有給消化を認められず引越先の物件を内覧する時間すら無かったため、長期契約のアパートを探すまでの仮の住居として新しい職場（駅前）近くにserviced apartment（あらかじめ家具等が備付られており、清掃などのサービスが含まれる、ホテルとアパートの中間的な物件）を契約した。

　今回の御題はそんな引越・旅行にまつわる宅内の有線LANに関する話題である。
　筆者の場合は短期間入居するアパートで無線LANによるインターネットアクセスが標準で提供されているのだが、旅行や出張でホテルやウィークリーマンションに滞在する場合にも同じような状況は発生する可能性がある。
　筆者の自宅にはデスクトップPCやRaspberry Pi（RPi）など多数の有線LAN接続デバイスが存在するため無線LANインターネットアクセスを宅内で有線LANに変換するワイヤレス ブリッジがあれば便利である。

選択肢

　ワイヤレス ブリッジはルーターの一種である、というか「無線ブロードバンドルーター」として販売されているハードウェアで実現可能な機能あるいはモードの一種である。
　一般的な無線ブロードバンドルーターでは有線接続 x 2と無線接続があり、有線接続 1 ポートをWAN・残りの有線接続と無線接続をLANにそれぞれ割り当て、WAN⇔LAN間やLAN⇔LAN間のフォーワーディング処理を行う装置である。
　これに対し、ワイヤレス ブリッジは無線接続1チャンネルをWAN・残りの無線接続や有線接続をLANに割り当て、WAN⇔LAN間やLAN⇔LAN間のフォーワーディング処理を行う装置である。

ワイヤレス ブリッジの実現方法は幾つか存在するが、ここでは以下のような選択肢を検討したい：

1. ワイヤレス ブリッジ機能搭載ルーターを使用する
2. 既存のルーターを改造してワイヤレス ブリッジ機能を有効化する
3. 開発ボードを転用する

1. ワイヤレス ブリッジ機能搭載ルーターを使用する

　LinksysやASUSなどの製品で標準ファームウェアでサポートしている製品もあるほか、GL.iNetのトラベルルーター製品ように、最初からホテルなどでの使用を想定してアピールポイントとしている製品もある。

　この選択肢の利点は導入が簡単な点で、逆に欠点は (1) GL.iNetのようなケース以外では対応している製品が不明瞭な点と (2) 他の選択肢と比べコストが割高になるケースが多い点だろう。
　もし、偶然にもLinksysやASUSなどのワイヤレス ブリッジ機能搭載ルーターを既に所有している場合は単に転用すれば済む話であるが、そうでない場合は購入すると最低でも$50～$100前後の出費が見込まれる。また、2022年8月現在の$50～$100前後の安価なルーターだとMediaTek MT7621A搭載製品など相対的に低性能な製品が多く、結果的に割高になってしまう。GL.iNet製品でも、～$75の製品はMT7621Aか同等クラスの製品が中心で、最近登場したGL-AXT1800だとQualcomm IPQ6000搭載でハードウェアは最新だが$130してしまう。

2. 既存のルーターを改造してワイヤレス ブリッジ機能を有効化する

　日本では電波法・技適の都合で違法となる可能性があるが、OpenWrtのようなカスタムルーターOSではワイヤレス ブリッジが提供されている製品も存在する。実のところ、上述のGL.iNet製品を含め高機能を謳う中国製ルーター製品の一部はOpenWrtを搭載し同OSが提供する多様な機能を利用しているものが少なくない。日本国外での使用を想定する場合はこの選択肢も考慮に入ってくる。

　この選択肢の利点は、もしユーザーが既に所有しているルーターがOpenWrtに対応している場合にそのルーターを使用できる点であるが、欠点は (1) OpenWrtが対応する市販ルーター製品は限定的で一般に一世代以上古いデバイスが多いこと（OpenWrt Table of Hardware 802.11ac Support、Table of Hardware 802.11ax Support）と (2) 導入までのユーザーの労力がそれなりに必要となることだろう。

　欠点 (1) についてだが、例えばAliExpressなどで安価に入手できる中国Xiaomi製ルーターを例にとると最新のRedmi AX6000（MediaTek MT7986A, Arm Cortex-A53 quad-core @ 2.0 GHz, 512 MB RAM）は2022年8月現在でOpenWrtに対応しておらず、WiFi 6（IEEE802.11ax）対応・OpenWrt対応で最新のSoCを搭載しているルーターは全メーカーを見渡してもXiaomi製Redmi AX6S/AX3200ぐらいのものである。

　欠点 (2) についてだが、OpenWrtのインストールが簡単でない場合がある。例えばRedmi AX6Sの場合OpenWrtのRedmi AX6S/AX3200のページを参照頂ければ解る通りTFTPを有効化したりPythonスクリプトを実行してアンロックしたりする必要がある。

3. 開発ボードを転用する

　理屈の上ではRaspberry Pi（RPi）などの開発ボードに無線LANアダプターを接続・OSを設定して自作することも可能である。
　この選択肢の利点は、もし手持ちでRaspberry Piなどの余剰機があれば導入できる点であるが、欠点は (1) 導入までのユーザーの労力が大きい可能性があること (2) 市販のルーターと比較して無線機能が低性能だったり不安定になり易い点である。

　欠点 (1) については、RPiやFriendlyELEC製品のように開発ボード用にOpenWrtが提供されていれば少ない労力で実現できる。Raspberry Pi OSなどの一般的なLinuxでもユーザーが各種設定することでも実現できるが、本稿では引越先・旅行先を想定しているからOpenWrtの利用を想定すべきだろう（外出先でDIYや、それにまつわるトラブルシューティングをやりたい人など稀だろう）。

　欠点 (2) についてであるが、昨今のRPiをはじめ、Wi-Fiモジュールが標準で搭載されている場合は対応OSでドライバーがサポートされていたりして比較的信頼性が高い場合が多いが、USB接続のWi-Fiアダプターの場合は、そもそもLinuxでの使用やルーターでの使用が想定されていなかったりして、そもそも使用できない場合や、使用できても不安定な場合もあるようだ。

　さらに言えば、開発ボードというとRPiのようにセットトップボックス用やタブレット用のアプリケーションプロセッサーを流用したものが多く、CPU性能は優れる一方でWiSoCなどの専用プロセッサーと比較すると、どうしても性能がCPUに偏重でネットワーク機能が貧弱であることが少なくない。
　RPiもRPi 4からはPCIe接続の1000BASE-Tが搭載されるようになったがRPi3+まではUSB2.0接続のSMSC製コントローラーだったし、WiSoCとは違い、QoSアクセラレーター・NATアクセラレーター・暗号エンジン・FastPathなど各種アクセラレーション機能も搭載されていない。

　以下は具体例としてRaspberry Pi 3 Model B+（2016/18年）とRedmi AX3200（2022年の$50～$100ルーター）・FtitzBox 4040（2016年の$50～$100ルーター。筆者が現在使用中のもの）のスペックを比較したものである。これらは登場時期も異なるため単純比較はできないが、用途の違いによる搭載されている機能の傾向を見ることはできる。
　RPi3はCPUコアやメモリー容量などは潤沢に搭載されており汎用的な演算に優れていることが伺えるが、AX6S/AX3200のMT7622BやFritzBox 4040のIPQ4018の方がネットワーク関連の機能が充実している。

		Raspberry Pi 3 Model B+	Redmi AX6S/AX3200	FritzBox 4040
SoC	Model	Broadcom BCM2837B0	MediaTek MT7622B	Qualcomm IPQ4018
	CPU Core	Cortex-A53	Cortex-A53	Cortex-A7
	Threads	4C/4T	2C/2T	4C/4T
	CPU freq.	1400 MHz	1350 MHz	638 MHz
	NW Accel	N/A	Hardware NAT, Hardware QoS, Crypto Engine, Wi-Fi Warp	Hardware NAT, Crypto Engine, Wi-Fi CPU
	Integrated MAC	N/A	1000Mbps x 2	1000Mbps x 2
RAM		LPDDR2 1GB x32 config	DDR3L 256 MB x16 config	DDR3L 256 MB x16 config
Wi-Fi	2.4 GHz controller	Cypress CYW43455 (SDIOv3)	MT7622B integrated	IPQ4018 integrated
	2.4 GHz bandwidth	150 Mbps (802.11n, 1x1)	800 Mbps (802.11n QAM, 4x4:4 MIMO)	400 Mbps (802.11n, 2x2 MIMO)
	5.0 GHz controller	Cypress CYW43455 (SDIOv3)	MT7975AN (PCIe 2.0 x1)	IPQ4018 integrated
	5.0 GHz bandwidth	433.3 Mbps (802.11ac, 1x1)	2400 Mbps (802.11ax, 4x4:4 MIMO)	866.6 Mbps (802.11ac, 2x2 MIMO)
Wired		1000BASE-T via SMSC LAN9515, up-to 300 Mbps	1000BASE-T (WAN) 1000BASE-T (LAN, with 5 port switch)	1000BASE-T (WAN) 1000BASE-T (LAN, with 5 port switch)

これらの違いの結果、ワイヤレスブリッジという用途に限って言えば選択肢 1. （例：AX3200）や選択肢 2.（例：FritzBox 4040でOpenWrtを利用可能）のような専用のネットワーク機器を使用する方が性能は高くなる。もっとも、本稿で想定しているアパートやホテルの共用インターネットアクセスではRPi3程度の性能でも十分かもしれないし、逆を言えば普通のブリッジ用途ではRPi3のCPUやメモリーのリソースは余っている可能性が高く、余剰なリソースでDocker等を使ってアプリケーションを動作させることもできそうだ。

Black Friday 2021 (2) Samsung 970 EVO Plus

　今年は珍しくBlack Fridayにいろいろと買い物をしたので、買った物についてメモがてら書いてみる。

[12/04 加筆修正] SLCキャッシュ周りの挙動に関する部分を加筆修正

Samsung 970 EVO Plus 1 TB

　言わずと知れたSamsung製M.2 NVMe接続SSDの旧世代品。安価（約€90≒¥11500）だったのと、とある記事（後述）で興味を持ったため購入。
　実は、来年初頭にも引越して新しくサーバーの構築を計画しており引越の邪魔にならない程度で部品調達を進めている。高信頼性のSSDとして既にSamsung 970 PROを確保済なのだが、それと組み合わせる比較的安価で高速なSSDとして970 EVO Plusを入手した。

　SamsungはSSD製品を主にPRO/EVOの2クラスで展開してきているが、960 PRO・970 PROまではMLC 3D NANDを採用していたところ、980 PROではTLC 3D NANDを採用しており、フラッシュメモリーの信頼性は低下している（1TB版で1200 TBW→600 TBW）。このことに関するSamsungによる説明をGuru 3Dが紹介しているのだが、これが実に興味深い。
　詳細はリンク先の記事を参照いただくとして、要は「5年間で600 TBW以上を書き込むユーザーは全体の0.3％以下・99％のユーザーは5年間で156 TBWかそれ以下しか書き込まない」ということで、言い換えれば99％の人が600 TBWを使い切るには19年間を要するため、970 PROの1200 TBWはおろか980 PROの600 TBWですら明らかなオーバースペックということである。
　代わりに、970 EVO/970 EVO Plusで先行して導入されたSLCキャッシュ技術＝Intelligent TurboWriteが導入され、970 PRO以上のRead/Write性能を達成している。

　筆者個人としては、信頼性を重視して確保した970 PROに満足しているが、上述のSamsungの説明を信じるなら980 PROと同等の信頼性を安価な970 EVO Plusでも実現できる可能性がある（実際、970 EVO Plus旧モデルでは耐久性は非常に高かったらしい）。加えて上述の通り高速/高信頼性という棲み分けが必要と判断したのが970 EVO Plusを入手した動機である。
　もっとも、970 EVO Plusの信頼性を判断するにはNANDフラッシュやSLCキャッシュ技術以外も検証する必要はあるのだが。

　…ここまでであれば、よくある「そういう話」なのだが…実は最新970 EVO Plus（v.3）は980 PROに近い仕様に変更されていたことを購入後に知ったので御紹介したい。

• 970 PROと同じPhoenixから980 PROと同じElpisに変更
  • Tom's Hardwareによると、これはSSDコントローラー不足による措置
  • ランダムR/W性能だけを見れば改良といえる。「選別落ち品ではないか？」という批判があるようだが型番が同じため根拠が無い
• 対応インターフェースはPCIe 3.0のまま
• NANDフラッシュは96層から128層に変更
  • Samsung 3D NAND Version 5=96層から3D NAND Version 6=128層への変更で、一概に改良とも改悪とも言えない
  • 型番をある読む限りでは品質に関わる部分は旧モデル・新モデルで共通
• SLCキャッシュ枯渇後の速度低下が著しい
  • SLCキャッシュ枯渇による性能劣化の自体は980 PROや980でも存在する問題である。もっとも、980 PROについてはPCIe Gen 4.0対応なせいか970 EVO Plus v.3よりは高速であるが
• 同じ製品名・JANコードのまま仕様が変更された

　コントローラーとIntelligent TurboWrite=SLCキャッシュの仕様の変更によりSLCキャッシュ枯渇までは新モデルが高速、SLCキャッシュ枯渇は旧モデルが早く（旧モデル：42 GB、新モデル：114 GB）、SLCキャッシュ枯渇後は旧モデルの方が高速ということになるそうだ（下表参照。数値はTom's Hardwareから引用）。TurboWriteが有効な場合は下記よりも高速な可能性があり、公式のスペック表では3300 MB/sとなっている。

	with TurboWrite	> 42 GB	> 114 GB
970 EVO Plus (v.2)	1750 MB/s	1500 MB/s (without TW)
970 EVO Plus (v.3)	2500 MB/s		800 MB/s (without TW)
980 PRO	5000 MB/s		2000 MB/s (without TW)

[12/04 加筆修正部分 ここから]

　某巨大掲示板などでは、このSLCキャッシュ枯渇後の「1500 MB/s」と「800 MB/s」という数字にのみ着目して改悪だと大騒ぎする人が多いのであるが…実際はそれほど単純な話では無く、筆者の個人的な見解としてはSLCキャッシュ枯渇前の高速化はメリットがあるしSLCキャッシュ枯渇についても運用対処でどうにかなる範疇だと思っている。

　この問題をややこしくしているのはSLCキャッシュの挙動が単純ではないからだ。例えばSLCキャッシュの容量「114 GB」という部分を考えてみると、日常的に114 GBもの巨大なサイズを読み書きする人は限定的で、多くの人々にとってはSLCキャッシュの枯渇は心配する必要の無いもののように思える。
　その一方で、SLCキャッシュを114 GB（動的確保部分108 GB）も確保できる条件は限定されるため本当に気にする必要が無いとは言い切れない場合がある。SLC 108 GB=TLC換算 324 GBなので、そもそも空き容量が十分でないと確保できないことになる。 使用容量が多い場合はSLCキャッシュ容量も減るから実際にはSLCキャッシュが114 GBに達する前に枯渇してしまう。

　実は、こういった内容を詳細に検証したサイト（参考1: 970 EVO Plus・参考2: 980）が存在し、それを纏めると以下の表のようになる。

SLC Cache	Utilized capacity	970 EVO Plus (v.2) 1000 GB			970 EVO Plus (v.3) 1000 GB
		Default	Intelligent	Total	Default	Intelligent	Total
Capacity	0 - 50%	6 GB	36 GB	42 GB	6 GB	108 GB	114 GB
	50 - 80 %		36 GB	42 GB		61 GB	67 GB
	>80 %		0 GB	6 GB		0 GB	6 GB

　そもそものSLCキャッシュ枯渇後に970 EVO Plus v.3で遅くなる理由であるが、どうやら970 EVO Plus v.2のIntelligent TurboWrite 1.0と970 EVO Plus v.3のIntelligent TurboWrite 2.0とで挙動が変わったためということのようだ。
　そもそものTurboWrite・Intelligent TurboWrite 1.0ではSLCキャッシュ枯渇後はTLC NANDに直接書き込まれ、SLCキャッシュの内容は書き込み完了後のアイドル時にTLC NANDに展開されるが、Intelligent TurboWrite 2.0ではSLCキャッシュ枯渇後はTLC NANDへの直接書き込みとSLCキャッシュ内容のTLC NANDへの展開が並行して発生するらしい。そのためSLCキャッシュ枯渇直後は速度が大幅に低下するが（2500 MB/s→800 MB/s）、SLCキャッシュのフラッシュ後は速度が一部回復する（800 MB/s→1000 MB/s）らしい。ホストからの書込とSLCキャッシュのTLC NANDへの書込が並列して動作するわけだから書き込み速度が大幅に低下するのも納得できる。

　このアルゴリズムの変更については変更内容も変更理由もSamsungは公式に発表していないため不明だが、ある程度の推測は可能だろう。というのも、SLCキャッシュが枯渇した場合書込とキャッシュのフラッシュとを並行して行わなければエラーとなる可能性が高いからである。例えば1 TB（1000 GB）のSSDのうち500 GBを消費していて180 GB（※新モデルでの最大SLCキャッシュ容量を上回る容量）の書き込みをする場合を考えてみる。
　この場合、旧バージョンののSLCキャッシュ容量と旧バージョンのキャッシュ制御方式の組み合わせであれば、36 GB（TLC換算 108 GB）のSLCキャッシュが確保され500 GB + 108 GB + 180 GB = 788 GBとなり、速度は落ちるかもしれないが問題無く書き込むことができる。
　ところが、新バージョンのSLCキャッシュ容量と旧バージョンのキャッシュ制御方式の組み合わせであれば108 GB（TLC換算324 GB）がSLCキャッシュが確保され500 GB + 324 GB + 180 GB = 1004 GBとなり4 GB溢れてしまう（→書き込みエラー）。
　このため、新バージョンのように大容量のSLCキャッシュを確保する場合は書き込みエラーを避けるためにもTLC NANDへの直接書込とSLCキャッシュの展開を並列して行う必要がある。また、SLCキャッシュのTLC NAND領域への展開もそれなりに遅延が発生することも考慮する必要がある。

[12/04 加筆修正部分 ここまで]

　某巨大掲示板等ではコスト削減のための改悪だという批判があるのだが、今回はコントローラーを新しい物への変更とそれに伴う挙動の変更で、個人的にはコスト削減で改悪されたとは言えないように思う。
　JANコードが同じだったことは混乱を招いたと思われるが、ただし「114 GB以上の書き込み」等の変更内容はワークステーション/エンタープライズならばともかく970 EVO Plusの想定ユーザー＝一般消費者からすれば非日常的な条件のため実用上の問題がないという判断だったのかもしれない。

Black Friday 2021 (1) - Gemini Lake Mini PC

　今年は珍しくBlack Fridayにいろいろと買い物をしたので、買った物についてメモがてら書いてみる。

MeLE Quieter2

　中国MeLE製ファンレスMini PC Quieter2が安価（€199）だったので衝動買いした。2017/18年登場のIntel "Gemini Lake"搭載PCだから2021年末にレビューするような代物ではないけれども。

Pros	Cons
Windows 10 Proプリインストール Windows 11アップグレード可能 安価	電力供給だけのUSB C（PD非対応/USBとして使えない） USB C HDMI/DP Alt Mode非サポート

　Intel E-Core系コア（旧Atom系コア）ベースの中華Mini PC製品としては、以前Celeron J1900 "Bay Trail"ベースのTronsmart Ara BJ19を所有していたのだが、良くも悪くも廉価版/省電力/省スペースPCという印象が強い製品だった。WebブラウジングやOffice程度の日常使いには足りる性能ではあったが…全方位で同世代のP-Core系コア（旧Core系コア）ベースのPCに劣った劣化版、悪い言い方をすれば「安かろう悪かろう」という印象が強かった。

　例えばスマートフォン/タブレットを想像してみると、絶対性能という点ではPCに劣るにしても、必ずしもPCの劣化版という扱いではない。
　それは例えばYouTubeなどの動画を再生する場合にはむしろ最新のスマートフォンは旧世代のPCよりスムーズにHD動画を再生できたりすることからも解る。これは、アプリケーションプロセッサーに搭載される動画や画像のエンコーダー/デコーダーが高性能だからである。だからFireTVなどのAndroid TVボックスのようなPCより都合が良いアプリケーションが存在する。
　逆に言えば、FireTVなどの安価なストリーミング動画プレイヤーでよく採用されているAmlogic S905シリーズの場合CPU・GPUは低性能（例えばハイエンドS922Xの場合：CPU Cortex-A73 x 4 + A53 x 2・GPU Mali-G52 MP2）で動画デコード/エンコード機能に特化している。

	Amlogic S922X	Intel "Gemini Lake"
CPU	Arm Cortex-A73 x4 Arm Cortex-A53 x2	Intel "Goldmont Plus" x4
GPU	Arm Mali-G31 MP2 54.4 GFLOPS	Intel HD Graphics GT1 (12 CU) 144.0 GFLOPS
Video Decode	4Kp60 H.265 10-bit, 4Kp60 VP9 Profile2, 4Kp30 H.264	H.265 10-bit, VP9 Profile2, H.264
Video Encode	1080p60 H.265, 1080p60 H.264	H.265, H.264

　筆者が思うに、Pentium/Celeron "Gemini Lake"搭載Mini PCは、ようやくそういう使い方ができる最低限の水準に達した製品だったと思う。言い換えればIntelがx86 CPUのスマートフォンやタブレットへの搭載を計画していた時点では、GPUもマルチメディア性能も電力効率も色々と足りていなかった。
　"Gemini Lake"に統合されている"Goldmont Plus" CPUコアも興味深いが、それ以上に興味深いのがIntelの動画エンコーダー/デコーダーSIPであるQuickSync Videoだろう。なにせ第6世代Core "Skylake"を上回り、第7～10世代（※"Ice Lake"を除く）Coreと同等でHEVC 10-bitデコード/エンコード（※4:2:0のみ）やVP-9 10-bitデコード/8-bitエンコードに対応している。

Platform

8-bit

10-bit

MPEG-2

MPEG-4 / H.263

H.264 / AVC

H.265 / HEVC Main 4:2:0

WMV3 / VC-1

MJPEG

VP8

VP9

AV1 4:2:0

H.265 / HEVC Main10 4:2:0

H.265 / HEVC Main10 4:2:2

H.265 / HEVC Main10 4:4:4

VP9

AV1 Main 4:2:0

AV1 Main 4:4:4

Intel

Version 5 (Skylake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

-

-

-

Version 5 (Apollo Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode

Decode

-

Version 6 (Kaby Lake, Coffee Lake, Whiskey Lake, Comet Lake, Gemini Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode

Version 7 (Ice Lake)

Decode

-

Decode / Encode

Decode / Encode

Decode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

Decode / Encode

　エンコーダーなどのツールを作成されているrigaya氏が2020年にSSIMで画質比較をされた記事があるのだが（参考：個人サイトのためGoogle検索結果）、ここにあるIntel "Kaby Lake"に搭載のQuickSync Video（Version 6）が"Gemini Lake"に搭載のものと同等で、さすがにx246/x265ソフトウェアエンコードと比較すれば画質は劣り永久保存版には向かないものの、リアルタイムのエンコード/デコードであれば十分実用になるレベルといえる。
　AV-1やHEVC 10-bit 4:2:2/4:4:4や12-bitのデコード/エンコードは対応していないが、そもそもNetflixやAmazon Primeなどのビデオフォーマットを見ても、UHDやHDRを謳うタイトル以外であれば問題無く再生可能なはずである。

　MeLE Quieter2が搭載しているプロセッサーはCeleron J4215 "Gemini Lake"でCPUコアは"Goldmont Plus"である。Intel E-Coreは最近になって急激に拡張されてきているが、恐らくその転機となったのが"Goldmont"→"Goldmont Plus"ではないかと思う。そこから最新の"Gracemont"まで大幅な強化が進んでいる。
　ワークロードにもよるが"Tremont"が概ね"Goldmont Plus"の+20％前後・"Gracemont"がさらに+20％前後ほど性能が向上している。"Gracemont" 4コアが"Skylake" 2コアと同等とされているから、"Goldmont Plus" 4コアは"Haswell" 2コアと同等ぐらいの性能である（凄いのか凄くないのか、よく分からない比較）。

	Silvermont	Goldmont Plus	Tremont	Gracemont
Year	2013	2017	2019	2021
L1$I	32 KB	32 KB	32 KB	64 KB
Decode	2	3	3 x2	3 x2
ROB	32		208	256
# Exec Ports	5	9	10	17
INT ALU	2	3	3	4
Branch	(1)	1	1	2
FPU/SIMD	2	2	2	3
Load	1	2	2	2
Store Address				2
INT Store Data		1	1	2
FP Store Data			1	2
L1$D	24 KB	24 KB	24 KB	32 KB

その意味では"Tremont" CPUコアを搭載した"Jasper Lake"搭載PCの方が良かったのだろうが…"Jasper Lake"搭載PCは比較的新しいせいか€300ほどしてしまい、個人的には価値を見出せなかった。

　やや話が脱線するが、MeLE Quieter2は自宅サーバー用途としてもある程度使えそうだ。ファンレスで消費電力は非常に低いし、中華Mini PCではWindows 10 Homeを搭載しているものが多い中でMeLE Quieter2はWindows 10 Proを搭載するためRemote Desktopできるからである。

　MeLE Quieter2で1点だけ非常に残念なのは、USB Type-Cに見えるコネクターがただの電源コネクターという点だろう。個人的にはHDMI Alt Mode対応USB Type-Cはドックと接続して電源供給とHDMI出力とキーボード等の接続を纏めて行えるので便利だと思うが、本製品ではそういった接続をすることはできない。

GPD WIN Max (5) GPD WIN Max 2021, Steam Deck

GPD WIN Max 2021

Ryzen搭載8型「GPD WIN 2021」の価格が決定 - PC Watch

　WIN Max (2020)に後継機として今年5月にWIN Max 2021がリリースされることが発表されたが、同時にWIN Max (2020)購入者はメインボードを換装することでWIN Max 2021相当にアップグレード可能であることが発表されていた。今回、そのWIN Max 2021および換装用のメインボードのIndieGoGoでの価格が発表された。
　WIN Max 2021にはIntel Core i7 1165G7/1185G7・AMD Ryzen 7 4800Uの3種類が存在するが、Core i7-1165G7・Ryzen 7 4800UがUS$999、Core i7-1185G7がUS$1400、換装用基板（Core i7-1165G7・Ryzen 7 4800U）はUS$669とのことである。

　個人的な率直な意見としては微妙な価格設定だと思う。
　そもそもWIN Max (2020)はIntel "Ice Lake" Core i5搭載でIndieGoGoでの価格はUS$780だったので、WIN Max 2021のCore i7-1165G7/Ryzen 7 4800Uの換装用基板US$669・システム全体US$999というのは相対的に高めの価格設定である。
　新規ユーザーならばUS$999で用途に合わせてGPU性能重視＝Core i7-1165G7またはCPUマルチスレッド性能重視＝Ryzen 7 4800Uから選択することになると思うが、筆者のような既存WIN Max (2020)ユーザーの場合は換装用基板を買うぐらいなら+$230で本体を丸ごと買い替えた方が割安かもしれない。

Steam Deckという選択肢

　ここで個人的に気になるのは、奇しくも時期を同じくして発表されたValve Steam Deckである。Steam Deckには64GB/256GB/512GB版が存在し、それぞれ$399/$529/$649である。
　注目すべきは価格設定であろう。既存WIN Max (2020)ユーザーとしては基板を換装するよりも安価に買えてしまうわけで、用途によってはWIN Max 2021への乗り換えではなくSteam Deckを買うという選択肢も考えられる。

　もちろん、Steam DeckはWIN Max 2021に対してははCPUもGPUも見劣りしてしまうが、重量でも恐らくバッテリー持続時間でもSteam Deckの方が優れているし、特にWIN Max (2020)に対してはiGPUも上回っているので、既存WIN Maxユーザーとしては基板換装も1つの選択肢ではあるがSteam Deckに乗り換えというのも1つの選択肢であろう。

	GPD WIN Max (2020)	GPD WIN Max 2021		Valve Steam Deck
CPU	Intel Sunny Cove x4 1.2 GHz (Base) 3.7 GHz (Turbo)	Intel Willow Cove x4 3.0 GHz (Base) 4.8 GHz (Turbo)	AMD Zen 2 x8 1.8 GHz (Base) 4.2 GHz (Turbo)	AMD Zen 2 x4 2.4 GHz (Base) 3.5 GHz (Turbo)
GPU	Intel Gen11 1075 GFLOPS	Intel Xe LP 2073 GFLOPS	AMD Vega 8 1792 GFLOPS	AMD Navi2 1600 GFLOPS
Memory	LPDDR4-3200 51.2 GB/sec 16 GB	LPDDR4X-4266 68.2 GB/sec 16 GB		LPDDR5-5500 88.0 GB/sec (?) 16 GB
Display	8-inch 1280 x 800			7-inch 1280 x 800
Battery	57 Wh			40 Wh
Dimensions	207 x 145 x 26 mm			298 x 117 x 49 mm
Weight	790 g	790 g (?)		669 g

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とかがざらであることを考えれば想像に難くないだろう。

NanoPi R4S (1) 導入編

Back Issue

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

NanoPi R4S

　FriendlyELEC製SBC（Single-Board Computer）、NanoPi R4Sを入手したので数回に分けて御紹介する。
　まずは入手の際の悩みどころであろうオプション類について説明する。

オプション1: メタルケース

　もしNanoPi R4Sを入手する場合は、メタルケースとのセットを御勧めする。
　筆者が入手したのはNanoPi R4Sとメタルケースのセットだが、手に取った印象を身近な例で喩えると小学校の書道の授業で使った文鎮のようで、見た目以上のずっしり感である。

　NanoPi R4Sのメタルケースはヒートシンクを兼ねており凸状の出っ張りが施され基板上のCPUと密接するように設計されており単なる金属製の箱というわけではないのだが、恐らくこの凸状の出っ張りの中身が空洞ではなく金属の塊になっているのだろう。類似の冷却方式を採用しているSBC用ケースとして有名どころではFlirc製のRaspberry Pi用ケースがあるが、こちらは軽量なアルミ製のうえ凸状の出っ張りの中は空洞になっているため非常に軽く、手に取ったときの印象は随分と異なる。

　詳しくは後述するが、Rockchip RK3399は結構発熱が大きくネットを検索しても巨大なヒートシンクを装着した例が多々あり冷却に困ることが伺える。その点、NanoPi R4Sの純正ケースは$14.00で十分な冷却性能とフィット感を達成できる。例えばCNX Softwareなどでもレビュー記事が掲載されているが概ね～55℃程度には収まるようで熱暴走の心配も無い。

オプション2: 電源

　消費電力が大きいとなれば次に気になるのは電源である。
　FriendlyElecサイトによると電源にはUSB Type-C形状の5V/3.0Aが必要となっており、別売の純正電源は5V/4.0Aとなっている。これは案外厄介である。この種のArm SoC搭載SBCでは自宅に何個か転がっているであろう5年ほど前のスマートフォンの充電器を流用できる場合も多いのだが、5V/3.0Aとなると容量が足りないことだろう。USBには多様な電源供給規格があるが、古典的なUSB1.1～2.0の電源では5V/500mA・USB3.0でも5V/900mAでしかないためである。

　以下にメジャーなUSB標準規格からの例を幾つか掲載するが専用コントローラーによるハンドシェイクが必要となるUSB Battery ChargingとPower Deliveryを除けば5V/3.0Aを満たす規格はUSB Type-Cのみである（ちなみに純正電源はUSB Type-Aで5V/4.0Aなので恐らく規格違反である）。

Standards		Voltage	Ampare
USB Power Delivery		5 V/2 A～20V/5A		10 W～100 W
USB Battery Charging 1.2		5 V	5 A	25 W
USB Battery Charging 1.1		5 V	1.5 A	7.5 W
USB Type-C		5 V	3.0 A	15.0 W
		5 V	1.5 A	7.5 W
USB 3.1		5 V	900 mA	4.5 W
USB 2.0		5 V	500 mA	2.5 W

　USB Battery ChargingとUSB Power Deliveryは電源の送電側と受側とでそれぞれ専用のコントローラーによるネゴシエーションが必要になるし、Qualcomm Quick Chargeなどのベンダー独自規格でも受側の電源管理コントローラー（PMIC）に専用のものが必要となるが、NanoPi R4Sにはいずれにも対応していない。RockchipによるRK3399マニュアル（PDF）によると一応USB Power Deliveryには対応しているそうだが、FriendlyELEC Wikiによると非対応となっている。

　ちなみに、純正電源は端子がUSB Type-Aである以外はOnePlus製スマートフォンの旧製品に標準添付されていたDash Chargerにそっくりで恐らくOEM製造元が同じと思われる。なぜDash Charger同様のUSB Power Delivery対応としなかったのか謎であるが、規格外上等で専用コントローラーやハンドシェイクなどの互換性の煩わしさ無しで5.0V/4Aの給電を実現しようとした結果かもしれない。

　上述の通りメーカーはNanoPi R4Sは5V/3.0Aを要求しているが、USBやGPIOの使用状況によって消費電力は変わってくるがNanoPi R4Sが5V/3.0A = 15.0Wというのがどういう条件を想定しているのかについては記載が無くよく分からない（例えばNanoPi R4SにはUSB3.0ポートが2ポートあるが、USB3.0 x 2ポートで最大5V/900mA x 2 = 9.0Wが含まれた数字ならNanoPi R4S単体では消費電力6.0Wということになる…さすがにそんなことは無かろうが…）。
　筆者はとりあえずUSB充電器でよくある5V/2.4A＝12.0Wで試したところ起動やベンチマークの実行には支障が無かったが、自己責任で試行錯誤して頂きたい。

搭載SoC: Rockchip RK3399

ハードウェアの概要

　中国製Arm SoCを搭載するSBCで最も高性能なSoCというとAmlogic S922X/A311D（以下S922X）とRockchip RK3399（以下RK3399）が代表的なように思われるが、両者は似て非なる性格を持っている。

　まず結論から述べてしまうと、ハードウェアの機能や性能という観点ではS922Xに軍配が上がる。
　インターネット上でS922XとRK3399とを比較した記事が幾つか見つかるが（参考1・参考2）、そもそもスペックシート上でもS922Xの方が優位は明らかで（下の比較表を参照）、これらの記事は実測して確認しただけに過ぎない。ちなみにS922XのGPUの項が（?）となっているのはMali-G52は1コアあたり2 EUと3 EUの構成が可能だがS922Xで採用されているのがどちらか不明なためである。2EU x MP4 = 8EUの場合108.8 GFLOPS・3EU x MP4 = 12EUの場合163.2 GFLOPSとなる。

　S922Xの方がRK3399より高性能ということで、S922XはRK3399よりも高発熱・高消費電力かといけば逆でS922Xの方が低発熱・低消費電力である。なぜなら、RK3399はTSMC 28nm HKMGプロセス（Appleでいうと2013年のiPhone 5Sに搭載のA5で使用されたプロセス）で生産されているのに対しS922Xはより進んだTSMC 12nmプロセス（Appleでいうと2018年のiPhone XSに搭載のA13で使用されたプロセス）で生産されており製造プロセスの優位がある。

		S922X	RK3399
CPU	big core	Cortex-A73 1.8 GHz x 4	Cortex-A72 1.8 GHz x 2
	LITTLE core	Cortex A53 1.8 GHz x 2	Cortex A53 1.4 GHz x 4
GPU		Mali-G52MP4 163.2GFLOPS (?) @ 850MHz	Mali-T860MP4 81.6 GFLOPS @ 600 MHz
Memory		DDR4 x32	DDR3 / LPDDR4 x32
Video	Decoder	4K H.264, 4K H.265, 4K VP9	4K H.264, 4K H.265, 4K VP9
	Encoder	1080p60 H.264, H.265	1080p30 H.264, VP8

OSの対応状況

　このように見ていくとRK3399のS922Xに対する優位性は無さそうに思えそうだが、RK3399の優位性はOSの対応状況にある。より具体的にはメインラインLinux Kernelでのサポートが歴然としている。

　Amlogicのプロセッサーというと、Amazon FireTVで採用されているようにビデオデコードに定評があるが、Armbianなどのオープンソースコミュニティーが開発するLinux系OSではビデオデコーダーほぼサポートされていない。これにはBSP=Board Support Packageが関係している。
　組込プロセッサーベンダーが自社製プロセッサーに搭載されている固有のデバイスを搭載製品で有効にする場合、当然ながら対応したドライバーが必要となる。Linuxの場合はオープンソースのためメインラインに取り込まれている場合はどのLinuxディストリビューションでも基本的に対応可能となるが、ベンダーが固有デバイス用のドライバーをメインライン化していない場合はベンダーが顧客向け提供するBSPを使うことになる。

　Amlogicのビデオエンジンを有効化したい場合、ドライバーはメインライン化されていないためAmlogic提供のBSPを使用する必要があるが、そのベースのLinux Kernelは2016年にリリースされたLinux 4.9である。Linux 4.9はLTSカーネルで2023年1月までサポートされているが、2016年以降に実装された新機能（具体例：WireGuard VPN）や追加されたドライバー類には対応しない。また、2023年1月以降のサポート状況にも不安がある。
　HardkernelやKhadasなどAmlogic製SoCを搭載したSBCを提供しているベンダーはこのAmlogic製BSP Kernelを使ったOSイメージを提供しているが、これに対しArmbianやOpenWrtなどのコミュニティーは古いBSP Kernelは使わずメインラインLinux Kernelを使用している。ArmbianやOpenWrtなどコミュニティーが開発する組込Linuxでは基本的に1つのソースコードツリーから多種多様なSBCのOSイメージをビルドするためボード毎に個別のBSPを使うなどというような対応はしていないからである。そのため、Amlogic固有のデバイスはドライバーが欠けているため使えないが、Linux Kernelの最新機能を使うことはできる。

　一方、RK3399はOP1として2016年頃からGoogle Chromebookに広く搭載されており、ドライバーの多くがLinux Kernelメインラインにマージされている。メインラインにマージされているということは、Linus TorvaldsのリポジトリーのソースからビルドしてもRK3399に搭載されているデバイスを使用できるということで、当然ながらメインラインカーネルを使っているArmbianやOpenWrtなどのLinuxディストリビューションでも標準でサポートされている。
　RK3399/OP1に搭載されているデバイスのドライバーがメインライン化されている件については、独自ビデオエンジンAVE10を搭載するAmlogic SoCとは違い、そもそもデバイスがRockchip固有のIPではないからかもしれない。公開されている情報やArmbianやOpenWrtのコミュニティーの解析を参考にすると、RK3399内蔵1Gigabit Ethernet MACはST Microelectronics製ST MAC・ビデオデコーダー/エンコーダーはVeriSilicon製Hontro G1/H1・USB3.0/USB-OTGコントローラーはSynopsys製DWCとのことで、これらは既にメインラインカーネルにマージされている。

　AmlogicのSoCはAmazon Fire TVのように端末ベンダーが後付けの拡張を考慮すること無くスマートTVボックスのような組込デバイスを開発する場合には優れた選択肢だと思う。しかし、GPIOにデバイスを追加したりOSを入れ替えたり…といったことが行われるホビー用としてはAmlogic製SoCよりもRockchip製SoCの方が優れているように思う。いくら優れたハードウェアを積んでいてもドライバーが無ければ意味が無いからである（例：Amlogic AVE10ビデオエンジン）。
　恐らくその使い勝手の良さも一因だろうが、RK3399は非常に多くの組込デバイスで採用されているベストセラーとなっている（参考：ASUS Chromebook Flip C101・Kobol Helios64・PineBook Pro・Station P1・Khadas Edge-V）。多くのデバイスで採用されているということは、コミュニティーやユーザーの知見も蓄積されておりドライバーや資料も充実しているということである。NanoPi R4Sとしての登場は間もないがWIP（Work-in-Progress）ステータスながら既にArmbianも公開されているほか、OpenWrtの開発も進行中である。

※筆者注：これらのOSを含めた記事は2月以降に投稿する予定である。Armbianは3カ月毎に公式イメージがリリースされるが、11月のBetaイメージは残念ながら筆者のデバイスでは動作しなかった。次回2月にリリース予定の正式版イメージで各種ベンチマークなどをレポートできると思う。

SoC以外のハードウェア

　搭載SoC=RK3399以外のハードウェアについてだが、NanoPi R4Sの最大の特徴は1000BASE-T=1GbE 2ポートだろう。
　2ポートの1GbEのうち1ポート（WAN側）はRK3399内蔵のMACにRealtek製PHY RTL8211Eを組み合わせたもの、残りのもう1ポート（LAN側）はPCIe x1接続でRealtek製EthernetコントローラーRTL8211Hが接続されている。

　NanoPi R4SはこれらのGbE 2ポートを中心としたコンセプト＝ルーターやネットワークアプライアンスを想定しているようで搭載部品は実に簡素である。GPIOピンヘッダーも搭載しているがRaspberry PiなどのGPIOとは異なりSPI・I2C・USB2.0のみである。RK3399には上述の通りGPUも搭載されているがHDMIやDisplay Portなどのディスプレイ出力も搭載されていない。

　メモリーはDDR3/LPDDR4対応だが、NanoPi R4Sでは1 GBモデル/4 GBモデルが用意されており前者がDDR3/後者がLPDDR4である。このような構成となった理由はよく分からない。もしかするとLPDDR4 8-Gbit（1 GB）チップが無かったかDDR3 512MB x2チップの方が安価だったのかもしれない。DDR3とLPDDR4の主流のインターフェースは異なり前者がx8かx16接続・後者はx32かx64接続が主流だが、NanoPi R4Sでも1 GBモデルは512MB x16を2個・4 GBモデルは4GB x32を1個搭載しており基板のデザインが異なっている。
　ちなみに、スマートフォンが4～8 GBものメモリーを搭載する時代に1 GBというと小容量に思えるが、家庭用Wi-Fiルーターなどは搭載メモリ容量がせいぜい512 MB～2 GB程度でおかしくない。ルーターの場合は受信したパケットを処理して転送すればメモリーを解放できるのでメモリー容量よりも遅延の方が重要となり、実際、例えば先日発表されたASUSのRT-AX89Xもメモリー容量は1 GBである。もっとも、ルーター以外のネットワークアプライアンス用途を考えているようであれば当然1 GBでは不足する可能性はあろう。筆者が想像するに1 GBモデルと4 GBモデルが用意された理由は、恐らくルーター用だと前者・それ以外だと後者という棲み分けではないかと思う。

AliExpressのFPGA開発ボード

　FPGAの勉強がしたくてAliExpressでZynq搭載ボードを物色中。
　先に言っておくと、不要なトラブルを避けるためにもDigilentあたりで買うことを強く推奨する。

　事の発端はHackadayでXilinx Zynq 7000搭載ボードが$20で売られているという記事を読んだためで、以前にもFPGA搭載ボードをAliExpressで探した記憶があるのだが$20以下というのは新しい。…とここで「普通$200するZynq 7000搭載ボードが$20！？」などと飛び付いてはいけない。この記事自体は間違ったことは言っていないのだが、いろいろと注意が必要である。

　まず、そもそもAliExpressをZynqで検索し観察してみると大別して$20以下のボードと$50以上のボードの2種類が掲載されていることに気が付く。
　実は$20以下のボードは中国の某仮想通貨マイニング装置の制御用ボードが落ちてきたものである（新品なのか中古なのかは不明）。FPGAなので理屈上はロジックを書き換えれば仮想通貨マイニング以外にも使用可能であろうが、そういう特殊な用途向けに設計された基板のため電源供給用のジャックが無かったり、JTAGヘッダーがパターンだけでピンが無かったりするので、電子工作やFPGAに慣れた人でなければ避けることをお勧めする（加えて、後述するOSの問題もある）。

　では$50以上のボードはというと、$20以下のボードよりはマトモそうで無償のVivado WebPackあたりでロジックを作ってプログラミングすれば使えるものと思われる。
　面白いのはJTAGである。既にXilinx FPGAに対応したJTAG Programmerをお持ちの場合はそれで良いとして、持っていない場合、正規品を買うとそれなりに高いし、かと言って怪しげなAliExpressで見つけられる安価なJTAG Programmerは本当に使えるのかよく分からない。そこで筆者が個人的に興味があるのは「DEBUG」や「JTAG」と表記された基板で、JTAG Programmerが基板上に搭載済のためPC/VivadoとUSBで直接接続するだけでアクセスできる（参考1・参考2）。

　FPGAのプログラミングはそれでどうにかなるとして、次の疑問はOSである。
　Zynq 7000はArm Cortex-A9プロセッサー 2コアとArm Mali-400 GPUを搭載しており、つまり8年ほど前のスマートフォン用SoCと小規模なAltix-7 FPGAが同居した格好になっておりLinuxを動かすことが可能である。つまり、うまくFPGAとドライバーを組めば理屈上はLinux上からFPGAのロジックを使えるはずである。恐らく多くの製品はXilinx Peta LinuxがプリインストールされたSDCardか、イメージをダウンロードするためのリンクなどが添付されていると思われるが、商品説明に詳細が明記されておらず不安がある。

　そんな中で個人的に興味があるのは「Pynq」の記載があるボードである。
　PynqとはXilinxが開発したJupyterのWebインターフェースからPythonでZynq上のFPGAにアクセスするための開発環境で、対応の環境としてはPynq-Z1・Pynq-Z2といった開発ボードが有名だが、AWSのFPGAインスタンスやXilinx Alveroを含む様々な環境に対応している。言い換えればZynq搭載ボードを含むLinuxが動作するXilinx FPGA環境ではPynqをポーティングして動作させることが可能で、「Pynq」が明記されている開発ボードであればPynqをポーティングされたPeta LinuxベースのOSが付属している（はず）。

GPD WIN Max (4) 導入編

　IndieGoGoで出資していたGPD WIN MAXが香港から到着した。

ハードウェア

　ハードウェアのファーストインプレッションについてはPC Watchなど各種メディアで既報なので深くは追及しないが、想像と違った部分を中心に書いておこうと思う。

　まず、材質や組立精度はなかなか良い。天板は金属・本体は樹脂製ということで身構えていたが、最初に手に取っただけでは材質の違いに違和感を覚えるようなこともなく高級感もある。一方で気になったのは、他のレビューでも触れられているがズッシリと重くNintendo Switchのように抱えてゲームするのは想像し難い。
　ほかに気になったのは8インチ液晶ディスプレイも天板も指紋が目立ちやすいことだろうか。天板はともかく液晶については保護フィルターを入手したいところだ。

　使ってみて気になったのはファンの風切音が意外に煩いことだ。ファンの停止方法についてはマニュアルにも記載されているため割愛するが、わざわざマニュアルに大きく載せているあたり当初からの問題点だったことが伺える。もっとも、GPDが謳う通りゲーミングを想定するならファン設定を変更することは現実的ではないかもしれない。

　ところで、GPD WIN MAXはゲーミングをウリにLPDDR4X-3733搭載を謳っていたが、いつの間にやらLPDDR4-3200にダウングレードされていたのは残念だ。IndieGoGoなどのプロモーションではLPDDR4X-3733のLPDDR4-3200に対する優位性が宣伝されていたのだが、それが特にアナウンスもなくひっそりと更新されていたことは個人的には騙されたような複雑な気持ちだ。

Windows 10 Proをクリーンインストール

　GPD WIN MAXにはWindows 10 Homeがプリインストールされているが、到着後すぐにWindows 10 Proに入れ直した。私の運用ではRemote DesktopでのアクセスやHyper-Vが使える方が便利というのもあるし、特別にGPDのことを疑う意図はないが中華PCのプリインストールOSやプリインストールアプリは一貫して信用しないことにしているためだ。テクノロジー系ブログ（？）で政治のことを話題にする意図は無いが技術を政治利用できてしまうのが共産主義の怖いところなのでリスクを事前に回避することは当然のことだ（※旅行先の外国で犯罪発生率の高い地域に立ち寄らないのと同じ）。
　そもそも、GPD WIN MAXには必要なさそうなソフトウェアがプリインストールされていることも個人的には気持ちが悪い。具体的にはOpenALやNVIDIA PhysX System SoftwareやMicrosoft XNA FrameworkやVisual C++ Redistributable Packagesが2008～2019まですべてプリインストールされているが、すべて必要とも思わないし、いずれも必要になれば自前でインストールすればいいのでプリインストールの必要性は感じない。ただでさえGPD WIN MAXはコントローラー部分やネイティブ ポートレートタイプの液晶ディスプレイなどドライバー周りなどが素のWindows 10とは異なりドライバーや各種設定に手が入っているので、まっさらにしておきたかったのもある。

　上記のような理由でWindows 10 Proをクリーンインストールしたが、内蔵SSDのパーティションも併せて変更した。
　GPD WIN MAXには中国BIWIN製 500 GBのM.2 NVMe SSDが搭載されているが、初期状態では概ね100 GB + 350 GBにパーティションが区切られており、350 GBのD:ドライブは空の状態になっている（※注：GBのカウント方法の違いやUEFI領域・リカバリー領域などの都合で総容量は450 GB程度である）。これを、今回は100 GB + 250 GB + 100 GBに切り直した。これはゲーミング用途を想定しシステム・ゲーム・データのライフサイクルの違いを念頭においたものだ。
　私の場合、前世代メインPC=ThinkPad X220では256 GBのSSDをシステムとデータの2パーティションに分割していたが、このシステム+データの区切りは一般的だろうと思う。WindowsシステムはWindows as a Serviceに従うなら半年に1回インストールし直すことになるしWindowsもアプリ類も壊れたらインストールし直せば済むが、データは半永久的に残すものだからだ。今回はこれに大容量 250 GBのゲーム領域を追加した格好だ。
　私のゲーミングプラットフォームはSteam + Epic Gamesで、上記の2パーティション制でいうとC:ドライブにインストールすべきアプリ類に相当するように思われるが、一般的なアプリ類（例：Microsoft Office）とゲームとを比較すると、ゲームの場合は新作を買ったらインストール・飽きたらアンインストールというライフサイクルが比較的短いし、また容量も大きく気が付いたらC:ドライブを食い尽くしていた…などということがあっても困る（つまりクォータの代わり）。そういったことを考慮するとゲーミング用に専用パーティションを区切ることは理に適っていると思う。

　GPD WIN MAXのWindowsのクリーンインストール自体は意外にも難しくない。
　GPD HKのダウンロードサイトからドライバーを入手する必要があるが、Windows 10 FirmwareセクションからGPD謹製の標準Windows 10 Homeイメージ、Driver & BIOSセクションからドライバーを一括ダウンロードすることができる。今回はMicrosoftからダウンロードした素のWindows 10に後者のドライバーパッケージを適用した。
　このドライバーパッケージが面白いのは、多くのベンダー製PCのドライバーとは違い一括インストールを想定していることだ。ダウンロードしたZipファイルを展開すると、各種ドライバー類が格納されたフォルダーとAutoInstallDrivers.batファイルが出てくるが、このバッチファイルを管理者権限で実行することですべてのドライバーを一括で適用することができる。
　ちなみに、フォルダーに入っているドライバー類が必要なドライバーかどうかは確認したが改変されているかどうかについては確認しなかった。Windows 10の場合、ドライバーもWHQLドライバーがMicrosoft Updateで更新可能なためドライバーのバイナリーを確認することにはほとんど意味がないからだ（Settings→Update & Security→Windows Update→View optional updates）。
　GPD WIN MAXの8インチ液晶ディスプレイはポートレート スタイルがネイティブでドライバーで90度回転させている状態だが、クリーンインストールするとWindows 10のインストール完了時点まではポートレート スタイルになっており、これがドライバー類をインストール・再起動するとランドスケープ スタイルに切り替わる。もっとも、Intel Graphicsは標準でControl + Alt + 矢印キーで画面を回転させることが可能なのでGPDが何かを改変しているわけではなくIntel純正の機能をレジストリー設定の追加で適用しているだけだ。ちなみに、もしドライバーインストール→再起動後にランドスケープ スタイルに切り替わっていない場合でもSettings→System→DisplayでDisplay orientationからLandscapeを選択することで切り替えることができる。
　AutoInstallDrivers.batで適用されるのはフォルダー内のすべてのinfファイルとレジストリー設定3個で、レジストリー設定は上述のディスプレイ オリエンテーションの変更のほかDPI設定の変更・PCデスクトップアイコンの追加だけだ。

　調べていて分かったのだが、GPD WIN MAXのようなやや特殊なPCを使う場合はDouble Driverを使う方法があるらしい。この場合、現時点で動いているシステムをベースにDouble Driverでドライバーのバックアップを取得し、Windowsのクリーンインストール後にバックアップしたドライバーを適用する。

　GPD純正のドライバーパッケージを使う方法とDouble Driverを使う方法とで、どちらが良いかは悩ましい問題だ。ドライバーパッケージはもとより、Double DriverでバックアップするプリインストールされているドライバーもGPDが提供しているものだからバージョンはともかく内容的には違いが無いと思われる。
　個人的には、初回はGPD純正のパッケージを利用し、次回からはDouble Driverを使う方法を検討したいと思う。上述の通りWindows 10ではWHQLドライバーもMicrosoft Updateで配信されることから、GPDのパッケージでインストールしたドライバーも更新されることになる。GPD自身もダウンロードページ上のドライバーパッケージを更新するだろうが、安定性や入手元の素性という意味ではMicrosoft経由のWHQLドライバーをインストールするのが一番安全だろうからだ。

自宅NAS構築計画：HPE Microserver Gen 10 Plus

07/07、07/11更新 - 解り難そうな部分を加筆修正
11/06 - 別記事に合わせタイトルを変更

　筆者は現在NASの新調を考えており、その候補として調査したHP Enterprise Microserver Gen10 Plusについての検討内容をまとめる。なお、購入前の調査のため実物を使った検証結果ではなく、実物レビューはServeTheHomeのレビュー記事を参考にされたい。

想定する用途

　本稿では用途としてNASを含めたストレージサーバーを想定して検討している。
　本稿で「ストレージサーバー」とは基本的にNAS（NFSやCIFSでネットワーク経由でファイル共有）やSAN（iSCSIやNVM-oIF）をホスティングするサーバーのことであるが、個人的にはUPnPやDAAP（iTunes）メディアサーバーも想定している。ネットワークプロトコルやインターフェースが異なるだけでネットワーク越しのファイル共有という意味では同じだからである。

　ストレージサーバーに用途を限定しているのは、個人用途で3.5インチHDD 4台（8TB～16TB x 4-bay = 32TB～64TB）が必要となるとストレージ以外を想定する方が難しいからである。もちろん、企業/SOHOであれば例えばデータベースサーバーやドメインコントローラー（+ホームディレクトリ）の用途も考えられるが、それらは本稿の趣旨からは外れるため割愛する。

　Microserver Gen10 Plusは価格は構成や購入元や国にもよるだろうがサーバー本体は10万円前後で購入できる。これに無償のTrueNAS Core（旧FreeNAS）やOpenMediaVault（OMV）などと組み合わせる場合、手間という追加コストはかかるがQNAP・SynologyなどNASベンダー製のハイエンドNASと予算的には同等に収まる可能性がある。NASや自宅サーバーとしての導入はありそうだ。

ハードウェア概要

　本機はHP EnterpriseのProLiant Gen10サーバーファミリーに属するいわゆるPCサーバーで、PCサーバーに慣れている人にとっては普通のHPE製ProLiantであるが、一般的なPCとは構成に一線を画すものがある。
　例えばメモリーにはDDR4 ECC Unbufferedメモリーが採用されておりCPUはそれに対応したものが採用されているし、本機のリアI/OにはVGAとDisplayPortのディスプレイ出力が見えるがIntel HD Graphicsの出力ではなくHPE製BMCであるiLO 5のディスプレイ出力でゲームや動画再生には適さない。筐体内部のメインボード上にはVMware vSphereなどをインストールするためのUSBポートがあるなど、一般的なPCとは似て非なるものである。

　HPE MicroserverにTrueNASやOMVを導入してストレージを管理するような人であれば、パーツを個別に購入して自作する選択肢も考えられるだろう。詳細は割愛するが、NASベンダー製NASアプライアンス・HPE Microserver Gen10 Plus・自作サーバーを比較すると概ね以下のような違いになるだろう。それぞれに利点はあるが、Microserverの利点は自作の自由度とNASアプライアンスの手軽さ・自由度・性能・価格のバランスの良さだと思う。
　ストレージとして使用する場合、ソフトウェア構成の自由度は重要かもしれない。NASアプライアンスではファイルシステムの選択肢が限られるからで、例えば、NASアプライアンスの多くはext4・一部でBtrfsが使用しており筆者が知る限りZFSを採用したNASアプライアンスは存在しない。Microserverや自作ではTrueNASやOMVを使うことで手軽にZFSを利用できる。

	メーカー製 NASアプライアンス	Microserver Gen 10 Plus	自作
導入の容易さ	〇	△	✕
構成の自由度 （Software）	△	〇	〇
構成の自由度 （Hardware）	✕	△	〇
設置スペース	〇	△	✕
コストパフォーマンス	△	〇	△ / 〇

マイクロプロセッサー

　搭載CPUとして購入時にXeon E-2224とPentium Gold G5420から選択できる。
　XeonあるいはPentium Goldという名前が付いてはいるが同じCPUアーキテクチャー＝Coffee Lake RefereshをベースとしたSKUの違いなのでCPUコア単体・シングルスレッドでのIPCはほぼ同等である。性能についてはARMプロセッサーを搭載したNASより優れていることは間違いないが、十分かといえばワークロードを検証する必要がある。

　E2224とG5420の2種類のCPUを一般的なワークロードをテストした場合ではE2224がG5420の倍ほどのパフォーマンスを得られる。物理CPUコア数と付随するキャッシュの容量が2倍でありピークの動作周波数も高いからこの性能差は妥当といえる。
　しかし、ストレージサーバーに限定した用途ではE2224の方がG5420よりも高性能ではあろうが2倍もの性能が得られるかについては疑わしい。HDDアレイのようなストレージやネットワークアプライアンスではI/O待ちでCPUが遊んでしまう可能性が高く、そのような用途ではSMTが効果的に働く可能性が高いが、E2224ではSMT無効・G5420ではSMTが有効だからだ。つまりG5420では演算ユニットが効率よく使われるがE2224では効率が上がらないため、性能差は2倍にはならない可能性が高い。
　個人的にはなぜHPEが4C/8Tのオプションを用意しなかったのかと疑問ではあるが、Coffee Lake-S/-E/-R/-ERプラットフォームで4C/8TとなるとXeon E-2134またはE-2234となりリストプライスで$50ほど高価になってしまうし、HPEはストレージサーバーに用途を限定していないせいだろう。

	E2224	G5420
Core/Threads	4C/4T	2C/4T
Frequency (Base)	3.4 GHz	3.8 GHz
Frequency (Turbo)	4.6 GHz
Last Level Cache	8 MB	4 MB

　ここではMicroserverをストレージサーバーとして使う想定なので、ZFSファイルシステムのRAIDZアレイをホストすることを想定すると、課題は消費するリソースの多さである。ZFSについてはそれだけで記事1本分以上になるので割愛するが、あらゆるZFS解説書・解説blogが高速なCPUと大容量メモリーを勧めているので、ZFSの導入を想定しているのであればXeon E2224の選択をお勧めしたい。

　ところで、メディアサーバーとして考えた場合、UPnP/DLNAサーバーとしてはもちろんPlex/Embyサーバーとして使うことも考えられるが、トランスコードにQuickSync Videoは使えないので注意が必要である。Xeon E2224はiGPUが無効化されているしG5420はiGPUがあるはずだがHP Enterpriseによるとファームウェアで無効化されているためである。

ネットワーキング (1) 内蔵GbE: i350-AM4

　私が個人的に疑問に思うのが本機に搭載されているGbE＝i350-AM4である。
　Intelの4ポート1GbEコントローラーで、1GbEながらVMD-qやSR-IOVに対応する。SR-IOVは例えば合計4台以上の仮想マシンがホストされている場合でもPCIeパススルーでネットワークアダプターを割り当てたりといった使い方ができる。こういう使い方は特に10GbE以上では有効なのだが1GbEではあまり採用例は見ない。

　個人的には、i350-AM4よりも例えばIntel i225-LMなどの方が良かったのでは？という疑問もある。2.5GBASE-Tに対応しており$4.06なので4ポートに4チップでもi350-AM4よりも安価だが、SR-IOVに対応していない。HPEがどういった使い方を想定して本機にi350-AM4を選択したかは不明だが、恐らくはVMwareなど仮想マシンホストとしての使い方を想定してi350-AM4を選択したのだろう。

　本稿では本機を仮想マシンホストとしてでなくストレージサーバーとすることを想定しているから、残念ながらi350-AM4はあまり良いNICとはいえない。後述するがPCIe x16に10 GbEアダプターを接続することを提案したい。

ネットワーキング (2) PCIe 10GbE

　拡張性に余裕のあるPCサーバーならばともかく、本機にはPCIe x16 1スロットしか拡張の余地が無いので本当に必要なものを選択する必要がある。
　そこで検討・提案したいのがQNAP製かSynology製の10GbE・M.2コンボカードである。PCIeカード1枚で10GbEとM.2接続のデバイス x 2個を拡張できる。これらの拡張カードはPCIeカードにPCIeスイッチと各種コントローラーを載せたものだからPCIeスロットを持つマシンと対応ドライバーがあれば技術的には動作するはずだが、メーカーが想定している用途ではないから保証を受けられない可能性があるので注意されたい。

　QNAP製4種とSynology製1種が存在するが、搭載しているパーツ・対応するデバイス・性能に差異があるため注意が必要である。
　10GbEコントローラーはQNAP製の旧モデル（QM2-2S10G1T・QM2-2P10G1T）ではTehuti TN9710P、QNAP製の新モデル（QM2-2S10G1TA・QM2-2P10G1TA）ではMarvell（旧Aquantia）AQC107である。Synologyは情報がないが恐らくAQC107だろう。TN9710PとAQC107の機能的な差は前者は10G/1GbE対応に対し後者は10G/5G/2.5G/1GbE対応なので後者を選ぶのが無難であろう。Intel製・Mellanox製の10GbEと比べれば性能的・機能的に見劣りするのは否めないがストレージサーバーで使う分には十分だろう。性能面から言えばSATA HDDはアレイを組んでも10Gbpsより遅いし、Intel・Mellanox製の10GbEコントローラーに搭載されるSR-IOVなどの機能はストレージサーバーには不要だからである。
　Marvell・Tehuti製コントローラーになくIntel・Mellanox製にある機能でストレージサーバーで効果的なのはRDMAやRCoEである。これらの機能が必要な場合はIntel・Mellanox製コントローラー搭載製品を選ぶ必要がある。

　M.2スロットについてだが、QNAP製はSATA接続とPCIe Gen2 x2接続・Synology製はPCIe Gen3 x4接続から選択することになる。PCIe接続の場合M.2 M-key形状であれば他のデバイス（例えばGoogle EdgeTPUなど）も接続できるが、本稿ではストレージサーバーを想定しているためSSDになろうかと思う。
　個人用途では考え難いが、サーベイランスカメラのビデオ保存先として使用する場合、EdgeTPUやIntel Myriadを接続して顔識別などもできそうだが、本稿の趣旨とはずれるため割愛する。

　注意が必要なのは、接続されるプロトコルと性能についてである。
　PCIeカードそのものはホストとPCIeで接続され、PCIeスイッチでスイッチングして各デバイスと接続するわけだが性能がやや異なる。

	QNAP SATAモデル	QNAP PCIeモデル	Synology PCIeモデル
PCIe Switch	IDT 89HPES12T3G2 3 port 12 lane	IDT 89HPES10T4G2 4 port 10 lane	? 4 port 20 lane
Host-PCIe Switch	PCIe Gen2 x4 (20Gbps)	PCIe Gen2 x4 (20Gbps)	PCIe Gen3 x8 (64Gbps)
PCIe Switch-NIC	PCIe Gen2 x4 (20Gbps)	PCIe Gen2 x2 (10Gbps)	PCIe Gen3 x4 (32Gbps)
PCIe Switch-SSD	PCIe Gen2 x2 (10Gbps) SATA III 6Gbps x2	PCIe Gen2 x2 (10Gbps) x2	PCIe Gen3 x4 (32Gbps) x2

　QNAP SATAモデルではPCIe Switch - 10GbE NIC間がPCIe Gen2 x4（片方向20GT/s・双方向40GT/s）で接続される。これは10GbEよりも高速なためネットワーク接続は高速だが、一方でSATA III SSD（計12Gbps）がPCIe Gen2 x2接続（10GT/s）のSATAコントローラーで接続されるためSSDは十分な性能を発揮できない可能性がある。
　例えばM.2 SATA SSDをWriteキャッシュとして用いる場合、書き込みでは以下のようなフローになる。
Client＝(10Gbps)⇒10GbE NIC＝(<20GT/s)⇒CPU＝(10GT/s)⇒SATA⇒M.2 SSD＝(10GT/s)⇒CPU＝(6Gbps x 4)⇒HDD
実際のホストCPU-PCIe Switch間の帯域は上り20GT/s・下り20GT/sだが、途中のPCIe帯域は下り10GT/s・上りが最大で計30GT/s必要な場合があり不安である。また、そもそもM.2 SATA SSDでキャッシュとして有意な速度が得られるのか？という疑問もある。

　QNAP PCIeモデルではPCIe Switch - 10GbE NIC間がPCIe Gen2 x2（10GT/s）で接続されるのでSATAモデルよりも若干遅くなる。また、PCIe接続のSSDを接続できるがPCIe Gen3 x4（32GT/s）ではなくPCIe Gen2 x2（10GT/s）なので高速なSSDを搭載しても十分なパフォーマンスは得られない。
　M.2 SSDがPCIe Gen2 x2（10GT/s）が2基なので、SSDだけを見ればストライピングなどによりキャッシュとして十分な性能を得られそうに見えるが、PCIe帯域が圧倒的に不足である。例えばM.2 SSDをWriteキャッシュとして用いる場合、書き込みでは以下のようなフローになる。
Client＝(10Gbps)⇒10GbE NIC＝(<20GT/s)⇒CPU＝(20GT/s)⇒M.2 SSD＝(20GT/s)⇒CPU＝(6Gbps x 4)⇒HDD
途中のPCIe帯域は上り40GT/s・下り20GT/s必要な計算だが、実際のホストCPU-PCIe Switch間の帯域（上り20GT/s・下り20GT/s）を上回ってしまっている。

　Synology PCIeモデルは3機種で唯一PCIe Gen3 x8（片方向32GT/s・双方向64GT/s）対応でNVMe M.2 SSD本来の性能を発揮できる。また、ホストと拡張カードの接続が64 GbpsあるからSSDと10GbEが競合し難い構成となっている。例えばM.2 SSDをWriteキャッシュとして用いる場合、書き込みでは以下のようなフローになる。
Client＝(10Gbps)⇒10GbE NIC＝(<20GT/s)⇒CPU＝(32-64GT/s)⇒M.2 SSD＝(32GT/s)⇒CPU＝(6Gbps x 4)⇒HDD
Synology製品の場合、上述の通りホストCPU-PCIe Switch間の帯域が片方向32GT/s・双方向64GT/sもあるため余裕がある。それでもM2 PCIe Gen3 x4 SSD 2基の帯域には僅かに不足しているのだが、SATA 6Gbps 4基のHDDのキャッシュとして使う分には十分以上に高速である。今回検証している用途＝ストレージサーバーではWriteでは10GbEがボトルネックになって10Gbps以上の書き込みが必要ない（もちろん、25GbEや100GbEも搭載可能だが…その場合はSSDの設置スペースが無いため、この想定そのものが無意味である）。
　もし、今回想定しているような用途で使用する場合はSynology製コンボカードの使用をお勧めしたい。

　ところで、PCIeに普通の10GbEカードではなく10GbE・M.2コンボカードを勧める理由はM.2 SSDにシステム領域やキャッシュ領域を配置して4ベイのHDDをデータ領域のみにするためである。
　ZFSでストレージを組む場合、システム領域・データ領域（ZFSプール）・キャッシュ領域（ZFS SLOG・L2ARC）の3種類を考慮する必要があるが、SSDにOSとキャッシュを格納することでHDDをデータ領域で占有できる。様々なZFS解説ページがZFSプールにHDD全体を使うことを勧めている。パフォーマンス面で利点があるほか管理面でも利点ある。
　メーカー製NASなどでは、メインボード上のフラッシュにBootloaderとLinux Kernelのみが入っており、Linuxルートファイルシステムはデータと同じHDDに格納されていることがあるが、管理やトラブルシューティングを考えると良いアイデアとは言えない。例えばBuffalo製NASの場合は搭載されているHDDすべての第1パーティションがRAID1でミラーリングされシステムが格納されているが、これは別の見方をすればディスクをすべて抜くと起動不可になってしまう。
　ZFSでは読み書きの高速化のために、読み出しキャッシュ＝L2ARCや書き込みキャッシュ＝SLOG（ZILの独立させた領域を割り当てたもの）を設定することが多くSSDを推奨されることが多い。また、SLOGは書き込み障害時にデータのリカバリーに使用されることからZFSストレージプールと同じHDDではなく別途領域を設定する方が信頼性の面で推奨される。