AMD Ryzen 3000 "Matisse" – samlingstråd

Största problemet med denna VRM design är att dom kör bara en enkel low side mosfet per high side vilket gör att det normala förhållandet man brukar ha mellan Hi och low inte finns, low brukar generellt vara ~50-100% kraftigare i ampere kapacitet än hi side, här är det en rätt anemisk low side vilket gör att ampere uttag av större dignitet kommer orsaka problem, sen är det som du säger en 3 fas och får jag dra till med en gissning så lider den säkert av rätt extremt rippel vid nära maxlast för att inte tala om vdroop.

Körde en tung rendering på mitt billiga B450 igår, höll på i 2-3 timmar med 100% på alla 8 kärnor med 2700X. Ström låg konstant på 100A och CPU + SOC på 150W konstant, den klarade då att hålla 4079MHz, också konstant, på alla 8 kärnor och ibland tippade någon enstaka kärna upp på 4104MHz. Vcore låg stadigt på 1.363V under körningen.
Max Tdie var 70C, max Tctl var 80C och CPU-socket var 65C. Dessa temps låg exakt samma under hela renderingen. VRM MOS maxade på 87C, VRM SOC gick inte över 50C, chipset gick aldrig över 45C. Helt stabilt, datorn har stått på i två dygn nu, har kört Skyrim med massa moddar 1440p/Ultra i ett par timmar. Allt fungerar hur bra som helst. Och 2700X boostar till 4435MHz på 7 av 8 kärnor, den enda sämsta kärnan boostar till 4385MHz. Och boost beteendet är bra, kolumnen "current" i HWINFO64 boostar hela tiden upp till max på alla kärnor när man använder datorn normalt.

Med tanke på att moderkortet står ut med en 2700X som använder PBO för fullt och med max belastning så borde en 3700X vara en ren barnlek för det här moderkortet.
Man bör dock ha god ventilation i lådan annars går säkert VRM MOS upp mot 100C vid tung konstant belastning. Skulle inte para detta med en 3900X, även om det säkert fungerar bra trots allt eftersom 3900X och 2700X drar nästan exakt lika mycket ström.

Men slutsatsen är ändå att kylning är A och O, detta skulle inte fungerat speciellt bra med stockkylaren, detta skulle inte fungerat speciellt bra med en dåligt ventilerad låda. Jag använder en Noctua NH-D14 som är state-of-the-art på luft och endast slagen av den nyare NH-D15, och jag har en Nidec Silent Typhoon som blåser rätt ner på VRM. Utan den skulle det blivit väl varmt. Men med dessa kylande åtgärder är prestanda/stabilitet hur bra som helst även under tung konstant körning över alla kärnor.

Som kuriosa, perfekt Skyrim burk, stänger jag av Nvidias 4K supersampling så det blir äkta 1440p och klockar GTX980 med 115MHz core och 200MHZ minne med Afterburner så håller sig Skyrim tämligen konstant på 60fps med ett 30-tal moddar i gång. Nostalgisk tidsresa att köra med GTX980 igen
(med 1080Ti är det ju löjligt, allt bara rullar, har endast använt Afterburner vid ren benchmark med 1080Ti)

Din interna mosfet temp var troligen högre ändå då mosfets på detta bord inte har integrerad temp avläsning, sitter då en sensor "nära" mosfet kan man lägga på ~20 grader för intern temp.

Så är det säkert, har ingen aning om hur tillförlitlig VRM MOS angivelsen är, därför jag skulle akta mig att använda en 3900X med det här moderkortet. Dock var/är det 100% stabilt och ingen throttling så so far so good. Men med en 3700X har man ca 50W marginal att knapra på, så upp till 3700X skulle jag säga är fullständigt safe bara man har ok ventilation.

Detaljen som borde vara omöjligt att missa vid det här laget är att allt i mitt system är "stock". Det har ett par implikationer. Bl.a. att all måste följa specifikationen för AM4-sockel och alla moderkort som säljs borde rimligen klara minikraven för AM4.

Klarar man minikravet för AM4 borde ett grundkrav vara att systemet åtminstone fixar basfrekvensen. Om inte, vad har basfrekvens överhuvudtaget för relevans?

