K75thunderbirdのブログ

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

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

 

 

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

EVと、各種バッテリーの正しい使い方

次期リーフはバッテリーが倍増して48kWhとか60kWhになるらしい。
何かのキーワードで情報検索していたときに、そのような話を見かけた。
たまに90kWhという文字もあったが、あれはバッテリーからの出力が90kWという資料を見間違えただけだろう。

ともあれ、バッテリー容量は大きければ大きいほど良い。
それは、長距離走れるからとか、充電の手間が減るから、という短期的な見方によるものではなく、バッテリーの負荷軽減につながるため寿命そのものを伸ばすことになるからだ。

一応説明しておくと、ある負荷装置があるとして、その装置に一定の電力を流す場合、容量の小さいバッテリーよりも容量の大きいバッテリーの方が、バッテリーが持っている電力量に対する放電電力の比率が小さいため、バッテリーへの負担が少ないということ。
もう少し具体的に言えば、100Wの負荷に対して、100Whのバッテリーを接続した場合、放電は1Cとなる。
しかし500Whのバッテリーを接続した場合、放電は0.2Cとなる。
1Cより0.2Cの方がバッテリーへのダメージは少ない、ということだ。

さらに、急速放電の度合いが低いほど、バッテリーの発熱も少ない。
全体で発生する熱量は等しいかもしれないが、温度上昇の度合いは低いので、温度的な意味でもバッテリーには優しいことになる。

同じことは充電する時にも当てはまる。
10kWhのバッテリーに20kWの充電器を使うと、2Cでの急速充電になる。
しかし40kWhのバッテリーであれば0.5Cの充電となり、バッテリーへの負担は少なくて済む。
もの凄く大雑把な計算なので、その辺のツッコミは勘弁してほしい。

必ずしも急速充電が悪いわけではなく、設計上の想定内で推奨される環境下での使用であれば問題はないものの、充電電流は極端に大電流でない方がいいのは明らかだし、温度も低すぎたり高すぎたりしてはいけない。
細かい話は、リチウムイオンバッテリーの種類によっても変わってくるので、また気が向いたら情報を集めることにしたいが、基本的な原則は変わらない。
バッテリーが無理なく動作できる範囲で、無理なく使ってやること。これが長持ちさせるカギになる。

 

話をEV以外に向けよう。
現在使われているバッテリーには様々な種類がある。
鉛蓄電池、ニッケルカドミウム、ニッケル水素、リチウムイオン、あたりが一般的だろうか。
それぞれ、適した使い方というのは異なるので、以前の常識が新しいバッテリーに通用することはない。
それを勘違いして「xxした方が良い」と最初から決めつけて、昔からの習慣に倣って使ってしまうと、寿命を縮めかねない。
自分の身の回りでも、意外と知らない人が多い(というよりも気にしていない人が多い)ので、メモがてらまとめてみようと思う。

 

鉛蓄電池
名前のとおり鉛を使用しているので、非常に重たいバッテリーである。
しかも古くから使われている。
では時代遅れなのか?というと、用途によってはそうでもなかったりする。

重量を気にしなければ、大容量のバッテリーを製造しやすい。
そのわりには安価である。
充電制御が比較的簡単である。
容量が大きいので、相対的に大電流を流すことも一応可能。
そのような特徴を生かして、自動車のバッテリーやUPSに使用されている。

長持ちさせるコツは?
保存するときは満充電にしておくことだ。
使ったら必ず充電する。充電した記憶が怪しかったらとりあえず充電する。
とりあえず満充電にしておけば問題なし。
非常にわかりやすいバッテリーである。

逆に、放電した状態で放置してしまうと電極表面に硫酸鉛が付着してしまい、内部抵抗が増大して出力可能な電流量が低下し、あっという間に寿命を迎える。
バッテリーあがりを起こした時、バッテリーが完全に復活しないのは、これが原因である。
詳しいことを知りたければ「サルフェーション」で検索してほしい。

 

ニッケルカドミウム
このバッテリーについて回る言葉。それが「メモリー効果」である。
憎きバッテリーの敵である。
これの対策は、使いかけの状態で充電すると徐々に本来の容量を使い切れなくなってしまうので、しっかり放電させてからしっかり充電すること。
今でもこの使い方が染みついている人は多いはず。

長持ちさせるコツは、上に書いたとおり。
保存時は、1.0Vあたりまで放電させてから保管。満充電での保管はNG、だそうだ。

 

ニッケル水素
ニッカドの後釜的存在。
モリー効果からは多少解放されたものの、自己放電は増加。
過放電により一気に寿命を迎えるケースがあるため、保存時は満充電した状態にしておくことが望ましい。
なお、エネループはメモリー効果や自己放電についての特性を改善しているが、満充電での保存が推奨されている点は変わりない。

 

