K75thunderbirdのブログ

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

今、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倍速に活用されてる技術だよね? とか、
気になることは山盛りですが、今後確認していくことにしようかと。

 


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

Twitterに動画投稿できない悩み

もう疲れたので、簡潔にまとめておきます。
同じような悩みの人のヒントくらいになれば。

 

40秒くらいの普通の動画を普通にアップロードしようとしたのですが、アップロードすると最後の最後で「お前の動画、互換性ないから無理(意訳)」と蹴られてしまう現象に悩み続けました。
実際、半日くらいトラブルシューティングに使いましたよ。

 

Twitterとしての公式の情報は以下のとおり。

Q:
ブラウザからアップロードできる動画の解像度と縦横比を教えてください。

A:
最小解像度: 32 x 32
最大解像度: 1920 x 1200(および1200 x 1900)
縦横比: 1:2.39~2.39:1の範囲(両方の値を含む)
最大フレームレート: 40fps
最大ビットレート: 25Mbps


以上。
実にシンプルです。
普通に考えれば、それほど問題になることはなさそうですね。

 


だがしかし、何度動画を作り直してもエラーになってしまう。


フレームレートが悪いのかと思い、オリジナルを保持 > 30fps に変更したもののNG。
元々は29.97でした。

バッファ容量が大きすぎるのかと思い、24000 > 12000 に変更したもののNG。

最大レートを 12000、10000、など変えてみてもNGのまま。

解像度を変更してみたものの、1080p、720p、480p、どれもNG。

メインプロファイルはレベル4.1で問題ないはず。

フレームパッキングは、なし。これも互換性を考える上では問題ないはず。

OpenGDP 有効
キーフレーム間隔 自動
最小GOPサイズ 自動

Bフレーム数 3 から 2 に変更するもNGのまま。

Bフレームモード なし で問題ないはず。

 

ここで設定をリセット。
その後、いつもどおりにビットレート制御モードを品質へ変更 値は26
最大レートを2400から10000へ変更。

・・・もしやこの設定を変更したら変わるかも?

 


・・・ということで、結局のところ「ビットレート制御モードをVBRにする」で解決しました。
品質固定は結果だけ見れば無問題でも、ファイルとしては互換性に乏しいらしいです。

実際に設定したのは、
平均レート4500
最大レート10000

実際に作られたファイルは平均6000Kbpsくらいでしたが。
ま、2passではないので、仕方ないですね。

 


そんなわけで、散々悩んだ挙句、原因は自分が好んで使用していたビットレート制御方式だったようです。
再現性の確認はもう少ししてみますが、とりあえずメモも兼ねて書いておくことにします。
訂正などがあれば、追って修正することになるかと。

 

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

Afterburner、OverClockするか? DownClockするか?

ちょいメモ。
自分のPCで、Geforce GTX 1060 3GB を使ったときの消費電力測定。

 

 

定格(元々OCされてる)状態でマイニング時、144W
パワーターゲットを60%に設定(メモリは7.6⇒8.7GHzにOC)時、117W
アイドル時、38W
(グラボ非装着時のアイドル時、28W)

定格より60%の方がハッシュレートが良くて、しかも27W省電力。
しっかり差が出ています。

具体的な数値が確認できて、一安心です。

 

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

マイニングではGPUよりもメモリが重要である? 確認してみた。

マイナー そして マイニング。
この単語が聞かれるようになって久しい。
いや、個人的に知ったのは数ヶ月前なのだが、数年前から存在はしていた。

そんなマイナーな、いやマイナーに関する話。

 


細かい説明は省略。
自分としても、全てを把握しているわけではないので。
せいぜいが、ビットコインを採掘するにはASICが必要で、汎用機での採掘はコストに見合わないこととか、主戦場は電気代の安い中国であるとか、その他の仮想通貨の採掘が日本での流行りであるとか、RADEONが日本のみならず中国で買い漁られていることもあって世界レベルで流通量不足になっていることとか、まぁそんな程度だ。
それだけ知っていれば十分かもしれないが、それでも人に説明をするには知識が不十分である。
よって省略する。

今回この記事をおこしたのは、マイニングがGPUに求める性能に偏りがあるように思ったことと、自分なりに確認してみた結果をまとめておこうと思ったからだ。
一般的に、マイニングにGPUを使うのは省略した説明に含まれる範疇の情報なのであしからず。


GPUに求める性能が偏っているとはどういうことか。
それは、メモリアクセス性能を極端に要求するアプリケーションであるということだ。

それを示しているのが、Geforce GTX 1070 と1080のハッシュレートを測定したとき、1070の方が上位であるという結果である。
少し調べればベンチマークの結果一覧は出てくるので具体的な値は省略する。


なぜ、シェーダーの数で1.33倍上回る1080が1070の後塵を拝するのか。
その鍵はメモリの種類にある。
1070はGDDR5、1080はGDDR5Xである。


