トップページunix
1001コメント272KB

Sun Microsystem 最大の遊撃

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@お腹いっぱい。2005/12/08(木) 17:43:05
今更「オープンソース」とか言い出したり、
 …でも「OpenSolaris-Closed-Bins」って一体…(´Д`;)

今更「Ultra20」とか言い出したり、
 …でも「"Ultra"SPARCではなくOpteron」って一体…(´Д`;)

Fujitsu製造のSPARC64V,
AMD製造のOpteron,
TI製造のNiagara(UltraSPARC T1)などと矢継ぎ早にCPUを模索しているが、
これは縦読みで、製品群が"FAT"になる暗示か?w

【前スレ】
Sun Microsystems 最後から二番目の真実
http://pc8.2ch.net/test/read.cgi/unix/1127872934/
0362名無しさん@お腹いっぱい。2006/01/03(火) 11:17:40
V20z/V40zもひどかったな。dell以下の品質。ベンチャーの製品だから仕方ないと
言えば仕方ないけど、ベクトルシャイムが関わっていてあの体たらくではね。
台湾の製造委託先がよろしくなかったのかな? 設計も委託してた?
その意味ではX2100もやばそうな。こちらも台湾
X4100/X4200はSunの設計だそうだから少しは期待しているが
0363名無しさん@お腹いっぱい。2006/01/03(火) 11:20:00
>>344
HyperThreadingは、投機的実行よりも確実性のある
余ったリソースの有効利用ですかね。
0364名無しさん@お腹いっぱい。2006/01/03(火) 11:37:01
>>363
良い評判聞かないけどね。
0365名無しさん@お腹いっぱい。2006/01/03(火) 11:41:53
>>361 芸が無いね
0366名無しさん@お腹いっぱい。2006/01/03(火) 11:46:46
Sunの板なのにItaniumやXeonの話題が多いのはなぜなんだろう。
もしかしてSPARCサーバのユーザ少ない?
0367名無しさん@お腹いっぱい。2006/01/03(火) 11:49:32
ホビーユーザーか零細ユーザーばかりなんだろ
じゃなかったらItaマンセーなNEC系の人とか
0368名無しさん@お腹いっぱい。2006/01/03(火) 11:50:37
>>365
気になるんだ?
0369名無しさん@お腹いっぱい。2006/01/03(火) 11:55:34
366>>368
じゃなくて、違和感を感じる。
終わってしまったItaniumで盛り上がっているのが特に。
0370名無しさん@お腹いっぱい。2006/01/03(火) 12:01:35
Sunの株価5$以下だろ。どっか買収してくんないかな。
Sun自身は買収下手で、せっかく買った会社の製品をまともに売ったためしが無い。
唯一の成功はStarfire。
SAM-FS/QFSも良い製品なんだが、Sunブランドになって忘れられてしまっている。
最近買ったStorageTekでも同じような失敗するんだろうな。テープ以外の製品、
全滅するんではないかな。ストレージにも良い製品あるのにね、。
0371名無しさん@お腹いっぱい。2006/01/03(火) 12:04:11
終わってるという意味では、SPARCもItaniumも大差ないんじゃねーの?
0372名無しさん@お腹いっぱい。2006/01/03(火) 12:16:31
SPARCの方がまだましかと
0373名無しさん@お腹いっぱい。2006/01/03(火) 12:27:12
Niagaraが成功すれば、Afara買収はうまく行ったと言えるのかな?
0374名無しさん@お腹いっぱい。2006/01/03(火) 12:36:43
ItaniumダメんなったらACOS-4もXeonで動かすのか>NEC
期待のPRIMEQUESTはどうするのか>富士通

intelが面子にかけても継続する?
0375名無しさん@お腹いっぱい。2006/01/03(火) 12:38:10
Sunは判断ミス多いけど、Itaniumを袖にしたのは正しかったかと
0376名無しさん@お腹いっぱい。2006/01/03(火) 14:00:48
>>359
25KもE10000も買ってるの?
なんて優良顧客なんだ...
0377名無しさん@お腹いっぱい。2006/01/03(火) 15:53:13
判断ミスをしないSunはだめぽ
0378名無しさん@お腹いっぱい。2006/01/03(火) 17:10:24
>>334
メモリだけならチップセットレベルで対応している鯖があったと思う。
それだけでRASというのは・・・。

