AMD Ryzen 3000 "Matisse" – samlingstråd

"Jakten på den försvunna boosten" fortsätter!

Jag kör nu PLL 1.8V satt till 1.54V. Systemet är stabilt. Går jag ner till 1.4 får jag instabilitet och konstigheter så det här är nog det lägsta jag kan gå innan det blir instabilt. Idag har det inte varit fönster öppna så har en ganska "normal" rumstemp på 23.5C, och så ser det ut såhär:

https://i.imgur.com/icsriKg.png

Låter jag PLL vara på 1.8 så är 4625 det högsta jag kan nå på de 4 bästa kärnorna, Så det verkar ge 25Mhz extra att sänka PLL så lågt det går i mitt fall. Om det beror på minskad temp eller något annat kan jag inte svara på, men PLL är det enda jag ändrat på sedan sist så i mitt fall verkar det påverka maxboosten.

Den mer intressanta frågan blir kanske om det faktiskt ökar prestanda, man kan tyvärr inte ta det för givet med zen2 att ökad frekvens per automatik betyder mer prestanda, de tweaks man gör måste hela tiden bekräftas med prestandatest så man inte råkar ut för sämre prestanda.

Så du förväntar dig 4.3GHz all core i CBR20? Då lär du klocka manuellt för FIT tabellen i chippen tillåter inte så kraftig klockning med dagens ageasa oavsett vad du sätter din PBO till, FIT kliver då in och skyddar kislet. Med manuell OC så åsidosätts FIT samt alla strömgränser.

Sedan är precision boost inte samma sak som PBO, precision boost är det som styr stock boost frekvens, PBO är det som ändrar de gränser som PB jobbar efter, till ett visst.

Skickades från m.sweclockers.com

ja även om det bara är en Micro sekund för att sedan vara på 85c. går det att stänga av eller höja nivån??

Jag brukar ju köpa nya saker om jag pajar något, så jag har testat vad min kan köra som max med manuel oc, och det är 4.4ghz med ca 1.45v(kom ej ihåg om den dropar till 1.35v under load) cbr20 stability..tempen går nästan upp till 90c, ca 175w..efter 4.4ghz blir det problem eftersom vcoren måste högre och då vill tempen över 90c och effekten över 180w. Köra en stabil Manuel max oc på alla cores så borde ett riktvärde va ca 4.3ghz, 1.35vcore som dropar till 1.25v underload om man har bra kylare..vill man köra riktigt safe så är nog 4.2ghz ett bättre riktvärde..tror det va 1.25v som dropar till 1.15v, sen är nog alla 3900 lite olika men det känns som de flesta fungerar så här I manuel oc. Jag kör med orginal biosen som kom med ASRock 570 kortet, men får se om jag ska byta till en nyare eftersom jag har grova problem just nu med att köra med auto/oc boost.

Ja 1.45V kommer degradera din processor speciellt vid de temperaturerna även om det är lastberoende hur fort det i slutändan går, PBO är som sagt begränsat av FIT tabellen för hur mycket ström som kan flöda genom kislet utan att elektronmigration eskalerar.
Bästa metod att klocka en dubbel CCD CPU är att klocka CCX individuellt, för en ensam CCD så kan all core clockning vara OK, personligen skulle jag hålla mig under 1.375/1.35V, dels för temp och dels för att inte det lönar sig att gå upp över detta rent frekvensmässigt, du kanske kan få ut 50MHz mer vid 1.45V jämfört 1.375V och i min bok är det inte värt det

Om din vcore droopar så hårt så bör du ställa in LLC bättre

Skickades från m.sweclockers.com

Jag tycker själv att det är märkligt att den svarar så bra ändå av så hög vcore när tempen blir så hög ändå, degraderingen är skit samma för min del...har klockat mycket I mina dagar..har fortfarande misslyckats döda något sen sockel a tiden. Ska testa LLC saken se om det går få till klocksen lite bättre men tempen + effekten hindrar nog mig..får väll testa med balkong tricket eftersom jag hade minus imorse. Har även testat stänga av så manga cores som möjigt, tempen + effekten sjönk ju bra då men ändå svårt att nå något mycket högre MHz. Önskar att man kunde välja vilken core som ska vara aktiv I bios så man kan testa vilken som klockar högst manuelt.

