Moderkortsfusk kan korta ned livslängden för Ryzen-processorer

Ok. Gigabyte X570 Aorus Master med 3900X. Körde igång en CPU-rendering i blender. Fick 85-86 procent stadigt för det här avvikelsevärdet. Så Gigabyte har tydligen kört en fuling här då.

Nej, där accepteras det av Intel. Där handlar det inte ens om hårda specifikationer utan rekommendationer. Det är först när moderkortstillverkare försöker möjliggöra överklockning av låsta (modeller utan K i namnet) som Intel brukar dyka upp och tvinga dem att ta bort det. Flera tillverkare har ju ännu en gång introducerat liknande ändringar igen så vi får se om de försvinner även denna gång.

Skillnaden är att detta i många fall inte är konfigurerbart av användaren och strider mot tydliga specifikationer från AMD. Intel släpper bara rekommendationer, de kräver inte att moderkortstillverkare följer dessa.

Hade det varit en inställning likt Multi Core Enhancement eller liknande hade jag hållt med dig om att det inte var någon nyhet dock. Om de inte hade mörkat detta utan istället lämnat det som en inställning hade jag däremot inte haft något emot det.

3700X Stock + Gigabyte Aorus X570 I Pro Wifi:
CB Multi: ca 86% (4625 CB)
Prime95: ca 91-93%
PPT och EDC når 100% nästan samtidigt i bägge fallen, i CB är det dock PPT som ligger något högre och tvärtom i Prime95.

Inte helt lyckat att visa fel på det viset på ett mITX-moderkort. I en liten låda är det ju viktigare att hålla sig till rätt effektförbrukning.

Lite intressant är att bus-klockan står på 100,00 MHz i UEFI, men diverse program rapporterar den till 99,8 MHZ. Så där verkar moderkortet trimma neråt.

Enligt The Stilts artikel är detta en kalibreringsfråga, så det hade varit kul att se mätningar med olika processorexemplar på samma exemplar av moderkort. Jag gissar att det finns en hel del individskillnader vad gäller vad som är "rätt" värde som ska kompileras in i UEFI.

Gäller detta enbart Zen2 generationen eller förekommer det även med äldre versioner av Ryzen och i så fall kanske också tidigare generationer av moderkort? Förstår att de gärna testar nyaste generationen men det kan ju vara något som försiggått även tidigare. Kanske också beror på vilken version av BIOS man har? Kanske går att lösa problemet med uppdatering av bios.

Jag har en Ryzen 7 1700 på ett X370 moderkort. Kör enbart Linux så jag vet inte hur man skulle testa detta i Linux.

Edit: Jag har en tidig CPU med "linuxbuggen" dessuom. Orkade aldrig byta ut den på garantin och den funkar OK ändå.

@cyklonen: Samma med Gigabyte X570 I AORUS PRO WIFI, körde bara lite snabbt CPU-Z stress och den lägger sig stadigt på 85%.
Det kan förklara varför jag får bättre resultat än "standard", klagar inte nu när jag fått ordning på kylningen. Ligger på 4,1-4,2 GHz all core, när endast någon kärna belastas når jag 4,4 på min 3700x

CPU-Z bench ger ca 2% bättre resultat än deras referensvärden för processorn.
Single: 525
Multi: 5527

Asus TUF B450M-PRO GAMING, Ryzen 3600, 90%.
Stressade med CPU-Z.
edit 98% med Cinabench, mycket bättre.

Jag håller delvis med. Men för att kunna ta ställning till hur orolig man ska vara för degradering behöver man ju veta hur risken faktiskt ser ut i olika situationer.

Då det faktiskt kan vara en risk är om man har olika parametrar som gör att strömdensiteten och temperaturen blir väldigt hög - samtidigt. Då kan det nog gå ganska fort, men Ryzen liksom alla moderna processorer har skyddsmekanismer som i första hand tvingar ner processorn i lägre hastighet, och i andra hand, om det inte hjälper, helt enkelt stänger av hela systemet. Så risken för gemene man är väldigt liten då de flesta ändå klockar med PBO, och då har du fortfarande dynamisk frekvens som delvis går på temperaturen. Men klockar man på det viset att man har en fast frekvens och väldigt hög spänning så ja, då finns absolut en risk.

Sen det här med att processorerna långsamt degraderas och att det då skulle handla om att de ger upp efter 12 år istället föt 15, ja det vet vi ju först om 12-15 år, och det lär inte vara jättemånga som både klockar sina processorer och samtidigt förväntar sig att systemet skall ha en livslängd på 15 år.

