::: AMD Zen Samlingstråd :::

Nej boost på en kärna är 4.0 med TBM3.0 men du har helt rätt i att all core inte är 3.7GHz den är 3.5GHz, inte helt lätt att få fram den informationen, normala turbo boost 2.0 för enskild kärna är 3.7GHz. MCE använder turbo boost 2.0 multipel för enskild kärna och applicerar det på boost för alla kärnor. Det är lite annorlunda på 2011-3 mot mainstreamplattformen med ett extra boost läge.
Kvarstår dock samma problem, med funktionen MCE från asus ändras turbo funktionerna från intel, igen hur många gånger kan man förklara samma saker?

Alltså med rätt frekvenser som dom ska vara för 6900k.
Basklock 3.2GHz
Turbo all core: 3.5GHz
Turbo en core: 3.7GHz
Turbo Max 3.0 (en core): 4.0GHz

Här kommer problemet med MCE
Bas 3.2GHz
Turbo all core: 3.7GHz
Turbo en core: 3.7GHz
Turbo Max 3.0 (en core): 4.0GHz

Sen finns det enligt utsago ett läge som tillför samma princip på TBM3.0 läget vilket ger en riktigt saftig OC.

Sen har vi 7700K då,
Bas:4.2GHz
all core:4.4GHz
en core:4.5GHz

Med MCE
Bas:4.2GHz
all core:4.5GHz
en core:4.5GHz

Inte den högsta ökningen direkt men fortfarande utanför intels specifikation och när folk nagelfar varenda procentuell skillnad i fps mot AMD gör 100Mhz skillnad. En annan är 6700k
Bas: 4.0GHz
all core: 4.0GHz
en core: 4.2GHz
MCE: 4.2 på alla

Källa
https://en.wikipedia.org/wiki/Kaby_Lake
https://en.wikipedia.org/wiki/Skylake_(microarchitecture)

Angående MCE och vad det gör så kan det inte förklaras mer, dom som fortfarande inte förstår kommer heller inte förstå...

Nu har jag inte direkt följt diskussionen här angående turbo boost så jag har inte särskilt koll på exakt vad som diskusterats.

Det som jag reagerade på var att 6900K påstods att köra i 3.7 GHz på alla kärnor i stock när det i själva verket var Multi-Core Enhancement (MCE) som var aktiverat, en funktion som inte finns i alla moderkort och är förmodligen inte aktiverad från start, utan att det sades i originalinlägget att man hade MCE på.

Intressant med 6900K's all core turbofrekvenser, var har du fått den infon från? Står inget om det i sidorna som du länkat in varför jag undrar vad källan är för denna infon.

Det mesta framgår relativt tydligt om du läser lite bakåt, för att få fram info på 6900k och dess turbo boost behöver du bara googla så får du rätt många svar. Intel själva är inte direkt öppna med vad som exakt gäller och av någon anledning har detta inte tagits upp speciellt noga i tester av 6900k heller. Den infon som är knepigast att få fram är all core boost men tack vare att ryzen ställdes mot 6900k i preview tidigare så finns info om 6900k på flertalet sajter i samband med detta och det går att läsa från användare av 6900k som undrar varför processorn bara boostar till 3.5 under flertrådad last. Intel själva specar på ARK allt utom "all core" boost

http://ark.intel.com/products/94196

Skickades från m.sweclockers.com

Med andra ord har du fortfarande inte länkat in en källa för 6900K's turbofrekvens när alla kärnor belastades vilket var det jag efterfrågade...

Angående källor har jag hittat detta som indikerar på att 6900K har en turbofrekvens på 3.5 GHz när alla kärnor belastas men även det är ingen slutgiltig källa, det är en indikation som bäst.

Om du har fått 3.5 GHz från någon annanstans länka gärna in det.

@tellus82: @yoshman

MS verkar ha bekräftat att schedulern inte riktigt tar hänsyn till Ryzens design.

https://i.redd.it/e9vdxtsb4bky.jpg

Fast just effektförbrukningen var väl något av en AMD marketing grej? Jag kommer ihåg från sweclockers recension eller om det var eftersnacket att Ryzen drar mer ström än motsvarande Intel CPUer, det är bara att AMD satt TDP på 95W, vilket alltså inte är ett mått på hur mycket ström CPUn drar, utan refererar till vad CPU-kylaren ska klara, om jag förstått det rätt.