>>336
IA-64マシンで、オーバークロックした人の話をどこかで見た。
マシンのフラッシュメモリにログが残ることもあるが、
いずれにしろWindowsはさっくりと落ちたそうな。
0379名無しさん@お腹いっぱい。2006/01/03(火) 17:17:05
>>346
>UltraSPARC-IIなんてCacheがECC保護されておらず
>サーバが落ちまくったものだ。

この件については私は「TIの設計または製造上のミス」で特定のロット
のSPARCが不良品だったのではないかと疑っている。それを宇宙線
のせいにしてリコール隠しをしたのではないかと。
0380名無しさん@お腹いっぱい。2006/01/03(火) 17:18:14
RAS機能が期待通りの動作するかどうか、検証してる?

動いている状態のダイにピンポイントでα線打ち込んだりするのかな?
0381名無しさん@お腹いっぱい。2006/01/03(火) 17:21:25
>>379
ECCがあれば大丈夫、なんてことはないと思う。

頻繁にビットが化けると、
ECCで訂正どころか検出すらできないほど化ける
ことだって、運が悪ければありうるから。

0382名無しさん@お腹いっぱい。2006/01/03(火) 17:24:28
> 頻繁にビットが化けると、
> ECCで訂正どころか検出すらできないほど化ける
> ことだって、運が悪ければありうるから。

こういうケースは、普通はブート前のOBP/POSTの診断ではねられる。

動作中にこのようなケースが起きたら(ハード故障)、OSはパニックし、
ハード・ソフトが2重化されていないければ、システムは停止するけれど、
このような激しいハード故障がいきなり起こるのはまれではないかな。



0383名無しさん@お腹いっぱい。2006/01/03(火) 17:43:04
>>366
そんな事ないと思うよ。
Sunの元気が無いだけにヘテロな環境にならざるを得ないというのもある。
0384名無しさん@お腹いっぱい。2006/01/03(火) 17:43:52
>>381
メモリなら理屈的に判るが、CPUのCacheでECCが有っても不安!?
やはり日常的に隕石が自分に当たらないかとか心配かね?
0385名無しさん@お腹いっぱい。2006/01/03(火) 17:54:32
>>376
F通のSPARC64GPも、CPUのキャッシュがECC保護されておらず、ただのパリティだった。
GP7000シリーズは、1年に1回くらい、キャッシュのパリティエラーで落ちた
0386名無しさん@お腹いっぱい。2006/01/03(火) 18:05:52
>>385
ググッたら出てきたけど、FUDでつか?
http://primeserver.fujitsu.com/primepower/products/lineup/pp200/
> SPARC64 GPでは、キャッシュメモリを全てECCで保護。
0387名無しさん@お腹いっぱい。2006/01/03(火) 19:31:21
>>379 おれも、製造不良、設計不良を疑っている。が、二次CacheがECC保護されて
いれば助かったケースも多かったと思う。
この板では宇宙線がどうのとちゃかしている人がいるようだが、Sunの大型サーバが
Cacheのエラーで落ちていたのは良く知られる話だよ。
メーカーが言うように宇宙線の影響なのか、品質の問題なのかは知らないけど。
0388名無しさん@お腹いっぱい。2006/01/03(火) 19:37:15
でかいサーバは落ちるととんでもなく起こられるんで、PRIMEPOWERみたいに
しつこい位のエラー検知・訂正機能を備えている位でちょうど良い。
>>385
富士通機でも昔はけっこう落ちたんだ。
Sunは今でも...
0389名無しさん@お腹いっぱい。2006/01/03(火) 19:44:34
>>382
>普通はブート前のOBP/POSTの診断ではねられる
10分以上かけてチェックするくせに、意外とはねてくれない。
そのため、手動でblacklistに追加するなんて言う保守を行っているケースも
少なくは無い。
PRIMEPOWERだと一度障害を起こした箇所はPOST通っても切り離したままに
しておいてくれると聞いたけど。
APLが出れば、全て解決かな。
0390名無しさん@お腹いっぱい。2006/01/03(火) 19:49:07
> >普通はブート前のOBP/POSTの診断ではねられる
> 10分以上かけてチェックするくせに、意外とはねてくれない。
> そのため、手動でblacklistに追加するなんて言う保守を行っているケースも
> 少なくは無い。

OBP/POSTの診断は、Diskの不良セクターとは違うよ。
サーバのは特に念入りに行うはず。

普通のPCの場合は....ダメかな。。。(ま、用途が違うので当たり前)
その代わり、お手軽に買えるので、それはそれでいい。