I fallet som nämns i artikeln så verkar det ju dock handla om att i praktiken på aktiveras PBO utan att användaren ber om det (fast via en annan mekanism) för att tillverkare X och Y vill hamna i toppen på staplarna när det skall skrivas recensioner, och PBO i sig, det vill säga att ge processorn mer spelrum är inget som leder till degradering, eftersom frekvenserna, och därmed temperaturen, är dynamiska delvis relaterat till just temperaturen.

CPU-Z är inte ett speciellt betungande multicore test, då är CB20, Prime95, Blender eller OCCT bättre, det kommer maximera strömuttag på ett annat sätt än cpu-z. Belastar man för svagt så kommer det inte visa 100% eller nära 100% även om det står rätt till, samma med idle eller single core last, där kommer deviation värdet visa fel. Andra saker som påverkar är hur vcore beter sig eller om man satt en offset på vcore.

Jag körde en ren CPU-rendering i blender. HWinfo rapporterar 161 W för CPU Package Power då, och effective clock på ca 4.07-4.09 GHz.

Precision boost och PBO har ett par parametrar att hålla sig till som exempelvis PPT, EDC och TDC samt temperatur & spänning, och detta påverkar frekvens. Det man gör med detta fulhack är att lura hela kontrollsystemet till att tro att processorn drar mindre ström än det faktiskt gör, det kommer inte kringå temp begränsning och inte heller spänning. Har man då en kraftig kylare så kommer precision boost fortsätta boosta långt över strömbegränsning, något som inte görs med bara kraftig kylning, där kommer PB/PBO hålla sig till strömbegränsningar oavsett temp ända tills man når temp limit där den sedan blir strypande faktorn. Att processorn boostar långt över strömbegränsning behöver i sig inte vara särskilt farligt MEN och det är ett rätt massivt men, denna metod kringgår helt FIT styrningen där chippets hälsa ska hållas i schack vad gäller ström, det är i praktiken samma sak som att manuellt klocka processorn där man också kringgår FIT.

Om man nu vill ha mer prestanda så är PBO en långt bättre metod där man fortfarande har en fungerande FIT och dessutom brukar PBO utöka temp taket en smula (5-10 grader) för hur varmt PB tillåts boosta frekvens, då kan man dessutom lita på den rapporterade förbrukningen istället för som med fulhacket där all rapporterad förbrukning bara blir ren goja, fulhacket är alltså en rent praktiskt skadligare variant av PBO där man samtidigt rent praktiskt och förmodat inte ser samma prestandaökning som med PBO pga temp limits. Hur skadligt fulhacket är blir mycket beroende på just hur kraftigt man underdriver strömförbrukning samt den belastning man lägger på processorn och vilken temp som uppnås.

Min poäng är enkel, detta fulhack är så jävla urbota korkat sätt att plocka ur mer prestanda ur en R3000 serie processor då det redan finns flertalet bättre sätt som inte kringår FIT eller fuckar upp rapporterad strömförbrukning.

Där ser man!
Fick 98% med Cinebench 20, tack för tipset.
PBO avslaget.

Läst lite i forumet för HwInfo.

• Man skall som sagt testa under full belastning.

• Klockning påverkar, så man bör testa oklockat.

• En tidigare Beta gav felavläsning för Ryzen 1000 och 2000, se till att du har senaste betan om du skall testa dessa.

• 95-105 % är klart godkända resultat.

Tidiga BIOS för Asrock verkar värst, de fixar det för senare.

Tvivlar, men frågan är onekligen intressant.

Nej detta gäller egentligen bara AMD's precision boost och dess implementering i Zen2 och hur vissa mobo tillverkare lurar systemet. Något som egentligen inte behöver göras då PBO finns. På Intel sidan finns just detta knep inte vad jag vet även om det rent praktiskt säkert skulle kunna göras men där har du istället automatisk MCE samt tillfulade PL1 och PL2 samt TAU om dom inte kör MCE automagiskt, det är lite samma sak men på ett ärligare sätt som inte lurar något system.

När man gör som här i detta fallet med fejkad strömförbrukning så ställer det bara till med jävelskap och det döljs dessutom från alla inblandade, att man utökar PL1/2 och tau på Intel det döljs inte på samma sätt och det lurar inte några system även om det också kan bli rätt vilseledande i tester om de som utför testerna inte tänker på det.