K75thunderbirdのブログ

どちらかというと自分の頭の整理用です。ネタとしてはモバイル、自動車、ロードバイク、電気関係やPC関係の突っ込んだ話題、ややデバイスやコンポーネント寄りの偏った内容になると思われます。

3300lmが3400lmになっても知覚できるかは別の問題

以前GXB260というHIDバーナーについて書いたことがある。
理屈は明確ではないが、純正と比較して暗いのは間違いないらしい、という結論に至ったアレである。

去年、このGXB260がモデルチェンジしていたことを知ったので、それについて少し書いておきたい。

モデルチェンジして何が変わったか。
カタログ上は明るくなった、らしい。
3300lmだった光束が3400lmに。
もっとも、数割変化しても知覚上は大差ないので、この違いを認識することは不可能と思われる。

それとは別に気になったことがある。
演色性(Ra値)が公表されていないことだ。
元々、CARMATEはRa値をパッケージに記載していた。
GXB260は、それが92となっていた。

しかし、モデルチェンジして数値の表記がなくなっている。

マーケティング上、不要であると判断されたのか。
あるいは、記載しなくても影響が小さいと判断されたのか。
どちらにせよ、一般消費者はそこまで気にしていないという判断が下ったのだと思われる。

この演色性、前にも書いたと思うが、値が高いほど自然に見えるという参考値だ。
しかし、明るく見えるわけではない。
よって、記載していないということは、演色性を落として光束の確保を優先した可能性が考えられる。
もっとも、100lm程度なら誤差とも言えるので、単なるコストダウンの可能性もあるわけだが。

それでは皆さん、ごきげんよう

Intel、キミのPCは何世代? CPUとPCHとPCIeとDMI !

何年か前に作成したPCを不満なく使用していたものの、Windows7のサポート期限が見えてきたり、AMDの頑張りで自作PC界隈が久しぶりに賑わっていることもあり、次のPCを作るための情報を集めてみた。

が、数年経ったら浦島太郎。

昔はチップセットのブロック図まで把握していたものだが、最近はそこまで気合を入れていなかったこともあり、知っているようで知らない単語がポツポツと。
知っているけど定義があやふやなものも、ちらほらと。
そんなわけで、今回はPC関連の調べものをしてみたメモである。

 

さすがにCore2Duo世代以前は放置。

一応、軽く脳内を整理すると
0.35μmのPen2から0.25のPen2になり450MHzまで、エントリー向けは0.25の300Aが人気を博して大盛り上がり。
その後Pen3が500くらいまで出てから0.18へ。L2外付けから内蔵の世代に突入。
CoppermineコアでAMDと鍔迫り合いして1.13GHzまで駆け上がるも、発熱とエラーとか諸々の事情で製品取り下げ。
並行してPen4が出るもチップセットとメモリで右往左往し、クロックだけは2.0GHzまで。
共に0.13にスイッチし、Pen3は1.4GHzまで上がるも製品終了。
Pen4は最も勢いに乗り、1.6GHzあたりから3.4GHzまでカバー。
しかしAMDがK8を出してきて大慌て、2ダイ1パッケージの爆熱伝説。まさに熱湯バースト。
救いとなるはずだった90nmは電流ダダ漏れでまさかの不発弾どころか大地雷、クロックは3.8GHzくらいで発熱に敗北、次世代の設計図を破棄。
イスラエルの優秀な頭脳が作ったBaniasコアに助けを求め、Coreシリーズへ。
その後、スイートスポットの2.4GHz近辺を中心に6600フィーバー。クアッドコアの時代到来。
65nmにスイッチして徐々にクロックも上がりつつ、次のアーキテクチャを模索。
その後、iシリーズが出てきて今に至る。

 

ということで、このiシリーズ辺りから情報収集。

まずはCPU。
1世代 知らない子
2世代 SandyBridge 32nm ソルダリング PCIeGen2.0
3世代 IvyBridge 22nm トライゲート化 PCIeGen3.0 ここからグリスバーガー
4世代 Haswell&HaswellRefresh 22nm 5世代が遅れたのでリフレッシュ追加
5世代 Broadwell 14nm 一瞬で終わった世代
6世代 Skylake 14nm 14nmの本命
7世代 Kabylake 14nm そろそろ惰性感が否めない
8世代 CoffeeLake 14nm AMDの性能に慌てて出した対抗馬

続いてチップセット
1世代 知らない子
2世代 LGA1155 6x 同ソケットで互換性あり チップセット側PCIeはGen2.0
3世代 LGA1155 7x 同ソケットで互換性あり 
4世代 LGA1150 8x 同ソケットで互換性あり 電圧レギュレーター内蔵 まだDDR3使える
5世代 LGA1150 9x 同ソケットで互換性あり m.2ソケットつきはじめたが大多数がGen2.0 DDR3使える
6世代 LGA1151 1xx 2xxと互換性あり チップセット側PCIeはGen3.0 システムバスDMI3.0 電圧レギュレーター外部化 m.2ソケットがGen3.0x4 DDR4対応 DDR3対応製品も多少あり
7世代 LGA1151 2xx 1xxと互換性あり m.2ソケットが増えた
8世代 LGA1151 3xx 2xx以前と互換性なし(リザーブピンを電源に変更) チップセット側のレーン数増加

 

情報を漁っていて分かりにくかったのがPCIeのレーン数と世代。
16レーン、20レーン、24レーンといった数値と、Gen2や3といった世代に関する情報がイマイチ整理されていない。
が、情報をまとめてみれば特に複雑でもなんでもない。

