インターネット浦島太郎がIPv6に挑む
久しぶりすぎて、自分のブログの場所を発掘するところから始めた浦島太郎です。
生きているのでご心配なく。
奇しくも2年前の同日に更新していたわけで、何となく感慨深いものが・・・ありませんね、ハイ。
さて、インターネットです。
IPv6です。
お恥ずかしながら、ここ10年くらいはまともに最新情報を吸収していなかったので、出てくる単語が異世界言語。
とりあえずIPv4とIPv6は分かります。アドレスの拡張なので。
問題は認証プロトコルのPPPoEやIPoEだけでなく、そこに関係して IPv4 over IPv6 なるものまで出てきたこと。
そして、それが単一規格ではなく複数存在し、呼称が様々であること。
脳内整理も兼ねて、メモ書きしておきます。
まず最初に、ざっくりと把握。
■ IPv4（PPPoE）
おなじみのIPv4アドレスを使って、PPPoE認証で接続する。
最も普通で、最もオーバーヘッドの多い（負荷の多い）接続方法・・・という認識。
ただし、IDとパスワードを使っているので、一番理解しやすい方式でもある。
■ IPv6（IPoE）
IPv6のアドレスを使って、新方式であるIPoEで接続する。
現在の最新方式と言っていいはず。
最も戸惑うのは、IDとパスワードが存在しないということ。
サポートセンターは言葉を濁しているものの、どうやらMACアドレスで認証しているらしい、という話。
でもMACアドレスって書き換えできましたよね、PCだと。ネットワーク機器ではどうなんだろう。
基本的にはこの組み合わせのどちらかでの接続となる。
簡単ですね。
が、ここで問題になるのはIPv6の対応が進んでいないという現状。
要するに、v4とv6で下位互換とかそういうのは存在しないんですね。
具体的な数値は確認していないものの、既存のホームページの大半がIPv4しか対応しておらず、IPv6で接続できるのは限られたページのみ。
そうすると、IPv4のアドレスが枯渇しつつあるのに、IPv4とIPv6の両方のアドレスを使わないとネットに接続できないことになる。
これではまずいわけです。
ここで出てくるのが、IPv4 over IPv6。
IPv4の通信をそのままIPv6に流してしまおう、という力技な解決法です。
いいですね、ブルートフォース。
具体的な手法は省略。
さて、この IPv4 over IPv6 ですが、問題がないわけではない。
というのも、最初に書いたように複数の方式が存在する。
当然、機器によって対応状況が異なる。
そのため、契約したら実際には使えなかったというパターンがありうる。
ここが今一番混乱を招いている部分だと思います。
代表的なサービスを挙げると
transix
v6プラス
IPv6オプション
OCNバーチャルコネクト
ちなみにこれ、IPv4 over IPv6 のサービス提供会社は「VNE事業者」と呼ばれ、プロバイダとは別の存在。
プロバイダが自社で提供している場合もあるものの、固有名詞が入っていないサービスは別会社と考えて良いかと。
また、話を難しくしているのが、同じプロバイダでもVNE事業者が途中で変わる場合がある、ということ。
最近のぷららとか、そんな感じ。
さらに、プロバイダによってはVNE事業者名を明らかにしていない場合もあるということ。
これは新興企業に多い印象。
もっとも、サービス名が正確ならそこから推測できるわけですが。
とまぁ、もうこの辺りまでくると何が何やら分からなくなってきます。
ちょっと脳内アーキテクチャを改変してレジスタ増やしたい。
理解が追い付かない。
ということで、今度は信号の流れを追って整理。
PCは、IPv4で通信を開始
↓
ハブは、イーサネットの信号を流すだけなので、アドレス変換は無し
↓
ルーターは、WAN側から見て単一のIPアドレスに変換し、ついでにIPv4をIPv6に変換（VNE事業者によって変換方法は異なる）
↓
ONUは、電気信号を光信号に変換
↓
光ファイバーは、1回線を32ユーザーで共有
↓
地域ごとに収容ビルでまとめる
↓
IPoEなので網終端装置を通らず、ゲートウェイルーターからVNE事業者へ
・・・ここから先は、ざっくり言ってインターネット網と考えていい気がするので、追いかけるのはここまで。
ひかり電話を契約している場合、ONUがIPv4 over IPv6をしてくれる・・・のか？
よくわからん。
そして複数のサービスが存在するIPv4 over IPv6 だが、決して高いルーターが対応しているとも限らないので、処理に要するパワーはそこまで高くないような気がする。
ただ、方式によってはファーム待ちだったり、ファームが古いと遅かったり、制限事項が多少違ったりする。
個人的にはASUSの無線LANが全滅してるのが残念でならない。是非対応してほしい。
■ IPv4のPPPoE接続
PCは、IPv4で通信を開始
↓
ハブは、イーサネットの信号を流すだけなので、アドレス変換は無し
↓
ルーターは、WAN側から見て単一のIPアドレスに変換
↓
ONUは、電気信号を光信号に変換
↓
光ファイバーは、1回線を32ユーザーで共有
↓
地域ごとに収容ビルでまとめる
↓
PPPoEなので各県の網終端装置を通ってプロバイダへ
・・・ここから先は、ざっくり言ってインターネット網と考えていい気がするので、追いかけるのはここまで。
PPPoEセッションを張るのは、ルーターかONUどちらかが担う。
何となくONUしかできない気がしてたけど、ルーターでも可能らしい。
その場合の性能差は気になるところ。
ちなみに、混雑する時間帯に遅いと言われるボトルネックが、この網終端装置とされている。
1装置あたりのセッション数が一定数に達しないと増設できない代物で、設置するのがNTTなので、プロバイダは手も足も出ない。
一定数って何やねん！と思って調べてみたら、網終端装置の規模や東日本西日本での差異はあるものの、元々は2000とか8000とか、そういう数値だった模様。
なお、平成30年6月に20％緩和されたらしい。
とはいえ、帯域をセッション数で割ると、1セッションあたり数百kbpsでしかない。
ブロードバンドって何？
ついでにもうひとつ。
2018年7月23日～29日の調査において、網終端装置総合計の帯域に対してトラフィックが最大で7割程度なので、NTTとしては余裕があると考えているらしい。
これに対しては、5割超えで増強を検討、7割で増強だろJKというツッコミがあったそうな。
また、全体の総合計では7割でも、局所的には問題あるだろというツッコミもあったそうな。
あと、利用率94％を超えるとパケットロス数が増加し始めるらしいので、覚えておくと役立つかもしれない。
参考：https://www.soumu.go.jp/main_content/000602335.pdf 44ページ
■ IPv6のIPoE接続
PCは、IPv6で通信を開始
↓
ハブは、イーサネットの信号を流すだけなので、アドレス変換は無し
↓
ルーターは、WAN側から見て単一のIPアドレスに変換
↓
ONUは、電気信号を光信号に変換
↓
光ファイバーは、1回線を32ユーザーで共有
↓
地域ごとに収容ビルでまとめる
↓
IPoEなので網終端装置を通らず、ゲートウェイルーターからプロバイダへ
・・・ここから先は、ざっくり言ってインターネット網と考えていい気がするので、追いかけるのはここまで。
以上、ものすごく大雑把に把握してみた。
ただし、スカパーなどのテレビ系コンテンツの経路など、不明点は結構多い。
まともに流したら帯域が不足するけど、どうやって多重化してるんですかね。
この辺は、気が向いたらまとめてみたい。
あと、思い出したのでもう一つ。
「IPv4 over IPv6 があればPPPoE要らないよね」というスタンスのプロバイダがある。
この場合、ユーザー側で任意に切り替えができない。
どうみてもPPPoEにかかるコストをケチっているようにしか見えない。
GMOはそのタイプなので、ある程度自分でコントロールしたい派の人は注意されたし。
とはいえ、今後は全体的な流れとして、その方向に向かうのだろうとも思う。
それでは皆さん、ごきげんよう。
Fermi以降のNVIDIA製GPUのスペック一覧
Fermi以降のNVIDIA製GPUのスペックを調べたので、なるべくフォーマットを揃えて書き出してみた。
世代を跨いで一覧できることに意義を感じる方々向け、ということで。
なお、複数の情報源で確認をとっているものの、間違っている可能性は0ではない。
この点をご留意いただきたい。
移り変わりを眺めていると、世代が進むほどに制御の粒度が細かくなっている。
また、レジスタ数やスレッド数は大幅に増やさず、相対的にキャッシュを増強している。
また、GDDR5の息の長さには驚いた。
次を担うメモリの決定打が出てこない状況が、キャッシュ増強を加速させている感は否めない。
もっとも、ロジックを詰めすぎると電力密度の関係で放熱が追い付かないのでキャッシュの割合を増やすという要素もあるのだが。
■Volta GV100
プロセスルール：12nm（TSMCの12FFN）
トランジスタ数：210億
ダイサイズ ：815mm2
コアクロック ：1126（ブースト1455）
メモリクロック：HBM2 900GB/s （879MHz）
メモリバス幅 ：512bitｘ8＝4096bit
TDP ：300W
CU数 ：16CUｘ4ブロックｘ14SMｘ6GPC＝5376（実効80SMで5120）
レジスタ数 ：256KBｘ84SM＝20480KB
65536ｘ84SM＝5242880本
スレッド数 ：2048ｘ84SM
L1キャッシュ ：↓
共有メモリ ：L1と合せて128KBｘ80SM＝10240KB
L2キャッシュ ：6144KB
■Pascal GP100
プロセスルール：16nm（TSMCの16FF+）
トランジスタ数：153億
ダイサイズ ：610mm2
コアクロック ：1328（ブースト1480）（TDP250WのPCIe版はブースト1303）
メモリクロック：HBM2 720GB/s （700MHz）
メモリバス幅 ：512bitｘ8＝4096bit
TDP ：300W
CU数 ：32CUｘ2ブロックｘ10SMｘ6GPC＝3840（実効56SMで3584）
レジスタ数 ：256KBｘ60SM＝15360KB
65536ｘ60SM＝3932160本
スレッド数 ：2048ｘ60SM
L1キャッシュ ：24KBｘ60SM＝1440KB（Read Only）
共有メモリ ：64KBｘ60SM＝3840KB
L2キャッシュ ：4MB
■Pascal GP104
プロセスルール：16nm（TSMCの16FF+）
トランジスタ数：72億
ダイサイズ ：314mm2
コアクロック ：1607（ブースト1733）
メモリクロック：GDDR5X 320GB/s 10Gtps
メモリバス幅 ：32x8=256bit
TDP ：180W
CU数 ：32CUｘ4ブロックｘ5SMｘ4GPC＝2560
レジスタ数 ：128KBｘ2ｘ20SM＝5120KB
32768ｘ2ｘ20SM＝1310720本
スレッド数 ：2048ｘ2ｘ20SM
L1キャッシュ ：24KBｘ2ｘ20SM＝960KB（Read Only）
共有メモリ ：96KBｘ20SM＝1920KB
L2キャッシュ ：2MB
■Maxwell GM200
プロセスルール：28nmHPM（TSMC）
トランジスタ数：80億
ダイサイズ ：601㎜2
コアクロック ：1000（ブースト1075）
メモリクロック：GDDR5 7Gtps
メモリバス幅 ：64x6=384bit
TDP ：250W
CU数 ：32CUｘ4ブロックｘ4SMｘ6GPC＝3072
レジスタ数 ： 64KBｘ4ｘ24SMX＝6144KB
16384ｘ4ｘ24SMX＝1572864本
共有メモリ ：96KBｘ24SMX＝2304KB
L2キャッシュ ：3MB
※HDMI2.0対応 NVENCの効率向上 H265対応 H264はスループット2.5倍
■Maxwell GM204
プロセスルール：28nmHPM（TSMC）
トランジスタ数：52億
ダイサイズ ：398㎜2
コアクロック ：1126（ブースト1216）
メモリクロック：GDDR5 7Gtps
メモリバス幅 ：64x4=256bit
TDP ：165W
CU数 ：32CUｘ4ブロックｘ4SMｘ4GPC＝2048
レジスタ数 ： 64KBｘ4ｘ16SMX＝4096KB
16384ｘ4ｘ16SMX＝1048576本
共有メモリ ：96KBｘ16SMX＝1536KB
L2キャッシュ ：2048KB
※HDMI2.0対応 NVENCの効率向上 H265対応 H264はスループット2.5倍
■Kepler GK110
プロセスルール：28nmHP（TSMC）
トランジスタ数：71億
ダイサイズ ：533㎜2
コアクロック ：875（ブースト928）
メモリクロック：GDDR5 7Gtps
メモリバス幅 ：384bit
TDP ：250W
CU数 ：192CUｘ15SMX＝2880
レジスタ数 ：256KBｘ15SMX＝3840KB
65536ｘ15SMX＝983040本
共有メモリ ：64KBｘ15SMX＝960KB（L1と共有・16/48～48/16なので240KB～720KB）
L2キャッシュ ：1536KB
※パイプライン見直し シェーダー倍速動作廃止
※NVENC一新
■Kepler GK104
プロセスルール：28nmHP（TSMC）
トランジスタ数：35.4億
ダイサイズ ：294mm2
コアクロック ：1006（ブースト1058）
メモリクロック：GDDR5 6Gtps
メモリバス幅 ：256bit
TDP ：195W
CU数 ：192CUｘ4SMｘ2GPC＝1536
レジスタ数 ：256KBｘ8SMX＝2048KB
65536ｘ8SMX＝524288本
共有メモリ ：64KBｘ8SMX＝512KB（L1と共有・16/48～48/16なので128KB～384KB）
L2キャッシュ ：512KB
※パイプライン見直し シェーダー倍速動作廃止
※NVENC一新
■Fermi GF110
プロセスルール：40nmバルク（TSMC）
トランジスタ数：30億
ダイサイズ ：520mm2
コアクロック ：772（シェーダー倍速1544）
メモリクロック：GDDR5 4Gtps
メモリバス幅 ：384bit
TDP ：244W
CU数 ：32CUｘ4SMｘ4GPC＝512
レジスタ数 ：128KBｘ16SM＝2048KB
32768ｘ16SM＝524288本
共有メモリ ：64KBｘ16SMX＝1024KB（L1と共有・16/48or48/16なので256KBor768KB）
L2キャッシュ ：768KB（Read Write可）
※レジスタ数増加よりもキャッシュ効率改善に注力
■Fermi GF100
プロセスルール：40nmバルク（TSMC）
トランジスタ数：30億
ダイサイズ ：526mm2
コアクロック ：700（シェーダー倍速1401）
メモリクロック：GDDR5 4Gtps
メモリバス幅 ：384bit
TDP ：250W
CU数 ：32CUｘ4SMｘ4GPC＝512（有効480）
レジスタ数 ：128KBｘ16SM＝2048KB
32768ｘ16SM＝524288本
共有メモリ ：64KBｘ16SMX＝1024KB（L1と共有・16/48or48/16なので256KBor768KB）
L2キャッシュ ：768KB（Read Write可）
※レジスタ数増加よりもキャッシュ効率改善に注力
それでは皆さん、ごきげんよう。
次世代のGPUはどうなるのか＠NVIDIA
GPUを使って日々演算に勤しんでいると、次の世代のGPUがどのような形でいつごろ登場するのか知りたくなる。
実際にはそれほど勤しんでいるわけでもないが、個人的に気になるのは事実。
現状、GPUの規模や速度は半導体プロセスによって制限されているので、半導体プロセスについて知ることがGPUを知ることにつながる。
よって、ここ数世代のGPUについて整理しつつ、少し情報を集めてみたのでメモとして残しておきたい。
まず、現在に至るまでの過去数世代の動き。
AMD（ATI）は動きが読みにくい（独断と偏見）ので、ここではNVIDIAに絞る。
現在のアーキテクチャはPascal、プロセスルールは16nm（TSMCの16FF+）だ。
製品リリースは2016年。
アーキテクチャをさかのぼると、新しい順にMaxwell（2014年）、Kepler（2012年）、Fermi（2010年）となる。
アーキテクチャの発表だけなら前年だったりするが、およそ2年周期と考えればよい。
なお、更に前世代となると設計思想が異なるので別物として考えてよいだろう。
そもそも前世代のコアはGT200系であり命名規則が異なるということからも、それが伺える。
さて、簡単に各世代の仕様というか特徴を確認しようと思ったが、各世代の詳細な情報が集めづらいため、今回は省略する。
もっとも、ここ数世代でTesla系列とGeforce系列で分裂しつつあるため、一律で比較できないということもある。
最大サイズで比較するのが分かりやすいかと思うが、これについては別途まとめてみたい。
で、最大の問題は、次世代GPUで使用するプロセスルールだ。
これについては、28nmでアーキテクチャ2回分足踏みしていたという前例もあるため、現在の16nmでもう1世代製造する可能性はあるかもしれない。
この可能性の根拠は、28nm当時、2世代目の時点で28nmは最先端プロセスではなかったことだ。
当時、既に20nmが使用可能であり、Appleは自社SoC製造のために20nmを使用している。
しかし、20nmはメジャープロセスではなかったため、NVIDIAは採用を見送ったという経緯がある。
その結果、28nmが予想以上に使われ続けることになった。
これに対して現在、10nmが使用可能となっており、例によってAppleは10nmを使用している。
しかし、この10nmもメジャープロセスではないとされているため、NVIDIAは採用しない意向だ。
10nmの次は7nmとなるが、これは現在立ち上げ中（リスク生産中）なので、まだ本格的に使用することはできない。
そのため、現時点での選択肢は16nmとなってしまう。
ここで考えたいのは、現在Voltaを製造している12nmプロセスだ。
10nmとは違うこれは何なのか。
簡単に言えば、これは16nmプロセスのトラック数を削減して面積を切り詰めたプロセスである。
具体的には16FF+というTSMCの一般的な16nmプロセスを元に、トラック数を削減してセルハイトを縮めている。
ただし、16FFCのようなシュリンクはほとんど行っていない・・・らしい。
つまるところ、ほぼ16nmプロセスと同一である。
このような成り立ちのため、16FF+よりも多少なりとも高密度にできる。
引き換えに、パフォーマンスの上限は低くなる。
しかし、Teslaブランドではクロックに対する要求は相対的に低くなる（無いわけではない）ため、少しでもロジックの密度を上げるために採用された、と考えられる。
とはいえ、高密度化したと言ってもダイサイズとトランジスタ数を見ると数％程度であり、それだけを見れば誤差と言ってもいいレベルだ。
また、NVIDIAは過去においてハイエンドチップの製造プロセスについては保守的な選択をしてきたので、今回は随分とチャレンジした印象を受ける。
本来であれば、巨大化というリスクを受け入れた上で枯れたプロセスを使っていたはずだ。
しかし、今回は新しいアーキテクチャで最大サイズのものを新規プロセスで製造している。
そのどれもがリスクを持っている。
ただ、GV100のダイサイズが半導体製造における一括露光の上限サイズとほぼ同一である事から推測するに、目標とする規模のロジックを収めるために逆算してプロセスを決めたようにも見える。
綱渡りだが、結果オーライということだろうか。
もちろん、勝算なくしてリスクは冒さなかったはずだが、担当者は生きた心地がしなかっただろう。
さて、この12nmプロセスがGeforce向けに使用される可能性はあるだろうか。
12nm採用によるパフォーマンス（クロック）の低下が許容範囲内であれば、可能性はあると思われる。
もちろん、12nmの歩留り改善が順調に進む保証はないものの、このプロセスが16nmの延長線上に位置することから考えて、それほど現実味のない話ではない。
現在使用している16FF+はハイパフォーマンス向けのセットであり、放熱に問題が無ければ十分すぎる高クロックを達成できていることから、多少パフォーマンスが落ちる程度なら欠点が露呈することはないはずだ。
また、折角設計したGV100があるのだから、これを元にして機能削減版を作成するのは過去の例から考えても自然な流れと言える。
ということで、次世代版のGeforceは16nmで足踏みする代わりに12nmで製造され、若干のダイサイズ拡大と併せてある程度のロジック規模拡大を果たし、スペック上の消費電力は据え置きつつも性能を何割か向上させてくるはずだ。
意地の悪い考え方をすれば、消費電力の実測値は増えるだろう。
ただし、クロックは現状から据え置きに近いレベルに設定するはずだ。
こう考える理由は、GP100からGV100になりベースクロックだけでなくブーストクロックが微減したこと。
これは、ロジック規模が大きくなるほどクロックが低くなるデメリットと、微細化によるメリットが相殺し、若干デメリットが上回っているものと考えられる。
また、TDPが据え置かれているので、電力的な制限もありそうだ。
というよりも、基本的に16nmからの変更点が少ないのだから、微細化したメリットらしいメリットは無い気がするので、微減で済んでいるのは意地と奇跡か。
ともあれ、同じことがGeforceでも繰り返されるとしても不思議ではない。
現在、世界的にGPU需要が高まっているためメーカー在庫が無い状態が続いている。
挙句、DRAMの高騰と相まってボード単価も上がっている。
これが、ただ単に需要による品不足ではなく、次の製品への切り替えなどによる生産調整も関係しているのでは？と考えてしまうのは考え過ぎだろうか。
もしそうなら、そう遠くないうちにVoltaアーキテクチャのミドルレンジ向けチップが出るかもしれない。
さて、真相やいかに。
それでは皆さん、ごきげんよう。
効率良くGPUを冷やすには、ヒートシンクの形状に従うべし
現在販売されているグラフィックカードを見ると、その膨大な熱を放熱するためにヒートパイプを使用しているものが多数を占める。
TDPを基準として考えれば、CPUが100W程度に収めているところを、GPUは180Wや300Wといった値になっているので、そもそも熱量が違う。
また、形状の自由度が高く交換が容易なCPUクーラーと異なり、GPUクーラーは厚さに制限があり、交換するとしても選択肢が少ない。
GPUのチップを正面に見てPCIeスロットを下にした場合、当然前後方向は基板があるため風は抜けない。
必然的に左右か上下に風を抜けさせて放熱することになる。
どちらが多数派か？というと、恐らく左右方向にフィンを設けているパターンだろう。
動作中のグラフィックボードに手をかざしてみると分かるが、上下方向には排気せず、左側のブラケットや右側の開放部から排気している。
しかし最近、上下方向にフィンを設けている製品が増えてきたように思う。
そして、そのいずれも、高い放熱性能を発揮している場合が多い。
排気がM/Bに直接当たるのが難点だが、この形状の利点は何だろうか。
ヒートパイプの取り回しを見ると、何となく答えが見えてくる。
左右方向のフィンの場合、GPUに接触しているヒートパイプをUの字に曲げてフィンまで熱を運ぶ。
つまり、フィンまでの距離が長い。
上下方向のフィンの場合、GPUに接触しているヒートパイプは直線的に配置できる。
つまり、フィンまでの距離が短い。
また、使用可能な本数も、後者の方が多いようだ。
これらが要因となって、放熱性能の差が生じていると考えられる。
さて、今回注目したいのは上下左右の違いによる性能差ではない。
これを、リグとしてフレームに取り付けた場合のエアフローである。
市販のフレームを見ると、たいていブラケット側にファンを取り付けられるようになっている。
風の流れ方としては左右方向だ。
しかし、左右方向のフィンの場合、一方向の風の流れは左右どちらかの排気の妨げとなる。
ブラケット側から吹き付けるような風があれば、間違いなくブラケット側への排気は困難だろう。
特にスペースに制限のあるGPUクーラーは薄型のファンを使用しているため、風量はともかく排圧が弱い。
よって、排気を妨げないようにするため、可能であれば左右両方から排気するようファンを設置したい。
その場合、吸気はどこから行うか？という話になるが、暖かい空気は上へ動くため、ベストなのはPCIeスロット側、つまり下側だろう。
本来であればM/Bがあるので下から風を通すことはできないが、ライザーを使っていればそれも可能だ。
では、上下方向のフィンの場合はどうだろうか。
この場合、理屈上では左右方向から吸気して上下に排気するのが良さそうに思える。
しかし、暖かい空気は上へ動くため、下から排気するのは少々効率が悪そうだ。
また、下側にはM/Bなどがあるはずなので、それらを温めてしまうのも良くない。
少々手間ではあるが、横からダクトなどを使ってファンまでの吸気経路をある程度限定し、排気と混ざらないようにしたうえで、ダクトとは反対側から排気を引っ張るのがベターかもしれない。
また、左右方向の風は排気の妨げとはならないはずなので、素直にフレームにファンをつけて普通に使っても問題は小さいだろう。
・・・と、机上の空論を記してみたわけだが、市販のフレームを使う限り検証実験は難しい。
よって、自由に組める自作フレーム（アングルの組み合わせ）で、そのうち検証してみたいと思う。
もっとも、同形状のグラフィックボードを揃えないと検証しづらいので、ハードルは高めだが。
あと、違いがあっても数度程度だろうとは思っている。
夏の高温下でなければ恩恵はないだろう、おそらく。
それでは皆さん、ごきげんよう。
PC内配線・コネクター・スロットの許容電流を知る
何故かPCに5枚も6枚もGPUが刺さっている方々向けの考察情報。
物理的に無理なのでは？という至極当然の疑問を抱いた方にとっては、残念ながら役に立たないと思われるのでウィンドウを閉じていただいて構わない。
PCを動かしているものは電気である。
大電力を要求される場合、電圧は一定であるので必然的に電流が増える。
しかし電流は無制限に流せるわけではなく、配線抵抗と接点抵抗によってある程度の制限を受ける。
配線抵抗の最たるものが配線の断面積によって定められる電流の定格値。
接点抵抗は、その名のとおりコネクタなどの接点に発生する抵抗であり、コネクタの設計電流が基準となる。
ここ数年のプラグイン電源は接点抵抗を増加させるので、その点では電源効率の改善に逆行するものと言える。
しかし、電源容量の増加により電源から取り出される配線本数が増加しているため、必要悪なのだと解釈している。
さて、配線抵抗については、少し調べれば断面積と電流の関係について一覧表が見つかると思うので割愛する。
PCの電源から出ている太さであれば、±2本1組で、10Aも流せれば御の字だと考えておけば良いはずだ。
問題は、様々な形状のコネクタがどれくらいの電流に耐えるよう設計されているのか、という点だ。
M/B用のEPS24pin
EPS12V8pin
ペリフェラル4pin
SATA用15pin
GPU用6pin、8pin
挙げてみると、現在使われているのはこれくらいだろうか。
Pentium4世代にも12V4pinが存在したが、今は廃れてしまったので無視しよう。
M/B用のEPS24pin、その昔はATX20pinだったコネクタ。
ピンアサインを見てみると、ほとんどが3.3Vや5Vに割り当てられており、+12Vの供給は20pin中1本しかない。
24pinでも+12Vは2本しかない。
なるほど、CPU用に12Vを別途供給する必要がある理由がよく分かる。
20pinへの追加4pin部分について、許容電流は5Aであるとの情報を得た。
コネクタの形状が同一であるので、24pin全体において、12Vの許容電流は2本で10Aであると考えて良いだろう。
つまりEPS24pinの12Vについての供給電力は120W。
昨今、CPUの電力供給は12Vラインからの生成であると聞く。
また、PCIeの電力供給も12Vが主であり、他の電圧は必要最小限であるとも聞く。
PCIe形式のSSDで12Vからレギュレーターを介して給電することで安定化を図った、というものもあるくらいだ。
そのような12Vの位置づけを見ると、たった120Wでは心許ない。
CPUだけで使い切ってしまい、GPUまで電力供給できないのは非常に問題である。
ということでEPS12V8pinの必要性が明確となった。
±4組なので、20Aと考えて良いだろう。つまり240W。
24pinの120Wと合せて、360Wが確保できる。
これならば、問題はないだろう。
GPUの話が出たところで補足しておくと、GPU向けに設計されているx16形状のスロットは75Wまでの電力供給を想定している。
GPU向けのx1スロットは25Wとのこと。
また、GPU向けではない通常のx16、x8、x4スロットは25W、x1スロットは10Wである。
なお、12V以外の電圧についてどの程度含まれているかは確認できていないのでご容赦いただきたい。
話を戻して、次はペリフェラル4pinである。
これは規格が古いこともあり、明確な許容電流は不明確と言わざるを得ない。
ただ、5Aという説と、9.4～11Aという具体的な値が確認できたことは、一つの材料になるだろう。
5Aという説はどうだろうか。
以前使用していたSR2では、M/B付属の変換コネクタに、ペリフェラルx2⇒EPS8pin というものがあった。
上述のとおり、EPS8pinは20Aと予想される。
この場合、ペリフェラル1つで10Aとなり、5A説は少々考えづらい。
コネクタもATXやEPSのものより接点方向に奥行きがあるので、5Aより多くても不思議ではない。
よって、10A前後と考えるのが自然だと思われる。
SATA用15pinはどうだろうか。
これは3.3Vと5Vと12Vの3系統を15pinで繋いでいるものだ。
1pinあたり1.5Aで、各系統3本使っていて4.5Aである、という情報があるが、恐らく正しいだろう。
構造を見ても、EPSやペリフェラルのような電流は流せないと考えるのが自然だ。
GPU用の6pinや8pinだが、これは明確な定格値が知られている。
75Wと150Wだ。
なぜ2pin増えただけで倍なのか？という疑問もあるが、それ以上に疑問なのは8pinのピンアサインである。
6pinは±3組なのだが、8pinは+を3本のまま、GNDを5本にしているのだ。
一応、ATXやEPSと同系統のコネクタなので、1本あたりの許容電流は5Aだろう。
3本で15A、これで計算上は180Wとなる。
よって、+が3本しかないとしても、一応150Wという定格値は余裕を持った設定だと考えられる。
GNDの方が重要視されていることや、必要以上にマージンを取っていることは、GPUの動作安定性に繋がる何か裏付けがあってのことだろう。
あるいは、PCIeスロットによって供給電力が75Wの場合と25Wの場合があるので、この50Wを吸収する目的があるのかもしれない。
また、コネクタは全体的にGNDの数が少ないので、バランスをとるための設計かもしれない。
余談だが、ペリフェラル4pinからGPU用の6pinに変換するアダプターは、ここまで考察した事が正しければペリフェラル4pinは1つで足りるはずだ。
しかし、一般に出回っているアダプターは2つのコネクタを備えている。
やはりペリフェラルは5Aか？と不安になるが、これはpin数の違いを吸収することと安全性の向上の2つを両立するための選択ではなかろうか。
つまり、ペリフェラル4pinは12VとGNDとGNDの3pinを使用できる。
これを12V3つとGND3つにしなければならないので、どうせ線の数を増やすのであれば2つ目のコネクタを付けよう、という考えだ。
ここまでの情報を覚えておけば、GPUを複数枚使用する時の電力供給について誤った選択をすることはないだろう。
ライザーカードにSATAで給電するのは、ライザーのPCIeがGPU向けの設計だとすれば過電流（コネクタ54Wに対して要求75W）だと判断できる。
しかし一般的なPCIeであれば適正電流（コネクタ54Wに対して要求25W）だと判断できる。
恐らく、過電流による発熱や発火の事例を確認する限りは、GPU向けの75Wを想定しておいた方が無難であろう。
よって、SATAコネクタから給電するのは、よほど非常事態でもなければ行わない方が良いと結論できる。
ちなみに、ペリフェラル4pinであれば、どちらのパターンでも適正電流だろう。
GPU用の6pinも同様だ。
また、SATAやペリフェラルのように1系統の配線に複数コネクタが存在する場合、1系統の許容電流は10A程度であろうと想像しているが、ライザーカードを2枚接続した場合は12.5A流れる計算になる。
この時点でマージンまで使い切ってギリギリだと考えられる。
よって、1系統の配線に3つ以上のライザーを接続した結果は容易に想像できるだろう。
以上、安全なPCの運用に役立てれば幸いだ。
それでは皆さん、ごきげんよう。
UEFI と セキュアブート と CSM
UEFIとかUEFIモードという単語は出てくるものの、定義がイマイチ明確ではないものが多い（ように思う）。
そもそもの定義から確認してみたい。
そもそもUEFIとは。
これまでのBIOSに取って代わるファームウェアアーキテクチャである。
BIOSではシステムチェック、デバイスチェック、ディスク検出、OSブートコードのロードと実行、といったOS起動に至るまでの一連の処理を行っていた。
しかし、BIOSは16bitのリアルモードでしか動作できないため、機能的制限が増えてきた。
そのため、32bitや64bitのネイティブコードを使用できるUEFIが2012年頃から（？）使用されるようになった。
これによって緩和される制約は幾つかあるものの、分かりやすいのは以下の点だろう。
・MBRではなくGPT形式のディスク管理形式のサポート
・GPTによる2TBを超えるディスクからのブート
2TBを超えるディスクは、今までも使用できた。
が、それはデーターディスクとしてであって、起動ディスクとしては使用できなかった。
さて、システムがUEFIをサポートしているか否かで変わるのは2TBの壁だけではない。
ここで出てくるのが セキュアブート という単語だ。
セキュアブートによって可能となるもの。
それは、ブートコードが改ざんされないことが保証されること。
そのため、ブートコードを変更するようなウイルスから保護されることになり、システムの安全性が確保される。
また、高速な起動・シャットダウンも可能となる。
BIOSでは上述のように律儀にチェックを実施してからOSを起動させていたが、UEFIではレガシーデバイスのスキャンを省略して起動を高速化できる。
・・・らしい。
BIOSでもメーカーによって起動速度は様々だったので、どの程度差が出るのかは少々疑問ではあるが。
UEFIとBIOSの切り替えは、BIOS（というかUEFI）のブート関連のところに設定がある。
PCによって異なるが、UEFIモードにするか、レガシーBIOSモードにするか、という設定になっているはずだ。
なお、これに関連してCSMという単語が出てくるかもしれない。
これはレガシーBIOSモードに属するもので、コンパチビリティナントカ だ。
大雑把に、互換性向上のための設定と理解しておけば良いと思う。
なお、セキュアブートの設定もBIOS（というかUEFI）にあるはずだ。
対応OSはWindows8以降の64bitなので、これだけ使用するなら有効に、過去バージョンも使用する予定なら無効にする。
また、同時に行っておく設定として、SATAモードもある。
世代的な意味で、UEFIならAHCIやRAID、BIOSならIDEとしておくのが無難だろう。
ここまでで、UEFIがBIOSに取って代わる高機能な存在であることは理解した。
しかし、必ずしも上に挙げたメリットを全て受けられるわけではない。
何故なら、OSの対応が必要となるからだ。
要求されるOSのバージョンは、VistaSP1（Server2008R2）以降の64bit版。
32bit版に関してはタブレットPCなどで例外があるが、ことPC環境に関して言えば無視して良いと思われる。
ただ、Windows7はUEFI対応であるがCSMは有効にしておいた方が良いという記述を見る。
過渡期ゆえの、ということだろうか。
さて、対応OSであれば安心かと言うと、まだ問題がある。
WindowsはBIOSからブートしてインストールした場合と、UEFIからブートしてインストールした場合とで、別々のモードで動作する。
動作モードはインストール時に確定し、以降変更することはできない。
UEFIのメリットを受けるためには、当然ながらOSをUEFIモードで動作させる必要がある。
OSをUEFIモードで動作させるには、UEFIからブートさせた状態でインストールする必要がある。
恐らくここが一番重要だと思うが、起動順序の設定が必要となる。
DVD ⇒ SSD の順にすればいい、ということではない。
インストールメディアを入れた状態で、BIOS（というかUEFI）のブート設定を行うのだ。
ドライブが空の状態では設定ができない。
インストールメディアを入れた状態だと、DVDドライブの左端に「UEFI：」という文字が付くものが出てくる。
これを指定してインストールを開始しなければならない。
余談だが、USBメモリからインストールする場合、BIOSでは先頭セクターにブートコードが必要である。
しかしUEFIでは必要なファイルが揃っていれば良いので、インストールメモリを作成する際はファイルコピーで済む、というメリットもある。
気にしなければならないのは、ファイルシステムがNTFSかFAT32か、という点くらいだ。
ここまでくれば、OSのインストールそのものはBIOSモードでもUEFIモードでも一緒である。
インストーラーが2TBを超える領域を認識するかどうか、といった違いはあれど、特に何かを意識することはないはずだ。
これを書くにあたって、幾つかの解説記事やBlogを見て思ったことがある。
UEFIモードという言葉が、BIOS（というかUEFI）の画面に関して用いられているのか、OSに対して用いられているのか紛らわしい。
ブート設定が分かりづらい。
正直なところUEFIでなくても起動は速くなっているからメリットが小さい。
OSをSSDにインストールするようになったので2TBの壁が問題となりにくい。
もう少し早く世に出ていれば、高速化のメリットも分かりやすかっただろう。
また、2TBの壁への対応も感謝されただろう。
とはいえ、Windows10のような新しいOSではUEFIが前提として設計されているだろうし、使わないのは勿体ない。
いささか消極的な選択ではあるが、今後UEFIを活用していけるだけの知識は持っておきたいと思う。
それでは皆さん、ごきげんよう。
東芝のNANDチップの読み書き速度
少し前、3DNANDでTLCなチップの製品発表があったと思う。
出荷発表だったかどうかは忘れてしまったが。
そこに書いてあったスペックが、1チップあたりRead900MB/s、Write180MB/s、となっていた。
つまり書き込みは読み出し速度の1/5となっている。
コントローラー内蔵の1チップソリューションなので、各種制限があると思われるが、デバイスレベルでの読み書きの速度比率の参考程度にはなると思われる。
なお、この値は64GBのチップの場合のようだ。
デバイスとしては256GBまで存在するので、大容量化したときに速度がどのように変化するかは別途確認してみたいとは思う。
仕様が公表されれば、であるが。
ということで、TLCの書き込み速度は、読み出し速度の1/5 という目安を覚えておいて損は無い。
それでは皆さん、ごきげんよう。
