Chromebook Plus CX34(CX3402)のベンチマーク結果

# はじめに

英語版キーボード、より容量の大きいSSDを使いたい等の理由でamazon.comで以下のChromebook Plusのラップトップを購入しました。
https://www.amazon.com/ASUS-Chromebook-1920x1080-Processor-CX3402CBA-DH386-WH/dp/B0CGJGZZ1L?th=1

そこで、内部のハードウェアの種類および、各種ベンチアマークを取得してみました。

# CPU
Alderlake世代のCore i3 1215Uが採用されています。

```
uname
Linux localhost 5.15.140-21048-g04ee62cda977 #1 SMP PREEMPT Thu, 15 Feb 2024 22:10:52 +0000 x86_64 12th Gen Intel(R) Core(TM) i3-1215U GenuineIntel GNU/Linux
```

https://www.intel.com/content/www/us/en/products/sku/226269/intel-core-i31215u-processor-10m-cache-up-to-4-40-ghz-with-ipu/specifications.html

- Geekbench 6(Android app on crosvm)
https://browser.geekbench.com/v6/cpu/5064523

```
1964 
Single-Core Score 

5006
Multi-Core Score 
```

- Geekbench 6(Linux binary)
https://browser.geekbench.com/v6/cpu/5064752 

```
1980 
Single-Core Score 

5036 
Multi-Core Score
```

- Web XPRT4 

```
Score

242

Workload 

ms 

Variation(%) 

Photo Enhancement 

352 

+/- 3.11 

Organize Album using AI 

1350 

+/- 0.86 

Stock Option Pricing 

103 

+/- 4.77 

Encrypt Notes and OCR Scan 

863 

+/- 0.87 

Sales Graphs 

255 

+/- 3.19 

Online Homework 

1788 

+/- 1.56 
```

# Memory

chrome://systemの情報より。

```
SPD: module type is LPDDR5 
SPD: module part number is H9JCNNNBK3MLYR-N6E 
SPD: banks 8, ranks 1, rows 15, columns 11, density 8192 Mb 
SPD: device width 16 bits, bus width 16 bits SPD: module size is 1024 MB (per channel) 
```

https://product.skhynix.com/products/dram/lpddr/lpddr5.go?appTypCd=APX02&treeNo=1054 

LPDDR5 6400MHzです。
以下はsysbenchのメモリテストの結果です。
(実際にはスレッド数、メモリブロックサイズを調整しながら複数回繰り返しています、おおよそこのくらいの値が限界値のようでした)

    zyake@penguin:~$ sysbench --test=memory --num-threads=8 --memory-block-size=8M run 

    WARNING: the --test option is deprecated. You can pass a script name or path on the command line without any options. 

    WARNING: --num-threads is deprecated, use --threads instead 

    sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3) 

    Running the test with following options: 

    Number of threads: 8 

    Initializing random number generator from current time 

     Running memory speed test with the following options: 

      block size: 8192KiB 

      total size: 102400MiB 

      operation: write 
    
      scope: global 

     Initializing worker threads... 

     Threads started! 

    Total operations: 12800 ( 9277.84 per second) 

    102400.00 MiB transferred (74222.74 MiB/sec) 

     General statistics: 

    total time:                          1.3783s 

    total number of events:              12800 

  

     Latency (ms): 

         min:                                    0.23 

         avg:                                    0.79 

         max:                                   15.79 

         95th percentile:                        1.10 

         sum:                                10089.15 

  

    Threads fairness: 

    events (avg/stddev):           1600.0000/0.00 

    execution time (avg/stddev):   1.2611/0.0 


デスクトップ版のAlder Lakeでもメモリコピーはおおよそ7xGiB/sなので、おおよそスペック通りの結果だと思われます。
https://www.tomshardware.com/news/gear-4-mode-tested-on-alder-lake 

 # Storage
chrome://systemの情報より、KLUEG8UHGC-B0E1というモデルのUFSデバイスを採用していることがわかります。

