Threadripper gillar Quad DDR, men inte Dual DDR?

Quad channel innebär att processorn kan läsa/skriva från fyra minneskanaler samtidigt, till skillnad mot två kanaler för dual channel. Så man får dubbelt så hög bandbredd med quad channel, och lägre latens eftersom minnesåtkomsterna kan spridas ut över fler minnen.

Men även om dubbelt så hög bandbredd kan låta mycket så brukar det inte göra någon större skillnad i de flesta tillämpningar, men i vissa fall kan det göra stor skillnad. Så det beror helt enkelt på vad du tänkt använda CPUn till. Tyvärr så brukar det vara svårt att hitta test mellan olika antal minnen, så det kan vara svårt att säga hur viktigt quad channel är i just ditt fall.

Global vs Local Mode (tror det egentligen heter Distributed vs Local Mode) har av allt att döma med NUMA att göra.

TR är såvitt jag förstår hårdvarumässigt ett NUMA-system (icke-uniform minnesarkitektur), vilket innebär att minne är olika lätt att accessa beroende på var den kärna som kör tråden fysiskt befinner sig relativt minnet. Detta har i sin tur att göra med att TR i princip är 2 limmade Ryzen 7 med en 2-kanals minneskontroller i varje. Att hämta minne från den andra Zeppelinkretsen tar längre tid än att hämta från den egna (latens påverkas men inte bandbredd). Detta är likt hur K10 Magny-Cours fungerade redan vid 1 sockel, samt hur alla multisocket-system från både Intel och AMD fungerat sedan minneskontrollern flyttade in i CPUn - alla kärnor grupperas i sk. NUMA-noder tillsammans med den minneskontroller som sitter närmast. Detta innebär en begräsning i hur effektivt det går att skala program över fler noder, särskilt spel blir lidande av att få oförutsägbar variation i minnessaccesstid. Windows och Linux är NUMA-medvetna OS men detta leder till att de helt enkelt låter bli att schemalägga enskilda program över olika noder, vilket i praktiken betyder att ett spel i ett 2-nods system skulle köra på endast halva maskinen.

Pga detta finns ofta möjligheten att "slå av" NUMA med något som brukar kallas Node Interleaving (något förenklat ≈ raid0 mellan minneskontrollers), vilket ökar latensen för alla minnesaccesser, men dubblar bandbredden vid 2 noder. (Logiken är i stort sett densamma som vid raid0 mellan diskar). TR har såvitt jag förstår detta läge (under namnet Distributed Mode, som reddit-posten kallar Global Mode) aktivt som default, dels för att användare ska slippa bry sig om NUMA, dels för att undvika scenariot att ett program begränsas till halva maskinen. (Möjligen också för att kunna skryta med lite bandbreddssiffror). Nackdelen är att minneslatensen ökar överlag, vilket inte heller är idealt för spel. För TR kallas Node Interleaving "Distributed Mode", medan läget där NUMA är synligt för OS och mjukvaran kallas "Local Mode". Distributed Mode är alltså default.

Jag vet inte om du läst Anandtechs review av TR, där förklaras en hel del kring detta samt TRs olika conf-alternativ kring minnesaccess. Framför allt dessa två sidor:
https://www.anandtech.com/show/11697/the-amd-ryzen-threadripp...
https://www.anandtech.com/show/11697/the-amd-ryzen-threadripp...

Samt även uppdateringen om game mode efter att AMD gjort tydligt hur det fungerar:
https://www.anandtech.com/show/11726/retesting-amd-ryzen-thre...

Jag har inte analyserat denna info i detalj eller dragit konsekvenserna av alla valmöjligheter, särskilt inte mot möjligheten att köra < quad channel. Men det känns som att det är relevant för din frågeställning, och kan bidra till att reda ut varför det verkar komma olika bud från olika användare och tyckare. Vad som inte är helt tydligt för mig är hur dual channel fungerar givet denna arkitektur - kommer varje minneskontroller att köras i single channel mode, eller kommer minneskontrollern i en Zeppelinkrets helt enkelt att stängas av? Det senare alternativet skulle göra det omöjligt att köra dual channel med Node Interleaving avslaget. (nu är jag inte säker på exakt hur TRs Distributed Mode fungerar, Anandtech skriver en del som tyder på att det inte exakt är interleaving utan något liknande). Påståendet att dual channel ger högre latens, som ges i reddit-citatet, är inte uppenbart vad det baseras på. Men det skulle kunna ha med detta att göra.

Det som kallas "Game Mode" blir särskilt intressant för dig om du tänkt virtualisera en gamingmaskin, givet denna beskrivning från AMD:

https://images.anandtech.com/doci/11726/game_mode_amd.png

"We tell the OS to use a Local Mode (NUMA) memory, which keeps a game and its memory footprint inside one CPU-die and the locally connected DRAM. This minimizes several key latency points in the system, which most games love. [min kursivering]

"Game mode", om jag ska ta AMD på orden innebär alltså att redan i BIOS halvera maskinen och bara visa OS en Zeppelinkrets - en radikal lösning på problemet med hög minneslatens i Distributed Mode (motsv. Node Interleaving), samtidigt som OS inte får veta något om NUMA. Jag är inte helt klar över varför de inte anförtror moderna OS att hantera detta. Detta måste också innebära att du inte bara får halva processorn utan även halva minnet, något som AMD inte skriver explicit, men underförstått i "the locally connected DRAM".

