Threadripper gillar Quad DDR, men inte Dual DDR?

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007

Threadripper gillar Quad DDR, men inte Dual DDR?

Jag flera gånger efterlyst argument för eller emot Dual eller Quad i olika trådar, men inte riktigt fått nån tydlig förklaring.

Nu hittade jag en tråd om det på Reddit, "Threadripper X399 performs poorly when in dual channel?"

https://www.reddit.com/r/Amd/comments/6utdlv/threadripper_x39...

Där skriver en läsare:

  • Quad channel in local memory mode is lower latency (basically dual dual channel), but has much less bandwidth.

  • Quad channel in global memory mode has more latency and bandwidth.

  • Dual channel mode has less bandwidth and higher latency.

Oki, jag köper det för det låter som att denne vet att är så... Jag varken vet att det är så eller varför det skulle vara så, så...

Är det någon här som vet eller förstår om det som påstås är sant eller åtminstone rimligt?

Gärna länk till någon sajt som förklarar.

Jag står i valet och kvalet mellan 2x16GB eller 4x8GB.

Grejen är att om jag väljer 2x16GB kan jag senare enklare gå upp mot 8x16GB om jag skulle vilja.

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Jun 2007

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.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av perost:

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.

Hej och tack för svar. Jo, bandbredden är säkert överskattad. Det syns i en länk till en artikel i pcworld.com, "Quad-channel RAM vs. dual-channel RAM: The shocking truth about their performance"

https://www.pcworld.com/article/2982965/components/quad-chann...

som också finns i länken ovan också, så, det är i praktiken inte så många benchmarks (utöver syntetiska bandbreddstester) som kan visa relevant skillnad. Nej, precis som du skriver, jag vet ju inte om mina användningsfall kan utnyttja dem heller.

Det känns i dagsläget som att 2x16GB är enklare att uppgradera när andan faller på.

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Plats
Karlstad
Registrerad
Mar 2007

Kort och gott så dubblar du minnes bussens bred, från 128-bit till 256-bit.

Det märks mest i benchmarks, inte speciellt mkt i praktiken, bortsett från vissa specifika scenarion.

Nackdelen med quad channel är att du oftast inte kan köra lika hög klock på minnet, som vid dual channel.

När du skall uppgradera måste du dock se till att få tag på exakt likadana minnen som du har, och då menar jag exakt som i samma kretsar och timings. Exakt samma stickor från samma tillverkare kan ha olika chip beroende på vilken version osv.

Trädvy Permalänk
Medlem
Registrerad
Jan 2003
Skrivet av sAAb:

...
Där skriver en läsare:

  • Quad channel in local memory mode is lower latency (basically dual dual channel), but has much less bandwidth.

  • Quad channel in global memory mode has more latency and bandwidth.

  • Dual channel mode has less bandwidth and higher latency.

Oki, jag köper det för det låter som att denne vet att är så... Jag varken vet att det är så eller varför det skulle vara så, så...

...

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.

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).

Trädvy Permalänk
Medlem
Plats
Karlstad
Registrerad
Mar 2007
Skrivet av Oegat:

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.

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)

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.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av Oegat:

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.

Skrivet av thereal_twisted:

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.

Tack för svaren! Grymt! Mina användningsfall är ju till viss del embarrassingly parallel, så 2x16 GB borde ju gå bra där. Men, med lite klister på trådarna mha lasso så borde man vid lustfyllda behov nog kunna allokera åtta kärnor och sexton trådar till spel och resten till sådant arbete.

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Registrerad
Jan 2003
Skrivet av thereal_twisted:

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.

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).

Skrivet av sAAb:

Tack för svaren! Grymt! Mina användningsfall är ju till viss del embarrassingly parallel, så 2x16 GB borde ju gå bra där. Men, med lite klister på trådarna mha lasso så borde man vid lustfyllda behov nog kunna allokera åtta kärnor och sexton trådar till spel och resten till sådant arbete.

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!

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av Oegat:

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!

Jag hoppades att den kommer lösas på sikt... Min nuvarande är bitvis så hopplöst föråldrad att jag inte orkade vänta mer.

Jag inser att jag kanske borde ha väntat, men det var för tungt. Jag får skippa Windows ytterligare tio år till.

Skickades från m.sweclockers.com

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Registrerad
Jan 2003

@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.

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av Oegat:

@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.

Jag saknar ju i alla fall ett vettigt grafikkort. Nu väntar jag på Ampere, vilket ändå är en rimlig förutsättning för en någorlunda bra upplevelse med Threadripper. Tills dess bör det ha kommit någon form av fix.

Jag misstänker också att sötebrödsdagarna med låga priser på AMD kan vara över. Om ipc-gapet minskar ytterligare så finns det inte längre någon anledning för AMD att krypa prismässigt under 2018.

EDIT: Hittade https://www.reddit.com/r/Amd/comments/72ula0/tr1950x_gtx_1060... där det verkar fungera.

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Registrerad
Jan 2003
Skrivet av sAAb:

Jag saknar ju i alla fall ett vettigt grafikkort. Nu väntar jag på Ampere, vilket ändå är en rimlig förutsättning för en någorlunda bra upplevelse med Threadripper. Tills dess bör det ha kommit någon form av fix.

Ok, så du hoppar över halvmesyren som Vega + passthrough skulle innebära och går på ett kort som (troligast) bara kommer att funka att virtualisera om någon ordnar en riktig fix. Om du inte tycker att täta omstarter är värt för att kunna köra Windows så är det nog vägen att gå.

Citat:

