ふるた技工所(てっこうしょ)

久しぶりに MicroSD card を買ったので速度測定をしてみる。SONY SR-16UY だ。まぁ、何だ、自分自身にとっての「解禁」(あれから 1 年経ったんだよな)という背景もある。



パッケージは MicroSD の大きさと対比してかなり大きい。うーん、販売店さん扱いたがらないだろうな。浜田電機で買ったときはコンテナボックスに放り込まれてた。

MicroSD - 標準 SD Card アダプタが付いている。印刷が不鮮明に感じる。より鮮明なマーキングができているメーカーもある。はげ落ちるような様子は無いので、性能には全く関係がないか...



アダプタの端子面を見てみる。母材の表面仕上げの目地が分る程度の金メッキだ。メッキが薄くて不具合を感じたことも無いのでこれで良しなのかもしれない。一部の端子は引っかかりを防ぐために角丸め(斜めカット)を入れてある。細かい改良はある。



MicroSD カードを見てみる。マーキングのフォントに入念な模造品対策が有るようには見えない。"16 GB" の辺りくらいか。



MicroSD の端子メッキは厚い様に見える。くすみ、地の模様は認められず。恐らくは OEM メーカー、仕上げを入念に選定・指定していると思われる。



性能を見ていこう。性能測定に使ったツール ssdtest 2.00 (ソースコードダウンロード)は自前の物だ。Linux で性能測定をするため ext4 でフォーマットしなおしている。/dev/sdc としてカードが認識されたとして次のようにファイルシステム作成、マウントを実施した。

# mkfs.ext4 -L SR_16UY_91726340 /dev/sdc1
# mkdir -p /mnt/sdc1
# mount /dev/sdc1 /mnt/sdc1

USB bus の転送性能を上げるため、USB Mass Storage Class プロトコルで 1 度に転送するセクタ数を 2048 (1Mibyte) にする。接続は Super Speed だ。

# echo 2048 > /sys/block/sdc/device/max_sectors

テストとグラフ作成は先の ssdtest 2.00 ツールを使って次のようにした。

# cd ${work_base_directory}/ssdtest_2.00
# ./ssdtest_light_usbmems.sh /mnt/sdc1
# cd log-SR_16UY_91726340-170114134639-12519m
# ../plotlogseq_uhs1.sh -L "SONY_SR-16UY_91726340"
# ../plotlogmix_uhs1.sh -L "SONY_SR-16UY_91726340"
# ../htmlplot.sh -L "SONY_SR-16UY_91726340" > index.htm

結果のグラフを見ていく。(sw1) Sequential write の結果は ほぼ 10Mbytes/sec 出ている。パッケージに示された性能通りだろう。(sw2) 突発的な転送速度の低下がある。他の SD card でも見られる現象なので大きな問題にはならない。(sw3) 辺りで連続的な速度低下現象になり掛かっている。これも高頻度で起きていないので、問題とは考えていない。動画録画、連続撮影で 6Mbytes/sec (48Mbits/sec) 程度に抑えて使うなら、ほぼオーバーランで録画・撮影が途切れる心配は無いと言える。



事務で出先のプレゼン用にフォルダ毎コピーして MicroSD に格納する様な作業で、偶に異様に待たされる様なことは無いだろう。

(sr1) Sequential read の結果はほぼ 60Mbytes/sec 出ている。パッケージに示された 40Mbyte/sec は余裕でクリアしている。余裕分を含んでいるのは、書き込み量が増えてきた場合でも表記性能を維持するためだろうか？



MicroSD にあるファイルを丸ごと PC にコピーする作業もスムーズであろう。

O_DIRECT を付けた(すなわち OS のキャッシュを無効にした) Random access test 結果を見ていく。write のグラフに興味深い傾向が有る。(attl1) 転送長が 512 byte (1 block) の時だけ突出して access time が短い場合が観測されている。Erase block 単位で書き込んでいる最中に追加で書き込み要求が来た場合、「追加で差し込んでいる」のだろうか？それとも、ベンチマーク対策で 1 block write request だけは cache 書き込みで complete して、Flash memory への書き込みは後回しなのだろうか？この場合の電源断対策はできている？ (attl2) TAT(Turn Around Time) は 2.5ms 程 IOPS 換算で 400 IOPS となる。MicroSD ならまずまずの性能だろう。(attl3) アクセス時間の分布からみて、内部の Erase Block は 256Ki byte か。(attl4) 書き込み時間のブレが大きい感が有る。10Mibyte 連続書き込みをしても、ランダムアクセス中ならば 10 倍以上の性能差ブレがある。組み込み Linux の root ファイルシステムを配置するには少々不向きか(調査結果は別に纏めよう)。



Random access test の read を見ていく、(attl5) read の TAT は 550us ほど、IOPS 換算で 1800 IOPS だ。まずまずの性能だろう。(attl6) 内部構造あるいは処理由来の筋が出ている。Weare leveling の統計処理か、Error Collection 処理か。(attl7) read 時でも書き込みに相当する時間が掛かるケースが多く見られる。random access test は read/write 混在で行っている。先行した write が完了するまでの待ちなのか。だとすると、Flash memory 書き込み完了前に complete している (USB の CSW 返信が起きている) ことに、それとも read 時でも wear leveling あるいは scrub (エラー訂正が多い場合に書き戻しをする) を積極的に行っているのか。(attl8) 先の (attl7) とも関係する事で、read request を効率的に行おうとすると 1 度に 500kbyte 読んでも 応答時間に 10 倍の差が出る事があり、動画・音楽再生をアンダーラン無しに行おうとするには、より長く先行読み出しをする必要がありそうだ。



SD card driver(MMC) ドライバが良くできていれば、先行読み出し長を長くすれば動画・音楽再生でアンダーランを起こしにくくなるだろう。ドライバに busy polling, udelay(), mdleay() 等の CPU 空走ループがある場合は、長い転送はかえって状況を悪化させる。

ここまでのテスト結果からすると、動画撮影の記録、デジカメ撮影画像の記録、プレゼンなどで出先へファイルを持ち出す/出先からファイルを持ち帰る場面で満足のいく性能(使用感)が得られそうだ。

高音質 MicroSD だと何か違うなかなぁ...

2017.1.20 追記: OS の cache を通してアクセスした場合の結果