結局のところ、メインストリーム向けのCPUでは、GPU向けに16レーンのPCIeバスが確保されており、これは不変だ。
言わばCPUからのネイティブPCIeバスだ。

そして、CPUからチップセットへのシステムバスは、DMIと呼ばれるものが使用されている。
DMI≒PCIe なので、完全にイコールではないものの、同じだと考えて問題ない。
レーン数は4である。

そしてチップセットから20レーン前後のPCIeバスが(最新のチップセットであれば)出ている。
ここに各種コントローラーやGPU以外のデバイスが接続されることになる。

Kabylakeでレーン数が20から24に増えた、などと書かれているのは、DMIの先のチップセット側の話であって、CPU側は何も変更されていない。
16レーン+DMI(実質4レーン)のままである。

ここまで読んでお気づきのとおり、チップセットには4レーンしか割り当てられていないのに、チップセットの先には5倍も6倍ものレーン数がある。
帯域としては全く釣り合っていない。
しかし、全デバイスが同時にCPUにアクセスすることはないという前提条件で設計されているのだろう。

 

そして、PCIeやDMIの世代について。
GPU向けのPCIeはIveBridgeでGen3.0になり、以降変わっていない。
DMIはSkylake(6世代の1xxチップセット)でGen3.0になり、以降変わっていない。

GPU向けは早々に3.0化したものの、チップセット側の対応は随分と遅れたことになる。

 

次に、PCIeやDMIの速度について。
PCIeは1レーンあたり(片方向)の速度がGen1.0で2.5Gbps、2.0で5Gbps、3.0で8Gbpsである。
ただし符号化により実際の転送レートは多少低い値となる。

Gen2.0までは「8b/10b」なので8割となる。
よって、転送レートはGen1.0で2Gbps、2.0で4Gbpsである。

Gen3.0の符号化は「128b/130b」なので、8*128/130=7.8769230769230769230769230769231Gbps・・・である。
面倒なので、8Gbps弱と考えておけばよいだろう。

例えば、DMIは4レーン使用しているので、Gen2.0なら片方向16Gbps(2.0GB/s)となる。
したがって、チップセット側に16Gbpsを超える速度のSSDを接続しても性能が発揮できない。
現行のNVME版SSDの帯域はPCIeGen3.0x4なので、DMI3.0採用の裏にはNVME版SSDの存在があったことは想像に難くない。

とはいえ前述のとおり、DMI3.0であっても決して十分な帯域であるとは言い難い。
また、m.2スロットを2つ以上搭載したM/Bが増えているため、DMIの帯域が再び問題視されるのは時間の問題だろう。

 

こうして見てみると、レーン数だけは十分にあるように見えるPCIeも、意外と制約が多いことに気づかされる。
速度だけ考えれば、GPU向けのCPUネイティブなPCIeバスを使用するのが近道である。
しかし、GPUの性能への影響や、CPU側のレーン分割の制約、さらにM/Bの設計上の制約などもあり、簡単ではない。

 

このような悩みを軽減できるのが、X299チップセットやX99チップセットだ。
X299については現時点で興味がない(高すぎる)ので置いておいて、X99(というかLGA2011-v3プラットフォーム)について触れてみる。

このプラットフォームでは、6コア以下は28レーンしかないが、8コア以上は40レーンを使用可能だ。
16レーンだのDMI3.0だの悩んでいたのが馬鹿らしく思える広帯域である。
もちろんM/B設計上の制約はついて回るものの、使用上の自由度やポテンシャルは遥かに高い。

欠点があるとすれば、X99そのものはDMI2.0接続であるので、チップセットから先の部分に接続されたデバイスに関しては速度的に期待しない方が良い、ということくらいだろうか。
また、チップセットから出ているレーン数は8しかない。この辺りは設計の古さが隠せない。
とはいえ、使用時に「X99はDMI2.0接続で、帯域は片方向16Gbps(2.0GB/s)」ということを把握して使えば、それほど問題が生じることはないはずだ。
まして、ドライブ間のデーターコピーなどであればDMAなので、ほぼ処理はチップセット内で完結する。
DMAであればDMIの速度は関係ない・・・はずだ。
影響するのはコントローラーが接続されているPCIeの世代とレーン数の方であろう。

符号化の話が出たので、ついでに参考値を記す。
 SATA6.0Gbpsは、符号化(8b/10b)を除けば転送レート4.8Gbps(600MB/s)
 USB3.0は5Gbps、符号化(8b/10b)を除けば転送レート4.0Gbps(500MB/s)
 USB3.1(Gen2)は10Gbps、符号化は「128b/132b」なので、9.6969Gbps(1212MB/s)

 

というわけで、昨今のCPUやチップセットに関する情報を整理してみた。

それでは皆さん、ごきげんよう

放熱は物量がモノを言う、という当たり前の結論

NVMeタイプのSSDで発熱と戦っている方々、いかがお過ごしだろうか。
冬になって、ほっと一息ついているのではないだろうか。
そんなわけで、今日は放熱について。

 

放熱と言えばヒートシンク、ヒートパイプ、はては水冷から液冷からガス冷まで様々あるが、今回はもっとも単純で簡単なヒートシンクに限定したい。

ヒートシンクの素材にはアルミ、あるいは銅が使用されるが、違いは重量だけではない。
銅の方が熱伝導率は良いのだが、アルミの方が自己放熱性が良い。
そのため、パッシブヒートシンクや風量の少ない状態ではアルミの方が放熱性能が高かったりする。

