Dotaz: nemohu se rozhodnout s virtualizaci...

[keygej]

Zdravim, mam dotaz.. mam "dost" vykonne pc a premyslim jestli je lepsi mit windows v linuxu, nebo linux ve windows. Wine mi nevyhovuje kvuli vykonu a dualboot jsem take vyloucil. Kvuli grafice bych uprednostnoval virtualizaci s vmware pro Debian, nebo mam pouzit VirtualBox s rozsirenim v Debianu s nainstalovanym Windows 7. Jde o co nejsmensi ztratu vykonu pri virtualizaci. Diky za kazdy nazor

Odpovědi

[Pavel 'TIGER' Růžička]

Pokud jsi hráč, virtualizuj Linux ... pokud hráčem nejsi, tak je nutné se rozhodnout, jaký systém chceš mít primární. Mnohdy o tom rozhodne i nějaký specifický software. Ale ode mne jako Linuxáka neočekávej objektivitu.

[Mac_CZ]

To s tím hráčem už díky VT-d neplatí.

[Pavel 'TIGER' Růžička]

Tak ano i ne ... pořád si hostující systém bude brát nějaké prostředky.

[Lazar]

Samozřejmě platí, že při výběru HW je nutné se orientovat dle "success stories".

Z vlastních pokusů (Asrock 970Ex4:AMD 970+Ath IIX4; MSI BigBang Trinery:P55&nF200+Xeon X3430) mi přišlo, že problém IOMMU/VT-d (pokud funguje!) není až tak v zátěži sdílených prostředků (CPU,MEM) HostOSem jako spíš v příslušnosti integrovaných device k nízkému počtu IOMMU_group což brání jejich optimální dělbě HW mezi HostOS a GuesOS(y). Testů, které by se exaktně zabývaly výslednými vlastnostmi virtualizované "Game machine" (KB/MS,LAN,SND,GPU:fps,latence,lagy, notabene s vlivem zátěže HostOSu) asi mnoho nebude.

[heh]

Problém s IOMMU_GROUP se ale týká hlavně platformy Intel kvůli absenci podpory ACS. Jednotlivá PCIe zařízení pak nejdou efektivně izolovat. Funguje to prakticky jen na PCIe linkách Xeonu E5.

V případě AMD je podpora ACS u SR5690/SR5670 i 990FX/990X/990 standardem. Chybí pouze u PCIe linek vycházejících z SB950.

[Lazar]

Jsem zvědav jak na tom bude platforma X99/Haswell-E, ale mám obavu aby nám naděje nevydržela pouze do první errata (pozn. respektive druhé, ta první bude patrně mj. o TSX).

Na to kolik je technologii IOMMU/VT-d již let (2006?), jí asimilace mezi ty běžně dostupné docela trvá.

[heh]

Toto není ani tak o IOMMU (která nesouvisí primárně s Virtualizací) ale o implementaci standardu PCI Express 2.0 a výše (jehož je ACS součástí).

O X99 bych si nedělal žádné iluze. Přidali hlavně další SATA 6Gb porty, čímž se ještě zvětšil obrovský DMI 2.0 bottleneck. Ten chipset je dopředu vadný by design, ale nechají si ho královsky zaplatit. Do opravy PCI Express (ACS) je spíše nic nenutí, protože passthrough (zejména SR-IOV) se používá hlavně na serverech, a již od dual socket 2011 jsou už zpravidla všechny PCIe sloty na desce přímo z CPU a chipset se pro I/O témeř nepoužívá.

[Lazar]

Spíš jsem narážel na nefukčnost VT-d v C1 revizi SB-E, ale nepřišlo mi že by se s IB-E/X79 situace nějak zvlášť zlepšila (tj. roztrhl pytel se VT-d success stories). Uvidíme.

[heh]

platforma X99 je na tom stejně blbě...

5.3. PCI Express* Root Ports (D28:F0,F1,F2,F3,F4,F5,F6,F7)

There are eight root ports available in the PCH. The root ports are compliant to the PCI Express 2.0 specification running at 5.0 GT/s. The ports all reside in Device 28, and take Function 0 – 7. Port 1 is Function 0, Port 2 is Function 1, Port 3 is Function 2, Port 4 is Function 3, Port 5 is Function 4, Port 6 is Function 5, Port 7 is Function 6, and Port 8 is Function 7.