Jämför med Intel. Det går att köra i9-9900K på ett "knäckebrödsmoderkort". I det läget kommer man inte kunna "låsa upp" strömbudget, vilket betyder att man är begränsad till 95 W TDP (som är ett krav för sockeln, innan 9000-serien var det ingen skillnad alls i prestanda mellan knäckebrödsmoderkort och oklockat på Zxxx moderkorten). Motsvarande är det enda jag förväntar mig av 3900X på ett budgetmoderkort.

Ah, det förklarar varför man aldrig lagt till stöd för att avläsa enskilda kärnor...

Men undrar om min sensor visar rätt värde givet att högsta jag ser under loopad Octave är 50.0°C. Kör jag däremot kompilering i loop når den strax under 60.0°C. Båda känns ju orimligt låga givet att systemet presterar som förväntat!

Kör man först kompileringsloop för att sedan direkt byta till Octave-loop sjunker temperaturen mot 50.0°C, så handlar inte om att jag inte väntat länge nog för "steady-state".

Nu har jag bara kört Octave på Linux, men svårt att se hur saker som skalning över kärnor skulle vara helt icke-existerande under Windows. Vad får du gör GFlops värde?

Detta är vad jag ser

From 8000 To 12000 Step=2000 Loops=3
        SIZE             FLOPS             TIME
        8000x8000 :      461.51 GFlops   6.656475 sec
      10000x10000 :      488.03 GFlops  12.551590 sec
      12000x12000 :      496.28 GFlops  20.891397 sec

Kör man ännu större matriser börjar det minska igen, verkar peak:a runt den storleken som testas här.

Är ju möjligt att frekvenserna inte rapporters på korrekt sätt i mitt system, för har annars lite svårt att begripa hur jag kan se i princip identiska resultat som Puget Systems som använde ett "Gigabyte X570 AORUS ULTRA".

De kan inte heller köra med tokstora eller allt för små matriser då 9900K systemet når väldigt nära 100 % av sitt teoretiska max (vilket är väntat för Skylake, den har nära 100 % effektivitet när man kör FMA/AVX, något som inte är fallet för tidigare modeller och inte heller för AVX512).

Har ingen Windows-dator i närheten just nu, kommer ha det senare idag. Men möjligen kan det vara så att Windowsversionen av Octave använder någon form av generell BLAS-implementation som inte presterar i närheten av OpenBLAS eller MKL (går att köra MKL om man vill, men föredrar själv OpenBLAS då det är standard under Linux). Du kan testa göra det som föreslås i denna tråd.

Körs en generell version lär du se GFLops ungefär en fjärdedel då det enda som är garanterat på x86_64 är SSE2.

Fast nog måste någon här köra Matlab/Octave eller liknande och därmed redan ha en vettig BLAS-implementation? Vad använder ni annars 8C/12C CPUer till, inte precis så att det behövs för att surfa eller spela!

Slutligen, GB4 har ett SGEMM test (S=single, D=double) och där får våra system ett resultat som skiljer ~6 %, 1,07 vs 1,14 TFLOPS (inom felmarginalen för singlecore). Det stämmer också helt med siffrorna jag ser för DGEMM, de borde vara något under hälften (64-bit vs 32-bit flyttal, lite högre overhead att hantera 64-bitars tal då man bara processar hälften så många per instruktion).

Så verkar inte ens som det throttlar mer under Octave-testet som tar betydligt längre tid än GB4 SGEMM (som tar några sekunder).

TL;DR alla resultat är där man kan förvänta sig, frekvenserna för FMA/AVX känns dock fel...

Edit: finns det ingen annan SGEMM/DGEMM/Linpack benchmark som är FMA/AVX optimerad? Helst någon som fungerar både på Linux och Windows.

Kanske MKL har någon sådan? Ska kolla lite på det.

I ditt fall är det många resor mer troligt mjukvara som ställer till frekvens mer än något annat, antingen i avläsning eller något som tokbelastar processorn på något vänster, efter det skulle jag placera VRM på trolig orsak och efter det skulle jag placera stock kylarn. Utan att ha tillgång till din hårdvara blir det dock en aning svårt & säga.

