質問: apmを無効にするか、オーバークロックの安定性のためにロードラインキャリブレーションを有効にすることが望ましいですか? amd fxシリーズプロセッサは、9シリーズチップセットとペアになっており、apm(アプリケーションパワーマネージメント)を無効にするオプションを公開しています。 ほとんどのオーバークロックガイドでは、安定性を高めるためにapmを無効にすることを推奨しています、少なくとも最初は。これらの中には、公式の amd fxパフォーマンスチューニングガイド の5および10ページがあります。 apmは事前定義されたtdp制限を設定するため、通常は無効にすることをお勧めします amd turbo coreテクノロジーと[〜#〜] apm [〜#〜] cpu周波数を上げるときの機能の両方デフォルト電圧を超える電圧。 ron's tech tips もこれを言っています: 簡単に言えば、amd application power management bios設定は、チップが設計された125w(8コア)または95w(4および6コア)tdp内にcpuがとどまることを保証します。 apmがcpuのスロットルを引き起こすという多くの言い方を私は見てきました。時々、apmがこれを引き起こすことは事実ですが、スロットルは常にそうすることではありません。 cpuをより高いクロックレートに保ちながら、電圧がわずかに低くなる場合があります。 すべての強調は私のものです。さらに、最近のほとんどの愛好家のマザーボードは、load-line calibration(llc)と呼ばれる機能も提供しています。 linus tech tips 'forums に投稿したユーザーによると: vdroopは、負荷が増加するにつれてcpuに供給される電圧の低下です。基本的に、アイドルから負荷に移行すると、電圧が低下します。オーバークロッカーが動作している小さな電圧許容誤差(増加した電圧は、オーバークロックが達成できるcpu周波数/乗数に比例する)を前提として、cpuに適用される電圧の垂下は、理論的に安定したオーバークロックを不安定にする可能性があります(設定周波数を達成する) llcなしの定義済み(x)と測定済み(y)のvcore値の違いは次のとおりです。 実際のvcore値が常に期待値を下回っていることに注目してください。次の画像では、その特定のcpu(i7 3930k)とmobo(asus rampage iv extreme)のllc設定が「高」(50%の値)で、vdroopを補正するのに十分であることがわかります。 tl; dr私が思っているのは、apmを無効にして(おそらく)低いllcレベルで解決する(時にはまったく必要ない場合がある)か、apmを有効にしておくために、より高いllc設定に頼る必要があるのかということです。すべてが安定しています。私の懸念は、この順序で: システムの安定性 計算の完全性 システムの耐久性(それほど重要ではない) 熱出力と消費電力(重要性はさらに低い) / tl; dr(追加情報) これを尋ねる理由は、この質問ですでに述べたように、より高いllc設定がcpuコアに短い電圧スパイクを導入するためです。< オフセットを使用するか、手動で設定したcpu電圧( cpu longevitityに関して)? >、そしてこの master's lair post も同様です。引用: あなたがまともなマザーボードを持っているなら、ロードラインキャリブレーションはより高いオーバークロックに関してあなたに本当に何も買いません(...)。 biosで設定する必要があるvcoreを人為的に低下させるだけですが、cpuに負荷がかかった場合でもcpuは同じ量の電圧を必要とします。 必要なオーバークロックを達成するのに苦労していて、過度のvdroopが問題であると思わない場合を除き、[llc]を無効のままにしておくことをお勧めします。 一方では、apmはtdp全体の上限を「単に」実施するだけではないので、反対の提案があっても、可能であれば有効にしておくべきだと思います。しかし、もう1つは、apmが不安定になるため、llc設定を高くする必要があり、それ自体がおそらくもっと悪いことです。完全性:- cpu: fx-6350 @ 4.8 ghz (default is 3.9) - motherboard: asus sabertooth 990fx r2.0 - turbo core: off - cpu offset voltage: +0.09375v - apm master mode: on - c1e, c6 state, cool'n'quiet: all enabled (on) - cpu load line calibration: ultra high (75%) - cpu power phase control: standard - cpu power duty control: c.probe (current) - spread spectrum is off for cpu, cpu-nb and vrm. ノート: 以前はこのクロック速度でllc high(50%)で実行していましたが、100mv(+0.1)のvcoreオフセットを使用しても、4時間30分テストした後、prime95で計算エラーが発生しました。 次に、オフセットを6.25mv下げ、llcを超高に変更しましたが、エラーは発生しません。 ただし、これにより、負荷電圧が平均20mv上昇し、特定の負荷遷移時に12mvのスパイク(結果として1.488v)が発生しました。これは、理想より少し高くなっています。 日中の長時間の数値計算の後、cpu温度は最大63°Cでした。これは空冷式システム(かなりのクーラーですが、hyper 212x)で、-85mvのオフセット(低電圧)で2年間うまく機能しました もう一年は働き続けたいです。
回答: tl; wr apmは少なくとも私の設定では安定性に影響を与えません llcは、しかし、実際には、私の場合、エラーのない安定したオーバークロックを得るために絶対に必要です。 (また、興味深いことに、ほとんどの場合、オフセット電圧をまったく構成できません)。 apmはパフォーマンスに負荷をかけます。ただし、一般的には有効のままにしておくことをお勧めします。これにより、より高いクロック速度を構成できるため、システム全体のパフォーマンスが向上します。軽くスレッド化されたワークロード。また、電力も節約できます。 これはそれを行う方法です: (prime95の小さいfftテスト中に6つのワーカースレッドで取得されたキャプチャ)(24k fftサイズ) 精巧 ron's tech tips によると: 実際にapmを無効にすると、cpuが125w tdp範囲外で実行されます。本質的には、より多くの電力と電圧を引き出し、より多くの熱を生み出して、ほとんど利益がありません。 (...) そして apm(application power management)(...)を無効にすることをお勧めする唯一の時間と状況は、次の場合です。 とにかくtdpの制限を超える4.9〜5ghzの範囲で計画された高オーバークロックのための、cpu向けの非常に優れたハイエンド液体冷却ソリューション。 (...) apmがシステムの安定性に影響を与えることを示すものは何もありませんが、(質問からの)前の引用がそうであることを示しているようです()cpuを高い状態に保ちながら電圧がわずかに低くなる場合がありますクロックレート ")。したがって、私はこれを次のシナリオで自分でテストしました: 4800 mhz @ 0.09375vオフセット。 llc [超高]; apm [有効] 同上、apm [無効] そしてそれを観察した: apmはシステムの安定性にまったく影響しません cpuパフォーマンスは3.27%増加し、passmarkパフォーマンステストで9132ポイントに達しました。これは fx-837 よりも高いスコアです: 最も注目すべき点: 浮動小数点のパフォーマンスが8.14%増加 sseパフォーマンスが8.93%増加しました(sseはfpの観点から実装されています) 素数の計算も10%高速です 整数のパフォーマンスは変更されていません ただし、罰金が科せられることはないため、高コストになります。prime95で全負荷をかけて15〜20分で73°Cに達します。これは、約16%熱が多く、cpuの熱マージンを3°C超えています。明らかに、空冷では維持できません。次に、これらのシナリオをテストしました。 4700 mhz @ストック電圧(オフセットなし); llc [超高]; apm [有効] 4500 mhz @同じ(電圧オフセットなし、llc ultra)、apmあり[無効] 結果は次のとおりです。 どちらも同等に非常に安定しています 電圧は、4500 mhzの場合は1.44vに固定されたままで、apmを使用した4700 mhzの場合は平均で約1.428vです。 消費電力は〜266.6 va、4700 mhz + apmの場合は最大239.9で全負荷時(クランプメーターで測定。実際の消費電力はワット単位で少し低くなります) アイドル時の電力はそれぞれ62.1 vaおよび64.7 vaです。 最大温度は4500 mhzで65oc(ソケット)、61.1oc(tcl)、75oc(vrm)でした。 4700 mhz + apmの場合、57°C(ソケット)、52.1°C(tcl)、68°C(vrm)。 windows 10 64ビットおよびarch linuxでmingwを使用して大規模なプロジェクトをコンパイルすると、4700mhzのセットアップで約3.8%高速になりました。 w10でvisual studioを使用してコンパイルし、handbrakeを使用して2分1080pビデオを変換すると、4700mhzで1.5%高速になりました。 passmark 2dグラフィックスのパフォーマンスは、4700 mhzで2.78%高速でした "basic"プリセットを使用したunigine heavenベンチマークは、平均して3.5%高速でした。 fpsは4700 mhzで6.84%高速でした エンコードはfp集中型のタスクであるため、この構成では浮動小数点のパフォーマンスが低くても、ハンドブレーキを使用したトランスコーディングがapmを有効にした4700 mhzで高速だったことに少し驚きました。最も可能性の高い説明は、テストの期間が短すぎたため(6min16s)、cpuを著しくスロットルさせることができなかったことです。そのため、同じビデオを「キュー」で2回変換し、合計テスト時間は13分03秒でした。 apmなしで4500 mhzに切り替えると、12m44segになり、2.49%速くなりました。 そして、これは私がなんとか再現した、「クロックが低く、apmが無効になっている構成の方が速い」唯一の「現実の」シナリオでした。 現在、これは10%以上の電力(およびより高いサーマル)を備えているため、最も特殊化されたfp集約型アプリケーションを除いて、理想的とは言えません。