これに関しては、SSDに装着するヒートシンクの比較記事で、同じサイズに切ったアルミ板と銅板ではアルミの方が低温だったという結果が出ている。
たしか記事はエルミタージュだったと思う。
熱伝導率に優れる銅であっても、風がなければ性能を発揮できない例である。

余談だが、自動車のラジエータもアルミ製と銅製(黄銅だったはず)がある。
通常はアルミ製だが、社外品のアフターパーツではアルミ製ではないものもあるのだ。
これに関しては、走行時の性能は後者が高く、渋滞時は前者が高い、という話も聞いたことがある。
これも素材の性質を裏付けるものと言えよう。

さらに余談だが、普通のアルマイトとブラックアルマイトで性能差はあるのか?という話を思い出した。
ヒートシンクの雄であるアルファのページで読んだ記憶があるが、これはブラックアルマイトだそうだ。
ただし、周囲の熱源から赤外線で熱を吸収しない環境にあることが条件だとか。
なんとも面白い話である。

はては、ファンはヒートシンクに対して吹き付けるのが良いのか、吸い出すのが良いのか、といった話もあるが、それは脱線しすぎるので置いておくことにする。

 

さて、自己放熱性に優れるアルミ製のヒートシンクであるが、同じアルミ製であるなら性能差はどこから生じるのだろうか。
複雑な形状による表面積の拡大は当然だが、一連のSSDヒートシンクのテストを見ていると、ヒートシンクの重量が重要であるように思える。

たとえば、変換ボードを使って高い冷却性能を発揮している有名な製品として、KryoM.2がある。
ちなみに日本語でどのように発音するかは不明である。
くりょー?

それはさて置き、この製品はそれほど複雑な形状のヒートシンクではない。
隣のスロットとの干渉を避けるため溝も浅い。
しかしテストしてみれば圧倒的な冷却性能を示す。

これに対して、変換ボードを使わないSSDサイズのヒートシンクの場合、縦方向に拡大して表面積を大きくした製品であってもKryoには及ばない。
接触面が熱伝導両面テープとシリコンの違いなのか?とも思ったが、そこまで相関性があるようにも見えない。

そのため、最大の違いはヒートシンクの重量ではないか、と思う。

NVMeとはいえSSDが発する熱量はそれほど大きなものではない。
まして、単体のヒートシンクとKryoのヒートシンクでは重量に何倍もの違いがある。
ヒートシンクの熱容量が増えれば、吸熱できる量も増える。
ただし熱伝達速度の問題もあるので、やみくもに表面積を増やしても実際に使用される面積は少ないのだろう。
熱源に対して、その熱量に見合った分の吸熱素材が、妥当な熱伝達の範囲内に十分な質量を持って存在していることが重要だと考えられる。
それにより、安定した冷却性能を獲得しているのだと考えるのが自然だ。

そうであれば、単体のヒートシンクも肉厚で重量化すれば性能を上げられると思うのだが、マザーボードに直接実装する関係上、製品のサイズには制限がある。
また、重量の増加によって使用中に脱落する危険も増す。
危険回避のためには確実に固定しなければならないが、実装上難しい。
そのようなわけで、簡単にヒートシンクを追加して得られる冷却性能は、それなりのものでしかない。
それが現状のようだ。

ただ、少しでも高い放熱性能を得たいのであれば、少しでも重たいヒートシンクを選ぶというのは判断基準としてはアリだろう。
確実に固定できれば、という但し書きつきで。

個人的には、過去のCPUクーラーを加工して格安かつ激冷を実現できないかと考えていたりするのだが、固定方法を確立できないのが最大のネックだ。
いっそのことPen4世代のCPUクーラーにSSDを2個並べて貼り付ければ相当強力に冷却できるはずだが、NVMeのSSDを2つ並べて使用できるマザーがなければ無理な話である上に、固定する方法を考えつかない。

ヒートシンクを見ているとゴムバンド(シリコンバンド)でSSDと束ねるような固定方法もあるが、耐久性はともかく見た目が悪い。
まして、テープで固定するような製品は簡単に浮きそうで怖い。

ここはパッシブヒートシンクを諦めてファンを使用すべきなのかもしれないが、NVMeなSSDは幅22㎜しかない。
しかしマザーボードとの干渉も考えると、それほど大きなファンは使用できない。
そのようなわけで、マザーボードに直接実装する場合はあまり効果的な冷却方法がない。
「何もしないよりマシ」と考えるしかないのかもしれない。

他に考えられるのは、PC内を負圧にしてサイドパネルからSSD周辺にダクトを作って風を当てる方法くらいだろうか。
問題は、エアフローが変わる(乱れる)ことで、他の熱源への影響があること。
数Wのために数十Wの熱源を無視することはできないので、難しいところだ。

あるいはSSDの場所を風洞化して、そこにブレードサーバーのごとく横方向に風を通せば・・・とも思ったが、それこそM/B上でユーザーができる範疇の話ではない。
アイディアだけはあるが、実現は難しい。

 

結局のところ、お手軽冷却はそれなりの結果しか得られず、性能を求めるのであればPCI-Eのレーンとスロットを犠牲にして変換基板を使うしかない、という現状を裏付ける結論となった。
そして、物理特性に逆らうのは面倒であるということだ。

 

 

取り留めの無い結論になってしまったが、こんなところで。

それでは皆さん、ごきげんよう

 

SSDでコントローラーが重要である理由

前回は、チップレベルの話について。
今回は、それを制御するコントローラーの話に移る。

 

最初に認識したいことは、NANDメモリは使いにくいメモリだ、ということだ。
何故か。
まず、NANDメモリには書き換え回数に制限がある。
これだけでも面倒だ。
そして、書き換えるときはブロック単位で書き換えなければならない。
更に面倒だ。