Vad det gäller frekvenser så ska all core AVX hålla sig över basfrekvens, detta ser du av de bilder jag postat här med all tydlighet, till och med den mest grisiga strömvirus testet med gimpad kylare höll sig på/över basfrekvens, varför Octave testet inte belastade mer än 8 trådar simultant har jag ingen aning om men som allra mest belastades bara 1/3 av processorn under testet, vilket är rätt långt ifrån all core belastning. Angående flops så får jag bara fram detta, alltså med 1/3 av processorn lastad

From 8000 To 12000 Step=2000 Loops=3
SIZE FLOPS TIME
8000x8000 : 329.93 GFlops 9.311195 sec
10000x10000 : 320.53 GFlops 18.718834 sec
12000x12000 : 334.83 GFlops 30.965309 sec

Sen säger jag så här angående Intel och AMD:

När Intel ger stöd för så många processorgenerationer på en sockel som AMD gjort med AM4 så kan jag ta med dom i beräkningen.

Edit; kräver dgemm java runtime förresten?

DGEMM är inget program, det är "Double-precision General Matrix Multiply". Men antar att frågan här är om Octave kräver en Java-runtime, svaret på den frågan är nej.

Prestandasiffrorna du får pekar på endera SSE/FMA alt AVX (utan FMA). Eller så är det helt enkelt AVX/FMA fast av någon orsak kan inte alla CPU-trådar utnyttjas (fast är lite väl mycket precis hälften av förväntad GLFOPS för att det ska vara en slump).

I.o.f.s. är det rätt stora matriser, inte så att ditt system börjar swappa (tror inte det, då man teoretisk sett behöver strax under 4GB men vet inte vilken overhead Octave lägger på)? Jag har 40 GB RAM, tänkte aldrig på hur mycket RAM detta faktiskt äter upp!!! Det kan nog också förklara ~6 % skillnad i SGEMM. Du verkar ha 3866 MT/s minnen medan jag kör med 2933 MT/s, det är en 32 % fördel i bandbredd och dessa matriser är långt större än L3$.

Kan vara så att frekvensavläsningarna blir fel, fast det verkar i så fall bara hända när man kör AVX/FMA. Ser helt vettigt ut vid kompilering (som är heltal och I/O).

BTW: fanns det en " libopenblas.dll" i Octave? Döp i så fall om den till "libblas.dll" så borde FMA/AVX användas. Kollar in Octave för Windows när jag kommer hem och har tillgång till min Surface.

Vad tror ni maxeffekten blir för en 3950X vid maximal belastning (nån form av tung rendering, t ex) utan överklockning men med alla OOTB-funktioner påslagna?

Jag föreställer mig att det bör vara som 3900X gånger 1.33, plus kanske lite högre boost, så 1.4x eller i extremfallet 1.5x. Låter det rimligt?

Hittar siffror på ca 140-150 W för 3900X under full belastning och tycker det låter rätt lite, men det kanske stämmer?

200 W är ju inget svårt att kyla, så varför skulle det vara ett hinder?

Alla moderkort klarar det inte.

Nä, total cpu belastning av octave överstiger aldrig under ens en millisekund 1/3 av alla 12/24 tillgängliga kärnor, alltså, 2/3 av procesorn idlar under beräkningen. Ja jag menar Octave ifall det kan orsaka problemet med att det inte vill nyttja mer än 8 trådar simultant (även om det har fler worker threads).

https://i.imgur.com/wAZpDdF.jpg
https://i.imgur.com/bWmKP9R.png
https://i.imgur.com/KHP6rwY.png

Edit: Missade att du skrev om minne, nä det verkar inte lasta mycket där heller, jag kör 3666@c15 med nuvarande agesa.

@Yoshman: Helt ärligt, jag har ofta fått debugga konstiga laster etc i mitt arbete. Spontant med det lilla jag förstår, så skulle jag gissa att något bottleneckar CPUn. Det kan va som tidigare talats hårdvara (VRM?) eller mjukvara/hårdvara, att CPUn helt enkelt väntar på något, vilket är varför det framstår att temp går ner.

OK, har nu testat Octave under Windows. Laddade ner .zip filen för att allt skulle hållas på en plats man har koll på.

Som programmet är uppsatt initialt ser jag samma problem som du, alla CPU-trådar lastas ej + prestanda skvallrar om att man inte ens kör med SIMD. 8000x8000 fallet tog nästan 900 sekunder vilket då medför endast 3,4 GFLOPS....