GDDR5とGDDR5Xの違いは何か。
詳しいことは調べれば出てくるが、ひっくるめるて一言で言えば、データーアクセス粒度の違いであると認識している。
1命令で読み出せるデーターの大きさが倍なのだ。
メモリクロックが「8GHz相当」のような表記になっているのは、データー転送時のクロックを示している。
読み出し命令(制御系)のクロックはもっと低い。
「8GHz相当」の場合、GDDR5が2GHzでGDDR5Xが1GHzである。

これが何を意味するか。

見た目上のデーター転送レートが高くとも、GDDR5Xの場合、データー読み書きの命令頻度が落ちるのだ。
そのため、細かい読み書きが苦手なのである。
本来の3Dグラフィックでは問題がないデーターアクセス粒度でも、マイニングで使用するには粒度が大きすぎるようだ。
その結果、1070と1080のハッシュレートが逆転するという現象が発生する。
シェーダーが多くてもメモリに足を引っ張られて性能が出ないということは、メモリアクセス性能が支配的であるということだ。

そのため、RADEONが人気である(性能が出やすい)というのも理解できる。
あれはGDDR5であり、メモリバス幅も比較的広い。
ただしコアクロックはそれほど高くないので、相対的にシェーダーの演算性能はそれほど高くない。

また、RADEONのL2キャッシュは同価格帯のGeforceのそれよりも多いのでハッシュレートが高いという話もある。
もっとも、最近のGeforceは昔よりもL2キャッシュを増やしているし、キャッシュよりレジスタの方が性能のためには重要であるという話もあるので、ここではメモリアクセス性能が重要であることを裏付ける情報である、という点を把握するにとどめたい。

 

実際のところ、GPUとメモリのクロックがハッシュレートに与える影響はどうなのか?
あまり、こういった視点でのベンチマーク結果は出ていないようなので情報がない。
よって調べてみた。

以下については、大雑把なテストであること、エビデンスをとっているわけではなく目視確認レベルであること、厳密に条件を整えているわけではないこと、などに留意して欲しい。
テスト環境では、Geforce GTX 1060 3GB を使用している。
採掘しているのは、一般的なETH(だったはず)。

コア1620MHz、メモリ8500MHzくらい
 ハッシュレート22.0MH/s

コア1780MHz、メモリ8500MHzくらい
 ハッシュレート22.2MH/s

コア1620MHz、メモリ8700MHzくらい
 ハッシュレート22.5MH/s

頑張ってコアをOCするよりも、メモリを少しOCする方が効果があるようだ。
コアをOCしないことで、不要な消費電力増を避け、ファン騒音の低減が実現できる上に、ハッシュレートは上がるという一石二鳥である。

余談だが、この1060で試したところコア2000MHz程度でも一応は動作するようである。
ファン100%で温度は75度くらいだったと記憶している。
当然電圧もそれなりに上がり、1Vを超えていたはずだ。
普段使用している1620MHz程度では、ファン75%で60度を下回っている。
電圧は0.8V程度で落ち着いている。
ちなみに1620MHzというのはパワーターゲットを60%に設定した結果である。結果としてほぼ定格であるが。


もっとも、メモリの動作温度がどうなっているかは測定していないので不明であるし、メモリの定格は8000MHzとなっているのでOCによる寿命短縮は避けられないはずだ。
今現在、9000MHzあたりまでは問題なく動作することを確認したうえで多少マージンをとっているが、いつかはマージンも無くなるだろう。
もし今回の確認結果を参考にする人がいるとすれば、それを踏まえたうえで使用すべきであることは承知されたし。

 

ということで、少々マニアックな話題を扱ってみた。
もし何か参考になることがあれば幸いだ。

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

PCの消費電力を計算によって確認してみる。PCというかWSみたいな何か。

SR-2という製品をご存じだろうか。
「それ知ってる!レカロ!」と手を挙げた方は残念賞。
今回は、2010年に発売されたM/Bの話。

 


何故このM/Bの話なのか。
それは、現在進行形で手元にあり、消費電力の多さから運用頻度が極端に低く、その消費電力の根拠が気になったから、だ。
使わないと勿体ないが大規模すぎて取り回しが面倒で使用頻度激減、という流れで現在に至る。

このM/Bの構成を簡単に記すと、チップセットに5520、ブリッジチップにnF200を2つ、LGA1366を2つ、DDR3が3ch、である。
ここにGeforce9600GTを組み合わせ、SSDを2台、HDDを13台、CPUは低消費電力版の6コアXeonを2つ搭載。
合わせると、12コア24スレッド、メモリが48GBにストレージが36TBとなる。
非常に快適だ。
しかし、何もしなくても約160Wを消費する。
フルロードであれば、定格2.4GHzで280W、3.0GHzで380W、エコとは無縁の暖房器具と化す。

