AMD Ryzen 3000 "Matisse" – samlingstråd

Får inga whea errors alls, dina symptom tyder på att det är någon spänning som är off. Posta screenshots av Ryzen Master och HWINFO64 så kan vi se.

Skickades från m.sweclockers.com

Ta en för laget! Gör mätningar på boostfrekvensen innan du uppdaterar och sedan jämför du och lägger upp vad du får fram

Får inte ihop din beräkning här och det verkar inte heller stämma med vad värmekameran visade.

Det som borde storkna först på VRM-delen är low-side MOSFET, som i detta fall är en Sinopower SM4336.

Visa innehåll

Vid 100°C fixar denna maximalt 40 A. Den MOSFET:en sitter till vänster om dioden i denna illustration

Det finns totalt 6 stycken sådan kopplade i 3 faser, vilket enligt Kirchsoffs lag betyder att maximal kapacitet blir 6 * 40 = 240 A.

Det är som sagt vid low-MOSFET temperatur på 100°C, vid 25°C kan de hantera 65 A enligt databladet.

Nu finns det inga "phase doublers" på detta moderkort så man kan inte garantera att exakt hälften av strömmen i de två parallellkopplade, men om mina elektronikkunskaper inte är totalt fel borde Ohms lag och lite potentialvandring visa att snedbelastningen per par i en fas borde inte kunna avvika mer än maximala varians i resistans, kapacitans och reaktans av komponenterna som igår. Man är garanterad en kapacitet på 120 A < X < 240 A, där man i praktiken kommer hyfsat nära övre gränsen.

Primära problemet med ett budgetmoderkort som detta är att endast tre faster ger betydligt högre rippel jämfört med mer avancerat moderkort med fler faser. Irrelevant i "stock", men det kommer betyda lite högre förluster i CPU (rippel översätts till förlorad effekt som blir värme i CPU). Primär implikation av detta är sämre stabilitet vid överklockning, det är primär flaskhals i detta moderkort och inte strömkapacitet.

Visa innehåll

SoC VRM

VCore VRM vid Octave-loop

Vcore VRM vid compile-loop

Tog lite bilder idag, varmaste punkten kring VRM är rätt långt från 100, är spolarna och inte MOSFET som är klart varmast

Kollade även strömförbrukning från väggen, även den visar att kompilering är tyngre. Matchar med någon W vad SweC fick hos deras 3900X i Blender och Handbrake, vilket rätt mycket pekar på att mitt system nog inte throttlar p.g.a. moderkort (SweC körde med "Asus Crosshair VIII Hero (AMD X570)").

Visa innehåll

"Idle"

Octave i "stock"

Kompilering i "stock", högsta förbrukning av det jag testade

Med GTX1030 och B350 är det i praktiken bara CPU som drar ström

199-41 = 158 W verkar CPU dra som mest, SweC uppmätte 210-50=160 W. Så ur alla praktiska hänseenden identiskt (har en guld-klassad 500 W PSU).

Gissar att du gjort allt rätt här. Hittade en del forumtrådar om att OpenBLAS (matrisbiblioteket som Octave, NumPy m.fl. typiskt använder) har problem med att skala på något vettig sätt under Windows. Nu var det primärt Xeon CPUer med lite mer än 12 C, men det indikerar ändå att CPUer med många kärnor i Windows är lite som de dyra lättmetallfäljarna jag hade på min första bil (Open Ascona från 1977), ser kanske coolt ut men är inte precis där flaskhalsen ligger...

Matrismultiplikation är, tillskillnad från CB, inte "embarrassingly parallel". Det är absolut skalbart, OpenBLAS används framgångsrikt på Linux med system som har över 100 CPU-kärnor och teoretiska gränsen går vid 1024 kärnor. Men krävs lite mer av OS:et än för att skala renderingsprogram.

Och man kan inte riktigt skylla på OpenBLAS då skalningen över kärnor görs med OpenMP, industristandard för det här typen av CPU-skalning.

Så vi får nog lämna det här spåret för Windows

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      482.13 GFlops   6.371750 sec
      10000x10000 :      511.45 GFlops  11.731346 sec
      12000x12000 :      522.66 GFlops  19.837067 sec

