|
|
|
2025.10.01
カテゴリ：ソフト開発日誌
パソコン工房 iiyama Style-S PC に入っていた DDR4 DIMM Kingston CBD32D4U2S1MF-8 をテストした日記の続き、NVMe SSD も Kingston 製 OM8TAP4512K1-A00だ。
 Kingston OM8TAP4512K1-A00 の説明を読んでみると産業用途とある。ソフト屋さん的に言うと「組み込み」だ。 特定の OS とアプリを変えること無く稼働日に決まった時間だけ動かし続けるコンピュータで使うことを前提とした SSD だ。旧モデル、プロトタイプ、あるいはシミュレーションによって、単位時間当たりの Read/Write 転送サイズ、転送量、頻度などを見積もり、性能、寿命が十分かを評価して使う。 販売後どのように使われるか分からない PC に組み込むのは用途が合わない。 Digikey のサイトに Kingston OM8TAP4512K1-A00 のデータシート がある。Linux で採取した dmesg の出力と、nvme id-ctrl の出力を照合して、関心がある構造と性能を抜き出すと次の様になる。
もう一つ気になるのが TBW だ。総容量の約 312 倍を書き込むと寿命が来てしまう。「データ書き込みが少ない産業用途」と言う説明の背景だろう。 オークションでよく見る SSD は総容量の 20 ～ 50 倍程度書き込んだ品が多い。出品前にチェックして選別しているのか、それとも平均的な運用終了までの総書き込み量なのか。運用終了までの総書き込み量だとすると総容量の 300 倍を越えているのであれば Style-S の構成部品として十分と考えているかもしれない。 出品者の殆どが SSD でも総使用時間を重視してオークションの値付けをしている。SSD でどのくらい使い込んだかの指標は総書き込み量なんだけどな... 自分は HDD 感覚の取引は選択優先順位を下げている。 速度テストの話に入らないと... 自分で作った sequential read/write, random read/write性能を測るツールを使う。よく使われる CrystalDiskMark と比べると重いテストだ。 Linux (lubuntu 24.04, Main memory 40Gibytes, 詳細は dmesg 出力を参照) で測定する。OM8TAP4512K1-A00 を ext4 でフォーマットし、テストファイルサイズは 400Gibytes だ。 測定結果から ほぼ全体が入る様にプロットしたグラフ と sequential read の低速部分の詳細が判る様にプロットしたグラフ の 2 つを作る。 sequential read の低速部分の詳細が判る様にプロットしたグラフは sequential read の結果と sequential write の書き始めの転送速度が高い部分のプロットがグラフ外になるのでプロットされていない。 Trim 直後の sequential write の速度を見てみる。  400Gibyte の 8% 程度を書き込むまでは 2.55Gibytes/sec を越えている。主記憶 40Gibytes 一杯まで cache される範囲だ。PC 全体での速度上限でもある。ちょっと低い気もする。cache されつつも SSD への書き込みは始まっている。HMB 構成で読み込み、書き込み量とも 2 倍になっているのが原因？ 25% 程(100Gibytes)を書き込むまでは 2.4 ～ 2.45 Gibytes/sec を維持、SLC cache が効く範囲と思われる。 25% 以降は速度低下する。グラフを拡大する。77 ～ 78Mbytes/sec 程度に書き込み速度が落ちている。上位グレード SD card あるいは PC 用途 HDD 並みの速度だ。  Random read/write 後の sequential write 速度は 38Mbytes/sec まで落ちる。  速度低下の主因は Erase 処理が加わったと考えられる。 Random read/write 後の sequential read 速度は 1.5Gbytes/sec 程だ。データシートスペック速度の 21% だ。dmesg の出力に 31.504 Gb/s available PCIe bandwidth, とあるのが理由だと考えている。31.504Gbits/sec なので、約 3Gbytes/sec ある。その半分だ。HMB への書き込みと system call で指定した read 領域への書き込みが平行して行われているのでは？と考えている。  1.5Gbytes/sec あればネット閲覧、文書(校正補助付き)、集計作業、20 page 程度の発表資料作成の様な普段使いで不満を感じることは殆ど無い。数百ページある PDF 検索、AI 要約で「もう少し早ければ」と思うくらいのはず。 Random read/write の write 速度を見てみる。100k ～ 100M byte の範囲で 18Mbytes/sec ～ 140Mbytes/sec だ。高頻度で 70M ～ 140M bytes/sec になる。100kbyte 未満の書き込みは速度低下する(後述する 100 IOPs 程度のスループットが原因)。自動保存機能が働く度に瞬き程度の引っかかりを感じる程度か。  興味深いのは 128Kibyte 以上の書き込みになると、おおよそ 36Mbytes/sec に収束することだ。消去込みの QLC 書き込みになる？ Controller 内の書き込み・消去並列動作のためのリソースが少なめなのかな？ IOPs を見ていく。300kbyte 未満の書き込みで 100IOPs 前後になる write が目立つ。最高 IOPS は 40k IOPs 程で希に見られる。データシートスペックに一桁足りない。  スクレイパー (SLC → QLC, Error Collection, 保留していた Erase, その他 house keeping) を動かす周期動作起動か、loop で while (!Emergency()) {if (IsRequestsPending()) {DoRequests()} else {DoScrapeUntilTimeOut(time)}} の様な動きでもしているのだろうか？ 100IOPs 前後になる挙動は read でも目立つ。最高 IOPs は 5k IOPs でこれも出現率が低い。  random read/write の read 速度は 10Mbyte 以上の書き込みでおおよそ 520Mbytes/sec だ。希に 1Gbytes/sec あるいはそれを越える速度が出る。SATA 接続の SSD ほぼ変わらない。  DRAM less 故に (Controller → HMB), (HMB → Controller), (Controller → read 領域) という転送を順次行い、速度が出ないのだろうか。HMB ←→ Controller 間の転送が PCIe のバンド幅上限の速度と一致し、Main Memory Controller の調停か一切発生せず、順次行う転送間の時間が 0s だとすると 1Gbytes/sec 出ても良いはず。何かの調停か、Controller - NAND 間の複数 channel 面揃え待ちで 1Gbytes/sec を定常的に出せていない？ Linux kernel の cache を使う O_DIRECT flag 無しのアクセス時間について軽く触れる。200Mbyte を越える read でアクセス時間が 100 秒を越える場合が出てくる(write だと 300Mbyte を越える場合)。  こうなると Kernel source からの full build, Android の source code からの full build, 組み込み開発での yocto project full build をすると build が失敗するか途中でハングする。 ソフト開発ユースケースで見られる失敗、ハングは「普段使い」ではほぼ経験することはないはず。大規模 update、大量の画像変換、操作ログを保存しながらのゲームプレイの様な一歩踏み込んだ使い方や状況で問題を経験するのかも。 一回のテストで寿命(TBW)の 2.2% を書き込む。テストを続ける？うーん。では運用に入れる？うーん。 お気に入りの記事を「いいね！」で応援しよう
最終更新日
2025.10.01 21:08:30
コメント(0) | コメントを書く
[ソフト開発日誌] カテゴリの最新記事
|
|