Om man tar bort filen octave-5.1.0-w64/mingw64/bin/libblas.dll och sedan gör en kopia av octave-5.1.0-w64/mingw64/bin/libopenblas.dll och ger kopian namnet octave-5.1.0-w64/mingw64/bin/libblas.dll hamnar prestanda där man kan förvänta sig, CPU-lasten är 100 % under hela beräkningen.

Jag använder octave-cli.exe i PowerShell, men borde inte göra någon skillnad om man kör GUI.

Surface 4 (i7-6650U) har en teoretisk maximal kapacitet på strax runt 90 GFLOPS om FMA/AVX används (frekvensen ligger ~2,8 GHz) och efter manövern ovan får jag som mest 79,5 GFLOPS (det vid 8000x8000 som då tar 38,7s, temperaturen ökar och klockfrekvensen går allt närmare basfrekvensen på 2,3 GHz med tiden).

Grejen är att CPU inte verkar slå i någon flaskhals: får i praktiken samma SGEMM-prestanda som folk med "feta" moderkort och kylning i GB4- Samt får i praktiken samma DGEMM-prestanda som Puget System får, och de kör med ett "Gigabyte X570 AORUS ULTRA".

Visst kan man misstänka att frekvenserna rapporteras fel, fast varför bara då när man kör FMA/AVX? Vidare pekar ju CPU-temperaturen på att Octave-lasten genererar mindre värme än kompilering (som dels kör vid högre frekvens men också låter I/O-kretsen jobbar betydligt hårdare).

Så slutsatsen här är att endera rapporterar Linux (specifikt /proc/cpuinfo) inte korrekta frekvenser eller så är det inte bara min 3900X som inte håller basfrekvens under ren FMA/AVX-last. Matrismultiplikation av stora matriser är speciellt här, något som CB20 må använda dessa instruktioner men inte i närheten lika intensivt som fallet i SGEMM/DGEMM.

Använder min 3900X primärt som byggserver/utvecklingsmaskin, det fungerar lysande till detta. Men då jag kör 3900X med ett väldigt billigt B350 moderkort samt även stockkylaren infann sig frågan: vad händer om jag kör maximerad AVX/FMA på alla CPU-trådar?

Som referens skapade jag en graf över frekvenserna hos varje CPU-kärna när den kör ett väldigt vanligt bygge i mitt arbete, inga konstigheter där.
https://i.imgur.com/EfdO2AB.png
En typisk kompileringslast är en kombination av kompilering (skalar nära nog perfekt över kärnor), länkning (rätt mycket I/O och skalar inte alls speciellt väl med kärnor -> enkeltrådprestanda viktigt) samt möjligen en del skript för post-processing. Man ser dessa olika delar i grafen.

#!/usr/bin/octave --silent

nfrom = 8000;
nto   = 12000;
nstep = 2000;
loops = 3;

printf("From %d To %d Step=%d Loops=%d\n",nfrom, nto, nstep, loops);
printf("        SIZE             FLOPS             TIME\n");

n = nfrom;
while n <= nto

  A = double(rand(n,n));
  B = double(rand(n,n));
  pause(3)
  start = clock();

  l=0;
  while l < loops

    C = A * B;
    l = l + 1;

   endwhile
   timeg = etime(clock(), start);
   mflops = ( 2.0*n*n*n *loops ) / ( timeg * 1.0e9 );

   st1 = sprintf("%dx%d : ", n,n);
   printf("%20s %10.2f GFlops %10.6f sec\n", st1, mflops, timeg);
   n = n + nstep;

 endwhile

Ska man tro det som skrivs bl.a. i dessa forum borde endera mitt system fixa detta, eller så borde VRM eller möjligen CPU överhetta.

Inget av det hände, faktum är att systemet drar något mindre från väggen i denna last jämfört med kompilering. Var det som fick mig att börja logga frekvens hos kärnor, för det kändes inte helt rimligt!

Här kommer det intressanta, CPUn går inte bara ned till sin basfrekvens på 3,8 GHz utan den går en bra bit under detta
https://i.imgur.com/e0JGLqV.png
De små "hornen" man ser är början av varje iteration där slumpmässiga matriserna skapas, detta innehåller inga FMA-instruktioner och antagligen minimalt med SSE/AVX. Notera också hur frekvensen skjuter iväg uppåt när man går från 100 % last till "idle", tror det är förklaringen till varför t.ex. GB4/5 ger så mycket lägre frekvens än vad externa program rapporterar, GB4/5 mäter enbart när CPU-last är 100 %.