Temperaturavläsningen för CPU verkar visa fel. Insåg det när jag hoppade in i BIOS (där den antagligen är rätt) för att sedan boota in i Ubuntu, verkar vara 20°C fel (visar 20°C för lite med lm-sensors). Om man antar detta så känns CPU-temperaturerna jag ser rätt mycket rimligare, ca 50°C i "idle" och 70-80°C under full last (högre vid kompilering än DGEMM).

Jag testade två nya saker idag. Dels "överklockning" till 3,8 GHz samt testade att slå på PBO. Dessa två resulterade i högre GFLOPS siffror jämfört med tidigare, faktum är att de nästan exakt matchar det du listar ovan!

"överklockning" @ 3,8 GHz (har helt rak MHz över tid graf här på alla kärnor)

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      473.13 GFlops   6.492989 sec
      10000x10000 :      501.08 GFlops  11.974052 sec
      12000x12000 :      515.66 GFlops  20.106171 sec

Med PBO (som enligt de flesta tester/tyckare ska vara meningslöst på 3900X med stock-kylare)

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      481.71 GFlops   6.377339 sec
      10000x10000 :      510.42 GFlops  11.754943 sec
      12000x12000 :      520.66 GFlops  19.913088 sec

Slutsatsen av detta kan bara bli en, i alla fall mitt system fixar inte att hålla basfrekvensen under FMA/AVX last när allt är helt "stock". Det kan inte vara en orsak av för klena VRMs, för dålig CPU-kylare eller liknande då det rimligen inte borde gå att nå (och med PBO marginellt överskrida i genomsnitt) basfrekvensen med någon form av överklockning.

"Ren" FMA/AVX last verkar dock vara den enda last där så är fallet. Kör jag CB15/CB20 med Wine i "stock" håller sig systemet hela tiden över basfrekvens, poängen är inom ett 2-4 % (mitt system är lite långsammare) jämfört med SweClockers siffror i 3700X/3900X testet.

Förväntar mig att Wine ger nära nog noll overhead för något som CB och Linux har ingen fördel av att hantera många kärnor bättre då det handlar om ett "embarrassingly parallel" (någon som klarat grundkurs i OS-design fixar att få ihop en schemaläggare som fixar de fallen perfekt).

Precis som @SAFA redan lurat ut, Octave kör i normalfallet med en referensimplementation av BLAS som varken kan använda flera trådar eller FMA/AVX/SSE.

Vet inte varför någon skulle vilja köra med referensimplementation mer än att kolla att Octave fungerar. Ubuntu använder OpenBLAS som standard (jag kör Ubuntu 18.04).

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      473.13 GFlops   6.492989 sec
      10000x10000 :      501.08 GFlops  11.974052 sec
      12000x12000 :      515.66 GFlops  20.106171 sec

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      481.71 GFlops   6.377339 sec
      10000x10000 :      510.42 GFlops  11.754943 sec
      12000x12000 :      520.66 GFlops  19.913088 sec

Du kikar på fel drain current, beräkning för max ampere uttag för dessa är baserade på förlust kontra maximal värmeavledning vilket ger 26A vid hög temp kontinuerlig last innan dom faktiskt brinner av. Det går tyvärr inte och enbart kika på maximal drain current under korta stunder, exempelvis har de en avalanche rating på 30A med en puls. Skulle du försöka plocka ut 60A kontinuerligt ur en mosfet skulle det helt enkelt säga SPRAK. ID Continuous Drain Current ligger på massiva 15A vid 70 grader. Detta är också varför moderkortet throttlar som fan över 150W belastning och en hård limit vid ~180W för att low side inte ska brinna av, vid 180W och 1.3-1.35V vilket en zen skulle ligga på beroende på last så hamnar man på 22-23A per mosfet, vore en aning underligt att sätta en hård limit på detta om mosfet pallade mer och som du hävdar upp till 60A.

Här är den ultimata VRM-guiden:

https://docs.google.com/spreadsheets/d/1d9_E3h8bLp-TXr-0zTJFq...

Har kollat på den videon, men är flera saker han hävdar som jag överhuvudtaget inte får ihop.