This section assumes the default PCI Express Function Number-to-Root Port mapping is used. Function numbers for a given root port are assignable through the Root Port Function Number and Hide for PCI Express Root Ports register (RCBA+404h).

Access Control Services (ACS)/Alternate Routing ID (ARI) are not supported on the PCI Express root ports. Devices connected to these ports may not support direct assignment for Single Root I/O Virtualization (SR-IOV)

[Lazar]

Česky řečeno, dá se očekávat využitelnost (separace) aspoň na úrovni slotů?

[heh.]

NE.

Kontrolu ACS lze ale na vlastní nebezpečí "ohnout" nebo "vypnout" (viz odkazy).

[Lazar]

Včera/dnes jsem zkusil na testovacím VT-d prostředí (tj. mb MSI BigBang Trinergy[P55&nF200]+X3430@3,6GHz+8GB/1600MHz RAM+HD4870/512MB) srovnat výsledky benchmarků Windows 8.1x64(native) a Windows 7x64(KVM+PCI passthrough/vga_vfio, 2GB, HD4870, 4-core). HostOS: Kubuntu 14.04 s vanilla 3.15.3

3Dmark 2006 (u moderních silných GK bráno jako čistý CPU benchmark, použitou HD4870 CPU nelimituje).

Windows 7x64 (kvm): 13638 (SM2.0 5175, SM3.0 5901, CPU 5030)

Windows 8.1x64 (native): 14143 (SM2.0 5170, SM3.0 6094, CPU 5802), výhoda native v CPU cca 15%.

Wprime 1.55 (vícevláknový CPU benchmark)

Windows 7x64 (kvm): 35,428s

Windows 8.1x64 (native): 34,594s , výhoda native cca 2%

SuperPi (jednovláknový CPU benchmark)

Windows 7x64 (kvm): 11,637s

Windows 8.1x64 (native): 11,580s , výhoda native cca 0,5%

Pozn. Pro relevatní testování by to chtělo silnější GPU, aby se mohly projevit případné rozdíly celkového výkonu. Použitelnost virtuální GameMachine je samozřejmě odvislá na mnoha dalších aspektech (zvuk,latence,..), na druhou stranu dnešní moderní HW by mohl jít svým výkonem/průchodností požadavkům naproti. Uvidíme zda X99/H-E splní v tomto naději či nikoli.

[Lazar]

Abych eliminoval vliv slabšího GPU otestoval jsem obě prostředí v 3D Mark 2001. Ten vzhledem ke své grafické nenáročnosti dosahuje v některých testech až 1000+ FPS. Rozdíl mezi nativními W8.1x64 a virtualizovanými W7x64 byl v některých případech (Game 2 - Dragothic - High Detail) až 120%, celkově dle score 44173/33800 cca 30%). Težko říct, nakolik jde o vliv nativnosti/virtualizace, či odlišností W7x64 a W8.1x64 pro DirectX8. Asi pro klid duše nainstaluji nativně i W7x64.

[Lazar]

Výsledky nativních W8.1x64 a W7x64 prakticky shodné. Po optimalizaci rozdíl 3DMark 2001 native_W7x64 versus kvm_W7x64 v celkovém skóre cca 20%(44700:36700).

[R]

Uz "len" najst dosku, na ktorej to funguje... Na desktopovych to nejde takmer nikde. Funguje to prakticky len na znackovych firemnych desktopoch (Dell a pod.) a potom na serveroch.

[heh]

KVM VGA-Passthrough using the new vfio-vga support in kernel =>3.9

+ přidružený seznam HW

[mca]

Nejprve se rozhodni, co vlastne chces. Pro zakladni cinnost staci VBox a nemusis hned porizovat asi nejlepsi reseni od VMWare Workstation. Avsak uplne kazda virtualizace bude mit ztraty a rezii, tomu se nevyhnes. Potom uz zalezi jen na hardware, ktere nesmi byt dokryplene a ocesane na samou kost (i bez virtualizace), proto popis vykonne hardware neznamena nic, kdyz si stupidni sitovka vyzere nechutnou cast CPU jen proto, ze nekdo u vyroby usetril par centu. Obecne vetsina virtualizace na Intel s1150/1155 mimo C200 chipsety byva peklo. Na uceni se tucnaka to staci, ale tim to konci.