```json
{
    "Name": "KLUEG8UHGC-B0E1",
    "DeviceId": "645dd3eabfbffd6d82917cc4a4cddc0487c3187d",
    "InstanceIds": [
        "SCSI\\VEN_SAMSUNG&DEV_KLUEG8UHGC-B0E1",
        "SCSI\\VEN_SAMSUNG&DEV_KLUEG8UHGC-B0E1&REV_01"
    ],
    "Guid": [
        "be494236-785f-522f-8747-c074e384fbf8",
        "afbcca46-77bb-5f70-ad77-3704f31337f6"
    ],
    "Summary": "UFS device",
    "Plugin": "scsi",
    "Protocol": "org.jedec.ufs",
    "Flags": [
        "internal",
        "updatable",
        "registered"
    ],
    "Vendor": "SAMSUNG",
    "VendorId": "SCSI:SAMSUNG",
    "Version": "01",
    "VersionFormat": "plain",
    "Icons": [
        "drive-harddisk"
    ],
    "Created": 1708858386
}
```

サムスン電子製のUFS 3.1の規格の製品となります。
https://semiconductor.samsung.com/emea/estorage/ufs/ufs-3-1/klueg8uhgc-b0e1/ 

仕様上は最大で帯域幅が2.9GiB/sであり、Linuxコンテナ上のfioでもおおよそ仕様どおりの性能を確認しています。
(現実的には、データベースでもないのに、ページキャッシュを無視してこれだけの負荷を発生させる機会はほぼないと思われますが...)

```
zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=read  -bs=1M -size=1G -numjobs=20  -name=seqread  -runtime=60  

seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=psync, iodepth=1 

... 

fio-3.33 

Starting 20 processes 

Jobs: 20 (f=20): [R(20)][87.5%][r=2951MiB/s][r=2951 IOPS][eta 00m:01s] 

seqread: (groupid=0, jobs=1): err= 0: pid=1621: Sun Feb 25 22:05:32 2024 

  read: IOPS=149, BW=150MiB/s (157MB/s)(1024MiB/6842msec) 

    clat (usec): min=1209, max=81592, avg=6678.35, stdev=4628.14 

     lat (usec): min=1209, max=81593, avg=6678.63, stdev=4628.15 

 

zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=write  -bs=4k -size=1G -numjobs=30  -name=seqread  -runtime=60  

seqread: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 
```

シーケンシャルリードやライトの性能は次の通りです。
4 KiBのページアクセスにて、1スレッドでも数万IOPSは発揮できているようです。

