[閒聊] Intel的最終防縮肛CPU微碼0x12B的分析

看板PC_Shopping (個人電腦購買)作者Kazama168 (チャキ丸)時間5小時前 (2024/10/08 01:20)推噓9(11推 2噓 13→)

留言26則, 19人參與討論串1/1

本文經過NGA 嗯嗯嗯嗯什么(ID:38922157)授權轉載這位嗯嗯嗯嗯什么寫過不少關於12-14代CPU的測試及分析有興趣的可以移至NGA看他過往文章原文連結：https://nga.178.com/read.php?tid=41965432 以下文章為了保持作者原意僅作簡轉繁並修正轉換過程中的錯字 ------------------------------------------------------------- 關於Intel的最終防縮肛CPU微碼0x12B強制開啟C1E功能的影響分析在2024年9月26日，Intel發布了最終防縮肛CPU微碼0x12B。 https://nga.178.com/read.php?tid=41799958 https://reurl.cc/E6ynxn (防縮網址掛掉備用https://community.intel.com/t5/Blogs/Tech-Innovation/Client/In tel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239) 後續到今天，各板廠已陸續發布微碼0x12B的beta或者正式BIOS更新。雖然我自己沒有更新BIOS，但根據其他已更新BIOS的用戶反饋，微碼0x12B和微碼0x129最大的區別在於其BIOS強制開啟核心的C1E功能。本帖將分析開啟C1E功能的影響。 https://i.imgur.com/SW4fLik.png

根據Intel文檔，核心C1E是核心C1的增強版。核心C0是核心正在執行代碼，為工作狀態；核心C1是核心暫停執行代碼，自動clock gating，但核心依然通電。處於C1的核心會產生預測電流；核心C1E是核心C1的基礎上，把處於C1狀態的核心的倍頻和VID請求電壓降到最低，對本代 CPU來說即降低到8x倍頻，0.8G。處於C1E的核心會產生預測電流，但由於倍頻極低，產生的預測電流非常小；核心C6是核心斷電。處於C6的核心不產生預測電流。為什麼微碼0x12B要強制開啟C1E？ Intel的公告可能給出了原因。公告翻譯：標題：英特爾第13代和14代台式機處理器不穩定問題的根本原因更新經過對英特爾酷睿第 13代和第14代台式機處理器“最低電壓偏移”(譯註：運行在相同頻率時穩定所需的最低電壓升高)不穩定性問題的廣泛調查，英特爾現在可以確認該問題的根本原因診斷。本文章將介紹英特爾對根本原因的理解，以及針對英特爾酷睿13代和14代台式機用戶的其他緩解措施和下一步措施。最低電壓偏移的根本原因英特爾已將最低電壓偏移不穩定性問題定位到IA核心中的時鐘樹電路，該電路在電壓和溫度升高的情況下特別容易出現可靠性老化。英特爾已觀察到以下條件會導致時鐘占空比偏移，並觀察到系統不穩定。英特爾已經確定了4種可能導致受影響處理器最低電壓偏移的運行場景： 1. 主板供電設定超出了英特爾的供電建議緩解措施：用於英特爾酷睿第13代和第14代台式機處理器的IDS(Intel® Default Settings)建議(譯註：2024年4月左右) 2. eTVB微碼演算法允許英特爾酷睿第13代和第14代i9台式機處理器即使在高溫下也能以更高的性能狀態運行。緩解措施：微碼0x125(2024年6月)解決了eTVB演算法問題。 3. 微碼SVID演算法請求高電壓的頻率和持續時間可能導致最低電壓偏移。緩解措施：微碼0x129(2024年8月)可解決處理器請求的高電壓問題。 4. 微碼和BIOS代碼在空載、輕載時請求的高電壓會導致最低電壓偏移。緩解措施：英特爾正在發布微碼0x12B，它包括了微碼0x125和0x129的更新，並且解決處理器在空載、輕載時的高電壓請求。英特爾內部測試比較了英特爾酷睿i9-14900K上的0x12B微代碼和0x125微代碼，內存速度為 DDR5 5200MT/s - 表明性能影響在運行變化範圍內(即Cinebench R23、Speedometer、 WebXPRT4、Crossmark)。對於使用英特爾酷睿i9-14900K和DDR5 5600MT/s內存的游戲負載，性能也在運行變化範圍之內(即《古墓麗影》、《賽博朋克》2077、《殺手3：達特摩爾》、《全面戰爭：戰錘III：瘋狂之鏡》)。不過，系統性能取決於配置和其他一些因素。英特爾重申，英特爾酷睿第13代和第14代移動處理器以及未來的客戶端產品系列(包括代號為Lunar Lake和Arrow Lake的系列)均不受最低電壓偏移不穩定性問題的影響。我們感謝客戶在整個調查過程中的耐心，以及合作夥伴在分析和相關緩解措施方面的支持。 (公告翻譯結束) 對應微碼0x12B強制開啟C1E的描述為第4點，在空載、輕載時請求的高電壓會導致最低電壓偏移。在空載、輕載時的輕重負載切換瞬間或者是像游戲這樣的瞬態負載，核心會更傾向於處於 C1狀態。在9月9日，我已演示過核心C1狀態的極大的預測電流-實際電流比例對預測升壓和電壓的影響。 https://nga.178.com/read.php?tid=41603066 核心處於C1時，可以產生300A的預測電流的同時只消耗大約40A的實際電流，預測電流-實際電流比例接近9倍。此時，實際電壓為VID_native + ACLL*預測電流 - DCLL(VRMLL)*實際電流。顯然，當按IDS規範要求的使用ACLL=DCLL(VRMLL)，實際電壓將會比VID_native高出非常多。顯然Intel已經發現了這個問題，但看起來他們無法從根源上解決，畢竟這個問題是和VRM 設計有關的，在改VRM設計之前幾乎不可能從根源上解決。那麼想要降低C1狀態的核心的預測電流，最簡單粗暴的治標不治本的緩解措施不就是把C1 狀態的核心降低到0.8G，即強制開啟C1E。預測電流和核心倍頻直接掛鉤，假如處於C1狀態的核心的倍頻從56x降低到8x，預測電流自然也就降低到了之前的七分之一。像華碩BIOS里這種強制全核心處於C1狀態的應用場景，開啟C1E對電壓的降低效果是顯而易見的。即使我使用了ACLL0.33搭配DCLL(VRMLL)0.49，開啟C1E也能把BIOS中的同頻電壓降低0. 05V多。如果是ACLL1.1搭配DCLL(VRMLL)1.1，在華碩BIOS中的同頻電壓下降幅度估計可達0.15V左右。但是重點來了，這麼做的代價是什麼呢？處於C1狀態的核心降低到了0.8G，它要恢復C0的工作狀態的同時就必須讓倍頻器慢慢恢復到正常狀態，而這個過程需要時間，這就導致了核心對於瞬態負載的響應速度變慢了。因此，持續負載比如跑分、烤機，不受C1E的影響，不會有性能損失；瞬態負載比如游戲，受C1E的影響，會有性能損失。開啟C1E會導致游戲性能下降，這一點我在用12900K時就出於好奇測試過了。我印象很深的是，那時候我在用3080玩荒野的呼喚，默認關C1E時顯卡占用率為100%，手動開啟C1E後顯卡占用率必定降低到98-99%，可復現。而像factorio benchmark這種無論是對核心調度(core parking)還是對CPU響應性能(核心提頻速度和C狀態恢復延遲)都極其敏感的負載來說，開啟C1E的影響更為顯著。舊BIOS默認關閉C1E，351FPS https://i.imgur.com/pAvJ9uD.png