[heh]

Intel s1150/1155 vcetne C200 chipsetu je pro pokrocilou virtualizaci naprosto nevhodny, kvuli absenci kvalitni podpory I/O passthrough pro VM.

[lertimir]

šlo by to trochu rozvést? Sice většinu virtuálních strojů provozuji na Xeonech a pár na i7 2011, ale postřehy a názory, jaké HW nedostatky dokriplí virtualizaci, zjistím rád.

[heh]

Závisí to na podpoře ACS (Access Control Services), ktera chybi u vsech chipsetu typu Intel PCH vcetne tech serverovych.

[PATCH] pci: Enable overrides for missing ACS capabilities

Quirk Intel PCH root ports for ACS-like features

PCI Passthrough with PCIe devices behind a non-ACS switch in vSphere

PCI Passthrough (Direct-IO or SR-IOV) with PCIe devices behind a non-ACS switch in vSphere

[heh]

Z dokumentace ke Xeonu E3:

It is recommended to avoid device direct assignment to Virtual Machines in virtualized environments with this processor due to the lack of Access Control Services (ACS) support in PCI-Express root ports. Some Operating Systems may check for ACS support and potentially disable direct device assignment (that is, affects SR-IOV setup/ configuration within the server) as well.

Z dokumentace k Intel C600 series chipsets:

Access Control Services (ACS)/Alternative Routing ID (ARI) are not supported on the PCI Express* Root Port of the Intel® C600 series chipset, devices connected to these ports may not support direct assignment or Single Root I/O Virtualization (SR-IOV).

[Jendа]

No tak si řekni, co děláš. Já třeba ve Windows provozuju jenom dvě aplikace jednou za čas, tak je jasné, že mám jako primární systém Linux a v něm virtualizuju Windows.

[petrfm]

Jak ten win v lin beha? Mam stare C2D - lenovo T400 a na nem W7. Chtel jsem delat dualboot, ale prijde mi, ze ve WIN pouzivam taky dohromady dve,tri aplikace a ze by mi stacil ve virtualce. ALE - kdyz na tom lenovu ve W7 virtualizuju UBUNTU, skoro vubec to nejede - ma to spatny vykon grafiky.

Proto by mne zajimalo, jak chodi takovy W7 naopak, pod linuxem? Da se na tom i na tom C2D pracovat trochu svizne, nebo je lepsi na takovem stroji pouzit dualboot?

 

P.

[Jendа]

Osobně provozuji ještě XP. Win7 a 8 jsou pomalejší a na práci bych to nechtěl.

[vlado]

V práci potrebujem občas aj widle, takže používam Gentoo-amd64, VirtualBox a w7 na core2-duo E6300 + 6GB RAM. Veľmi záleží na tom, či máš v BIOS-e zapnuté povolenie virtualizácie. S hardwareovou virtualizáciou idú aj widle svižne, keď som ju nemal zapnutú, nedal sa takmer používať.

[MadCatX]

Záleží na tom, čím to virtualizujete. Virtualiovat zrovna čisté Ubuntu není právě vhodné, protože Unity vyžaduje 3D akceleraci. Pokud není k dispozici HW akceletátor, renderuje se všechno sotfwarově přes llvmpipe, což je samozřejmě fest líné. Stačí buď použít virtualizační software s podporou 3D akcelerace nebo v Linuxu použít jiné pracovní prostředí, které se bez 3D akcelerace obejde.

Virtualizovaná Windows taky nejsou žádný zázrak, největší problém je nejspíš v nedostatku RAM. Kdyby se virtuálnímu stroji přiřadily aspoň 3 GiB, nejspíš by to dost pomohlo. Provozuji W7 na virtuálce s 1,5 GiB a většinu času je to utrpení. Visual Studio 2012 je téměř nepoužitelné, QtCreator jakž takž. Hodně dobrou zkušenost mám s virtualizací Linuxu s nějakým primitivním DE na Linuxu. To běhá naprosto v pohodě.