```
zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=read -bs=4k -size=1G -name=seqread  -runtime=60  

seqread : (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 

fio-3.33 

Starting 1 process 

Jobs: 1 (f=1): [R(1)][100.0%][r=176MiB/s][r=45.1k IOPS][eta 00m:00s] 

seqread : (groupid=0, jobs=1): err= 0: pid=1091: Sun Feb 25 22:00:11 2024 

  read: IOPS=42.0k, BW=164MiB/s (172MB/s)(1024MiB/6243msec) 

    clat (usec): min=15, max=40488, avg=23.59, stdev=103.63 

     lat (usec): min=15, max=40488, avg=23.62, stdev=103.63 

    clat percentiles (usec): 

     |  1.00th=[   18],  5.00th=[   18], 10.00th=[   19], 20.00th=[   19], 

     | 30.00th=[   19], 40.00th=[   20], 50.00th=[   20], 60.00th=[   20], 

     | 70.00th=[   21], 80.00th=[   22], 90.00th=[   27], 95.00th=[   30], 

     | 99.00th=[   80], 99.50th=[  149], 99.90th=[  445], 99.95th=[  529], 

     | 99.99th=[  922] 

   bw (  KiB/s): min=147184, max=184704, per=100.00%, avg=168237.33, stdev=9892.22, samples=12 

   iops        : min=36796, max=46176, avg=42059.33, stdev=2473.05, samples=12 

  lat (usec)   : 20=64.05%, 50=33.50%, 100=1.70%, 250=0.41%, 500=0.28% 

  lat (usec)   : 750=0.05%, 1000=0.01% 

  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01% 

  cpu          : usr=2.56%, sys=23.10%, ctx=262145, majf=0, minf=12 

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% 

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     issued rwts: total=262144,0,0,0 short=0,0,0,0 dropped=0,0,0,0 

     latency   : target=0, window=0, percentile=100.00%, depth=1 

Run status group 0 (all jobs): 

   READ: bw=164MiB/s (172MB/s), 164MiB/s-164MiB/s (172MB/s-172MB/s), io=1024MiB (1074MB), run=6243-6243msec 

zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=write -bs=4k -size=1G -name=seqread  -runtime=60  

seqread : (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 

fio-3.33 

Starting 1 process 

Jobs: 1 (f=1): [W(1)][100.0%][w=178MiB/s][w=45.6k IOPS][eta 00m:00s] 

seqread : (groupid=0, jobs=1): err= 0: pid=1125: Sun Feb 25 22:02:28 2024 

  write: IOPS=47.2k, BW=184MiB/s (193MB/s)(1024MiB/5557msec); 0 zone resets 

    clat (usec): min=11, max=8559, avg=20.95, stdev=40.30 

     lat (usec): min=11, max=8559, avg=20.99, stdev=40.30 

    clat percentiles (usec): 

     |  1.00th=[   15],  5.00th=[   16], 10.00th=[   17], 20.00th=[   18], 

     | 30.00th=[   18], 40.00th=[   18], 50.00th=[   19], 60.00th=[   19], 

     | 70.00th=[   20], 80.00th=[   21], 90.00th=[   25], 95.00th=[   31], 

     | 99.00th=[   72], 99.50th=[   82], 99.90th=[  184], 99.95th=[  314], 

     | 99.99th=[ 1860] 

   bw (  KiB/s): min=165016, max=200984, per=99.99%, avg=188676.36, stdev=11103.88, samples=11 

   iops        : min=41254, max=50246, avg=47169.09, stdev=2775.97, samples=11 

  lat (usec)   : 20=77.19%, 50=21.19%, 100=1.36%, 250=0.20%, 500=0.02% 

  lat (usec)   : 750=0.01%, 1000=0.01% 

  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01% 

  cpu          : usr=3.71%, sys=35.19%, ctx=262238, majf=0, minf=11 

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% 

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0 

     latency   : target=0, window=0, percentile=100.00%, depth=1 

  

Run status group 0 (all jobs): 

  WRITE: bw=184MiB/s (193MB/s), 184MiB/s-184MiB/s (193MB/s-193MB/s), io=1024MiB (1074MB), run=5557-5557msec 
```

一方でランダムリードに関してはやや悪い結果となりました。
ストレージ以外ほぼ同じCX3401(NVMe SSD)では数倍のIOPSを発揮しており、明らかにレイテンシーが大きいです。
10回以上繰り返しても再現性がありました。
```
 zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=randread -bs=4k -size=1G -name=rndread  -runtime=60  

rndread : (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 

fio-3.33 

Starting 1 process 

Jobs: 1 (f=1): [r(1)][100.0%][r=8268KiB/s][r=2067 IOPS][eta 00m:00s] 

rndread : (groupid=0, jobs=1): err= 0: pid=2459: Sun Feb 25 22:46:53 2024 

  read: IOPS=2095, BW=8382KiB/s (8583kB/s)(491MiB/60001msec) 

    clat (usec): min=13, max=20517, avg=471.98, stdev=287.13 

     lat (usec): min=13, max=20517, avg=472.49, stdev=287.31 

    clat percentiles (usec): 

     |  1.00th=[   27],  5.00th=[   47], 10.00th=[   73], 20.00th=[  219], 

     | 30.00th=[  343], 40.00th=[  424], 50.00th=[  482], 60.00th=[  545], 

     | 70.00th=[  611], 80.00th=[  685], 90.00th=[  799], 95.00th=[  898], 

     | 99.00th=[ 1074], 99.50th=[ 1156], 99.90th=[ 1582], 99.95th=[ 2311], 

     | 99.99th=[ 5342] 

   bw (  KiB/s): min= 5696, max=36352, per=100.00%, avg=8405.65, stdev=3712.32, samples=119 

   iops        : min= 1424, max= 9088, avg=2101.41, stdev=928.08, samples=119 

  lat (usec)   : 20=0.27%, 50=5.61%, 100=7.29%, 250=8.91%, 500=30.90% 

  lat (usec)   : 750=33.19%, 1000=11.78% 

  lat (msec)   : 2=2.00%, 4=0.05%, 10=0.01%, 20=0.01%, 50=0.01% 

  cpu          : usr=2.37%, sys=11.67%, ctx=125856, majf=0, minf=11 

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% 

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     issued rwts: total=125732,0,0,0 short=0,0,0,0 dropped=0,0,0,0 

     latency   : target=0, window=0, percentile=100.00%, depth=1 

  

Run status group 0 (all jobs): 

   READ: bw=8382KiB/s (8583kB/s), 8382KiB/s-8382KiB/s (8583kB/s-8583kB/s), io=491MiB (515MB), run=60001-60001msec  
```