0391名無しさん@お腹いっぱい。2006/01/03(火) 19:52:37
T1000/T2000には本当にがんばってもらいたい。
これが売れなければ、ボリュームラインの1U/2UサーバはLinux/Windowsの
侵食を防ぐ事すら出来ないだろう。
0392名無しさん@お腹いっぱい。2006/01/03(火) 20:01:53
>>390
> OBP/POSTの診断は、Diskの不良セクターとは違うよ。サーバのは特に念入りに行うはず
念入りに行ってもPOST通ってしまう事が良くあるんだよ。
もしかして素人とでも思っている? わざわざblacklistと書いているのに
0393名無しさん@お腹いっぱい。2006/01/03(火) 20:17:15
メモリの診断なんてそんなに念入りにやってない
cacheなら容量少ないし、念入りにやってんじゃないかな
0394名無しさん@お腹いっぱい。2006/01/03(火) 20:37:20
メモリは指定しないと全部を確認しないよ、確か。
OSがブートできる程度ぐらいしか、デフォルトでしなかった気がする。
これだと、ブート後に2bit壊れている(UEエラー)のメモリを触ると
パニックしてしまう。パニック後は、壊れたメモリを切り離して
リブートする。

全メモリを診断して、2bit壊れている(UEエラー)のメモリを見つけると
切り離してからブートするはず。


0395名無しさん@お腹いっぱい。2006/01/03(火) 20:43:31
> これだと、ブート後に2bit壊れている(UEエラー)のメモリを触ると
> パニックしてしまう。パニック後は、壊れたメモリを切り離して
> リブートする。

ちなみに今は、カーネルが2bit壊れているメモリを触った場合だけ
パニック。ユーザアプリが2bit壊れているメモリを触った場合は、
プロセスを停止して、そのメモリ(ページ)を切り離す。

0396名無しさん@お腹いっぱい。2006/01/03(火) 21:02:52
>390
PC だと memtest86 実行するのにどれくらいかかるか、知らないの?

で memtest86 通らないものでも数GBメモリ積んでたら
数分(10分オーダー)かける ECC 初期化&POSTチェックは大抵通る。
まあこちらのテストはエラーチェック目的ではないけど、
エラーチェックをしようとしたらどれだけ時間がかかるかってことですね。
0397名無しさん@お腹いっぱい。2006/01/03(火) 21:13:38
月に1回とか年に1回、エラー検出不能なエラーが出るくらいの頻度では、
POSTなんかでは検出不能だと思う。POSTに1ヶ月とか1年かけるならともかく。

検出できないエラーは、そのまま正常に処理されたデータとして扱われるので、とても厄介よ。
0398名無しさん@お腹いっぱい。2006/01/03(火) 22:28:51
>>386
ttp://magazine.fujitsu.com/vol51-4/paper06.pdf を読むと、一部、パリティ保護の
部分もあるようだがパリティエラーでシステムダウンとなるかどうかは不明。
0399名無しさん@お腹いっぱい。2006/01/03(火) 22:33:01
ほんと盆暮正月はレベル下がるなぁ... サーバー落ちまくるのの原因が cache の ECC が
ないせいだなんて... 笑える。そんなレベルで機種選定するやつ実在するんだな。びっくりだ。
(ま、選定にクチはさめる立場の人間とは限らんがなw)
0400名無しさん@お腹いっぱい。2006/01/03(火) 22:48:45
>>399
保守している経験からすると、CacheのECC errorで落ちるマシンが多いのは
事実。(UltraSPARC-IIの時代はparity error)

この部分を以って機種選定をするとは誰も言っていないでしょう。
大型のサーバでは外せない常識的な機能であると言っているだけ。
次期サーバではチップキル位は装備して欲しい。
Cacheの障害の次に多いのがメインメモリの障害だから。

