AMD hoppas bryta Intels dominans på servermarknaden med Zen

Permalänk
Master of Overkill
Skrivet av Bloodstainer:

Beror helt och hållet på. Om hårdvaran inte vore dyrt, så känns det dumt att påstå att AMD vore dyrare än Intel

För du ökar antalet cores det är där det blir dyrt.

Visa signatur

CASE Caselabs SMA8-A + TH10+PED + Louqe Ghost S1 CPU 9900k @5.3GHz (No AVX) 9800X @4.8GHz GPUs RTX 3090 FE RAM 4x16GB Corsair Dominator Platinum 3533MHz CL13 + 2x16GB Corsair Dominator Platinum RGB 3000MHz PSU EVGA T2 1600W + Corsair SFF 750W SSD 905p 480GB, 4x Samsung 970 Pro M.2 Headphones Audeze Maxwell + FOSTEX TR-X00 + Audeze LCD-2 + Moon Cable DAC/AMP Chord Mojo, Schiit Magni&Modi Screen LG 48CX 4K 120Hz HDR + ASUS ROG SWIFT PG258Q 240Hz
Motherboard X299 EVGA DARK + ASUS ROG Strix Z390-I Watercooling 560+480+480+280+360. 240+240

Permalänk
Medlem
Skrivet av Marsupilami:

http://www.tweaktown.com/news/55836/amd-zen-based-naples-cpu-...
Finns en del äldre artiklar också från andra källor, bara att googla

Jag är ju lite orolig för att de faller på enkeltrådsprestanda pga låga klockfrekvenser den här gången. Är medveten om att det inte är alls lika viktigt i servervärlden, men ändå, 1,4 GHz är inte mycket att komma med. Vi får hoppas att den kan använda turboläget duktigt.

På vilket sätt är det där officiella siffror menar du? Jag tar fortfarande inte frekvenserna speciellt seriöst. ST är knappast intressant för det segment som Naples ska fylla, utan bara så stor throughput och parallellism som möjligt.

Visa signatur