UFSは仕様上、ソフトウェアの層が厚く、I/Oの処理のオーバーヘッドが大きいそうなので、I/Oのマージが難しいランダムアクセスではこのあたりの仕組みが影響しているのかもしれませんが、残念ながらLinuxコンテナ上で詳細な分析の実施は難しそうでした。
https://media-www.micron.com/-/media/client/global/documents/products/white-paper/ufs_nvme_storage_stack_system_level_performance_in_embedded_systems.pdf?la=en&rev=9ebf709677e54c06ba8688a53b7fe006

一方でランダムライトでは1スレッドでも数万IOPSを発揮しており、CX3401(NVMe)よりも明らかにレイテンシーが低く、スループットが安定していました。
本来ソフトウェアのオーバーヘッドが低いNVMeですが、処理中に明らかにI/Oが停止しているように見える瞬間が存在するので、残容量や利用状況の関係でwear levelingやSLCキャッシュの枯渇等が発生している可能性があります。
しかしながらS.M.A.R.T.を読んだりはできないので、これ以上の深堀りは難しそうです。

```
zyake@penguin:~$ fio -filename=/home/zyake/testfio.file -direct=1 -rw=randwrite -bs=4k -size=1G -name=rndwrite  -runtime=60  

rndwrite : (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 

fio-3.33 

Starting 1 process 

Jobs: 1 (f=1): [w(1)][100.0%][w=175MiB/s][w=44.7k IOPS][eta 00m:00s] 

rndwrite : (groupid=0, jobs=1): err= 0: pid=2493: Sun Feb 25 22:48:14 2024 

  write: IOPS=42.5k, BW=166MiB/s (174MB/s)(1024MiB/6164msec); 0 zone resets 

    clat (usec): min=13, max=6629, avg=23.16, stdev=38.16 

     lat (usec): min=13, max=6629, avg=23.23, stdev=38.17 

    clat percentiles (usec): 

     |  1.00th=[   17],  5.00th=[   18], 10.00th=[   19], 20.00th=[   19], 

     | 30.00th=[   20], 40.00th=[   20], 50.00th=[   21], 60.00th=[   21], 

     | 70.00th=[   22], 80.00th=[   23], 90.00th=[   28], 95.00th=[   34], 

     | 99.00th=[   78], 99.50th=[   87], 99.90th=[  182], 99.95th=[  297], 

     | 99.99th=[ 1205] 

   bw (  KiB/s): min=151352, max=182546, per=99.70%, avg=169602.83, stdev=9447.63, samples=12 

   iops        : min=37838, max=45636, avg=42400.67, stdev=2361.85, samples=12 

  lat (usec)   : 20=46.78%, 50=50.90%, 100=2.04%, 250=0.23%, 500=0.02% 

  lat (usec)   : 750=0.02%, 1000=0.01% 

  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01% 

  cpu          : usr=3.62%, sys=38.73%, ctx=262254, majf=0, minf=9 

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0% 

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% 

     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0 

     latency   : target=0, window=0, percentile=100.00%, depth=1 

  

Run status group 0 (all jobs): 

  WRITE: bw=166MiB/s (174MB/s), 166MiB/s-166MiB/s (174MB/s-174MB/s), io=1024MiB (1074MB), run=6164-6164msec 
```