[petrfm]

Diky za info, ale chybi mi podstatny udaj, NA CEM to virtualizujes? Kdyz uz se bavime, ze je to fest line, chtelo by to aspon zakladni udaje o stroji, na kterem je to line. Ja trena na W7 tedka ve virtualboxu a tom C2D virtualizuju XP a da se s tim v pohode delat. Na hrani her to nebude, ale nepozoruju vyrazne zpomaleni.

[MadCatX]

Prastaré T9550 2,66 GHz, 4 GiB RAM, Arch Linux, VirtualBox 4.3. Výkon CPU podle mně až takovou roli nehraje, rozdíl oproti provozu na železe bude pár procent; Phoronix.com to před nějakou dobou benchmarkoval. Daleko větší problém při virtualizaci desktopového systému vidím v RAM. Když si hostitelský systém sám zbaští 2 GiB, moc toho pro virtuálky nezůstane a zejména na Widlích je to dost znát. Třeba Linux s Fluxboxem ale běhá perfektně, pokud tedy člověk nechce 3D akceleraci, která je ve VBoxu od verze ~4.2 rozbitá.

[Jendа]

XP jednou celkem použitelně i na 8 let starém Sempronu 2800+, Win7 nejsou nic moc ani na i3-2350M.

[R]

Pri Windows ide hlavne o velkost RAM a rychlost disku. Takze na tom Semprone by to mohlo ist lepsie ako na i3, keby mal rychle SSD a i3 nejaky pomaly disk (5400RPM).

[MilanK]

Záleží na tom, které app potřebují přímý přístup k hw. Ve virtualizovaném prostředí býval problém s periferiemi přes USB. Další typický kandidát je grafická kata: provozovat grafické app ve virtuální mašině je dost k ničemu (DxO, tipuji Photoshop a RAW konvertory).

[Filip Jirsák]

Co by RAW konvertory počítaly na grafické kartě? A Photoshop taky asi nemá moc příležitostí ji využít.

[lertimir]

Windowsí foto programy mladší cca 8 let počítají na grafické kartě skoro všechno. Osobní zkušenost mám u kamaráda, který vyměnil asi před 3 lety grafárnu z nějaké hodně staré za střední třídu AMD, a nesmírně (cca 5-10x) se v ACDSee zrychlilo skoro všechno, načítání obrázků na next/previous, úpravy vyvážení bílé, doostření, změny epozice podle přechodové křivky, vše se začalo provádět mnohem rychleji. Snad až na načítání RAWů. Ostatně to jsou přesně operace na kterou je ta paralelizace grafické karty jak dělaná. Vezme bod, případně jeho okolí a přepočte ho podle poměrně jednoduchého vzorce. Protože ji měl běžně podtaktovanou kvůli spotřebě tak říkal, že dávkové zpracování fotek je jedna z mála věci, které ji zahřeje.

[Filip Jirsák]

To musela být super grafická karta, když zrychlila načítání souborů z disku...

[lertimir]

Pokud narážíš na operaci next/previous, tak vzhledem k tomu, že posloupnost je definovaná nastavením, ACDSee má v posloupnosti několik fotek načteno dopředu i dozadu a operaci s diskem s načtením dalších dělá ve chvíli, kdy se uživatel na fotku dívá. Také načtení nenafragmetované fotky do paměti je tak 1/10 sec (dvakrát 10 ms na seek, a 0.08 sec na vlastní sekvenční čtení sektorů, předpokládám cca 80MB/s sekvenční rychlost a fotky do 5MB) a disk byl udržován nefragmentovaný, zbytek je práce v paměti.

Mimochodem to, že linuxové foto programy nemají přednačtené fotky v poslopnosti next/previous a čtou z disku až když fakticky zmáčknu next, považuji za nebetyčnou chybu.

[Filip Jirsák]

I kdyby pak vlastní zobrazení fotky znamenalo přesun z RAM do VRAM, nemůže to trvat déle, než načtení z disku. Nebo vy máte nějaké vysvětlení, jak by lepší grafická karta mohla zrychlit prohlížení fotek? („Paralelní zpracování“ není vysvětlení, jde o to, co a jak se paralelně zpracovává.)