Till att börja med, totalt 156 A. Delat med 3 -> 52 A, finns inget i databladet som är 52 A. Delat med 6 -> 26 A, finns inte heller.

Vidare hävdar han att strömkapaciteten inte ökar om man saknar "phase doublers". Det kan inte stämma, eller så har han precis hittat ett fall där Kirchhoff lag inte gäller.

Fast det är ett rätt ointressant sidospår. Det jag var ute efter var om det kunde stämma att systemet faktiskt inte fixar 3,8 GHz (basklocka) vid FMA/AVX, det verkar ju stämma och väldigt lite pekar på att det har med vare sig kylning eller undermåliga VRM:er att göra. PBO verkar ju trots att göra något i mitt fall, så lämnade det på. Får se om systemet fortsätter att vara stabilt...

Har absolut inga klagomål på min 3900X, den är lysande till det jag gör just nu (skapa Docker images för CI-pipeline av en väldigt stor kodbas suger verkligen CPU och på ett sätt som kan utnyttja kärnor!).

Tyvärr lär det bli en "class-action" för AMDs del om det visar sig att de också har problem med att hålla basfrekvens i något folk lycka gräva fram. Var mer ur det perspektivet jag tyckte det var intressant att undersöka.

Det blir extremt beroende på UEFI imlpementation också, det är inte bara & slappa ihop en SMU med befintlig agesa/uefi, en hel del saker som lär klaffa faktiskt och har någon schablat sig så hjälper inte bara rätt SMU version.

Finns en tråd på Reddit med rätt många resultat där folk som tidigare inte nådde sin boost nu når den, så att basera sin uppfattning på ett enda resultat från en enda användare (även om det råkar vara mäster 1usmus) blir ganska skevt. Kan ju också vara så att just MSI's UEFI inte är så bra optimerat eftersom det är framstressat innan officiell release från AMD. Boosten påverkas dessutom inte bara av SMU utan en rad andra faktorer. Men vi lär ju märka hur det blir för de lesta de närmaste dagarna.

Själv sitter jag fortfarande på moddat UEFI (0002+) till Crosshair VII och får ut 4625Mhz ur min 3900X. Jag kommer dock uppgradera när Asus släpper nytt då jag vill kunna gå högre än så. Vore väldigt kul att få se de där 4850Mhz som guldchipen skall kunna få. För jag är nämligen helt övertygad nu att det är ett guldchip jag sitter på då jag konsekvent fått bättre boost än de flesta, så det blir kul att se hur den lilla rackaren presterar med en bra AGESA-version.

Det man kan se i testet är att MSI's implementation är mycket dålig. Förhoppningsvis för MSI-ägare så är det bara för att det är en framstressad beta. Herregud CPPC har funnits i andra tillverkares UEFI sedan launch och MSI lägger till det först nu. Det är ju en viktig del i ZEN2. Vore som om MSI skulle skippa Speed Shift i sina Intel UEFI. Folk skulle gå i taket.

Även om huvuddragen jag tar med mig är att MSI gjort ett mycket dåligt jobb finns ändå en hel del annat intressant att läsa i artikeln som temperaturskillnader mellan SMU-versioner osv, så kul läsning hursomhelst

Men ja... Tar man detta som "ÖÖÖÖH KOLLA VA DÅLI NYA SMU KOMME VARA!!" Ja... Då är det fel. Det är på intet sätt en indikation på hur ABBA med tillhörande SMU kommer fungera hos andra tillverkare. Om det mot förmodan skulle vara det (Alltså om andra framstressat lika mycket som MSI gjort), så då lär det bli grupptalan mot en hel drös moderkortstillverkare och kanske även AMD, vilket i slutändan kan få till följd att AMD ger mindre frihet till moderkortstillverkarna när det gäller UEFI, så MSI leker verkligen med elden här.

Nej, jag ville bara accentuera någon som gapar och skriker utan att veta vad de pratar om, vilket jag tycker att folk gör om resultatet av det här dåliga som MSI gjort blir att de skyller på AMD istället.