ざっと簡単に考えてみる。
Intel製のチップセットは基本的にそれほど消費電力は多くないはずだ。
nF200は不明。
比較的最近のCPUは消費電力に関しては大人しいと思って良い。
メモリはアクセスしなければそれほど電力を消費しないはずだ。
GPUはそれなりに電力を消費する。現行の1060がアイドル時実測で9W程度なので、プロセスルール的に考えてそれよりは多く消費しているはずだ。
SSDは数W程度。
HDDは7200rpmであることが災いして、1台あたり5W以上消費しているはずなので、70W近いのではないか。

HDDの分を差し引いても、アイドル時に90W程度の消費電力がある。
電源でもロスがあるはずだ。
さて、そう考えていったとき、計算は合うだろうか。

もう少し正確に求めてみよう。

 

 

一番怪しく不確定要素なのは、nF200である。
nF200について調べたところ、NVIDIAの780iチップセットで使用されていることが分かった。
780iは680iと同じMCP55系(C55)を採用、OCして駆動、スイッチチップとしてnF200を採用、という構成だ。
よって、780iチップセットについて調べれば何か判明するのでは?と考えた。

M/Bのみ交換し、他は同等の構成でテストした結果があった。
X38のアイドル時 52-68W(ave64W)
nForce780iのアイドル時 114-125W(ave119W)
平均値で比較して、フルロード時46W、アイドル時55Wの差。

別のベンチテストでは、アイドル時、X38が168W、780iが214W、差は46W。
よって、X38との比較では、消費電力は50W程度増加すると断定して問題はない。

X38の情報を調べると、製造は90nm、TDPは26.5W とある。
つまり、780iのTDPは70~80W程度と算出できる。
間を取って75Wと仮定する。

さて、この75Wの何割かはnF200が担っている。
さほど大きくないヒートシンクとはいえ、ファンつきのクーラーを使用しているので、1桁ではない。
仮定するとすれば10W以上、20Wまでは届かない、といったところだと思われるので、15Wと仮定する。
2つ搭載すれば30Wである。

上記より、SR-2の主要構成チップ 5520+nF200+ICH10R の消費電力(TDP)は 27.1+30+4.5=61.6 となる。
M/B上の他のチップも含めて、M/BのTDPは65W程度と見積もることができる。


他のコンポーネントの消費電力も計算しよう。

7200rpmのHDDは、調べたところアイドル時で5.6Wとのこと。
13台搭載すれば72.8W

電源効率は80+程度の750W電源なので、82%と仮定。

GPUは、ローからミドルレンジ程度の構成であれば、アイドルで10Wを少し切る程度に収まっているという情報が2009年に確認できたので、10Wという値を採用。


さて、アイドル時に160W消費していたPCは計算上成り立つのか。

まず、電源のロスを除外。
160*0.82=131.2

HDD分を除外。
131.2-72.8=58.4

GPU分を除外。
58.4-10=48.4

この48.4Wが、CPUとメモリとSSDとM/B分の消費電力となる。

アイドル時、DRAMの消費電力はほぼ0に近い(FB-DIMMなどを除く)という実験結果があった。
しかしDRAMのセルフリフレッシュは8GBでも3ケタmWくらいは消費しているという説明資料があったので、メモリの消費電力は1Wとする。
したがって、48.4-1=47.4
余談だが、メモリの枚数を増やすとアクセス時の消費電力が上がるのはコントローラーのチャンネル数が増えたから。
メモリをOCするとアイドル時の消費電力が目に見えて上がるのは、メモリコントローラーの動作クロックが上がったから。
幾つかのサイトで、目の前の事象だけに注目して短絡的に誤った結論に至っているものがあった。
いとをかし(違

閑話休題
CPUのアイドル時の消費電力だが、Ivy BridgeのC7ステートの消費電力は最大で2.2Wとなっている。
世代的に近いので、4コア2.2Wという値を参考値とすると、12コアで6.6Wとなる。
Xeonは他にもロジックの規模が大きくなっているので、8W程度と考えておけば良いだろう。
したがって、47.4-8=39.4

SSDはどうか。
使用しているSSDはアイドル時に100mWを下回るようなので、2台で0.2Wとする。
したがって、39.4-0.2=39.2

さて、M/BのTDPは計算上65Wだった。
それがアイドル時は計算上では39.2W。
悪くない結果、納得できる範囲かと思う。

 

 

参考メモ
Intel(R) 5520 I/O Hub
 65nm
 TDP 27.1W

ICH10R
 TDP 4.5W

Intel(R) X99 Chipset Product Specifications
 32nm
 TDP 6.5W

B75
 65nm
 TDP 6.7W

H87
 TDP 4.1W

 

 

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