[lertimir]

Většina photo editorů vezme jpeg, rozbalí ho do nekompresovaného tvaru, obvykle 32bitů na pixel v 8 bitové škále nebo 64bitů na pixel pro 16 bitovou škálu. a většinou preferují zaříznutí po 32/64 bitech pro nativní práci procesoru na pixelech bez nutnosti posunu o několik bytů. ta ztráta paměti jim za to stojí. tím se 10 Mpix fotka zabere 40/80MB a potom se přeškáluje na konkrétní výřez a pixely monitoru. Všechny tyhle operace grafická karta urychluje. Ještě brutálnější jsou operace z RAW. ACDSee navíc bere práci s kartou do vlastních rukou a strká do karty na jednotlivé video stránky fotky pro next/previous takže následná fotka je okamžitá protože jen přepne stránku. Je to brutálně vidět, když se stránkuje rychle, první jedna až dvě jsou okamžité, různé video stránky, následující asi 4 o trochu pomalejší fotky v RAM ale nezpracované pro výřez, a následující ještě pomalejší, už je nemá ani v paměti a dotahuje je z disku. Ale na rozumnou demostraci to chce přepínat tak 2 a více fotek za vteřinu, jinak stíhá doplňovat buffer. Tohle práve linuxové editory nemají, zmáčknu next a čekám. A pokud při zpracování fotek z jednoho focení zmáčknu next, tak 3000 krát a každý přesun trvá 2 vteřiny a ne 0.1 tak to jsou skoro dvě hodiny času jen čekání.

[Josef Kufner]

Když máš panorama poskládané z takových 10Mpx fotek, tak už je takové dekomprimování do paměti docela problém.

[Jendа]

Všechny tyhle operace grafická karta urychluje.

Počkej, jako že se grafice pošle JPEG a rozbalí se přes OpenCL? Nějak si nedokážu představit rozbalování JPEGu napsané v OpenCL.

[lertimir]

Nevím jak to lidi v ACDSee skutečně dělají. Jen jsem popisoval reálné pozorování. (a trochu spekuloval, jak by to pozorování mohlo být rozumně vysvětlitelné.)

[Filip Jirsák]

Všechny tyhle operace grafická karta urychluje.

„Všechny tyhle operace“ jsou konkrétně tyto tři (podle vašeho textu):

• načte z disku JPEG
• dekomprimuje JPEG
• přeškáluje se

Třetí operace jde udělat na GPU. První určitě ne. O druhé pochybuji.

Ještě brutálnější jsou operace z RAW.

Stejné tři kroky, dekomprese RAWu na grafické kartě je ještě daleko nepravděpodobnější, než u JPEGu.

strká do karty na jednotlivé video stránky fotky pro next/previous takže následná fotka je okamžitá protože jen přepne stránku. Je to brutálně vidět, když se stránkuje rychle

Zatímco když není dalčí obraz připraven ve videopaměti, ale vykresluje se tam nebo se do ní přesouvá z hlavní paměti, tak na překreslení čekáte? Takže třeba když pohnete kurzorem myši nebo dokonce přetahujete celé okno, nedejbože přehráváte video, tak vidíte, jak se obrazovka pomalu překresluje? Tomu bych věřil u dvacet let starého počítače…

následující asi 4 o trochu pomalejší fotky v RAM ale nezpracované pro výřez

Když si takhle pustíte video, je to 25 snímků za sekundu. Osobní počítače to už hezkých pár let zvládají. Buď ty následující fotky prohlížíte větším tempem než 25 snímků za sekundu, nebo máte fotky v nějakém obrovském rozlišení, nebo je to zpomalení způsobené něčím jiným, než si myslíte. Ona ta RAM zas tak pomalá není.

[Jendа]

Co přednačtené, to ještě podrží cache filesystému. Ale rozbalené. Ono takové dekódování 3MB 10MPx JPEGu a následné škálování na rozlišení obrazovky taky chvíli trvá.

[lertimir]