Som referens kan nämnas att om jag kör samma last på min NUC med i7-8559U (4C/8T med 28 W TDP) så ligger den efter någon sekund exakt basfrekvens (2,7 GHz). Men den går aldrig lägre än 2,7 GHz.

Så den uppenbara förklaringen då kändes som: well, självklart throttlar CPU då Ryzen borde rimligen borde throttla och inte brinna upp i det läget. Ett underbetyg till AMDs medföljande kylare i så fall, för den borde fixa basfrekvens.

Tyvärr har jag inte hittat något vettig sätt att läsa av temperaturen hos enskilda kärnor under Linux när man kör Ryzen (AMD har lite att jobba på för att matcha Intels Linux stöd här...). Har någon form av temperaturmätare för CPU, gissar att det är någon sensor på moderkortet givet att den aldrig når över 60°C under de här två testerna (alt. så visar den helt enkelt fel).

Grejen är dock att jag får 450-500 GFLOPS i Octave/Matlab testet, det är helt i linje med Puget Systems uppmätte i deras Linpack mätningar. Puget kör med AMDs BLAS bibliotek medan jag kör med OpenBLAS, så om något borde AMDs bibliotek vara bättre optimerade (men i enklare fall som detta är OpenBLAS faktiskt i nivå med Intels MKL som är det mest välputsade BLAS-bibliotek som existerar för x86, så OpenBLAS är väldigt bra).

Har någon som sitter på fetare moderkort, fetare kylning och framförallt Windows där man kan läsa av temperatur för enskilda kärnor testat Linpack eller liknande? Den som vill kan ta mitt program, stoppa in det i en fil med namnet dgemm.m och köra det i Matlab eller Octave (Octave är gratis och kan laddas ner här).

Om mitt system inte throttlar har nog AMD mer problem att hantera kring frekvens, får i så fall fixar 3900X inte ens basfrekvens under FMA/AVX last. Och dgemm/sgemm är inget syntetisk fall, det är just det fallet man får när man multiplicerar stora matriser!

Det är lite svårt att guide dig längre än så här på fjärr gällande felsökning men vi kan försöka såklart, absolut enklaste sättet att utesluta att det är fel på 3900x är att prova den i ett annat moderkort, kan du däremot inte göra det så kan det bli lite knepigare, har du provat att bara köra ett minne och i slot A2 för & se ifall de kan väcka liv i 3900an?

Detaljen som borde vara omöjligt att missa vid det här laget är att allt i mitt system är "stock". Det har ett par implikationer. Bl.a. att all måste följa specifikationen för AM4-sockel och alla moderkort som säljs borde rimligen klara minikraven för AM4.

Klarar man minikravet för AM4 borde ett grundkrav vara att systemet åtminstone fixar basfrekvensen. Om inte, vad har basfrekvens överhuvudtaget för relevans?
.......
Men undrar om min sensor visar rätt värde givet att högsta jag ser under loopad Octave är 50.0°C. Kör jag däremot kompilering i loop når den strax under 60.0°C. Båda känns ju orimligt låga givet att systemet presterar som förväntat!

Kör man först kompileringsloop för att sedan direkt byta till Octave-loop sjunker temperaturen mot 50.0°C, så handlar inte om att jag inte väntat länge nog för "steady-state".
ra med tokstora eller allt för små matriser då 9900K systemet når väldigt nära 100 % av sitt teoretiska max (vilket är väntat för Skylake, den har nära 100 % effektivitet när man kör FMA/AVX, något som inte är fallet för tidigare modeller och inte heller för AVX512).

Reous lade ut den här länken nyss till en ny bios för Asus Prime X370 Pro.

Agesa 1003 Patch ABB, version 5216
https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/PRIME_X370-PR...

Har dock inte sett den här ännu:
https://www.asus.com/se/Motherboards/PRIME-X370-PRO/

Ok, Reous:
"It was uploaded to the Asus Server several minutes ago. It will take some hours/days until they add it to the homepages... like every time"

samt:
"It is just the ABB Bios, not the SMU/Boost fix. The manufactures will get this fix tomorrow from AMD."