リチウムイオン
現在一般に使用されているバッテリーの中で、最も重量あたりの電力密度が高いバッテリーである。
ただし、充電制御に失敗すると発火する。
製造を少しミスっても発火する。
便利だが危険なバッテリーである。
それゆえ、セル単体で使用されることは皆無に等しく、制御回路とセットにして販売・使用されることがほとんどである。
セル単体だと思っても、実際には小さな回路を挟んでいたりする。

長持ちさせるための使用法、それは 満充電しない&過放電しない である。
もっと具体的に言えば、残量20~80%くらいの間で使用すること。
これはバッテリーの開発者やEVの開発者、さらにはノートPCの開発者までもが口を揃えて言っていることである。

では保存はどうするか。
これも使い方と同様に、中途半端な充電状態で保存するのがベストである。
自己放電で電圧降下することを考えれば、残量70%くらいで放置しておくのがよいと思われる。

 

まとめると、鉛蓄電池は使ったらひたすら充電。満充電が正義。過放電は死亡フラグ
ニッカドは使い切ってから充電。メモリー効果に注意。ただし保管時は使い切った状態で寝かせる。
ニッケル水素はメモリー効果についてはニッカドよりルーズな管理で問題なし。保管時は満充電で。自己放電が多く過放電は死亡フラグ
リチウムイオンは充電のしすぎと放電のしすぎに注意。中途半端が正義。過放電は即死の可能性あり。

言い忘れたが、どのバッテリーも過充電と過放電がNGなのは共通認識だ。
過充電は発火、過放電は即死、というケースが多いが、そうなった場合の許容度はバッテリーによって異なるので、バッテリーに応じてしっかり考えて使ってほしい。
とはいえ、充電器を介して普通に充電し、正常に動作している機器で使用する分には全く問題ないはずだ。

問題があるとすれば過放電だ。
内部抵抗に起因する自己放電は不可避なので、放置しておけば必ず放電が進む。メンテナンスを怠れば過放電となる。
過放電は即死となるケースが多いのは前述のとおりなので、定期的なメンテナンス(充電)は欠かさないようにしたい。

 

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

RX100M5のイメージセンサーに積層されたDRAM容量を探る

前略
HFR撮影の記録時間=積層されたDRAMの容量限界 と考えて、どれくらいの容量が撮像素子に存在しているのか探ってみる。

画質優先と時間優先で、それぞれ解像度と撮影可能秒数が異なる。
詳細はメーカーページを参照のこと。

バッファされるデーターはRAW相当だと考え、速度優先なので読み出し8bitだと仮定して、単純計算。
そうすると、公称値の撮影可能時間が大雑把すぎるので計算結果にブレが出るものの、計算上は12Gbit~14GbitクラスのDRAMが存在することになる。

現在、最先端のDRAMチップ(ただし3Dトランジスタではないプレーナ型)の情報を集めてみると、16年末あたりで20nm(主流は8Gbitチップ)、17年中に18nm(容量変わらず)、といったところ。
ちなみに16Gbitチップが主流になるには、プロセスルールにして12nmくらいまで世代が進まないと難しいとのことで、早くても18年か、遅ければ20年といったところ。
容量増加が異様に遅いのは、プロセスの微細化が極端に難しくなっていることに端を発しているので、早急に解決することはありません。

閑話休題
メインストリームになるDRAMチップは1チップ50~80mm2と言われている。
計算上は2015年で8Gbitチップが70mm2、2016年で60mm2くらいなので、現在は50台に乗っているはずだ。
そのため、最新のプロセスで製造した場合、現状は大雑把に言って1Gbit=7mm2くらいだと考えられる。
SONYCMOSイメージセンサー製造ラインがどれくらいのプロセスルールを使用しているかは不明だが、最新鋭のDRAM製造ラインよりは多少世代が落ちると考えて間違いはないはず。
となると、84mm2~98mm2より大きいサイズ、100mm2は超えてくるくらいでなければ計算が合わないことになる。

ここで撮像素子のサイズを見ると、13.2mmx8.8mmなので116.16mm2になる。
ただし半導体のダイは撮像範囲より大きいので、仮に四方に1㎜ずつ余白があるとすれば、15.2mmx10.8mmで164.16mm2になる。
積層範囲は不明、プロセスルールも不明だが、計算上は問題なさそうなので、DRAM容量については概ね計算どおりということで良いように思う。
あとは撮影時のフレーム数をカウントすれば、正確に容量が算出できそうです。

 

 

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