舊BIOS手動開啟C1E，335FPS https://i.imgur.com/a6jv8mI.png

損失幅度接近5% 那麼開啟C1E真的能很好的防縮肛嗎？我認為並不能。已經驗證過開啟C1E後，普通使用場景下軟體抓到的最高電壓並沒有什麼變化。可能示波器抓到的峰值電壓會稍低，但如果真的想降低峰值電壓，為什麼不自己設定個更低的IA VR Voltage Limit呢？如果原有設定本來就會縮肛，那麼開啟C1E只能緩解縮肛的速度；如果原有設定本來就不會縮肛，那麼開不開C1E都不會縮。只看Intel在微碼0x129給出的1550mV電壓牆，我認為即使強制開啟C1E也是不足以避免縮肛的，只能讓普通人的普通使用強度的CPU勉強撐過5年保修期後再寄。就我而言，我自己依然會選擇使用舊BIOS+舊微碼0x10E+禁用C1E+手動1375mV電壓牆的搭配。關於舊微碼，網上一般的說法是0x11F的性能最佳，但我跑factorio benchmark總是0x10E 跑出來的結果最好，所以一直用這個。 -------------------------------------------------- 心得：根據內文分析，作者對12B微碼改善縮肛呈否定態度近期如果不是喜歡拆裝電腦的還是建議先避開13、14代的CPU -- 本篇文章有很多錯誤的地方... -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.230.249.86 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/PC_Shopping/M.1728321654.A.162.html

→

Depthsharky

10/08 01:24, 5小時前 , 1^F

10/08 01:24, 1^F

我本來也有想換回缸這個字的但我向他徵詢時說會維持原文所以就沒改了全文改的字很少... ※ 編輯: Kazama168 (125.230.249.86 臺灣), 10/08/2024 01:26:08

推

johnjohnlin

10/08 01:27, 5小時前 , 2^F

10/08 01:27, 2^F

→

johnjohnlin

10/08 01:27, 5小時前 , 3^F