エンドユーザーのストレステストハードウェアは目的にかなっていますか?


2

エンドユーザが特定の種類のハードウェアを「ストレステスト」するための良い方法を求める質問が時々出てきます。これはそれらの1つではありません。

むしろ、私は尋ねています ハードウェアのエンドユーザーによるストレステストが実際に実際の目的にかなっているかどうか。

1〜2パスでMemtest86 +を実行してRAMスティックがインストール後もまだ問題ないことを確認するなど(インストール中に静電気が放電されないなど)、出荷中に何も問題がないことを検証するハードディスクのSMART搬送テスト損傷など 新しいハードウェアで 合理的な製造業者によって出荷されるように、 ストレステストでは検出できるが、通常の使用では検出できない可能性がある、初期の故障モードがいくつかありますか?

これを「意見に基づいた」ものにしないようにするために、あなたが具体的な参考文献を提供できるものに対する回答を限定し、行われた主張に対する参考文献を提供してください。


"実際には" なにかの?製品開発かエンジニアリングかそれともエンドユーザーとして? QAとDVTはストレステストを実施して、設計プロセスや製造プロセスを検証します。
sawdust

@sawdustは私の例の言及でカバーされていると感じましたが、私がエンドユーザーによるストレステストを意味することを明確にするために編集しました。
a CVn

「ストレステストでは検出できるが、通常の使用では検出できない可能性がある、初期の故障モードがいくつかありますか?」あなたはキーポイントを逃しています。箱から出してすぐに死ぬシステムのいくつかの小さな割合があります。インストール、設定、カスタマイズ、微調整などを行うのに何日も費やすことができますが、それがこれらのシステムの1つである場合は、その作業のすべてを失うことになります。その期間にテストを実行しても失敗しても、時間を失うことはありません。失敗は通常の使用で検出可能であり、それが代わりにそれをテストする理由です。
fixer1234

@ fixer1234意図的な「ストレステスト」は、Windowsデスクトップ(またはBIOS / UEFIセットアップ)を起動してシステムを数日間放置するだけではなく、これらのエラーを検出するのにどのように役立ちますか?またはMemtest86 +、SMART搬送テストなどを実行していますか?
a CVn

私の言いたいことは、システムが使用の初期段階で失敗するようなものである場合、その失敗を引き起こすためにシステムを実行する無人のアクティビティを実行することは時間の投資(およびファイルの損失)よりも望ましいことです。通常の使用いくつかの/任意のアクティビティを実行することは、座っているがアイドル状態であることよりも失敗の引き金を引くことにおいて優れています。システムを圧迫するような何かを実行すると、失敗を引き起こす可能性がはるかに高くなります。さまざまなコンポーネントが失敗する可能性があります。あなたが強調しているそれらが多いほど、早すぎる失敗を見つける(引き起こす)可能性が高くなります。統計です。
fixer1234

回答:


1

ごくわずかな割合のコンピューターでは、途中で失敗します。あなたの質問は、テストする価値があるかどうかではありませんが、 もし あなたがテストする、ストレステストが良いです。出発点は、あなたのマシンは早すぎる時期に故障する10,000台のマシンであり、あなたの目標はその失敗を引き起こすことです。それを実現するための最善の方法は何ですか? (失敗しなかった場合、テストに合格しました。)

失敗する可能性があるさまざまな部分がたくさんあり、トリガーはシステムを短時間起動するだけの場合もあれば、システムがウォームアップしたときには一般的に熱くなっている場合もあります。どの部分またはどのトリガーが早期故障の原因になるかを知る方法はありません。機械的(振動または熱膨張および収縮)など。

システムの電源を入れてアイドル状態にしただけでは、システムの起動や一般的な温度に敏感な問題を引き起こすのに十分な場合があります。 Memtest86 +を実行すると、RAMがテストされます。包括的なストレステストを実行すると、実行しないよりもはるかに多くのトリガーが発生する可能性があります。テストするものが多いほど、またテストする時間が長いほど、失敗を発見する(引き起こす)可能性が高くなります。

私は、少なくとも特定の方法によるテストの実際の利益に関して、統計が存在しない(少なくとも一般に利用可能な)と言うように冒険するでしょう。時期尚早の失敗は、ある種類のテストの利点と別の種類のテストの利点、またはある期間または別の期間のテストの利点を引き分けるために意味のある数を生成するにはあまりにも稀です。