enda saken som är kvar som kan stänga av systemet kan ligga på 85c för att helt plötsligt få en restart där av vill jag höja nivån eller stänga av skyddet. Men då ingen har svarat så går det troligen inte. (4,5Ghz all cors)

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
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!

Alltså, stockkylaren når över 90C redan i Cinebench R20 som har AVX, och det håller på i bara typ 30 sekunder. Klart att det throttlar särskilt om du kör konstant last under längre tid. Mycket värme att transportera bort Det är därför dom flesta här har uppgraderat kylning.

Sen förmodar jag att VRM på moderkortet blir skapligt varm under en sådan last, så där kan det också throttla.

"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!"

Jo, det gör den, om kylning och VRM är tillräckligt bra. En bra bit över 4GHz faktiskt, men aldrig med stock kylaren. Den är designad typ för gaming där man aldrig ser sådana krävande laster.

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!

Hur billigt är "väldigt billigt"? Sitter du med en knäckebrödsbräda med ~160A eller mindre till Vcore VRM så kan den throttla även i stock. Handlar då inte om att det fattas Ampere utan att VRM blir för varm eftersom det är för hög last på för få komponenter på en för liten yta.

Det du kan testa är att sätta en fläkt som blåser direkt på VRM och se om det beter sig annorlunda.

Sen är det det här med stock-kylaren. Jag tycker inte den borde gå under Base vid de lasterna även med stockkylare, men har du dålig ventilation i lådan så kyler ju vad som helst dåligt. Så för att testa om det är kylningen så kan du t. ex öppna lådan, eller tvinga fläkten att gå på max via en UEFI-inställning. Jag tror det behöver redas ut om det är VRM eller CPU som temp-throttlar om det ska bli något vettigt ur dethär.

Har ett ASRock AB350M Pro4, det har som lägst legat på 750 kr enligt prisjakt. Så rätt billigt

Köpte det då det vid lansering av första generationen Ryzen fick betyget "bästa Ryzen-moderkort under $100" i ett par tester, ville bara köpa en enkel plattform för att själv kunna känna på Ryzen. M.a.o så det är inte precis värdelöst, men ändock budget.

TechSpot har testat detta moderkort med 3900X, så länge man inte överklockar (vilket jag inte gjort sedan Ryzen 5 1600) fungerade det hur bra som helst i deras test (och vad är poängen med att överklocka när prestanda ändras några enstaka procent med effektförbrukningen skjuter genom taket?).

Man inte ens är nära att nå gränsen för VRM temperatur utan överklockning.
https://static.techspot.com/articles-info/1872/bench/3900X.png

Värt att nämna här: såg större värde av att ha denna dator på jobbet än hemma, så min 3900X står nu i ett kylt serverrum. Har en 120 mm Noctua-fläkt som blåser över båda VRM-flänsarna (men gick bra att köra 2700X på detta moderkort utan den kylningen).

OK, nu lär jag bryta ner detta så du förstår. Ditt moderkort kan maximalt kräma ur 156A ur VRM, oavsett vilken kylning du applicerar till den, över detta och den kommer brinna, vid 156A pratar vi en värmeproduktion på 70W enbart från VRM, vid 100A belastning spottar din VRM ur sig 21-23W värme inte inkluderat drivern. En 3900x som inte temp throttlar kommer dra 140A i stock under AVX all core load.

Räkna sen ut hur svalt det kommer gå.

Om du kombinerar en vattenkylning för processorn så den tillåts dra 140A under längre perioder så kommer din VRM throttla, det är inte ens en fråga och det syns även i testet hos techspot där PBO körs och temp throttling för cpu inte inträffar lika snabbt.