Egentligen är det synd att "stora" sidor redan börjat testa baserat på MSI's beta för det kan ju ge folk intrycket att den här nya AGESA'n inte är bättre än den gamla och att boosten fortsatt kommer vara trasig.

Sedan handlar det såklart om mindre tweaks. ABBA blir ingen revolution med 25% bättre prestanda som många verkar hoppas.

Fan, det kliar att testa till Crosshair VII, men känns inte riktigt värt då det moddade UEFI't endast är ny SMU men fortfarande ABB som AGESA-version.

Flashar ni bios via USB eller hur går det till konkret på Ryzen 3000? Vilken soppa att behöva flasha bios varje vecka i jakt på prestanda.

Syftar på 3900X, den går en hel del varmare än 3700X. Min 3700X maxar också på 75C under CB20 med Dark Rock Pro 4.

Skickades från m.sweclockers.com

Hur har det varit på din bräda med uppdateringarna? Asus är lite slöa att få ut skiten, va? Kanske är ett bra tecken för kvalitetstestning. Eller så har de annat för sig.

Det är olika beroende på tillverkare och modell. Alla, vad jag vet, har stöd för flashning via ett windowsprogram (använd aldrig, allderles för stor risk att brädan blir en dörrstopp, oavsett tillverkare, modell, Intel eller AMD osv) En del har endast flashning via en meny i UEFI, typ EZ-flash och liknande som låter en flasha via en fil på ett USB-minne eller till och med en en ens interna lagringsenheter, och vissa modeller från vissa tillverkare har en funktion där man kan flasha nytt UEFI från en viss USB-port med datorn avstängd. Det är den metoden jag brukar använda själv då det känns minst riskabelt med så få komponenter igång som möjligt.

"prestandajakten" handlar främst för många om att krama ur sista droppen blod ur hårdvaran. Det är inte så att folk är gravt missnöjda med prestandan och uppdaterar frenetiskt varje vecka för att förhoppningsvis få något som presterar som tänkt. Missnöjet är mer riktat mot moderkortstillverkarna, och då kanske främst ASUS och MSI, då många känner att UEFI-versionerna har mycket problem, som inte är relaterat till hur Ryzen 3000 i sig presterar-

Men ja, jag har sagt det förut. Är man en person som bara vill köpa grejer, bygga sin dator, installera operativsystem och sedan låta den stå där i 5-7 år och "bara funka" utan att tweaka något så är inte AMD på samma nivå som Intel, det tror jag de flesta håller med om. Och är man en "jag gillar inte att tweaka, det skall bara funka ur kartong" så är det nog lätt att se AMD som ett dåligt val. Men har man det här med att krama ur sista droppen blod ur sitt system som intresse som jag har så bryr man sig inte på det sättet. Det är snarare en go känsla när det kommer nytt UEFI man får leka med

2501 var första versionen jag testade till min 3900X, såg boost på 4675Mhz som högst, men detta var ett mycket dåligt UEFI i övrigt för mig då minnena inte kunde köras i mer än 2400Mh utan "C5" vid uppstart så överlag kul med bra boost men minnena var ingen rolig historia alls.

2606 Blev det sedan. Denna version var stabil för mig och nu kunde jag äntligen få fart på minnena! Kunde köra mina 3600Mhz cl16-minnen i 3800Mhz med 1:1:1 på MEMCLK, UCLK, och FCLK, Upplevde heller inga av de problem som andra rapporterade om som stannade fläktar, spontana omstarter mm, så så sett var det en bra version men min 3900X boostade nu endast till 4525Mhz så boosten var en besvikelse för mig.

0002+ (moddat 2703 med äldre SMU-version) är den version jag nu kör. Beter sig ungefär som 2606 men Max-boost ligger nu på 4625Mhz, så det är en klar förbättring, men jag vill såklart högre så skall definitivt testa 1.0.0.3ABBA när den kommer till brädan. Om det blir officiellt UEFI eller en mod får vi se. Beror på hur ASUS sköter sig.

Hej,
Hur tror ni att dessa minnen skulle fungera med 3000-serien parade med ett Crosshair VI Hero?

https://www.inet.se/produkt/5301780/g-skill-64gb-2x32gb-ddr4-...

Skickades från m.sweclockers.com