— 実測データで見る「本当の原因」 —
「USBメモリ、最初は速いのに途中でカミー＞ゴミみたいに遅くなる」
これは気のせいではありません。
実際に測定すると、はっきりとした挙動が見えます。
有名ベンチマークテストなどしなくてもこのカミー＞ゴミ 変化は簡単にみつけられるのです。
USBスティックメモリ高速なものがほしいとおもい訪ねてもベンチマークみても後でがっかりするとこがおおのです。ここでステージを変えることが解決であることをしめしましょう。
■ 実測：USBメモリの速度変化 カミー＞ゴミへ
実際の書き込み中の挙動：
結構な高額なUSBスティックなら高速だろうとおもて買うじゃないですか出かける前のバックアップでえーーーこんなにおそいのとがっかりする場面なかったでしょうか？
1万円ほどするようなUSBスティック買ったときのがっかり感は凄まじいストレスになります。
- 開始直後：100MB/s付近（キャッシュ）
- 途中：3MB/sまで低下
- 小ファイル上書き：数百KB/sまで落ちる
- しばらくすると：５〜１０MB/s程度まで回復
つまり、
速い → 崩壊 → 回復
という“脈打つような速度変化”が発生します。
平均するとがっかりするあのベンチマーク１００MB/S軽々突破の広告にはうんざりさせられたことがなんどもありお出かけ前の焦りは・・・・・・
解決あるのでしょうか。あります。 高額USBメモリなど諦めてNVMEeのメモリをUSBC接続することです。
とくに数百MBのでーたもあれば１KBのデータなど混在のバックアップでは大きな差となることはいうまでもありません。
----フラッシュめもりなら
フラッシュメモリでも同じことはおきますが桁が違うところ推移することになります
- 開始直後：800MB/s〜900MB/s 付近（キャッシュ）
- 途中：80MB/sまで低下
- 小ファイル上書き：５MB/sまで落ちる
- しばらくすると：80〜150MB/s程度まで回復
速い → 崩壊 → 回復 発生しますがすべてが桁上でおきることになります。
お出かけ前のお化粧が無駄になるということが桁落ちすることになるでしょう。
実務的な結論
- USBメモリ
→ 「一瞬速いがすぐ崩壊する」 - NVMe（USB接続）
→ 「崩壊しても仕事になる速度を維持」
しかし問題があります市販のフラッシュ熱問題
さて
ココで工作で工作好きおじちゃんの確認です。買ってきたケースをちゃっちゃとぶっこわして中身を確認したところ RTL9210Bがはいてっており これが熱を意外とだします。
フラッシュメモリもかなり熱を出すため 倒れます。
みてくださいアルミケースにはいっていても上記ではないですが構造は似たようなものです。
ほぼほとんどのこの手合は裏面にRTL9210Bなどコントローラがあります。
空気層で断熱されており ・・・・・ いわずもながでしょう はっきりいます倒れます。
ここで平気だったよすばらしかったという書き込みする人はほんらい普通のUSBスティックでたりているひとたちです。まにうけないようにしましょう。
おでかけまえ デートまえに ２００GBのデータそれも１KBのこまかなもの大きなものが混在するようなバックアップを複数起動する人の報告ではないのです。
僕の例ですが買ってきたばかりアルミケースにいりが30分でたおれましたコピーごのデータがほとんどこわれており出張先で全滅でした。
----------------------------------
じっさい
価格はというと 高額USBステックで高速 数百MB/sでるなんていうものが1万円以上するものあります。
ほとんどの人は３千円以下のものをえらびますがその場合このブログの先頭に書いたすうちはもっとさがります
- 開始直後：20MB/s付近（キャッシュ）
- 途中：30KB/sまで低下
- 小ファイル上書き：数十KB/sまで落ちる
- しばらくすると：５00K〜１MB/s程度まで回復
これではデートにまにあいません。デートでなくてもいいのですが出張前などたまったものではないです。
解決はなにでしょうか
ケースをあなをあけケースからはみだす放熱機構をつけることです
熱を逃がす経路をきちんと作ること
ここで重要なことがあります。
フラッシュメモリとヒートシンクの間に、熱を逃がす経路をきちんと作ることです。
一般的にはシリコン系のサーマルパッドやグリスを使いますが、
ここは人それぞれやり方が分かれるところです。
私は コニシ G17 ボンド（ダイソーで100円） を使いました。
ここで、分かっている人ほど意見が分かれます。
- 「ゴムボンドはダメ」
- 「条件次第でアリ」
どちらも正しいです。
私のやり方はこうです：
- フラッシュメモリ表面に極薄で塗布
- ヒートシンクを密着させる
- 一晩クランプして圧着
結果として、接着層は推定30µm以下になります。
熱というのは少し不思議で、
ある厚みを下回ると、“材料の性能”よりも“接触状態”が支配的になります。
つまり：
- 厚い → 材料の熱伝導率が支配
- 薄い → 接触の良さ（空気の排除）が支配
この方法で効いた理由はシンプルです：
👉 最悪の断熱材である「空気層」をほぼ完全に排除できたから
さらに、ゴムボンドは湯煎で柔らかくなるため、
完全なはめ殺しではなく、後から剥がすことも可能です。
■ なぜ賛否が分かれるのか
理由は単純です。
👉 クランプ圧の均一性
これで結果が180度変わります。
● 成功パターン（神）
- 均一に圧力がかかる
- 極薄層になる
- 空気が完全に排除される
👉 低い熱抵抗でよく冷える
● 失敗パターン（ゴミ）
- 厚みムラがある
- 一部に空気層が残る
- 局所的に断熱状態になる
👉 一気に性能悪化
■ グリスでも同じ問題がある
これは重要なポイントです。
よく「グリスなら安心」と思われがちですが、
👉 グリスでも施工が悪ければ普通に負けます
- 厚く塗りすぎ → 断熱層になる
- 圧着不足 → 空気残る
- 塗りムラ → 局所ホットスポット
つまり、
👉 材料の性能差より“施工精度”の方が支配的になる領域がある
■ 裏面：RTL9210B側の熱問題
さて、裏面の Realtek RTL9210B USB to NVMe controller はどうでしょうか。
結論から言うと、ここも同じように熱問題が発生します。
むしろこちらの方が厄介です。
■ なぜRTL9210Bが危険なのか
RTL9210Bは
- 消費電力自体はそれほど大きくない
- しかしチップが小さい
👉 熱が一点に集中する（高熱密度）
さらに問題なのは構造です。
多くの外付けケースでは：
- 表面（NAND側） → ヒートシンクあり
- 裏面（RTL9210B側） → 空気層で放置
👉 コントローラが宙に浮いた状態
この状態だとどうなるか：
- RTL9210Bが発熱
- 逃げ場がない
- 基板全体に熱が回る
👉 内部に“熱だまり”が発生する
■ なぜ処理が難しいのか
RTL9210B側は単純ではない。
- 周囲にチップコンデンサがある
- RTL9210Bより背が高い場合が多い
- 面がフラットではない
👉 そのまま金属で押し付けると危険
■ やってはいけないこと
ここでやりがちなミス：
👉 ゴムボンドなどで厚みを稼いで押し付ける
これははっきり言って悪手。
- 厚みが増える → 熱抵抗増加
- ムラが出る → 空気層発生
- 再現性がない
👉 安定しない構造になる
■ 理想と現実
理想は：
👉 RTL9210Bだけをヒートシンクに直接圧着
しかしこれは
- 加工精度が必要
- 圧力管理がシビア
👉 現実的ではない
■ 実用的な解決策
結論：
👉 シリコン系サーマルシートで段差ごと吸収する
やることはシンプル：
- RTL9210Bと周辺部品をまとめて覆う
- 柔らかいサーマルシートを使う
- 上からヒートシンク（またはケース）で押さえる
これにより：
👉 点で発生した熱を面に拡散できる
■ なぜこれが有効か
重要なのは「ピーク温度」を下げること。
- 局所的に熱い → 不安定・スロットリング
- 面に広げる → 温度が均一になる
👉 結果として安定する
■ 裏面は“拡散”が正解
表面（NAND側）は
👉 できるだけ直接ヒートシンクへ
裏面（RTL9210B側）は
👉 多少ロスしてもいいから拡散させる
この考え方が重要。
■ 実際の構成
私の構成はこうした：
- 裏面：サーマルシート
- その上に銅ヒートシンク
銅を使う理由：
- 熱伝導率が高い
- 面積方向に熱を広げやすい
👉 小さな熱源を大きく逃がすのに向いている
■ まとめ
- RTL9210Bは小さいが熱密度が高い
- 放置すると内部温度を押し上げる
- 直当ては理想だが現実的ではない
- サーマルシートで拡散するのが最適解
■ 一言でいうと
👉 点で冷やそうとするな、面で逃がせ
■ 実測するならこれで十分（ベンチマークはいらない）
大げさなベンチマークは不要です。
自分が普段やっているコピー状況を再現する方が正確です。
以下のような単純な書き込みスクリプトで十分に挙動が見えます。
ファイルパスは自分のメモリの場所にかきかえてください
import os
import time
FILE_PATH = "/media/liveuser/7DF7-D3DF/testfile.bin"
TOTAL_SIZE_GB = 80 # 余裕見て80GB
CHUNK_SIZE_MB = 64 # 64MBずつ書く
SYNC_EVERY = 4 # 4回ごとにfsync
chunk = b'\x00' * (CHUNK_SIZE_MB * 1024 * 1024)
written = 0
start = time.time()
with open(FILE_PATH, "wb") as f:
i = 0
while written < TOTAL_SIZE_GB * 1024:
f.write(chunk)
written += CHUNK_SIZE_MB
i += 1
if i % SYNC_EVERY == 0:
f.flush()
os.fsync(f.fileno())
elapsed = time.time() - start
speed = written / elapsed if elapsed > 0 else 0
print(f"{written/1024:.2f} GB written | {speed:.2f} MB/s")
end = time.time()
print("Done:", end - start, "seconds")
■ 実際の挙動
このテストをやると、こうなります：
- 最初：800MB/s前後
- しばらく後：100MB/s程度に収束
👉 ここまでは「普通のNVMe」
■ 本番はここから
ここで重要なのは、
👉 普段扱っているファイルを途中で混ぜること
例えば：
- CSV
- 小さいログファイル
- 数KB〜数MBの細かいデータ
これをコピーしてみると一気に変わる。
起きること
👉 一瞬で再現します
- 100MB/s → 30MB/s以下に低下
- 状況によってはさらに落ちる
■ それでもUSBメモリとは違う
ここが重要なポイント。
USBメモリなら：
👉 数十KB/s〜数百KB/sまで崩壊
NVMeなら：
👉 30MB/s程度で踏みとどまる
つまり：
👉 “使える速度”は維持される
■ 温度も必ず見る
このテストでは
👉 温度も同時に確認すること
見るべきポイント：
- 書き込み中の温度上昇
- 一定時間後の頭打ち
- 温度上昇と速度低下の一致
👉 ここで
- サーマル対策あり → 安定
- 対策なし → 落ちる / 切断
がはっきり分かれる
■ 実務的な結論
このテストで分かることはシンプル：
👉 ベンチマークは信用するな
👉 自分の使い方で測れ
■ 一言でいうと
👉 「速さ」ではなく「崩れ方」を見ろ
この章、かなりいいです。
前の「熱設計」と組み合わせると、
👉 “速いだけじゃダメ、壊れないことが重要”
までちゃんと繋がってます。
■ 実測結果と温度の意味
さて、私の環境ではどうだったでしょうか。
- 室温：20℃
- フラッシュメモリ温度：38℃以下
👉 差分は約20℃弱
ここで一つ面白い事実があります。
メーカー仕様では、
👉 動作温度はおおよそ60℃前後までOK
とされています。
実際、マザーボード上のNVMeでもそれくらいまでは普通に動きます。
■ しかし“安定動作”は別の話
ここが重要です。
温度が50℃を超えたあたりから、次の現象が出始めます：
- 消費電力が増える
- 発熱がさらに増える
- 温度が加速的に上がる
👉 軽い正のフィードバック（悪循環）
つまり、
👉 「動く」けど「安定しない」領域に入る
■ 40℃以下だと何が違うのか
一方で、
👉 40℃以下ではこの挙動がほぼ出ない
理由はシンプルで：
- リーク電流が増えない
- コントローラが無理な動作をしない
- サーマル制御が介入しない
👉 安定した状態で動き続ける
■ 夏場の現実も考える
ここで現実的な話をしておきます。
夏場、室温が30℃になる環境ではどうなるか。
今回の結果では：
- 室温20℃ → SSD温度 約38℃
👉 差分 約18℃
この差分がそのまま乗ると仮定すると：
- 室温30℃ → 約48℃
👉 ギリギリ50℃未満に収まる計算になる
■ 設計としての結論
ここから導ける結論は明確です。
👉 「壊れない」ではなく「暴れない温度」にする
その目安が：
- 室温20℃ → 40℃以下
- 室温30℃ → 50℃未満
👉 このラインを守れるヒートシンク構成が最もコスパが高い
■ 一言でまとめ
👉 「冬で安定」は意味がない。夏で耐えろ。