あなたがその不運なコンピュータを手に入れた不運な魂で、あなたがそれをセットアップして重要なファイルを蓄積することに多くの時間を費やした後、それが死んだならば、あなたはおそらくかなり愚かです。それで、あなたがそれを使い始める前に、ある種の標準テストをする価値がありますか?それは何を傷つけますか?あなたが最初にそれをテストすることにした場合、それが練習の目的であるので、最も有用なテストはあなたが見つけることができる最も包括的なストレステストでしょう。

相対的な利益に関する確固たるデータがない場合は、どの程度のテストで快適性レベルが満たされるかについて「管理上の決定」を行う必要があります。熟考すること:問題なくそれをテストしてから、それをセットアップして重要なファイルを蓄積することに時間を費やすと、とにかく死んでしまいます。あなたが最初にそれをテストするために時間を費やしていなかった場合よりあなたはもっと混乱するでしょうか?それは別の決定要因です。


0

いいえ。簡単な大まかなテストでは、ハードウェアが早期に故障する運命にあるかどうかを示します。ストレステストは必要ありません。試作品に対してストレステストを実施して、市場向け製品の大多数が期限内に故障しないことを確認します。これが「製造元の保証」の目的です。彼らはすでに彼らの製品のサンプルをテストしたので、あなたはそれらがデバイスが持続すると確信している最低限の時間であることを確信することができる(例えば100%で走ること)または製造業者の欠陥。実際、1週間のストレステストの後にハードウェアを焼き尽くした場合、彼らはあなたの保証が無効であると主張するかもしれません。

ハードウェアは、通常の状況下では約80%の容量で快適に稼働することを目的としています。残りの20%は「バースト」許容範囲と見なす必要があります。平均的な使用量が許容範囲内であれば、短期間の極端な使用量でもハードウェアが故障することはありません。あなたはこれを車と比較することができます。自動車のエンジンの最大回転数は8000ですが、「赤い線」はもっと低く、おそらく6500回転です。常に6500 RPMを超えて走行すると、エンジンの寿命が短くなります。同様に、ハードウェアをストレステストしても、それ以降のどこかで早期の障害が発生するだけです。

容量が80%を超えるファイルシステムは、新しいファイルを効率的に書き込むためのOSの能力を低下させます。容量が80%を超える電源装置は、内蔵ハードウェアを早く消耗し、故障は早くなります。常に80%を超える容量で稼働しているCPUは、より早く過熱するか、ハードウェアが冷えている間は容量が減って動作する可能性があります。コンピュータの各部分は最大の許容誤差で構築されていますが、日常的に使用されることは想定されていません。

一般に、通常の速度で実行されるハードウェアは、常に最大容量で実行されるハードウェアよりもはるかに早く(修理または交換のための時間がかかりますが)失敗することを示します。 CPUが遅くなり始め、電源装置が定期的に「電圧低下」し、ファイルをハードドライブに保存する時間が長くなります。同じハードウェアを常に最大限の能力で実行しているのであれば、たとえそのストレステストが短いとしても、ハードウェアを交換する以上のことができないほど遅くなるまで、問題に気付かないでしょう。

使用する予定の容量だけを購入するよりも、必要以上の容量を持つハードウェアを購入する方が適切です。長期的には、このような購入はハードウェアの寿命を延ばすでしょう。単純な1週間のストレステストでも、ハードウェアの寿命を数ヶ月から数年短縮する可能性があるため、購入するハードウェアを悪用しないでください。


素晴らしい答えであり、個人的には私はあなたの主張に同意するでしょうが、OPが話していたような言及はありません。あなたの答えと一緒に行くための「証明」や参照がありますか。
agtoever

それはどこにでも、そしてどこにもありません。あなたは90%を超えてWindowsドライブをデフラグすることはできないことを知っていてください。 PSUの製造元は、通常の負荷で80%の容量で稼働するユニットを購入することをお勧めします。大部分の大規模データベースベンダーは、少なくとも20%の物理メモリを空けておくことをお勧めします。新しいラップトップには、充電量を80%に抑える「バッテリー延長」ソフトウェアが付属しています。この数字は、文学のいたるところに見られるので、無視するのは困難です。エンジニアは80%がマジックナンバーだと決心しました、あなた自身の危険を無視してください。
phyrfox
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.