Intressant, hoppas det kan informera KVM-folket tillräckligt för att hitta nya workarounds. Själv är jag då för gammal för att lära mig en ny hypervisor...

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av Oegat:

Ok, så du hoppar över halvmesyren som Vega + passthrough skulle innebära och går på ett kort som (troligast) bara kommer att funka att virtualisera om någon ordnar en riktig fix. Om du inte tycker att täta omstarter är värt för att kunna köra Windows så är det nog vägen att gå.

Intressant, hoppas det kan informera KVM-folket tillräckligt för att hitta nya workarounds. Själv är jag då för gammal för att lära mig en ny hypervisor...

Här är först två användbara länkar om virtualisering gjorda av GrayWolfTech. Mycket lugna och sansade.

Windows on Linux! PCI passthrough quick guide

Beskrivning av installation mm

How fast is KVM? Host vs virtual machine performance!

Virtualiserat Windows under Linux är typ 94-96 % av barebone Windows! Sedan en annan jämförelse.

GTX 1080TI SLI | AMD TR 1950X OC VS Intel I9 7900X OC | Comparison

De är väldigt lika här. Fast 7900X är nog enklare med KVM.

För gammal, du?! Jag är nog inte tonåring mer än i sinnet själv.

För att vara on-topic. De varnar för mindre än 16 GB RAM.

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Registrerad
Jan 2003
Skrivet av sAAb:

Här är först två användbara länkar om virtualisering gjorda av GrayWolfTech. Mycket lugna och sansade.

Windows on Linux! PCI passthrough quick guide

Beskrivning av installation mm

How fast is KVM? Host vs virtual machine performance!

Virtualiserat Windows under Linux är typ 94-96 % av barebone Windows! Sedan en annan jämförelse.

GTX 1080TI SLI | AMD TR 1950X OC VS Intel I9 7900X OC | Comparison

De är väldigt lika här. Fast 7900X är nog enklare med KVM.

För gammal, du?! Jag är nog inte tonåring mer än i sinnet själv.

För att vara on-topic. De varnar för mindre än 16 GB RAM.

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.

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Jan 2007
Skrivet av Oegat:

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.

Jo, jag tänkte på att åtminstone fungerar ESXi, och att det, precis som du skriver, kan vara en väg framåt. Men, inser att jag inte följt upp det mycket mer än så.

Jag visste inte heller vad ESXi var och var tvungen att googla det. Men, utan någon djupdykning verkade det okej, eller? Var finns skillnaden som gör att det inte passar ditt användande?

| Fractal Design Define R5 | Asrock X399 Fatal1ty | AMD Ryzen Threadripper 1950X | Enermax Liqtech 360 | Corsair Vengeance LPX 4x8GB 3200 C16 | OCZ ZX 1000W | ASUS GTX 1070 Ti Strix | Samsung TA24-550 | Debian Sid | KDE 5 |

Trädvy Permalänk
Medlem
Registrerad
Jan 2003

@sAAb: Som sådant är det säkert inget fel på ESXi, men det är en klassisk "typ 1" hypervisor vars enda jobb är att utgöra virtualiseringsplattform till andra OS. Medan KVM/Qemu ligger närmare att vara en "typ 2" hypervisor (oinformativa namn, och något daterade...) där Linux körs i botten och andra OS körs virtuellt som ett ytterligare lager. Den praktiska nackdelen som jag ser är med ESXi är att du behöver virtualisera både Linux och Windows, förmodligen helst med dedikerade GPU i båda, om du vill ha en arbets/gamingstation med både Linux och Windows. Medan för KVM/Qemu behöver du bara virtualisera Windows men inte Linux. Det finns alltså hälften så många saker som kan ställa till problem, i fallet att vi gör knepiga och halvt osupportade tricks som att skicka igenom (konsument-)grafikkort.

Men med det sagt så är det nog ingen nämnvärd prestandaförlust med ESXi ens för Linux, och funkar det så funkar det! Så jag rekommenderar inte alls emot det (har inte kunskapen för att säga bu eller bä), tycker bara att den något enklare modell som KVM/Qemu innebär verkar mer smidig. Men det är en hel del konservatism inblandat där jag inte känner för att lära om (därav "för gammal"-kommentaren) samt att jag vill att Linux som jag kan rätt bra ska ha direkt kontroll över hårdvaran, snarare än ett nytt OS som är mycket yngre och som jag inte kan alls. Så jag vill inte avråda från ESXi om det funkar bra för det du vill göra, det är mer en personlig preferens. Testa gärna och berätta hur det gick!

Jag hoppas dock att information från fungerande fall med ESXi kan leda till att problemen med TR och KVM reds ut. Jag har inte heller sett några rapporter från försök med Xen och TR, den är visserligen typ 1 men ger betydligt mer makt till Linux relativt andra virtuella OS, så den är definitivt intressant.

Datorparken över tid: Pentium 150MHz non-MMX @208MHz OC (1997-1998), Dual PentiumII-350 @2x350MHz (1998-2008), DEC Alpha 21164 @500MHz (1999-2001), Pentium4 @2.53GHz (2004-2008), Athlon x2 be2300 @2x1.9GHz (2008-2011, 2017), C2D(laptop) @2x2.53GHz (2008-2011), PhenomII x4 910e @4x2.6GHz (2011-2012, 2018-), Dual Opteron 6140 @2x8x2.6GHz inkl. virtuell Win8 + GPU (2011-2017), Atom Avoton C2550 @4x2.4GHz (2014-), i7 8700 @6x3.2GHz inkl. virtuell Win10 + GPU (2017-)
Färgnyckel: Desktop/spel (primärt windows), Server (primärt *nix), Wks/Server (primärt *nix).