::: AMD Zen Samlingstråd :::

De har gjort småuppdateringar till sina kretsar tidigare. Som sagt, se 790FX till 990FX.

Och vadå riskera ny processteknik? Det är ju ganska satt i sten att de ska byta. De har pratat om 14nm+/12nm i månader, inklusive släppt kodnamnet Pinnacle Ridge. Så den kommer, frågan är bara när. Ryktet ovan säger Februari, om inte det stämmer så är det en annan månad, men processövergången kommer oavsett.
Dessutom är "12nm" ganska mycket just en 14nm+, från AMDs sida behöver de inte göra mycket för att konvertera Zen till den nya processen.

För de har produktlinjen på14nm som backup. Så fort volymerna är igång på 12nm så kan de släppa. Att det tog tid för Ryzen att släppas var snarare för att 14nm var färdigt innan Ryzen. Av allt att döma gick det ganska fort för AMD att få Ryzen till konsument från det att de första kretsarna provtillverkades.
Produktionsfel beroende på tillverkningsprocess märker man väldigt fort, då är det inga smygande buggar man upptäcker efter många månader som det kan vara med konstruktionsfel.
Men ja, att de har produktionen igång en bra bit innan Februari förutsätter jag så klart. Det är inte så att de startar riskproduktionen i Januari och redan har kretsar på marknaden i Februari. Det vore ju en sanslös bedrift. Allra helst om de kan lova det nu.
Att de satt lanseringsmånad nu pekar ju på att de redan fått bra resultat av sample production. Passar väl tidsscemat rätt bra med lansering 5 månader från nu om de sett resultaten från provexemplaren.
Som sagt är det ingen svår övergång heller. En annan variant av samma nod.

Ok, ett hett tips för den som får dålig FPS i 3DMark Firestrikes sista deltest "Combined".

Med 4GHz OC får jag ~40 FPS i detta test, detta förutsätter dock att Coreparking är aktivt, slår jag av coreparking sjunker fps ända ner till 30!
Detta gäller även vid stock klocks och där trodde jag att det berodde på XFR eller något men uppenbarligen är det inte detta utan Coreparking i sig själv som gynnar Ryzen på något sätt.
Har sett exakt samma beteende i en del spel också där CP aktivt konsekvent gett mer prestanda, om detta beror på att det limiterar processens förmåga att hoppa mellan kärnor i onödan vet jag inte men det känns spontant som en rimlig förklaring.
För den som vill kontrollera coreparking rekommenderar jag ParkControl

Standard firestrike test, samma som är länkat i signatur.
Eller menar du corepark?
Där kör jag på corepark aktivt med 5% min cores och frekvens kontroll på 90% minimum.
Skickades från m.sweclockers.com

Att Windows inte tar hänsyn till CCX är i praktiken ett mindre problem än man kanske kan tro. Linux har helt optimerat för fallet att man jobbar med oberoende saker på olika trådar. En bra första ansats för en server, inte alls säkert det rätt valet för desktop då två trådar på samma CCX kan kommunicera billigare (har en hel del resultat kring detta).

Specifikt vad Linux gör är att den utgår från att det man kör är separata uppgifter, så om första tråden allokeras från CCX#0 kommer nästa tas från CCX#1 för att maximera utnyttjande av L3$ (som är separat per CCX).

Alla funktioner på moderkortet fungerar, enda problemet jag märkt har med USB att göra (är ju samma ASMedia krets i alla B350 moderkort). Bootar man datorn och sedan använder USB fungerar allt perfekt så långt jag märkt, problemet uppstod när jag bytte till en 850Evo disk som tar ner boot-tiden ~1s. Bootar man först och sedan aktiverar WiFi (har en USB-dongel) fungerar det alltid, men tar man upp interfacet m.h.a. boot-script verkar det som USB-kretsen inte hinner initiera sig (det fungerade utmärkt med en långsammare disk).

Allt som skapar en OS-level tråd utan att ange en preferens för vilken CPU-tråd den ska köra på fungerar på det sättet. Det inkluderar då ett C++ program som skapar en ny tråd via std::thread.

Då jag har ett /etc/network/interfaces script som tar upp WiFi händer det långt efter (well, i CPU-tid i alla fall ) att userland är initierat. Detta kan självklart vara ett driverproblem, men som OS-utvecklare kan jag säga att det mycket väl kan vara ett HW-fel (som i detta fall då borde kunna lösas i en driver genom att helt sonika vänta en "säker" tid).

Har inte testat att montera en USB-disk på det sättet, så kan inte svara på det. Ska testa i något läge.

Finns förutom USB-problemet ingenting att klaga på, Ryzen-stödet i Linux-kärnan är lysande.

Kolla först vilken powerplan som är vald i Windows och välj även den i parkcontrol, sätt sedan corepark aktivt för ac och sätt min cores till 5%, sätt sedan frequency control AC till 90% för bäst prestanda eller 5% för max energisparande. Kombineras bäst med ryzen balanced powerplan.

Skickades från m.sweclockers.com

@JonkenPonken: Tror du lär vara admin inloggad eller ge parkcontrol admin rätigheter i alla fall. Till höger i bild ska de kärnor som parkeras bli gråa staplar, som i nedanstående bild.
https://i.imgur.com/0BDMWiU.png
Som synes är minst antal kärnor aktiva satt till 5% och lägst frekvens satt till 5%.

Här är också alternativet för att visa parkeringsinställningar under windows energiplans alternativ ikryssat, detta ger tillgång till en ännu större kontroll över hur kärnor parkeras, man kan som exempel justera den övre gräns som en kärna anses vara för mycket belastad och nästa kärna ska väckas, normalt står detta på 80% vilket kan vara lite i underkant då extra kärnor kan väckas i onödan. Vilket får till följd att XFR går ner i frekvens.

Jag vet inte riktigt varför men på min efter nybygget pinfärska windows installation med alla drivare inlagda så var coreparking helt avslaget för alla energiplaner, jag trodde i min enfald att AMD/M$ hade koll på läget men tydligen icke.

@JonkenPonken: För bäst prestanda med Ryzen bör du ha coreparking påslaget, slår du av det kommer du få sämre prestanda i en majoritet av spel och program, detta skiljer sig mot äldre processorer där coreparking för det mesta försämrade prestanda. Zen reagerar dock inte som äldre processorer. Detta oavsett om du kör klockat eller inte klockat. Bäst funktion och prestanda får man om man kombinerar coreparking med Ryzen balanced power plan då den ger möjlighet för processorn att byta strömtillstånd mycket fortare än andra energiplaner.

Om du vill få lägre frekvens i idle vid klockning så måste du använda P. state klockning