そう、HDDのようにセクター単位で書き換えることができないのだ。
そのため、あるファイルに1bitの修正を加えただけで、そのファイルが書き込まれたブロックを読み出し、ブロック内を消去し、修正後の情報を書き込むという動作をしなければならない。
限りある書き換え回数が必要以上に減ってしまう仕様、それがNANDメモリだ。

では、そのブロックはどれくらいの単位なのか。
手持ちのSSDで、予備ブロックと無効化された容量から計算したところ、512GBの製品で2MB、960GBの製品で4MBのようだ。
おそらく、製品の容量に応じてブロックの粒度は異なると思われる。
参考までに、上の2製品はCrucialで、コントローラーはMarvellで、NANDはMLCである。

NANDメモリの仕様は上に書いた通りなので、下手な使い方をすると頻繁に同じ場所を使用することで早期に寿命を迎えることは想像に難くない。
そこで、コントローラーには「ウェアレベリング」という機能が搭載されている。
名前のとおり、摩耗の平均化だ。
ここで改めて説明しておくと、ブロックの書き換えには 読み出し⇒消去⇒書き込み の3ステップが必要である。
書き込む先として使用頻度の少ないブロックを優先的に使用し、書き換えが特定のブロックに集中しないようにするのが、この機能の目的だ。

しかし、空き容量が少なくなってくると、ウェアレベリングに使用できる領域が減ってくる。
極端な話、空き容量が数%といった状態で使用していると、書き換え対象のブロックを分散させることが難しくなり、どうしても特定のブロックを酷使することになる。
NANDメモリは読み出しこそ高速なものの消去には時間がかかるため、空き容量が減少すると消去待ちの時間が表面化する。
これの顕著な例が「プチフリ」である。

このような時、消去に要する時間を隠蔽し、パフォーマンス低下を抑制するための手法が「オーバープロビジョニング領域」である。
あらかじめ一定量の消去済みブロックを用意しておく、というもので、別名は余剰領域である。
漢字の方が分かりやすいだろう、読んで字のとおりだ。
ユーザーが使用できない領域を事前に確保しておけば、パフォーマンス低下を防ぐことができ、ウェアレベリングも行いやすい。

なお、容量が256や512や1024といった数値ではなく、240や480や960といった数値になっているSSDは、出荷時にオーバープロビジョニング領域として何GBか確保されていることになる。
また余談であるが、SSDパーティションを作成する際に敢えて未使用領域を確保しておくという使い方も、同じ効果をもたらすようだ。


しかし、ここで疑問には思うかもしれない。
パーティションで区切ってしまえば、その領域は一生使われないままなのではないか?と。
しかし、これに関しては全く問題とはならない。
何故か。
確かに、HDDのような媒体であれば論理アドレス物理アドレスは一致しているため、一度パーティションを区切ってしまえば当該領域は物理的に未使用となる。
これに対してSSDの場合は論理アドレス物理アドレスが一致しない(参照テーブルはコントローラーだけが持つ)ため、PCから見て同じ場所であるとしても、物理的に同じ場所であり続けることはない。
つまり、当該領域はウェアレベリングにより移動し続けることになるため、未使用領域が固定されることはない。


さて、NANDのチップレベルでの耐久性低下については前回書いたとおりだが、コントローラーも手をこまねいているわけではない。
NANDの多値化に伴ってECCを強化し、仮にある程度までセルが劣化してエラーレートが増えたとしても問題なく使用できるようにしている。
これにより、同じNANDを使用していてもSSDとしての耐久性を上げることができる・・・とされている。

 

まだ書き足りない点もあるが、脳内メモとしては以上としたい。
Trimの話や、NVMeタイプの発熱の話、仮想SLCキャッシュの話、TLCの書き込み速度の話などについては、別途書くことにしたい。
KryoM.2に関連した話も、少しだけあるかもしれない。

 

 

それでは皆さん、ごきげんよう

今、SSDの信頼性と寿命を考える(NANDメモリ編)

このBlog開設から1年経ったというメールが届いた。
大した内容は書いていないが、これからも脳内整理を兼ねて時々情報を書き留めておきたい。

 

話は変わって、SSDだ。
既に使っておられる方が大半かと思う。
高速であり、耐衝撃性に優れ、低発熱で、非常に優秀なデバイスである。

現在、速度はI/Fの限界に迫るものを獲得し、アプリの起動時間はすでにこれ以上短縮できないまでに飽和している。
この点において登場当初から飛躍的な進歩を遂げたことは疑う余地がない。

しかし、上に挙げたような特徴を本当に信じ続けて良いだろうか。
今のSSDは昔のSSDと同じ扱いで良いのだろうか。
SSDに使われているデバイスの観点から考えてみたい。

 

SSDが一般的なデバイスになったのは、一つにはIntelが自社製品としてSSDを発売したことが大きかったのではないだろうか。
当初、SSDと言えば「プチフリ」という単語に表されるように、安定性に欠けるデバイスである感が拭えなかった。

確かに速い。しかし扱いが難しい。

そのような状況に対してIntelが高速性と安定性を兼ね備えた製品を投入し、割高であるにもかかわらず人気を博した。
以来、徐々にではあるが、極端に性能の悪いSSDは駆逐されてきたように思う。

そのIntelの製品投入と前後して、SSDを低価格にするための技術革新があった。
フラッシュメモリ(NAND)の多値化である。