[ AMD 7800X3D // EK-Block @ custom loop, 2x420mm ][ MSI B650 Tomahawk ][ 32GB G.Skill Z5 Neo @ DDR6000 CL28 1T ][ AMD 7900XTX @ custom loop ][ Corsair 750D // Corsair RM1000X ][ 2TB Samsung 990PRO M.2 SSD ][ Win10 PRO x64 ][ LG 34GN850 ]

Permalänk
Skrivet av tvelander:

För du ökar antalet cores det är där det blir dyrt.

Kan du utveckla lite mer? Otroligt mycket oneliners..
Man blir inte klokare av det

Mvh,

Visa signatur

Mitt kärnkraftverk
|Asus PRIME-B350-PLUS|PH-TC14PE_OR|Ryzen 5 1400@3890MHz|Vega 56@Vega64bios |Corsair 2x4GB 3200MHz|Corsair TX 650w Bronze|CM Storm Enforcer|AOC G2460PF / 24"144Hz FreeSync|

Permalänk
Master of Overkill
Skrivet av Ytbehandlad:

Kan du utveckla lite mer? Otroligt mycket oneliners..
Man blir inte klokare av det

Mvh,

Licenser som är baserade på cores.

Visa signatur

CASE Caselabs SMA8-A + TH10+PED + Louqe Ghost S1 CPU 9900k @5.3GHz (No AVX) 9800X @4.8GHz GPUs RTX 3090 FE RAM 4x16GB Corsair Dominator Platinum 3533MHz CL13 + 2x16GB Corsair Dominator Platinum RGB 3000MHz PSU EVGA T2 1600W + Corsair SFF 750W SSD 905p 480GB, 4x Samsung 970 Pro M.2 Headphones Audeze Maxwell + FOSTEX TR-X00 + Audeze LCD-2 + Moon Cable DAC/AMP Chord Mojo, Schiit Magni&Modi Screen LG 48CX 4K 120Hz HDR + ASUS ROG SWIFT PG258Q 240Hz
Motherboard X299 EVGA DARK + ASUS ROG Strix Z390-I Watercooling 560+480+480+280+360. 240+240

Permalänk
Medlem
Skrivet av Garderoben:

Alltså är så trött på dom här "Vi får se Zenare" du förstörde precis min dag.

Samma här. Så jäkla tråkigt och uttjatat. Det var roligt EN gång.

Visa signatur

Hur många datorer är för många?

Permalänk
Medlem
Skrivet av tvelander:

Licenser som är baserade på cores.

Licens verkar vara lite olika, jag har tidigare hört det om antal kärnor.

Enligt WindowsServer2012R2_Licensing_Guide.pdf så är det som nedan och då passar det ju mycket bra med en Naples med 32 core, även om Naples även kommer med 16 core och "kanske" 24 core.

Sidan 12
Volume Licensing reference guide for Windows Server 2012 R2

Går här på antal fysiska processorer eller virtuella maskiner, det som ger högst värde (avrundat upp till närmsta heltal) avgör antalet licenser.
Antal fysiska processoerer / 2 = Antal licenser
eller
Antal virtuella maskiner / 2 = Antal licenser

Där står även: (Note: The number of cores on the physical processor is irrelevant.)

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!

Permalänk

Väldigt få som implementerar nya system på Windows idag om vi inte pratar om förlegade myndigheter eller gamla bolag.

Visa signatur

Fractal Design Define R5 - SuperNOVA 750 G2 750w - KFA2 GeForce RTX 3080 SG - G.Skill Flare X Black DDR4 3400mhz CL14 - Ryzen 3600 - MSI B450 Tomahawk Max - Samsung 850 Series EVO 500gb - Samsung 970 Evo Plus 1TB - Acer 27" Predator XB271HU

Permalänk
Medlem
Skrivet av Bengt-Arne:

Licens verkar vara lite olika, jag har tidigare hört det om antal kärnor.

Enligt WindowsServer2012R2_Licensing_Guide.pdf så är det som nedan och då passar det ju mycket bra med en Naples med 32 core, även om Naples även kommer med 16 core och "kanske" 24 core.

Sidan 12
Volume Licensing reference guide for Windows Server 2012 R2

Går här på antal fysiska processorer eller virtuella maskiner, det som ger högst värde (avrundat upp till närmsta heltal) avgör antalet licenser.
Antal fysiska processoerer / 2 = Antal licenser
eller
Antal virtuella maskiner / 2 = Antal licenser

Där står även: (Note: The number of cores on the physical processor is irrelevant.)

Microsoft's Windows Server 2016 will be moving from per-processor to per-core pricing.

Permalänk
Skrivet av tvelander:

Licenser som är baserade på cores.

Vilket inte alla är. Och sen oavsett användarmål så kanske man fortfarande kör virtualisering på en maskin och ändå behöver ett X antal cores per virtualisering. Det finns otroligt många fall där sånt inte körs via Windows, och där man behöver en aktiv licens per virtualisering. Vilket gör att det spelar ingen roll längre, behöver man 50 licenser för 50 maskiner som körs via ett nätverk där större servrar kör virtualisering så påverkas inte kärnantalet ändå. Det är absolut inte alla som delar upp maskiner i max antalet kärnor

Visa signatur

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Permalänk
Datavetare
Skrivet av Kyroz:

Lönlöst att sia om framtiden men Zen kommer med två saker till virtualisering som Intel saknar idag; SME och SEV - återstår att se hur väl dessa mottags av potentiella kunder.

Vad kan man göra med SME/SEV som inte kan göras med Intel SGX?

Sett att Wccftech hävdat med en dåres envishet att SGX inte har stöd för virtualisering, men de har bara totalt missförstått tekniken.

Ett av Intels huvudexempel för SGX är just fall när man har programvara och data i publika molntjänster som man vill skydda, det även från den som äger maskinvaran.

Det man missförstått är nog att SGX används per applikation, inte VM eller liknande. Gör ingen skillnad om applikationen kör i ett virtualiserat system eller inte, fungerar på samma sätt.

Är själv inte helt på det klara vad SEV gör, men klarnar säker när mer information om Zen hittar ut.

Skickades från m.sweclockers.com

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

Ändå så verkar det inte ändra kostnaden nämnvärt, då en grundlicens fortfarande startar på minst 8 core/processor och minst 16 core per server, nåot som passar en 16 core Naples.
Nästa steg förefaller vara 2 licenser och då upp till 32 core vilket passar 32 core Naples, nu var inte det dokumentet särskilt informativt men det verkar ändå inte vara att man enbart betalar linjärt per core utan det sker i typ trappsteg.

Om någon känner till prisbilden bättre, vilket jag är säker på att här finns, så rätta/förklara/förtydliga

Dom kör fortfarande med antal fysiska processorer som en faktor vilket kan ge fördel för Naples då antalet fysiska processorer blir mindre, behovet av antalet core per server borde inte behöva öka.
Såvida man inte förutsätter att Naples är så mycket svagare än Intels motsvarighet så man kompenserar med fler kärnor, vilket enbart är en spekulation då Naples prestanda och kostnad ännu inte är känd.

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!

Permalänk
Medlem
Skrivet av Yoshman:

Vad kan man göra med SME/SEV som inte kan göras med Intel SGX?

Sett att Wccftech hävdat med en dåres envishet att SGX inte har stöd för virtualisering, men de har bara totalt missförstått tekniken.

Ett av Intels huvudexempel för SGX är just fall när man har programvara och data i publika molntjänster som man vill skydda, det även från den som äger maskinvaran.

Det man missförstått är nog att SGX används per applikation, inte VM eller liknande. Gör ingen skillnad om applikationen kör i ett virtualiserat system eller inte, fungerar på samma sätt.

Är själv inte helt på det klara vad SEV gör, men klarnar säker när mer information om Zen hittar ut.

Skickades från m.sweclockers.com

Hur spritt är användadet av SGX?

Vet att det blev varnat en del för just SGX i början då det verkade enkelt för mailware att dra nytta av SGX och kanske få åtkomst till ring 0.
Här är en artikel "SGX: the good, the bad and the downright ugly"

AMD's motsvarighet bör vara "AMD Secure Technology" som troligen har liknande svagheter.

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!

Permalänk
Medlem
Skrivet av Yoshman:

Vad kan man göra med SME/SEV som inte kan göras med Intel SGX?

Sett att Wccftech hävdat med en dåres envishet att SGX inte har stöd för virtualisering, men de har bara totalt missförstått tekniken.

Ett av Intels huvudexempel för SGX är just fall när man har programvara och data i publika molntjänster som man vill skydda, det även från den som äger maskinvaran.

Det man missförstått är nog att SGX används per applikation, inte VM eller liknande. Gör ingen skillnad om applikationen kör i ett virtualiserat system eller inte, fungerar på samma sätt.

Är själv inte helt på det klara vad SEV gör, men klarnar säker när mer information om Zen hittar ut.

Skickades från m.sweclockers.com

Hittade ett pdf från AMD om just dessa funktioner SEV/SME. Om jag förstått det hela rätt handlar det om att AMD nu tagit fram ett sätt att kryptera inifrån CPU direkt innan data hamnar i RAM, Intels sätt lägger det i RAM okrypterat och är då känsligt för intrång just när det handlar om Molntjänster/virtualisering.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/1...

Visa signatur

Rʏᴢᴇɴ 5800X3D / Tᴀɪᴄʜɪ X570 / 64Gʙ DDR4/ RX 6950XT Mᴇʀᴄʜ 319

Permalänk
Datavetare
Skrivet av Bengt-Arne:

Hur spritt är användadet av SGX?

Vet att det blev varnat en del för just SGX i början då det verkade enkelt för mailware att dra nytta av SGX och kanske få åtkomst till ring 0.
Här är en artikel "SGX: the good, the bad and the downright ugly"

AMD's motsvarighet bör vara "AMD Secure Technology" som troligen har liknande svagheter.

Ser själv en hel del intresse för SGX för inbyggda system. SGX är rätt mycket mer flexibelt jämfört med ARMs TrustZone (som också används en hel del inom detta område).

I "molnet" finns det t.ex. projekt att köra "big-data" med t.ex. Hadoop där delar eller all data skyddas m.h.a. SGX.

Microsoft jobbar också på ett ramverk, Haven, som gör det möjligt att t.ex. köra delar eller hela RMDB i molnet hos en leverantör man kanske inte litar på men där man ändå kan skydda sin data m.h.a. SGX till ungefär samma nivå som om man körde allt på en lokal server stående i ett låst rum.

För Docker (som inte är virtualisering i teknisk bemärkelse) finns ett projekt som heter Scone: Secure Linux Containers with Intel SGX.

Länken du postar innehåller ju bara ren spekulation skrivet innan specifikationen på SGX fanns och innan det fanns kisel som implementerade funktionen. Den stora nyheten i SGX, jämfört med t.ex. ARM TrustZone och AMDs SME/SEV, är just att SGX fungerar även i lägen där man inte litar på koden i ring0/dom0 (endera att man inte litar på den som driftar servern alt. att något lyckats stoppa in elak kod i ring0/dom0).

Varje "enklav" man sätter upp med SGX kör i ring3, d.v.s. på samma nivå som "vanliga" applikation. Det är också förklaringen till varför det är helt irrelevant om applikationen är virtualiserad eller ej. Det enda serverägaren kan ställa in är om SGX ska vara på eller ej, om det är på kan inte ens serverägaren läsa den kod/data som ligger i applikationers enklaver (allt är krypterat i fysiskt RAM).

Efter att läst specifikationen för SEV tycker jag denna teknik är rätt lik ARM TrustZone, men man fixar den största begränsningen med TrustZone: att kunna ha mer än en säker zon (i ARM fallet har man i princip två "världar", en vanlig och en säker).

Så finns absolut tekniska skillnader mellan SME/SEV och SGX. Innan vi ser SME/SEV i verkligheten är det svårt att exakt säga hur bra tekniken är, på pappret känns ändå SGX som en betydligt mer flexibel lösning med en mindre attackyta (enda koden i kärnan för SGX är att skapa enklaver, resten sker i ring3 och hackar man en enklav är fortfarande både ring0/dom0 samt andra enklaver fortfarande skyddade).

Skrivet av TurboFreak68:

Hittade ett pdf från AMD om just dessa funktioner SEV/SME. Om jag förstått det hela rätt handlar det om att AMD nu tagit fram ett sätt att kryptera inifrån CPU direkt innan data hamnar i RAM, Intels sätt lägger det i RAM okrypterat och är då känsligt för intrång just när det handlar om Molntjänster/virtualisering.

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/1...

Om inte SGX krypterade informationen i RAM, vad vore då poängen med tekniken? Självklart är allt krypterat.

Dold text

Till skillnad från SME så är det inte ens möjligt för kernel kod / hypervisor kod att läsa/skriva RAM som används i en SGX-enklav. Just att SME inte krypterar innehållet i register vid VM-exit är något man pekat är en svaghet.

  • As with standard (AMD virtualization), under SEV, the virtual machine control block is not encrypted and handled directly by the hypervisor, allowing him to bypass VM memory encryption by executing conveniently chosen gadgets.

  • The general purpose registers are not encrypted upon vmexit, leaking potentially sensitive data.

  • The control of the nested pagetables allows a malicious hypervisor to closely control the execution of a VM and attack it with memory replay attacks.

SGX duckar alla dessa problem

  • SGX spänner upp noll eller flera enklaver inom varje specifik process, kontrollblocket för varje enklav är krypterat och enda sättet man kan exekvera kod och läsa/skriva data i enklaven är via eenter (enclave enter, fungerar ungefär som syscall från user-land in i kärnan). Den enda information den "osäkra" världen har är ett handtag för varje enklav, all kod/data i enklaven är krypterad för all kod som inte kör inuti enklaven.

  • motsvarande VM-exit från en enklav kallas Asynchronous Enclave Exit (AEX). Alla register sparas innan man kliver ut ur enklaven (så all information sparas krypterat i RAM) och det enda den "osäkra" världen ser är ett "syntetiskt" tillstånd där alla register är nollade (detaljer står i kapitel 40.3 för den som är intresserad)

  • ring0/dom0 kan överhuvudtaget inte göra en virtuell-till-fysisk mappning till fysiskt minne som används av någon enklav. Eller, det går logiskt att göra mappningen men man läser bara nollor och det man skriver går ner i ett svart hål (d.v.s. man kan inte mappa den verkliga fysiska page:en). D.v.s. det krävs en bugg i CPUn för att ens kernel kod / hypervisor ska kunna läsa/skriva minne skyddat av SGX.

Så ser faktiskt inte riktigt vad SME/SEV kan göra som man inte kan göra med SGX.

Vidare så verkar SME/SEV skydda från vissa typer av attacker, t.ex. det går inte att läsa innehållet i RAM (även om det ligger i non-volatile RAM). Men SME/SEV verkar fortfarande förutsätta att man litar på koden i ring0/dom0. Man kan inte direkt läsa informationen bara för att man befinner sig i högsta priviligeringsnivå, sock har kod som kör i ring0/dom0 möjligheter att t.ex. via register + hög frekvens av interrupt/vm-exit få tag i den skyddade informationen via s.k. information läckage.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Ser själv en hel del intresse för SGX för inbyggda system. SGX är rätt mycket mer flexibelt jämfört med ARMs TrustZone (som också används en hel del inom detta område).

I "molnet" finns det t.ex. projekt att köra "big-data" med t.ex. Hadoop där delar eller all data skyddas m.h.a. SGX.

Microsoft jobbar också på ett ramverk, Haven, som gör det möjligt att t.ex. köra delar eller hela RMDB i molnet hos en leverantör man kanske inte litar på men där man ändå kan skydda sin data m.h.a. SGX till ungefär samma nivå som om man körde allt på en lokal server stående i ett låst rum.

För Docker (som inte är virtualisering i teknisk bemärkelse) finns ett projekt som heter Scone: Secure Linux Containers with Intel SGX.

Länken du postar innehåller ju bara ren spekulation skrivet innan specifikationen på SGX fanns och innan det fanns kisel som implementerade funktionen. Den stora nyheten i SGX, jämfört med t.ex. ARM TrustZone och AMDs SME/SEV, är just att SGX fungerar även i lägen där man inte litar på koden i ring0/dom0 (endera att man inte litar på den som driftar servern alt. att något lyckats stoppa in elak kod i ring0/dom0).

Varje "enklav" man sätter upp med SGX kör i ring3, d.v.s. på samma nivå som "vanliga" applikation. Det är också förklaringen till varför det är helt irrelevant om applikationen är virtualiserad eller ej. Det enda serverägaren kan ställa in är om SGX ska vara på eller ej, om det är på kan inte ens serverägaren läsa den kod/data som ligger i applikationers enklaver (allt är krypterat i fysiskt RAM).

Efter att läst specifikationen för SEV tycker jag denna teknik är rätt lik ARM TrustZone, men man fixar den största begränsningen med TrustZone: att kunna ha mer än en säker zon (i ARM fallet har man i princip två "världar", en vanlig och en säker).

Så finns absolut tekniska skillnader mellan SME/SEV och SGX. Innan vi ser SME/SEV i verkligheten är det svårt att exakt säga hur bra tekniken är, på pappret känns ändå SGX som en betydligt mer flexibel lösning med en mindre attackyta (enda koden i kärnan för SGX är att skapa enklaver, resten sker i ring3 och hackar man en enklav är fortfarande både ring0/dom0 samt andra enklaver fortfarande skyddade).

Om inte SGX krypterade informationen i RAM, vad vore då poängen med tekniken? Självklart är allt krypterat.

Till skillnad från SME så är det inte ens möjligt för kernel kod / hypervisor kod att läsa/skriva RAM som används i en SGX-enklav. Just att SME inte krypterar innehållet i register vid VM-exit är något man pekat är en svaghet.

  • As with standard (AMD virtualization), under SEV, the virtual machine control block is not encrypted and handled directly by the hypervisor, allowing him to bypass VM memory encryption by executing conveniently chosen gadgets.

  • The general purpose registers are not encrypted upon vmexit, leaking potentially sensitive data.

  • The control of the nested pagetables allows a malicious hypervisor to closely control the execution of a VM and attack it with memory replay attacks.

SGX duckar alla dessa problem

  • SGX spänner upp noll eller flera enklaver inom varje specifik process, kontrollblocket för varje enklav är krypterat och enda sättet man kan exekvera kod och läsa/skriva data i enklaven är via eenter (enclave enter, fungerar ungefär som syscall från user-land in i kärnan). Den enda information den "osäkra" världen har är ett handtag för varje enklav, all kod/data i enklaven är krypterad för all kod som inte kör inuti enklaven.

  • motsvarande VM-exit från en enklav kallas Asynchronous Enclave Exit (AEX). Alla register sparas innan man kliver ut ur enklaven (så all information sparas krypterat i RAM) och det enda den "osäkra" världen ser är ett "syntetiskt" tillstånd där alla register är nollade (detaljer står i kapitel 40.3 för den som är intresserad)

  • ring0/dom0 kan överhuvudtaget inte göra en virtuell-till-fysisk mappning till fysiskt minne som används av någon enklav. Eller, det går logiskt att göra mappningen men man läser bara nollor och det man skriver går ner i ett svart hål (d.v.s. man kan inte mappa den verkliga fysiska page:en). D.v.s. det krävs en bugg i CPUn för att ens kernel kod / hypervisor ska kunna läsa/skriva minne skyddat av SGX.

Så ser faktiskt inte riktigt vad SME/SEV kan göra som man inte kan göra med SGX.

Vidare så verkar SME/SEV skydda från vissa typer av attacker, t.ex. det går inte att läsa innehållet i RAM (även om det ligger i non-volatile RAM). Men SME/SEV verkar fortfarande förutsätta att man litar på koden i ring0/dom0. Man kan inte direkt läsa informationen bara för att man befinner sig i högsta priviligeringsnivå, sock har kod som kör i ring0/dom0 möjligheter att t.ex. via register + hög frekvens av interrupt/vm-exit få tag i den skyddade informationen via s.k. information läckage.

OK! Då hänger jag med...

Däremot så vet vi inte mer om SME/SEV just nu än vad man viste om SGX innan det kom, så det är bara att vänta tills där finns mer dokumentation.
AMD verkar hålla hårt på det mesta innan lansering, ja hur som så är det rätt nära. Då fortsätter vi/jag

Visa signatur

Engineer who prefer thinking out of the box and isn't fishing likes, fishing likes is like fishing proudness for those without ;-)
If U don't like it, bite the dust :D
--
I can Explain it to you, but I can't Understand it for you!