Men nu till den trevliga biten med detta - med virtuell spelmaskin så kan du göra exakt det som "Game Mode" innebär, och samtidigt ha andra halvan av maskinen kvar till annat! Du ser bara till att ha NUMA synligt för Linux (Local Mode + Creator Mode) och pinnar i Linux virtuella maskinen till en NUMA-nod (numatune samt vcpupin i libvirt). Då kommer Windows bara att se en NUMA-nod, och allt minne som accessas är garanterat NUMA-lokalt. Nackdelen är att du inte kan partitionera maskinen exakt hur du vill, men samtidigt så kan det vara en acceptabel begränsning givet hur många kärnor du får. På min Opteron-rigg i signaturen gjorde jag oftast så och gav en av de 4 NUMA-noderna till Windows, vilket innebar 4 kärnor och 8Gb minne. Ibland kändes det snålt för vissa laster och då gav jag mer i kombination med Node Interleaving, men jag såg inga stora praktiska skillnader i spelscenarier (2.6GHz var den stora flaskhalsen i vilket fall).

Slutligen: Jag tror inte att hastighetsskillnaden mellan 2 eller 4 kanaler är särskilt relevant i andra fall än för benchmarks i dagsläget, oaktat NUMA. Men givet NUMA så kan det vara relevant att tänka på hur du vill partitionera maskinen i praktiken, och optimera för detta.

Jag skulle nog i ditt läge satsa på 2x16 nu men budgetera för 2 likadana stickor till inom en inte alltför avlägsen framtid. Alternativt om du vet att du nöjer dig med 64Gb totalt köra 4x8 nu, men det är förmodligen lättare att hålla minnena med vettig klock om du inte i slutändan behöver 8 stickor.

Hmm, intressant det du nämner ang. minneskontrollerna vid dual channel. Skulle det ens bli samma prestanda som dual channel då? Du får ju isf 2x64-bit(eller vad man ska kalla det) minnes buss istället för 128-bit som vid normal dual channel.

Isf borde ju quad channel skala helt linjärt och inte ha någon nackdel alls, vilket får mig att tro att det går på en och samma kontroller vid dual channel.

Kollar man i Aida64 tex.(ett DDR3 system iofs)

http://piclair.com/data/u7knj.jpg

Det är väldigt viktigt att man får tag i exakt samma minnen när man väl uppgraderar till quad. Det bästa är att köpa ett quad kit som är testat och binnat så dom är så jämna som möjligt. Det går att köra quad channel med tex. hynix blandat med samsung ic, men då får man dra ner klocken riktigt lågt och köra väldigt slappa timings. Kan tänka mig att det kan bli ganska struligt då TR väl i likhet med ryzen är känslig vad gäller minnen.

I fallet att den kör en sticka per kontroller så borde det bli så. Detta inser jag är något som borde gå att räkna ut bara genom att läsa manualen från ett TR-moderkort, utifrån hur rekommendationerna är för att bestycka banker vid olika antal stickor (jag har inte försökt).

Jag är inte säker på att det finns något i just det parallella fallet att dela maskinen i två, som gör 2x16 mindre ofördelaktigt än annars. Snarare tvärtom, då det inte är säkert att du kan utnyttja minnets lokalitet i det fallet. Menar mest att 2x16 ska vara lugnt för att oavsett hur det är löst, så kommer bandbredden inte att vara en flaskhals i normala fall. Jag skulle ge en spelVM antingen en CCX eller en Zeppelinare beroende på behov.

Tänkte du leva med buggen som gör att VM inte kan resettas utan reboot av host, och att vissa grafikkort inte fungerar alls med passthrough på TR? För den har väl ingen löst ännu. Glöm inte att berätta hur projektet går!

@sAAb: Ja jag iddes inte heller vänta, valde Coffee Lake delvis för TR-resetproblemet och delvis för att kunna spara watt genom att använda IGD i hosten. Rapport kommer såsmåningom.

Dock så är ju windows ganska stabilt nuförtiden, så du kan nog få helt ok bootcykler beroende på användning. Tyvärr så är väl winupdate fortfarande glad i att starta om i tid och otid.

Hmm, undrar om vi inte pratar förbi varann nu... hur noga läste du reddit-länken du skickade? Personen där får det att funka med ESXi, men inte med KVM (hen testar båda). Jag känner inte till att någon fått Nvidia-kort att funka med KVM på Threadripper (till skillnad från Ryzen 7), det verkar vara specifika problem med just TR som gör att bara kort som lider av Resetbuggen fungerar öht (men fortfarande bara en gång per powercycle, pga just resetbuggen). Se https://forum.level1techs.com/t/threadripper-gpu-passthrough-... (första posten, min fråga, och TS svar). Har även sett någon reddit-tråd som gör den slutsatsen, men har inte kvar länken.

Ovanstående verkar mycket relevant för dig om jag förstått ditt användarfall rätt! Så du inte köper ett grafikkort som inte går att använda alls till det du vill.

Men situationen kan ju fort förbättras iom att så många testar. Jag menade alltså att kunskapen om att det funkar med ESXi kan kanske hjälpa personerna bakom KVM & vfio att hitta en workaround, samt att jag inte vore så pigg på att byta till ESXi från KVM (som jag använder nu). "För gammal" var mer bildligt... vill inte byta dels för att jag kan KVM bäst, men också för att det passar mitt användande bäst.