>>399 パリティエラーを検知すると、もう一度トライする。
それでもダメだった場合は、395の通り。カーネルの場合はpanic
0401名無しさん@お腹いっぱい。2006/01/03(火) 22:58:08
Sunの場合、あんまし品質が良くないんで(I、h、Fに比べて)、
エラーのリカバリ機構はふんだんに搭載して欲しいって事。
x900や20K、25Kが落ちた日には胃が痛くなるでしょ。
0402名無しさん@お腹いっぱい。2006/01/03(火) 23:01:31
チップキルより、システムボードまたいでミラーして欲しい。
メモリRAIDなら尚うれしい。
0403名無しさん@お腹いっぱい。2006/01/03(火) 23:12:31
サーバ機でPOSTのレベルをmaxにすると30分以上かかるんじゃなかったっけ
0404名無しさん@お腹いっぱい。2006/01/03(火) 23:16:44
cache ECC エラーが頻発するってことは、なんか別に原因があるでしょ? >>379 みたいに
製造上の欠陥とか。ECC がないのが原因なわけがない。付いてれば継続運用はできたかも
知れないけどね。ECC 付けたら本質的な問題が解決するわけじゃない。
0405名無しさん@お腹いっぱい。2006/01/03(火) 23:26:22
>>404 みんなそう思っているんじゃ?
0406名無しさん@お腹いっぱい。2006/01/03(火) 23:30:13
品質問題は、Sunである以上、ある程度見込んでおかないと。
エラー訂正でカバーしてあげないと怖くて使えない。
APLは富士通と共同で設計されるマシンだから期待はしているが。
# E10000から素晴らしく改良されたはずのsf15000やsf25000があれでは
04074062006/01/03(火) 23:32:38
蛇足だけど、俺はSunが好きです。復活して欲しいと思っている一人。
でかくて高いサーバは、処理能力もさる事ながら、信頼性でも優れて
いないと売れないからね。
0408名無しさん@お腹いっぱい。2006/01/03(火) 23:34:09
FT機、大々的にやってくんないかな。売れそうも無い?
0409名無しさん@お腹いっぱい。2006/01/03(火) 23:39:18
T1000/T2000を評価した方いる?うちの会社、まだなんだわ。
Sunが言うように、Webアプリサーバで高性能なら期待の星なんだが。
あと、メールサーバ、アンチウイルスゲートウェイとか。
0410名無しさん@お腹いっぱい。2006/01/03(火) 23:44:23
Sun Ray スタートパック、Sun Ray 1g 2 台と Ultra20 で 20 万円かぁ。買ってみようかなぁ..
0411名無しさん@お腹いっぱい。2006/01/03(火) 23:49:53
個人で?
0412名無しさん@お腹いっぱい。2006/01/03(火) 23:56:05
一応会社。ほぼ個人だけどw。評価用に。
0413名無しさん@お腹いっぱい。2006/01/03(火) 23:56:36
http://jp.sun.com/promotions/spack2006/
漢ならSun Ray スタートパック 2逝っとけ
04143852006/01/03(火) 23:59:36
>>388
漏れの記憶では、CPUの1次キャッシュのデータ部や命令部分そのものはECC
で保護されていたが、キャッシュのタグは、パリティで、エラーは検出するが訂正
はできなかった。
0415名無しさん@お腹いっぱい。2006/01/04(水) 00:26:50
>>414
SPARC64Vでも1次キャッシュはデータだけがECCだよね。
でも、Sun含めて他の会社のCPUは、1次キャッシュはデータ含めてパリティのみ
がほとんどだから。(メインフレーム用CPUだけかな。ここまでやんの)
0416名無しさん@お腹いっぱい。2006/01/04(水) 00:29:42
>>413 SunRayは素晴らしい機械だが、結局Windows環境は必要になるんで。
Windows2003 ServerやTaranteraを買うと割高になる。
WBTの方が安上がりなのは痛い。
IS部門からすると悪夢かもしれんけど、HotDeskは便利だよ!
0417名無しさん@お腹いっぱい。2006/01/04(水) 00:43:04
漏れの会社はSunRayに移行中...
SunRayに限った話じゃないんだが、Thinクライアントになると、便利な
ユーティリティをインストールする事が(権限の関係で)出来なくなるのが
つらい。情報システム部門のお仕着せ環境しか使えない。
これはかなり悲しいぞ。
SunRayはUNIXベースなんだからemacs位入れて欲しい...
メーラーも使いやすい物を使わせて欲しい...
0418名無しさん@お腹いっぱい。2006/01/04(水) 00:50:28
アプリなら自分のホームディレクトリにインスコすれば良いと思うけど。
0419名無しさん@お腹いっぱい。2006/01/04(水) 00:53:30
さすがにgcc+emacs+漢字変換をホームに入れるのは...
Windows系のアプリだとレジストリいじるやつがいて...
0420名無しさん@お腹いっぱい。2006/01/04(水) 01:16:09
>>417
業務に必要なら申請できるはずだけどダメなの?
0421名無しさん@お腹いっぱい。2006/01/04(水) 01:52:29
>>419
Web ブラウザーのキャッシュサイズとか考えたらたいした大きさじゃないようなw。
/opt 下とかに入れてもらうほうがいいけどね。pkgadd するだけなんだし。
妙な言い訳で断られるようなら、みんなバカスカホームディレクトリに
入れ出したら管理者も考えるだろう、という線もありかも。
0422名無しさん@お腹いっぱい。2006/01/04(水) 08:37:55
SunRayって鯖落ちたら全員死亡なのか?
0423名無しさん@お腹いっぱい。2006/01/04(水) 08:43:02
コンピューター落ちたからって死んだ人はまだ見たことないな。
0424名無しさん@お腹いっぱい。2006/01/04(水) 11:18:55
> SunRayはUNIXベースなんだからemacs位入れて欲しい...