(a to dělá ta grafická karta) Právě to je v linuxu problém to, že bych mohl digikamu říci někde v konfiguraci: "Vezmi si 4GB (nebo 16GB) mé operační paměti a tam si načti a rozbal fotky dopředu a dozadu alespoň 3, ve přeškálování a v 1:1 pohledu kolem daného bodu." To nijak říci nejde. Na mých 8GB se schovává v nějakých 800-1000MB a nejde na víc i když je to jediná běžící aplikace (kromě konsole a dolphinu, kteří berou minimum), když by se do dalo nastavit, tak klidně koupím třeba dalších 16G, za rychlostní zisk by mě to stálo.

[Filip Jirsák]

Pro předchozí/další se snad do dekódování a škálování dělá po načtení z disku, ne? A co na tom podle vás ta grafická karta dělá? Dekódování JPEG asi těžko, takže zbývá možná to škálování.

[lertimir]

No to nevím, jednak je to closed source kod a asi bych to nestudoval i když by byl otevřený. Ale pozorování dává jednoznačné výsledky, výkonnější grafická karta, (Geforce 6000 řada původně, pak Geforce GTX 500 řada - nějaká střední třída cca za 4k v době prodeje) jinak celý počítač stejný, zrychlení odhad tak 3-5 na next pro ACDSee. Obrovské cca 8x zrychlení pro editace. Co tam fakticky dělá a kdy jí to pomůže nevím

[Heron]

Nevím jak ACDSee, ale Adobe toho na GK dělá poměrně dost.

http://helpx.adobe.com/photoshop/kb/photoshop-cs6-gpu-faq.html

[Heron]

Tak tak. Je smutné, že určitou akceleraci uměl už i dosový ACDSeee (určitě readahead a přípravu obrázků do jednotlivých videostránek), zatímco dneska rozumný prohlížeč pro linuxové distribuce snad ani neexistuje.

Přednačítání funguje (pokud někde vůbec funguje) jen pro jeden snímek dopředu (ale už nikoliv dozadu, takže se opět musí dekódovat do bitmapy) a procházení galerií je utrpení.

(Pokud je něco jinak, tak si nechám poradit ten správný soft. Před lety jsem to řešil tak, že jsem instaloval Google Picasa (což běží ve Wine), jenže to Google ukončil.)

[nobody]

zkus Gwenview...

[lertimir]

pro mne gwenview 0.5 - 0.7 sekundy pro obrázky z SSD což pro 5000 přechodů je zase hodina zbytečného čekání. Navíc to přecházení má za cíl vybrat fotky které si nechám a které vyhodím, těch co vyhodím bude 5-10x tolik, než ty co si nechám. a z hlediska práce s fotky je tento výběr ta nejvíc otravná část.

[nobody]

no tak me z SSD gvenview zobrazi cca 5 fotek / sekundu kdyz mackam space jak pako a jeste stiham sledovat fota :)

[JanM]

Spousty věcí:

darktable-opencl-na-nvidia-gtx-750-ti/. A to ta karta není high-end.

Zrychlení je příjemné už při práci s editorem, rychlejší export desítek fotek také není k zahození.

Kdysi jsem zkoušel DxO ve Virtualboxu (hostitel: linux, host: Win XP) a bez akcelerace GPU to bylo nepoužitelné. Doslova.

[Lazar]

To,že se debata částečně zvrhne v mírný OT (akcelerace výpočtů pomocí GPU) se u tohoto okrajového dotazu dá vcelku očekávat. To, že se zakladatel nepodílí (dle uvedených autorů příspěvků) ani na něm mne stejně dovede překvapit.

[keygej]

Zdravim, vicemene sleduji diskuzi, ktera jak pisete smeruje k GPU. Nektere casti jsou jiz tak odborne ze se nemohu podilet na diskuzi a dale se vsim souhlasim. Asi se hodi podekovat vsem zucastnenym za rady a postrehy. DIKY

[Lazar]

OK. V horní části debata OT není. Jen je škoda že jsme se nedozvěděli detalní specifikaci "silného PC" (MB,CPU,RAM,GPU). Nemůžeme tak posoudit ani teoreticky variantu Linux(nativně), Windows(virtualně kvm+IOMMU/VT-d).