それまで、NANDの1セルに1bitしか記録することができず、SSDが高コストである主因となっていた。
これが、1セルに2bitを記録できるようになったことで、単純に同一面積に倍の容量を記録できるようになり、文字通りコストが半減した。
非常に大きな進歩と言える。

しかし、喜べる事ばかりではない。
引き換えになったのは、NANDの耐久性である。

今までは、セルに記録された情報が0か1(2値)が見分けられればよかったため、相当劣化したセルでも何とか使用できた。
しかし、2bit記録の場合は0か0.33か0.66か1(4値)を見分ける必要がある。
そのため、セルが劣化してきた場合に数値が判別できなくなるまでのマージンが少ない。

では、NANDメモリはどれくらい使ったら寿命となるのか。
これは単純に書き換え回数に比例する、と考えてよい。
 ※正確には読むだけでも多少影響があるようだが事実上無視できると考えている

1bitの頃、SLCと呼ばれているNANDメモリは、10万回とも言われる高い耐久性を持っていた。
これが2bitになり、MLCと呼ばれるNANDメモリは、一気に5000~1万回程度の耐久性に落ちてしまった。
今は3bit記録のNANDメモリも登場し、これに至っては3000回を下回るレベルとも言われている。

 

もっと悪いニュースがある。
半導体は年々微細化し、それによりロジックの大規模化を進めてきた。
IntelSSDを投入した当初、NANDメモリは50nmまたは34nmといったプロセスルールで製造されていた。
それが今や15nmに到達している。
問題なのは、微細化するほどNANDメモリの耐久性が落ちることだ。
つまり、多値化と微細化により、NANDメモリの耐久性は加速度的に下降し続けていることになる。
実際、15nmに到達したのは2年ほど前になるが、それ以降更なる微細化が進んでいないことは耐久性に致命的な影響があることの裏づけと言える。

実際、現在のMLCタイプでも3000回という値を聞くこともあり、TLCに至っては1000回という話もある。
使い方によって耐久性は上下するので一概には言えないが、基本的に耐久性は新しい世代ほど落ちる傾向にある。
これだけは間違いない。

 

ここまでの話を見る限り、NANDメモリは古いほど耐久性があって安心できることになる。
では、今のSSDは安心して使用できない欠陥品なのだろうか。
答えは否、だ。

これに関しては良いニュースがある。

微細化を進めていたNANDメモリだが、微細化しすぎて壁に突き当たったのだ。
前述のとおり、ここ2年ほど微細化は行われていない。

だからなんだ?と思うかもしれない。
が、話はこれからである。

これ以上微細化できない(微細化しても十分な性能が確保できない)と知ったメーカーは、今まで平面方向に作成していた半導体を立体方向に作成し始めた。
生産コストの安い従来型のNANDメモリを作りつつ、積層プロセスで3次元化したNANDメモリも製造するのが、ここ数年の各社のトレンドとなっている。

勘違いしやすいのは、この3次元化は、積層パッケージとは別の話であることだ。
積層パッケージは、メモリチップをパッケージ化する際に何枚ものダイを積層し、チップの実装個数を減らす技術だ。
これに対して積層プロセスは、ダイ作成時にトランジスタを立体的に作成するもので、物理的には1枚のダイである。
ただし、共に組み合わせることは可能なので、積層プロセスで作成したダイを積層パッケージにした製品は存在する。
ややこしいが、分けて考えてほしい。

話を戻すと、3次元NANDは64層くらいまで実用化されており、100層近くまでは実用化が見えているのが現状だ。

で、多層化すると何が良いのか。
問題はここである。

それは、多層化することで、同一面積で飛躍的に記憶容量を増やすことが可能になったのと同時に、半導体の微細化を少し前のレベルまで戻すことが可能になったことだ。
語弊を恐れずに言い方を変えれば、古いプロセスルールで耐久性を確保しつつ、減ってしまった容量を立体方向で稼ぐことができる。
その結果、耐久性(書き換え可能回数)と容量を両立させることができる。
これがNANDメモリにとっての3次元化の最大のメリットだ。

ただ、メーカーは具体的なプロセスルールや書き換え回数などの情報を明かしていないため、どの程度改善されたかは不明だ。
各社の論文を調べれば分かることもあるかもしれないが、そこまでの確認を行っていないのは勘弁していただきたい。
しかし、著しく減少していた耐久性が3次元化によりある程度のレベルまで戻ったことは事実である。
これが、現状のNANDメモリである。

 

ここまでが、NANDメモリについての話となる。
大容量化の影には、耐久性とのトレードオフや構造の変更があったのだ。

次回は、そのNANDメモリを制御するコントローラーの話について書きたいと思う。

 

それでは皆さん、ごきげんよう

気難しいサイバーナビ

今日び、融通の利かないナビで動画を再生するとか時代遅れもいいところ・・・なのは承知だが、そこにある機能を使えないのは悔しいのも事実なので、メモとして記しておく。

何か、誰かの役に立てば。

 

 

現行のサイバーナビFMCして 1DIN+1DIN の製品が消滅してしまったので、車のレイアウト上FMC前のサイバーナビを使っている人も多いはず。

現在自分が使用しているのはAVIC-VH0009である。

 

 

対応フォーマットについて、公式からの情報は次のようになっている。

pioneer.jp

 

VC-1ビットレートは低すぎるので無視するとして、MPEG4かAVCが一般的だろう。

MPEG4 であれば Advanced Simple Profile で 720x480@30fps で 平均4MbpsまでOK。

AVCであれば Baseline Profile で 720x480@30fps で 平均2MbpsまでOK。

 