漏れの会社には、あちらこちらにSunRayがおいてあって、
昼のご飯の後に適度に使わせて貰ってる。

ネットサーフ以外にも、ちゃんと{x}emacsが使えて、
ほどよく便利。

0425名無しさん@お腹いっぱい。2006/01/04(水) 17:48:25
>>417

418のいうとおり、パーミッションの問題なら自分のホームに
インストールすれば問題なし。

全体で共用して使いたければサーバにインストールすればいいだけ。

SunRayはインテリ端末みたいなもんだから、何を使うか、
インストールするかは、SunRayとは関係ないよ。
0426名無しさん@お腹いっぱい。2006/01/05(木) 02:45:57
エラーが頻発してるけどECCでエャ堰[訂正できてb驍ゥら大丈夫

なんて恐ろしいことは言えないよ

エラー検出できてない可能性だってあるんだから。
0427名無しさん@お腹いっぱい。2006/01/05(木) 13:01:58
大気圏外ではそうやって使うんだろ、きっと。
0428名無しさん@お腹いっぱい。2006/01/05(木) 13:21:15
大気圏外運用の世界では
"メモリに 1bit error 起きますた!"
"ECC にて自動修復された模様でありますっ!"
みたいな連絡・報告が人間組織の中でビビビっと飛びまくります

エラー頻発なんて状況は… 恐ろしい
0429名無しさん@お腹いっぱい。2006/01/05(木) 17:37:33
製造不良を検知して自動修復する機能を入れてはどうか?
0430名無しさん@お腹いっぱい。2006/01/05(木) 18:17:59
そんでその機能が初期不良なんだな。
0431名無しさん@お腹いっぱい。2006/01/05(木) 18:21:18
滅多に動作しないものにこそバグが潜んでるからね
0432名無しさん@お腹いっぱい。2006/01/05(木) 18:33:40
その機能が頻繁に動作すれば品質は上がる。
よいよい。
0433名無しさん@お腹いっぱい。2006/01/05(木) 20:29:10
「はやぶさ」はリスタートしたんと違う?
0434名無しさん@お腹いっぱい。2006/01/05(木) 22:48:05
はやぶさってイトカワに衝突してあぼん?w
0435名無しさん@お腹いっぱい。2006/01/06(金) 07:26:25
>>426 じゃぁ、Sunのx900は使えないね。
エラー修復のメッセージ、月1位で出るぞ
0436名無しさん@お腹いっぱい。2006/01/06(金) 09:51:55
月1位で 1bit error だったら
2bit以上のエラーが起きる可能性はそこそこありそう
0437名無しさん@お腹いっぱい。2006/01/06(金) 13:36:59
ツマンネ
0438名無しさん@お腹いっぱい。2006/01/06(金) 13:38:04
?
0439名無しさん@お腹いっぱい。2006/01/06(金) 17:50:13
>>435
そりゃ不良品だろ。早く直せ。
0440名無しさん@お腹いっぱい。2006/01/09(月) 06:19:58
「ソフトエラーは、ほかの信頼性メカニズムのすべてを含めたものの中でも、最
も高い不良率を引き起こしている」
ttp://www.ednjapan.com/content/issue/2005/02/feature/feature02.html
0441名無しさん@お腹いっぱい。2006/01/09(月) 08:29:45
>>439
え?
0442名無しさん@お腹いっぱい。2006/01/09(月) 08:58:40
ソフトエラーはいいんだよ、普通の頻度で発生してりゃ(稀って意味で)。
ECCでエラー訂正するんだから。

でも、素子が壊れてたりしてハードエラーになったりすると、2bitエラーに
波及しないように交換する。

1bitエラーのメッセージは、月1,2回程度の発生してECC訂正する程度であれば
抑制されるはずだから、普通は気づかない。

でも、ECC訂正の頻度が上がると1bitエラーのメッセージが出力されるので、
それを見たら2bitエラーにならないように予防保守として交換すればいい。
0443名無しさん@お腹いっぱい。2006/01/09(月) 14:11:48
メッセージが表示されるということは、内部である期間内に一定回数以上のエラーを検出しているということ。
ソフトエラーだとメッセージ表示まではあまり達しないと思うので、メモリがハードウェア的に悪いのかもしれない。
毎回同じビットが化けているのか、そうでないかとかにもよるけど。
0444名無しさん@お腹いっぱい。2006/01/09(月) 17:55:03
おまいらメモリエラーの話大好きだな。
なんでもいいからとりあえず替えとけよ。
0445名無しさん@お腹いっぱい。2006/01/09(月) 21:39:51
止めんのめんどい。
0446名無しさん@お腹いっぱい。2006/01/09(月) 21:40:31
>>444 アホだなぁ。下手に交換するとさらに悪化する場合があるんだよ。
0447名無しさん@お腹いっぱい。2006/01/09(月) 21:43:51
エラー起こしている間はメーカーのせい。
交換して悪化した場合土方のせい。
0448名無しさん@お腹いっぱい。2006/01/09(月) 22:29:27
放射線でソフトエラーが起きやすいのはDRAM
CPUのキャッシュに使われているのはSRAM

信頼性よりも製造コスト優先の糞メーカーのDRAMだと、ソフトエラー起きやすい。

0449名無しさん@お腹いっぱい。2006/01/10(火) 00:18:00
放射線によるエラーは、DRAMの静電容量だかなんだかに依存するはずで、
製造コストは関係ないんじゃないの。
タイミング関係のマージンがぎりぎりぎりでも通しちゃうために放射線
じゃなくてタイミング問題で化けるとかなら、製造コストの問題だけど。
0450名無しさん@お腹いっぱい。2006/01/10(火) 04:55:24
Windows VistaのAero Glassは超高負荷みたいだね
http://pc.watch.impress.co.jp/docs/2005/1220/kaigai230.htm
0451名無しさん@お腹いっぱい。2006/01/10(火) 10:58:49
Microsoft は Intel 揺さぶってるんじゃないか? 最近そういう行動が目立つような。
0452名無しさん@お腹いっぱい。2006/01/10(火) 16:14:19
>>450
やっぱ(あの重い)Looking Glassより、さらに重いんだろなぁ。
ところでLooking GlassってJAVAで書かなければもう少し軽くなるの?
0453名無しさん@お腹いっぱい。2006/01/10(火) 17:55:33
>>449
静電容量を大きくするのにコストがかかる。
0454名無しさん@お腹いっぱい。2006/01/10(火) 19:07:47
そんなところにはコストはかからんでしょ。
0455名無しさん@お腹いっぱい。2006/01/10(火) 21:31:10
製造コストが減るし、
静電容量を確保するための技術開発も不要になる。

http://pcweb.mycom.co.jp/articles/2005/12/08/iedm2/

Infineonは30fF
Samsungは25fF
0456名無しさん@お腹いっぱい。2006/01/10(火) 23:14:00
> そんなところにはコストはかからんでしょ。
半導体の話になると、頓珍漢な事を言い出す奴が多いな。
大気圏外ネタとか。
0457名無しさん@お腹いっぱい。2006/01/10(火) 23:37:24
【エラー】メモリを語ろう【大気圏】
でも立ててそっちでやってくれ
0458名無しさん@お腹いっぱい。2006/01/11(水) 00:27:38
セル容量はチップ面積(==コスト)に直結する。
放射線はパッケージの材料から出る。高純度の材料は高い。
0459名無しさん@お腹いっぱい。2006/01/11(水) 01:04:38
>>456
意地でも ECC 必須の結論に誘導したいヤツが 1 名だろ?
それもトンチンカンな状況説明で。
0460名無しさん@お腹いっぱい。2006/01/11(水) 04:56:23
>>459
「備えあれば憂いなし」ではあるけどな。
0461名無しさん@お腹いっぱい。2006/01/11(水) 07:42:34
損部レ炉、損部レ炉〜
■ このスレッドは過去ログ倉庫に格納されています