アカウント名:
パスワード:
（よく知らないのですけれども）メインフレームのCPUは独特な仕様が必要で、信頼性を担保するには独自開発が重要になるのでしょうか？
それとも、大々的に市場に売り出すというよりも、顧客のアテができたから、細々とCPU生産の火を絶やさないためのリリース？
この分野だと、信頼性担保のためにIntelが言うところのMCA、PAL、SAL等といった機能が重要なんです。このうち、MCAはXeon(E7系)にあるんですが、他が無いのでItaniumの代用にできないんだろうと思います。
MCA, PAL, SALって何だろうと思ったら、ブレードで実現する「小規模基幹システム」 [hp.com]と言う解説が。ハードウェア障害を検知すると、それを起こしたプロセッサを殺すシステム?そこら辺のCPUだと、障害起こしてもスルーかそのまま逝っちゃうけど、Itaniumだとしっぽ切って生き残る?
私の知ってるFT機（FT機とメインフレームって違うんだっけ？）だと、CPUボードは3枚積んでました。
で、3枚で常に同じ計算をし、3枚で相互に計算結果を比較しています。2枚から見て、「1枚からの計算結果が違う」と、このCPUボードは自動的に切り離されます。
当然残る2枚で処理は継続するし、「壊れてるらしい1枚を切り離す」際、一切ダウンタイムは出ません。
>2枚から見て、「1枚からの計算結果が違う」と、このCPUボードは自動的に切り離されます。すごい。エヴァンゲリオンのMAGIじゃん。３という数字はとても合理的なんだなと。
すごい。エヴァンゲリオンのMAGIじゃん。 ３という数字はとても合理的なんだなと。
そこはアポロ宇宙船 [biglobe.ne.jp](1960年代の設計)とか, せめてラーマ [wikipedia.org](1973年のSF)とかを出しましょうよ.
>せめてラーマ(1973年のSF)とかを出しましょうよ.計算機の三頭政治はうまく行っても、人間の三頭政治が行なわれた例は歴史上に数えるほどしかないよなあ。
人間だと全く同等のスペックの人間を三人揃えるのが不可能で、入り組んだ力関係になるから、現実のシステムとして、頂点をもたない少数リーダー制にしようとすると、共和制のころの古代ローマ人のように二頭政治 [wikipedia.org]に落ち着くのかねえ。
アポロは三重系ではないという話http://smatsu.air-nifty.com/lbyd/cat5978563/index.html [air-nifty.com]
複数プロセッサ（もしくはノード）間で演算結果の多数決をする構成は珍しくないですよ．スペースシャトルの制御では4＋1台のコンピュータが多数決（というか相互監視）してました．
ぜんぜん違うよ。全く逆。MAGIはそれぞれが違う観点から答えを求めて合議制で結論を出す個体の差異を組み込んだシステム(多数決やその内訳までが結果に含まれる。だから、結論に対して賛成2,保留1みたいな曖昧な結果になる)だけど、多重系は全く同じ挙動を示すものを複数用意してうち一つが壊れても他の2つと比較すれば間違ったのがわかるし間違ったのを切り離してそのまま動けるねというシステム。
# 1でも2でもなく3というのは対立が起きて(2以上)、偶数じゃない最小の数という点で重要だけど。
>MAGIはそれぞれが違う観点から答えを求めて合議制で結論を出す個体の差異を組み込んだシステム(多数決やその内訳までが結果に含まれる。>だから、結論に対して賛成2,保留1みたいな曖昧な結果になる)だけど、これが機能するとしたら、計算機の世界で、ここで妥協する代わりに別の条件で譲るといった、政治的な取引が行なわれないからだろうな。
個体の差異を組み込んだ合議制のシステムって実用例はあるのだっけ？
> 個体の差異を組み込んだ合議制のシステム
コンピュータ将棋での「激指」、「GPS将棋」、「Bonanza」、「YSS」の4つの将棋プログラムを使用した多数決合議制システム「あから」 [srad.jp]とか?
#実際には、アルゴリズムごとの重み付けがかなり偏ってる [livedoor.jp]ので、合議というより「激指メイン、迷ったら他のアルゴリズムの意見も聞いてる」って感じですかね。
エヴァどころかアポロの時代からの伝統ですよ。むしろMAGIはアポロ搭載のコンピュータから引いてきてるんだと思う。
FTとメインフレームは違うシロモノ障害に備える方針からして違いますよ
FTだと「2重、3重に系を持っていて、壊れているらしい系は切り離す」という対応だと理解しています。メインフレームだと、どんな感じなんでしょう？？
メインフレームの基本は予防保守です.
PCレベルでもハードディスクではSMARTなどで不具合にいたらない障害を記録していますが, メインフレームではCPUやメモリ, 各種入出力モジュールでもそうした軽微な障害発生統計を採っています. また電源の変動や温度変化といった外部要因も記録していたりします.
保守契約にもよりますが, そうした統計データをオンラインで保守センターで記録し, 統計的に障害が発生しそうな部品を障害発生前に定期保守で交換します.
こういう統計的な予防保守というのは, それなりの数が出ていないと基礎データが収集できませんし, また各ユーザに近い保守センターを設けないといけないということで, 必然的に高コストになります.
Itaniumのシステムなら、CPUの処理過程で問題が起きても、そこで検出できますそれをトラップして、抽象化のとこで再構成して立て直し、OS側で対処して…云々
演算中のものをどうするかは…なんかしゃべったら良くない気がする# お察しください
まともに対応してるシステムなら、動作中にCPU引っこ抜こうが、バスが潰れようが、動き続けますよこれ [srad.jp]はネタだと思いますが、こういうことされても動き続けてくれます
バスにぶら下がったデバイスやプロセッサどころか、ブリッジ単位でバスごとホットに増減可能ってのを最初に聞いたとき、テセウスの斧のように電源入れて運用したまま全モジュールが入れ替わったメインフレームとかあるのかなと思った。設計だけでなく開発段階とかでは当然実際にやっているんでしょうねえ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
メインフレームに独自CPUを載せる理由について (スコア:0)
（よく知らないのですけれども）メインフレームのCPUは独特な仕様が必要で、
信頼性を担保するには独自開発が重要になるのでしょうか？
それとも、大々的に市場に売り出すというよりも、顧客のアテができたから、
細々とCPU生産の火を絶やさないためのリリース？
Re:メインフレームに独自CPUを載せる理由について (スコア:2, 参考になる)
この分野だと、信頼性担保のためにIntelが言うところのMCA、PAL、SAL等といった機能が重要なんです。
このうち、MCAはXeon(E7系)にあるんですが、他が無いのでItaniumの代用にできないんだろうと思います。
Re:メインフレームに独自CPUを載せる理由について (スコア:1)
MCA, PAL, SALって何だろうと思ったら、
ブレードで実現する「小規模基幹システム」 [hp.com]
と言う解説が。
ハードウェア障害を検知すると、それを起こしたプロセッサを殺すシステム?
そこら辺のCPUだと、障害起こしてもスルーかそのまま逝っちゃうけど、
Itaniumだとしっぽ切って生き残る?
TomOne
Re:メインフレームに独自CPUを載せる理由について (スコア:1)
私の知ってるFT機（FT機とメインフレームって違うんだっけ？）だと、CPUボードは3枚積んでました。
で、3枚で常に同じ計算をし、3枚で相互に計算結果を比較しています。
2枚から見て、「1枚からの計算結果が違う」と、このCPUボードは自動的に切り離されます。
当然残る2枚で処理は継続するし、「壊れてるらしい1枚を切り離す」際、一切ダウンタイムは出ません。
Re: (スコア:0)
>2枚から見て、「1枚からの計算結果が違う」と、このCPUボードは自動的に切り離されます。
すごい。エヴァンゲリオンのMAGIじゃん。
３という数字はとても合理的なんだなと。
Re:メインフレームに独自CPUを載せる理由について (スコア:1)
そこはアポロ宇宙船 [biglobe.ne.jp](1960年代の設計)とか, せめてラーマ [wikipedia.org](1973年のSF)とかを出しましょうよ.
Re: (スコア:0)
>せめてラーマ(1973年のSF)とかを出しましょうよ.
計算機の三頭政治はうまく行っても、
人間の三頭政治が行なわれた例は歴史上に数えるほどしかないよなあ。
人間だと全く同等のスペックの人間を三人揃えるのが不可能で、入り組んだ力関係になるから、
現実のシステムとして、頂点をもたない少数リーダー制にしようとすると、共和制のころの古代ローマ人のように二頭政治 [wikipedia.org]に落ち着くのかねえ。
Re: (スコア:0)
アポロは三重系ではないという話
http://smatsu.air-nifty.com/lbyd/cat5978563/index.html [air-nifty.com]
Re: (スコア:0)
複数プロセッサ（もしくはノード）間で演算結果の多数決をする構成は珍しくないですよ．
スペースシャトルの制御では4＋1台のコンピュータが多数決（というか相互監視）してました．
Re: (スコア:0)
ぜんぜん違うよ。全く逆。
MAGIはそれぞれが違う観点から答えを求めて合議制で結論を出す個体の差異を組み込んだシステム(多数決やその内訳までが結果に含まれる。
だから、結論に対して賛成2,保留1みたいな曖昧な結果になる)だけど、多重系は全く同じ挙動を示すものを複数用意してうち一つが壊れても
他の2つと比較すれば間違ったのがわかるし間違ったのを切り離してそのまま動けるねというシステム。
# 1でも2でもなく3というのは対立が起きて(2以上)、偶数じゃない最小の数という点で重要だけど。
Re: (スコア:0)
>MAGIはそれぞれが違う観点から答えを求めて合議制で結論を出す個体の差異を組み込んだシステム(多数決やその内訳までが結果に含まれる。
>だから、結論に対して賛成2,保留1みたいな曖昧な結果になる)だけど、
これが機能するとしたら、計算機の世界で、
ここで妥協する代わりに別の条件で譲るといった、
政治的な取引が行なわれないからだろうな。
個体の差異を組み込んだ合議制のシステムって実用例はあるのだっけ？
Re:メインフレームに独自CPUを載せる理由について (スコア:1)
> 個体の差異を組み込んだ合議制のシステム
コンピュータ将棋での「激指」、「GPS将棋」、「Bonanza」、「YSS」の4つの将棋プログラムを使用した多数決合議制システム「あから」 [srad.jp]とか?
#実際には、アルゴリズムごとの重み付けがかなり偏ってる [livedoor.jp]ので、合議というより「激指メイン、迷ったら他のアルゴリズムの意見も聞いてる」って感じですかね。
Re: (スコア:0)
エヴァどころかアポロの時代からの伝統ですよ。
むしろMAGIはアポロ搭載のコンピュータから引いてきてるんだと思う。
Re: (スコア:0)
FTとメインフレームは違うシロモノ
障害に備える方針からして違いますよ
Re: (スコア:0)
FTだと「2重、3重に系を持っていて、壊れているらしい系は切り離す」という対応だと理解しています。
メインフレームだと、どんな感じなんでしょう？？
Re:メインフレームに独自CPUを載せる理由について (スコア:1)
メインフレームの基本は予防保守です.
PCレベルでもハードディスクではSMARTなどで不具合にいたらない障害を記録していますが, メインフレームではCPUやメモリ, 各種入出力モジュールでもそうした軽微な障害発生統計を採っています. また電源の変動や温度変化といった外部要因も記録していたりします.
保守契約にもよりますが, そうした統計データをオンラインで保守センターで記録し, 統計的に障害が発生しそうな部品を障害発生前に定期保守で交換します.
こういう統計的な予防保守というのは, それなりの数が出ていないと基礎データが収集できませんし, また各ユーザに近い保守センターを設けないといけないということで, 必然的に高コストになります.
Re: (スコア:0)
Itaniumのシステムなら、CPUの処理過程で問題が起きても、そこで検出できます
それをトラップして、抽象化のとこで再構成して立て直し、OS側で対処して…云々
演算中のものをどうするかは…なんかしゃべったら良くない気がする
# お察しください
Re: (スコア:0)
まともに対応してるシステムなら、動作中にCPU引っこ抜こうが、バスが潰れようが、動き続けますよ
これ [srad.jp]はネタだと思いますが、こういうことされても動き続けてくれます
Re: (スコア:0)
バスにぶら下がったデバイスやプロセッサどころか、ブリッジ単位でバスごとホットに増減可能ってのを最初に聞いたとき、テセウスの斧のように電源入れて運用したまま全モジュールが入れ替わったメインフレームとかあるのかなと思った。設計だけでなく開発段階とかでは当然実際にやっているんでしょうねえ。