正直なところ、これだけでは情報が不足していて失敗するのは目に見えているので、適当に情報収集。

XMedia Recode 使ったらイケた、というざっくりした情報をつかんだので、いつも使っているツールでもあるので、これで設定を詰めていくことに。

 

このソフト、メーカーや用途別に相当数のプリセットを持っている。

その中に pioneer があるので、それを適当に使えば良い、ということだった。

ということで、デフォルトのまま変換。

ナビで認識されず、見事失敗。

 

ネットの情報など、所詮この程度です。

ちなみにどうでもいいことですが、ソースは閣下が中野でアレしたアレのアレです。

 

とりあえずメーカー別プリセットと決別し、MPEG4で試してみる。

平均ビットレート1500Kbpsで変換すると、一応再生可能だった。

が、ブロック状に画面が崩壊するので、ビットレートの変更が必要と判断。

PCでは崩壊しないため、情報過多の可能性を考え、ビットレートを1200に。

結果、更に崩壊が進行。

MPEG4は実用にならぬ。

 

そのようなわけで、メーカー別プリセットで失敗したAVCを使うしかないようだ。

普通にAVCで変換。

当然のように失敗。

ここで疑問に思ったのが、プロファイルレベルの4.1とか3.1とかの値である。

考えてみれば、pioneerのプロファイルでは3.1であった。

そしてAVCのデフォルトでは4.1である。

もしや・・・と思い、3にしてみると成功。

2.2でも成功。

2.1は解像度がVGA以下に落ちているようなので、そこで確認を打ち切り。

ということで、プロファイルレベルが2.2~3までであれば再生できることを確認。

 

その後、ビットレートを平均1500Kbpsから1200Kbpsに落としたものの、画面の崩壊なども起きないため、これくらいの低ビットレートでも問題はないのかもしれない。

 

 

さて、話をまとめてみる。

MPEG4はビットレートのわりに再生品質がダメなので論外とする。

VC-1ビットレートが低すぎるので問題外。

実質使えるのがAVCのみ。

AVCであれば、Baseline Profile@L2.2~L3 で 720x480@30fps で 平均2Mbpsまでが再生可能。

 

 

それでは皆さん、ごきげんよう

CMOSと動画の関係は面白い!

一眼レフや大面積なイメージャーを使ったカメラの動画対応状況を調べていたところ、
ルフレーム? 全画素読み出し? ピクセルビニング? 画素混合? 画素加算? クロップ? ラインスキップ? ドットバイドット?
このような感じで疑問符が大量に浮かんできたので、ざっくり調べたメモを残しておきます。

 

ルフレーム
ニコンのDSLR説明文で見ることが多い。
ルフレームと言われて思い出すのはCCDだ。
一般的なインターラインCCDは受光部と伝送部が平面配置、フルフレームCCDは受光部と伝送部が立体配置、よってインターライン式よりも感度やDレンジ特性の面で有利というものだった。
正確には立体配置というよりバケツリレーのようなイメージらしいが。
が、今回はCCDではなくCMOSである。
どうも、35mmフィルムフルサイズフォーマットの意味で使用されているようだ。
撮像素子の方式ではなく、面積の話であった。
微妙に紛らわしい。


全画素読み出し
読んで字のごとく、そのままの意味。
動画生成時に対象範囲を全画素を読み出し、映像エンジン内で縮小処理することで、モアレやジャギーなどが少ない。
現状、最も理想とされる方式がこれ。


ピクセルビニング or 画素混合 or 画素加算
これらは、ほぼ同義と考えていいはず。
読み出し前にイメージャーで一定数の画素を足し合わせて仮想的な1画素を生成し、信号を映像エンジンに出力する。
CCDの場合、飽和信号量の関係でDレンジが狭くなる弊害があったはずだが、CMOSではどうなっているのか。
気になるので今後確認してみたい。


ラインスキップ
恐らく、もっとも嫌われている間引き方式。
5Dmk2やD800が有名。
もっとも、D800では3ラインごとに読みだして画像生成してから最終的に縮小処理をかけているらしく、mk2よりマシという話で、ラインスキップが全て同列で無能というわけではなさそう。
とは言え、ジャギーが出やすいので積極的に使用する理由はない。


ドットバイドット
拡大も縮小もせずに済む領域のみ読みだすことで、後処理を最小限に抑える方式。
処理が軽く、そこそこキレはあるが、画角が狭くなり、絶対的な解像度・ノイズの点で全画素読み出しに及ばない。
D5とか1DXmk2とか5Dmk4の4K対応がこれ。
EOSについては画角について情報が少ない(ほぼない)ので、買ってから後悔した人は多いのでは。

 