Edit: för att förtydliga ännu mer, med stock kylaren så kommer CPU lägga sig mot TDC snarare än EDC tå temp kommer gå för högt under EDC, det gör att PB ger sig och lägger sig på TDC vilket är 95A, 95A på ditt bord är på gränsen men fullt möjligt med gott luftflöde, sätter du dit en vattenkylning eller liknande så kommer PB jobba mot EDC snarare än TDC vilket resulterar i 140A, detta är på ditt moderkort inte hållbart alls.

Men det är ju ganska imponerande att moderkortet + cpun klarar av det så bra som de gör ändå

Skickades från m.sweclockers.com

Har ett ASRock AB350M Pro4, det har som lägst legat på 750 kr enligt prisjakt. Så rätt billigt

Köpte det då det vid lansering av första generationen Ryzen fick betyget "bästa Ryzen-moderkort under $100" i ett par tester, ville bara köpa en enkel plattform för att själv kunna känna på Ryzen. M.a.o så det är inte precis värdelöst, men ändock budget.

TechSpot har testat detta moderkort med 3900X, så länge man inte överklockar (vilket jag inte gjort sedan Ryzen 5 1600) fungerade det hur bra som helst i deras test (och vad är poängen med att överklocka när prestanda ändras några enstaka procent med effektförbrukningen skjuter genom taket?).

Man inte ens är nära att nå gränsen för VRM temperatur utan överklockning.
https://static.techspot.com/articles-info/1872/bench/3900X.png

Värt att nämna här: såg större värde av att ha denna dator på jobbet än hemma, så min 3900X står nu i ett kylt serverrum. Har en 120 mm Noctua-fläkt som blåser över båda VRM-flänsarna (men gick bra att köra 2700X på detta moderkort utan den kylningen).

OK, då har du definitivt det jag klassar som "knäckebrödsbräda".

Bara så jag är med... De här testerna har du alltså gjort i ett kylt serverrum så vi kan helt ta bort kylning av både CPU och VRM ur ekvationen?

Stockkylaren må vara "meh", men ställer du en dator i ett kylt serverrum så ska det ju inte behövas mycket kylning alls egentligen.

Det som i så fall skulle kunna vara orsaken är att PB2 (inte PBO) även den är beroende av vad moderkortet kan spotta ur sig. Kan mycket väl vara så att 3 faser är för lite för att få till stabil spänningsreglering vid så tunga laster. Även om VRM tekniskt sett inte blir "för varm" så blir det ändå svårt att upprätthålla bra spänningsreglering, lågt rippel osv när strömuttaget pressar grejerna till max.

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!

Just det sistnämnda syns också i techspot testet där uppnådd frekvens skiljer ganska markant mellan borden under olika belastning, speciellt med tanke på att x570 bordet rullade med 1.0.0.3 agesa och b350 bordet rullar på 1.0.0.1, om något skulle b350 bordet ha legat rätt långt över x570 bordet i fråga om frekvens om bägge levererat samma kvalité på spänning

Lägg därtill att det är väldigt billiga komponenter. Att VRM-delen presterar sämre på en rad egenskaper när de närmar sig maxbelastning gäller ju alla, men särskillt illa blir det när det är låg kvalitet på komponenterna, så ja.. Det är nog därför boosten inte ens orkar hålla Base Clock i det här fallet skulle jag tro.

Sen har jag sagt förut att jag tycker att AMD borde försökt ställa högre krav på tillverkarna från början, eller helt enkelt specat högre maximalt strömuttag för AM4, men det är ju knepigt när man har Bulldozer i bagaget och ingen tror på plattformen.

Sen just den här brädan är väl extra illa med då de fått skit för att det ser ut som 6 faser men egentligen bara är 3.

@Yoshman: Som en sidokommentar till din stora post, AMD (tråkigt nog) exponerar endast en value för alla temp sensorer, så du kan inte läsa av fler (vare sig i linux eller annanstans). Den representerar dock inte bara en sensor, utan den sensors som just nu har högsta värde (eller om man kör senaste Ryzen Master, rolling högsta värde över en average av sensorer). Det förklarar också spikigheten i deras sensor. Det är inte att AMD spikar mer än Intel, det är att de mäter närmare var värmeutveckigen verkligen sker.