Håller med till 100 % om att kör man utanför specifikation så är det överklockning. Däremot drog du det för långt med TDP-exemplet, hela poängen med XFR är ju just att CPUn kommer gå utanför sin specificerade TDP om det är möjligt (R7 1800X drar ju 125 W under maxlast enligt SweClockers mätningar). Intel gör också detta, fast bara på sina laptop CPUer.

Det man kan fråga sig är: exakt vad är "gå utanför specifikation". Skulle säga att funktioner likt de som de flesta moderkort med Z97/Z170/Z270/X99 där man kör alla kärnor på sin Turbo 2.0 frekvens är helt att jämföra med "fabriksöverklockning" på grafikkort. Det är en gråzon då det är utanför specifikation från kretstillverkaren, men å andra sidan är det inom vad tillverkaren av moderkortet faktiskt garanterar. D.v.s. om jag köper ett moderkort från ASUS där funktionen är påslagen från start (väldigt vanligt) så har jag nu en garanti att det kommer fungera, fungerar det inte är det fel på produkten och jag ska ersättas med en ny.

Till och med mitt relativt enkla mini-ITX Z97 moderkort har ju funktion att köra alla kärnor på max turbo, fast här var funktionen inte påslagen som förval. I praktiken kommer det fungera i 100% av fallen förutsatt att man har kylare nog då detta kan få CPUn att behöva en kylare med högre kapacitet än TDP.

SweClockers är faktiskt helt konsekvent här, de kör GPU i den frekvens AMD/Nvidia specificerar och man kör CPUer utan dessa prestandahöjande moderkortsfunktioner. Däremot kan man fråga sig om det var rätt av SweClockers att även köra utan Turbo Boost 3.0 (TomsHardware körde med TB3 på och då presterar 6850K, 6900K och 6950X identiskt i Cinebench ST, vilket inte är fallet för SweC). Då jag inte har mycket till övers för E-serien var det inget jag orkade påpeka.

Och exakt vad är problemet då?

Är det detta? I så fall verkar det problemet vara relaterat till moderkort/mikrokod i CPU, inte Windows då vissa faktiskt får rätt resultat från Coreinfo. Det är inte heller ett problem för SMT då detta inte är något OSet reder ut från cache-topologin utan från en specifik CPU-tråd-till-kärnor topologi som kommer från en annan källa (är den fel går det inte att aktivera alla CPU-trådar).

De problem jag läst faktiskt finns härrör till problem med frekvensskalning och C-states (lägga en kärna i vila). Här finns saker som påverkar prestanda negativt för Ryzen, alla dessa problem går dock att komma ducka för tillfället genom att köra "performance" profilen i Windows. Detta var något som bl.a. Toms Hardware tagit upp i sitt Ryzen-test, man kör normalt alltid med "balanced" profilen. För Ryzen har man testat både "balanced" och "performance", den senare presterar något bättre i spel.

För när det kommer till Unigine Heaven Benchmark så uppvisar den helt förväntat beteende givet hur Windows idag hanterar SMT, har fortfarande inte förstått vad @tellus82 anser problemet vara. Detta program använder inte cache-topologin till låsa program trådar till specifika CPU-trådar (vilket var det enda jag pekade på innan det hela spårade ur).

Programmet är multitrådat, en tråd är klart hårdare lastad än övriga och Windows verkar av någon anledning ha en förkärlek att lägga den på CPU-tråd #0 oavsett om det är en Ryzen eller en Core. Det finns jobb nog att fullt ut lasta ungefär två kärnor, fast det på betydligt fler trådar än två. Windows försöker hålla dessa trådar på en av det två CPU-trådarna i varje kärna när det finns mer CPU-kraft än nödvändigt (vilket är en fullt rimlig policy för SMT, Linux gör på samma sätt).

Om man specifikt låser ner Unigine Heaven Benchmark till en CPU-kärna och två trådar används båda trådarna till 100 %, i det läget blir CPU-delen flaskhals i mitt system. Detta skulle vara intressant att se även på Ryzen, om det inte blir på detta sett finns det ett problem.

