Tråden om Minnen till Ryzen, frågor svar, goda råd, resultat med mera.

@Dallen: 3dmark kan variera i totalpoäng ett par hundra hit & dit med samma inställningar vid olika rundor så för att med säkerhet testa prestanda måste man köra ganska många testvändor. Tricket är också att balansera timings vs frekvens, måste man öka timings för mycket för att uppnå en hög frekvens så kommer vissa applikationer ge sämre resultat än lägre frekvens med lägre timings. Man får helt enkelt testa vad som ger mest för sin egen burk, för mig så är prestanda i snitt ganska nära mellan 3333 och 3466 men då jag kan köra samma timings vid dessa frekvenser så är ändå 3466 snabbare överlag. När det gäller Infinity fabric frekvens så tjänar man inte jättemycket på minnesfrekvens över 3200 enligt utsago och vad det gäller bandbredd så kommer man såklart nå en punkt där minnesbandbredd inte heller är en flaskhals, det beror såklart på om man kör stock och om man kör en R5 eller R7 också. AMD själva har vid flertalet tillfällen pekat på att timings är viktigare för spelprestanda än bara ren frekvens men personligen skulle jag säga bägge delarna och sweetspot verkar ligga runt 3333/3466 beroende på vilka timings man kan pressa ur sina minnen.

Sen finns ett till problem som är lite lurigt att hantera och det är hur moderkort & IMC sätter tertiära timings under memory training, detta har man som användare ingen direkt konrtoll över och det kan vara så att moderkort/IMC sätter alldeles för höga tertiära timings för att uppnå en högre frekvens och man kan således tappa prestanda trots samma primär och sekundär timings med endast höjd frekvens.

Har tittat lite på effekten av frekvens och timings på RAM för mitt Ryzen-system (det kör Ubuntu-server).

Latens
Viktigt för hela diskussionen här. Latens i cykler, d.v.s. CL värdet, är i sig ofta rätt ointressant. Det man vill minimera är latensen räknad i nanosekunder och den beror både på CL och frekvens!

ns(Freq, CL) = 2000 * CL / Freq

där CL är CAS-latency i cykler och Freq är "frekvensen" på RAM i MT/s (DDR4-2666 har faktiskt en frekvens på 1333 MHz, fast 2666 megatransfers per sekund då DDR står för Double Data Rate -> två överföringar per cykel).

CCX
Kan börja med en sak som faktiskt var rätt intressant. Har skrivit ett program som gör samma sak som det PcPerspective trummat för , d.v.s. ett program som mäter tiden för att skicka ett paket från kärna N till kärna M och tillbaka till kärna N. Får extremt konsekventa resultat med programmet, diffar som mest en nanosekund upp/ner och oftast får man på nanosekunden samma resultat mellan körningar.

Väljer man CPU-kärnor i olika CCX har ju teorin varit att dessa kommunicerar via Infinity Fabric (IF). IF kör på samma frekvens som RAM, man ser också att latensen minskar med ökad minnesfrekvens. Det intressanta är att latensen mellan CCX även minskar med minskad RAM-latens, d.v.s lägre CL vid samma frekvens påverkar CCX latensen. Detta betyder att CCX:er inte direkt kommunicerar via IF, transaktionen går via RAM! Lärdom: både RAM latens och frekvens påverkar CCX kommunikation (inte bara frekvens som hade varit fallet om CCXer kommunicerat direkt via IF).

Minneskontroller
Total latens man får mot RAM är summan av latens från minneskontroller samt latens från RAM. Har 14 st mätpunkter med frekvenser från 1833 till 3066 samt CL från 10 till 18, följande formel ger CCX<->CCX ping latensen med på enstaka nanosekunder när

Latency(Freq, CL) = 2000 / Freq * (75 + CL)

D.v.s helt väntat minskar latensen från minneskontroller med ökande RAM-frekvens. Som synes är det ett rätt stort tillskott från minneskontroller, så blir rätt mycket dimishing returns för riktigt låg CL. Detta indikerar att man ska prioritera frekvens om man har två fungerade minneskonfigurationer med ungefär samma latens (räknat i nanosekunder) men olika frekvens. Är precis vad jag även såg i de program som har något relevant skalning med RAM-hastighet.