というわけで、全画素読み出しがベスト。
次点で画素加算かドットバイドット。
ラインスキップが許されるのは小学s(ry

 

 

それなら、何故全画素読み出しが普及しないのか。

原因は2つ。
1つは信号処理の速度の問題。
もう1つはCMOSの動作速度の問題。


前者は理解しやすく、一般的だと思われる。
考え方は簡単。
4K30pが可能なら、2K120p(FHDと書くのが面倒なので2Kと表記)が可能、という単純計算である。
つまり、1秒間に処理するピクセル数を判断材料にする。
細かいことを言えばイコールにはならないだろうが、大雑把な考え方としてご理解いただきたい。
もっとも、この辺は半導体を物量投入し、消費電力と発熱を二の次にすればどうにかなるレベルの問題である。


問題は後者。
これに関しては、メーカーはマーケティング上マイナスになる事を話さないので、メーカーの発言は正確に理解する必要がある。
ただ、少し考えれば難しいことはない。

例えば・・・
RX100M5の動画は全画素読み出し方式である。
これはある意味正しい。
しかし、メーカーは「全画素読み出しによる4K動画記録が可能」と言っているにすぎない。
したがって、2Kでは(恐らく撮影モードによっては)全画素読み出しではない。

フレームレートの方面から考えると理解しやすい。
4Kのフレームレート上限は30fpsである。
2Kのフレームレート上限は120fpsである。
全画素読み出しする場合、対象となる範囲の画素を全て読み出すので、フレームレートと動画の解像度は関係がない。
つまり、記録解像度が4Kだろうが2Kだろうがそれ以下だろうが、全画素読み出しが可能なのは30fpsまでなのだ。
よって、何らかの方法で読み出す画素数を減らさない限り、120fpsは不可能となる。

余談だが、RX100系ではなくRX10系の場合、同じ世代(RX100M4世代)であってもセンサーの読み出しスピードを60fpsに高速化したと明記しているので、消費電力や発熱などの問題さえクリアできれば、全画素読み出しで60fpsは可能なのかもしれない。
この辺り、発売時の情報を見る限りは読み出しに使用するフロントエンドLSIの性能次第のようだ。
ただし、RX10系の連写速度はRX100系のそれと同じなので、動画に直接関係しないのかもしれない。
しかし、連写速度については映像エンジンの制約の可能性もあるので判断はできない。
ただ、一つ言えることとしては、CMOSから映像エンジンへのデーター転送はフロントエンドLSIの性能で引き上げることが可能、ということは事実のようだ。

ちなみに、CMOSの読み出し速度が積層化で5倍になったというのは受光素子からDRAMへの転送部分であって、最終的にはCMOS内部のDRAMから外部へデーター転送しなくてはならないので、ネックになっているのは外部への転送の部分である。
このチャンネル数を増やしたりクロックを上げたりできれば、一気に高速化が進むであろうが・・・今はまだ布石の段階か。

もう一つ余談だが、SONYEVF搭載機でEVFfpsを60から120に切り替えできるものがある。
これは解像度の低下を伴うと書かれているので、上に書いたような全画素読み出し速度を高速化する話とは別と考えて良い。

 

 

閑話休題
では、全画素読み出しの限界解像度はどのあたりにあるのか。

ただし、業務用・映画用などの桁違いに物量投入されているものを除く。
また、センサーサイズによって駆動周波数限界は違うはずだが、その辺の差異も無視する。


CMOSの高速性ということで考えると、上にも挙げたとおりSONYの積層系のCOMSセンサーがある。
RX10系は上に書いたようにセンサー読み出しが60fps、ただし静止画連写性能は上がっておらず、証拠不足のため保留。
よって、確実なのは全画素読み出しで4K30pのところまで。


他にも、2000万画素クラスのカメラで、全画素読み出しで4K30pを実現しているものはある。
そのため、普通に設計されたCMOSセンサーであれば、この辺り(2000万画素クラス、全画素読み出し30fps)が無難なところに思える。

APS-CセンサーのSONYのαで2400万画素で全画素読み出しのがあったのでは?という話もある。
確認してみると、24fpsなら全画素読み出しで2.4倍の画素数からの縮小処理となるものの、30fpsでは1.6倍の画素数からの縮小処理であるとされている。
画素加算か?と思いきや、単にクロップしているだけのようだ。


ここで大本命。
動画対応が最も進んでいるカメラといえばGH5だろう。
これは全画素読み出しの60p・・・という話をよく聞く。もし事実なら同世代の倍速近い性能を持つことになる。
これはとんでもない話だ。

しかし、GH4との比較で「イメージセンサーからの信号読み出し速度は1.7倍」とされている。
これはimpressやITmediaなどのリリース記事に書かれており、間違いない情報と言っていいだろう。
ちなみにGH4はGH3の2倍となっており、2K60pから4K30pに進歩しているので、公称値通りの変化だった。

このような数値を公表する場合、メーカーは自分に有利になるよう情報を展開するのが常である。
更に、画素数が1600万画素から2000万画素に増えていることを考えれば、4K30pが4K60pになるわけがない。
もっとも、単にフレームレートが1.7倍になったとしても、51fpsであり60fpsには届かない。

また、4Kフォトは60fpsであるのに対し、6Kフォトの記録は30fpsにとどまる。
60fpsでの全画素読み出しに成功しているのであれば、30fpsではなく60fpsを実現していても良いように思う。
もっとも、これはコーデック(H265)や映像エンジンの問題も考えられるが・・・。

さて、どう考えればよいのか。

いろいろ読み返しているうちに、そもそも思い違いをしている事に気づいた。

GH3もGH4も、動画撮影時の読み出し性能が全速力というわけではないのだ。
GH3は連写性能20fps、GH4は40fps。
共に1600万画素なので、読み出し性能は2倍である。矛盾は無い。
とすると、計算上はGH4で全画素読み出し4K30pが可能である(16:9エリアなら47.4fpsまで)ことになるが、映像エンジンにおける縮小処理が追いつかなかったと解釈すべきだろう。
あるいはイメージャーの発熱の問題があったのかもしれない。

なお、GH5は連写性能が12fpsと控えめになったので、この尺度での比較はできない。
が、1.7倍という情報を元に計算すると、40*1.7/2000*1600=54.4fpsとなる。
60fpsに届いていない!と焦るが、これが全領域を読み込んだ場合である。
16:9のエリアに絞れば、64fpsとなるので、無事に目的の性能を達成している。

余談であるが、GH5ではセンサー読み込み速度が2.5倍になり、ローリングシャッター歪が低減されたというメーカーの方の発言がある。
これはどのように解釈すればよいだろうか。
動画撮影に関しての発言だったことを考えれば、画素数が増えたことと60fps化を掛け合わせて2.5倍となっている、という趣旨と判断するのが無難だろう。
2000/1600*60/30=2.5
前述のとおり、イメージャーの全力駆動時の速度は1.7倍であるので、限定された条件下での速度が2.5倍というわけだ。
もっとも、GH4は4K撮影時に全画素読み出しではないので、厳密に言えばこの発言は正確とは言えないが、同じ土俵で比較するならば・・・と考えれば理解はできる。
また、いくら速度が高速化しても画素数が増えて相殺されれば時間軸方向での改善は無いのと等しいので、読み込み頻度が2倍になったと表現するのが親切だろうか。

よって、紆余曲折したが、GH5は全画素読み出しで4K60pを実現していると結論できる。
他社が 2000万画素で24fps、1700万画素で30fps、などと言っている最中に1700万画素で60fpsである。
素晴らしいと言えよう。

他に気になるのは、ピクセルあたりの情報を何ビット取得しているのか?
コンデジ向けの撮像素子であれば10bitや12bitといったところだが、デジタル一眼レフでは14bit記録になって久しいので、12bitか14bitと考えるのが妥当だ。
GH5では10bit記録をサポートしていることからも、今更10bitで読みだしているとは考えにくい。
とはいえ、高速性を求める処理で14bitは重いはずだ。
よって、12bitが妥当なところではなかろうか。

試しに1秒間のデーター量を計算してみると、1700万画素で12bitで60fpsの場合、12.24Gbpsとなる。
これだけの情報量をイメージャーから映像エンジンに転送し続けるのに何ch使っているのだろうか。
駆動周波数やプロトコルや信号のエンコード方法は何だろうか。
機会があれば調べてみたい。

 

 

ということで、GH5で大盛り上がりした話を強制的に戻そう。
ここで、改めてRX100M5の素子の仕様を考えてみたい。

4Kについては、30fpsまでなので全画素読み出しで確定。
2Kについては、30fpsであれば全画素の可能性が残っている。
60fpsであれば画素加算で画素数を半分以下にしなければいけない。
120fpsであれば画素加算で画素数を1/4以下にしなければいけない。
この辺りはフレームレートを変更してエッジを確認すれば判断できると思われる。

4K時の全画素は5472x3080。2x2の画素加算で2736x1540。3x3だと1824x1026.6・・・
2x2は2Kに対して2倍の画素数3x3は僅かに拡大処理が必要となる。
ロジック的には2x2で120fpsまで対応できるはずなので、拡大処理は非採用だと思いたい。

と、ここで気づいたことがある。
ピクセルビニングを行っても、フレームレートに影響するのは垂直方向の情報だけであり、水平方向のビニングはフレームレートに影響しないのだ。
とすると、4K30pを基準にすると、2K120pでは縦解像度を1/4にしなければならないことになる。
ほぼ720pだ。
これはどうしたものかと思ったが、積層CMOSでは 受光素子 > DRAM > 映像エンジン となっているので、DRAMから映像エンジンに転送するのは通常のCMOSの考え方を適用する必要はないはずだ。
よって、2x2のビニングを行ってDRAMに置いたデーターを映像エンジンに流していると考えて問題ない気がする。
 ※でもGH5は通常のCMOSだから180fpsの実効解像度は結構落ちているのでは疑惑・・・

 

ここで、持っているわけではないが、D850の仕様も考えてみる。
FXフォーマットDXフォーマット、共に4Kと2Kの撮影が可能とのこと。
FXフォーマットなら3830万画素、DXなら1644万画素。
前者は画素加算で確定。後者はもしかすると30fpsであれば全画素読み出しの可能性あり。
これはどこかで検証してもらいたいところだ。

 

そういえば、某impressのα7R2のレビューで、画素加算はノイズの点で全画素読み出しに劣ることになっている。
しかし、CMOSの仕様を何度も確認してみたが、ピクセルビニングはノイズを低減する方向に働くはずなのだ。
だとすると、ピクセルビニングでドットバイドット記録したものと、約2倍の画素数から縮小処理したものとでは、後者の方がノイズ低減効果が大きかったということになるのだが、こればかりは検証したわけではないので仮定の域を出ない。
何か良い検証の素材があれば試してみたい。

 

話が飛び飛びになってしまったが、この辺でメモを終了としたい。

RX100M5に搭載されたPP7のS-log2は感度2000以上の設定だが、その感度では9EV程度のDレンジしかないので機能は無駄では? とか、
CMOSピクセルビニングのDレンジは結局どうなるんだ? とか、
RX10M3は「高速フロントエンドLSIの搭載により、動いている被写体を撮影した際に生じるゆがみ(ローリングシャッター現象)を軽減」って書いてあるけど、5倍に高速化したのは受光素子からDRAM部分であって、そこにフロントエンド関係しそうにないんじゃないか? とか、
RX10M3からM4で読み出し速度1.7倍っていうのは連写性能が14コマから24コマにアップしているから納得できるけど、そもそも動画撮影で全画素読み出し4K30pやってるのと矛盾するんじゃ? とか、
http://dc.watch.impress.co.jp/docs/news/439455.html
この5倍速って積層の5倍速に活用されてる技術だよね? とか、
気になることは山盛りですが、今後確認していくことにしようかと。

 


それでは皆さん、ごきげんよう