いずれにせよ、普通に使っている範囲では非常に快適です。

# Network

ネットワークアダプターはこのモデルを採用しているようです。
```
01:00.0 Network controller: MEDIATEK Corp. MT7921 802.11ax PCI Express Wireless Network Adapter
```
https://corp.mediatek.com/news-events/press-releases/mediatek-wi-fi-6-chipset-powers-new-asus-gaming-notebooks

wifi経由でのiperfの結果は次のとおりです

```
zyake@penguin:~$ iperf3 -c 192.168.10.6  --parallel 1
Connecting to host 192.168.10.6, port 5201
[  5] local 100.115.92.199 port 60286 connected to 192.168.10.6 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  27.8 MBytes   233 Mbits/sec    0   1.66 MBytes       
[  5]   1.00-2.00   sec  28.8 MBytes   241 Mbits/sec    0   1.66 MBytes       
[  5]   2.00-3.00   sec  27.5 MBytes   231 Mbits/sec    0   1.66 MBytes       
[  5]   3.00-4.00   sec  27.5 MBytes   231 Mbits/sec    0   1.66 MBytes       
[  5]   4.00-5.00   sec  28.8 MBytes   241 Mbits/sec    0   1.66 MBytes       
[  5]   5.00-6.00   sec  27.5 MBytes   231 Mbits/sec    0   1.66 MBytes       
[  5]   6.00-7.00   sec  28.8 MBytes   241 Mbits/sec    0   1.66 MBytes       
[  5]   7.00-8.00   sec  27.5 MBytes   231 Mbits/sec    0   1.66 MBytes       
[  5]   8.00-9.00   sec  27.5 MBytes   231 Mbits/sec   34   1.66 MBytes       
[  5]   9.00-10.00  sec  28.8 MBytes   241 Mbits/sec    0   1.66 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   280 MBytes   235 Mbits/sec   34             sender
[  5]   0.00-10.06  sec   278 MBytes   232 Mbits/sec                  receiver
```

並列度を上げてもほとんど結果が変わらなかったです。

```
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  75.8 MBytes  63.5 Mbits/sec   18             sender
[  5]   0.00-10.05  sec  73.1 MBytes  61.0 Mbits/sec                  receiver
[  7]   0.00-10.00  sec  62.0 MBytes  52.0 Mbits/sec   11             sender
[  7]   0.00-10.05  sec  59.8 MBytes  49.9 Mbits/sec                  receiver
[  9]   0.00-10.00  sec  93.2 MBytes  78.2 Mbits/sec   16             sender
[  9]   0.00-10.05  sec  91.0 MBytes  76.0 Mbits/sec                  receiver
[ 11]   0.00-10.00  sec  55.4 MBytes  46.4 Mbits/sec   24             sender
[ 11]   0.00-10.05  sec  53.4 MBytes  44.6 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   286 MBytes   240 Mbits/sec   69             sender
[SUM]   0.00-10.05  sec   277 MBytes   232 Mbits/sec                  receiver
```

サーバー、クライアントのCPU負荷などはかなり余裕があるようでした。
サーバー側のnetwork adaptorの性能の限界かもしれません。

# GPU

Android版 3D Markより。

```
brya 
Wild Life 
Overall score 
Average frame rate (FPS) 
7 208 
43.16 
```

# まとめ

以上のように、Chromebook上のブラウザ、Linux/Androidコンテナ上で各種ベンチマークを実施しましたが、オーバーヘッドはかなり少なく、CPU/GPUは同スペックのWindowsと同等の結果でした。
ストレージについてはUFS 3.1という主にスマートフォン向けの仕様ではあるものの、eMMCとは異なり、高速なシリアルインターフェースかつ、非同期/並列処理もサポートしていることから、通常の利用でここがボトルネックとなることはほぼないと思われます。
ランダムリードの遅さについても、現実にはランダムリードのみが連続が行われることは考えづらいこと、そもそも本来はページキャッシュが挟まることから、ここまで悪い結果にはならない認識です。