Med en mindre parallellförskjutning ger ovan formel extremt bra förutsägelse på Geekbench 4 RAM-latensmätning. Så den kanske inte är helt perfekt, men det lär vara en rätt bra modell för Ryzens totala minneslatens.

20/80-regeln
Av det jag fått fram är att påverkan från RAM verkligen är ett typexempel på där Paretoprincipen (också känd som 20/80 regeln) verkligen gäller.

80 % av alla applikationer ser i princip noll påverkan från RAM-hastighet. För många här på SweC är det ändå intressant med RAM-hastighet då många spel finns bland de 20 %-en.

80 % av all påverkan från RAM är en direkt konsekvens av CL+Frekvens. Huvudtimings är CAS/RAS-to-CAS/RAS-precharge/Active to Precharge Delay och ibland finns även Command-rate med (är 1T/2T). Testade att sätta varje på ett "normalt" värde samt det högsta tillåta värdet och titta på effekten. CAS ger stort utslag, RAS-to-CAS ger i en del i syntetiska mem-copy tester men rätt lite i verkliga program (men ändå mätbart). Övriga ger minimalt utslag i syntetiska mätningar och var inte mätbart i något av de program jag testade.

Kunde överhuvudtaget inte mäta en skillnad när t.ex. tRFC var 250 i stället för förinställda 347. Möjligen var uppmätt latens i Geekbench 4 ytterst marginellt lägre, men såg ingen skillnad i applikationer eller i CCX-ping.

Command-rate
Detta är den sista delen av huvud-timings, finns inte alltid men när den finns brukar den listas som 1T eller 2T. 2T ger inte lägre prestanda, command rate är överhuvudtaget inte en flaskhals då en enda minnesöverföring ändå tar 4 cykler (burst rate är så lång). Men man ska ändå försöka köra med 1T då RAM-kretsarna drar mer ström i 2T läge, dock kan man nå högre frekvens med 2T.

Låt udda vara jämnt...
Vet inte om det är mitt moderkort eller något med Ryzen-plattformen, men för mig avrundades alltid CAS-värdet uppåt till närmaste jämna värde. Så CL13 och CL14 ger exakt samma resultat, likaså CL15 och CL16 osv. Det är fullt möjligt att sätta CL till 13, men blir alltså samma resultat som CL 14.

Spänning
Verkar som höjning av RAM-spänning (inom rimliga gränser) ger möjlighet till lägre latens. Egentligen helt logiskt då det som sänker systemet vid för aggressiva inställningar är att minnescellerna inte hinner ladda upp sig igen efter läsning -> bitar kan då spontant byta värde -> systemet kommer krascha.

Gissar att det är kring återladdning av minnesceller man kan hitta prestanda med subtimings. Kan mycket väl finnas inställningar där som möjliggör lite högre frekvens och/eller lägre CL utan att minnet börjar flacka.

Några resultat
Alla är tagna på en oklockad R5-1600 som kör Ubuntu Server 17.10

1866 10-18-18-35 vs 3066 16-18-18-35
2666 14-18-18-35 vs 16-18-18-35
2666 14-16-16-35 tRFC=267 vs 2666 14-16-16-35 tRFC=347

Har noterat att SGEMM resp. SFFT ibland ger väldigt avvikande resultat. Dessa två är de enda testerna som jobbar med AVX, vet inte om det har med saken att göra. Har som sagt inte klockat min CPU, temperaturer är väldigt låga (~60C).

För udda Cas värden måste du aktivera Gear down mode.

Skickades från m.sweclockers.com

Ok.

Geardown mode verkar sätta command-rate till 2T, är som sagt inget prestandaproblem men vill nog själv undvika detta på en dator som står på 24/7 (RAM utvecklar mer värme med 2T).

Kan man räkna ut det lättare?

14/3466 = 0,004
13/3333 = 0,0039
12/3200 = 0,00375

Då borde 12/3200 vara bästa att köra?