Om man specifikt låser ner Unigine Heaven Benchmark till två CPU-kärna och fyra trådar används två CPU-trådar till nära 100 % (en per fysisk kärna) och två används mindre men är ändå lastade. I detta läge är GPU åter igen flaskhals i mitt system, vilket visar att det programmet är inte speciellt CPU-krävande. Åter igen, skulle vilja se motsvarande köras på Ryzen för det är beteendet som är förväntat.

Fast det var väl ändå aldrig kritiken mot Bulldozer? Kritiken var väl ändå att den presterade dåligt rakt över i saker som inte jobbade med alla trådar, vissa försökte förklara detta med en delad flyttalsdelen men den förklaringen höll inte riktigt vatten då problemet även gällde program som jobbar med heltal.

Nej XFR tillhör spec från AMD själva och det är samma över hela plattformen, precis raka motsatsen till MCE, en teknik som absolut inte tillhör Intel själva, en specifikation från dom eller ens plattformen i stort.

Men det du inte verkar vilja ta in är detta: att undvika att lägga last på båda CPU-trådarna i en fysisk kärna är RÄTT beteende, så den graf du postade visar ju att Windows uppför sig på FÖRVÄNTAT sätt även på Ryzen.

Och ovan har överhuvudtaget inget med att cache-topologin visas på fel sätt. Faktum är att om det hade påverkat hade Windows behandlat alla CPU-trådar som fysiska kärnor. DET hade varit ett stort problem, men åter igen, grafen över CPU-last du postade visar med otrolig tydlighet att Windows föredrar att lägga jobb på var annan CPU-kärna. CPU-trådar ligger ju som AaBbCcDd|EeFfGgHh hos Ryzen så alla udda CPU-trådar ligger på samma fysiska kärna som den CPU-tråd precis innan, man räknar alltid från #0 så första CPU-tråden (A) är ett jämnt nummer och den delar fysiska kärna med nummer #1 (a).

Säger inte emot något du skriver här.

Konstaterar bara att om MCE finns som beskriven funktion och är påslagen som förval så spelar det ingen roll för mig som kund vem som specificerat vad. Om det inte fungerar är produkten trasig och jag kan enkelt begära få problemet åtgärdat. Så från perspektivet som användare betyder det att MCE kommer fungera i 100 % av fallen, precis som "fabriksöverklockade" GPUer kommer fungera i 100 % av fallen. Om det av någon anledning strular har jag fått en defekt produkt som ska ersättas.

Håller också med om att MCE bör vara avslaget vid test, men man skulle gärna få göra några testskott som visar ungefär hur mycket mer man kan förvänta sig få i praktiken då ingen lär köra med det avslaget.

Men det du inte verkar vilja ta in är detta: att undvika att lägga last på båda CPU-trådarna i en fysisk kärna är RÄTT beteende, så den graf du postade visar ju att Windows uppför sig på FÖRVÄNTAT sätt även på Ryzen.

Och ovan har överhuvudtaget inget med att cache-topologin visas på fel sätt. Faktum är att om det hade påverkat hade Windows behandlat alla CPU-trådar som fysiska kärnor. DET hade varit ett stort problem, men åter igen, grafen över CPU-last du postade visar med otrolig tydlighet att Windows föredrar att lägga jobb på var annan CPU-kärna. CPU-trådar ligger ju som AaBbCcDd|EeFfGgHh hos Ryzen så alla udda CPU-trådar ligger på samma fysiska kärna som den CPU-tråd precis innan, man räknar alltid från #0 så första CPU-tråden (A) är ett jämnt nummer och den delar fysiska kärna med nummer #1 (a).

Detta kanske redan tagits upp men verkar som att Ryzen hålls tillbaka av Windows 10.

http://wccftech.com/amd-ryzen-performance-negatively-affected...

Not All Threads Are Created Equal
Windows 10′ scheduler correctly identifies Intel’s hyper-threads as lesser performing than principal core threads and schedules tasks in a way that’s takes advantage of the additional throughput without negatively impacting performance. Unfortunately the scheduler currently is not able to differentiate principal core threads from virtual SMT threads with Ryzen and in fact sees 16 thread Ryzen 7 processors as processors with 16 physical cores with equal resources per thread.

Because it does not give any preferential prioritization of scheduling tasks to primary threads over SMT threads like it does on Intel platforms, a massively larger percentage of tasks can and do end up getting scheduled for a virtual SMT thread rather than a principal core thread. Resulting in significant artificial performance degradation.