Om man enbart räknar på timing känsliga applikationer ja, nu är dock till exempel inte alla spel enbart timingkänsliga, en balans mellan hög frekvens och låga timings kommer ge mer I slutändan. Du får ut runt 5GB/s extra I bandbredd mellan 3200/12 och 3466/14 och detta gör att när bandbredd är flaskhals så kommer 3466 ändå vara snabbare, dessutom är det ovanligt att få ner timing så lågt som 12 på minnen som bara klarar 14 vid 3466, klarar dom 12 vid 3200 är det mer troligt att dom kan köra 13 vid 3466. Sen har vi ett till bekymmer i det hela och det är sekundära och tertiära timings, dessa gör en mycket stor skillnad på Ryzen och här får man prova vad man kan komma undan med men generellt är det mycket liten skillnad på hur lågt du kan gå i dessa vid 3200 eller 3466, sweetspot ligger någonstans 3333/3466 pga av detta. Infinity fabric frekvens påverkar även lite med lägre latenssänkning på högre frekvens och bättre bandbredd, dock är inte IF ett problem i hastigheter över 3200Mt men detta är lite svårt att testa för själv.

Skickades från m.sweclockers.com

Jag har precis börjat klocka mina minnen.
Kom ner på 3333/13 eller 3466/14 dock klarade de inte 3200/12. datorn vägrade boota.

Så då är frågan vad jag skall välja.
Förstår att det är mer avancerat än jag vill ha det som.

Gear down mode har också möjlighet att ändra command rate så det ska gå att sätta 1t även vid udda Cas, möjligt att moderkortet du kör frångår detta men det borde inte göra det.

Skickades från m.sweclockers.com

But what about overclockers?1 For overclockers, Geardown Mode will be noteworthy because it also tells the memory subsystem to "disregard" the command rate set in the BIOS. As 1T command rates can be beneficial (though tough to maintain) for performance, the chart below is really asking whether it’s useful to run GDM if the desired memory clockspeed can be achieved. Spoiler alert: probably not.

Our data points indicate that Geardown Mode should be disabled for gaming if you can achieve your desired memory overclock with a 1T command rate. The opposite holds true if 1T CR proves too aggressive to reach your desired clockspeed--leaving Geardown Mode enabled may get you there. Finally, when it comes to GDM vs. 2T CR (not shown), specific memory throughput testing should be conducted as the balance of power will come down to your other memory timings.

När jag stresstestar min burk (ej GPU) så drar den runt 205-215 W från vägguttaget. Tycker inte det är så superfarligt. Vet dock ej hur pass pålitlig den mätaren är. Har totalt 7 st fläktar i burken och de drar "ett par" Watt de med. Egentligen borde jag dra ned min CPU lite men grejerna funkar, och vissa filter i Photoshop tycker om hög frekvens på CPU. Spelen (strategi) och 4K lägger ju lasten på GPU och kommer så göra många CPU-generationer till innan man får klura på vad som bottnar vad. Men, mycket vill ju ha mer som det så vackert heter.

Hade XFR funkat så som jag vill, så hade jag nog nöjd mig med det. Men när kärnorna belastas till max så får jag numer bara 3.7 Ghz på alla kärnorna. Äldre UEFI så fick jag 3.8 Ghz på alla kärnor vid max belastning. Hade jag kunnat få 4.1 Ghz vid XFR på två kärnor och resten på 3.7 Ghz, så hade jag kört default på CPU.

Vad skulle ni säga är en safe RAM-temperatur för G.Skill 16gb 3200 Flare X-minnen? Antar att det är DIMM temperature Sensor man ska läsa av i HWiNFO.

Testade 3466-14-13-13-13-26-40-1T men fick inte lägre latenser i AIDA64 Benchmark så jag testade 3600-14-14-14-28-42-1T men fick än högre latenser så jag hoppade tillbaka till det jag kör 24/7 3466-14-14-14-28-42-1T, men har UEFI-buggen som gör att nån inställning gör så latenserna inte går tillbaka till det jag hade före jag labbade. Får hoppas det släpper efter några omstarter av burken.

Det enda jag har ändrat i spänningsväg för RAM är att jag ökade i UEFI idle 1.45 V och bootvolt 1.46 V. Vid mina 24/7 utan att ändra spänningen för RAM var att Windows kraschade vid inloggningsrutan.

Vet ej varför latenserna ökade och orkar inte ta reda på varför heller, men gissningsvis kanske minnena blev för varma. Har ingen direkt direktkylning på de utan den enda fläkt som kan blåsa lite på de är den som sitter i sidoplåten, och det är inte mycket det.

Känns som det finns potential i mina minnen. https://i.imgur.com/b9exeSo.png