Várjál, azt hiszem összekevertem a dolgokat. Én csak az IO ütemezők hatását néztem meg, ezt a kettőt amit mondasz, ezeket nem.

Flash alapúakon a noop helyett mikor volt jobb a deadline? Szerintem ott a noop, ami beérkező sorrendben írja és olvassa az adatokat, teljesen jó. SSD-n is ezt érdemes használni. szerintem

(#38) CPT.Pirk

hibahatáron belüli Az mennyi?

BFQ-v7r6 versus CFQ, DEADLINE and NOOP on an SSD

Demo of the performance of the bfq disk I/O scheduler on a hard disk

Milyen meghajtón csináltad a tesztet és melyik 6 ütemezővel?

Ez a BFQ amúgy nem rossz és 4.12 óta már tartalmazza a kernel, nem kell patchelni.

[ Szerkesztve ]

Ha arra gondolsz amire én is, akkor én is összekevertem a CPU és az IO schedulert régebben. Megesik. Akkor a másik felhasználónak szólt a válaszom. A CPU schedulernek nem biztos hogy mindig lehet érzékelni a hatását, de nagy eséllyel ugyanazt vagy rosszabb teljesítményt nyújt benchmarkban. Nem biztos hogy kimutatható, mert sok más dolog valszeg kompenzált érte a ck-ban.

Minap én is GPU passthrough-val szenvedtem, de nem tudtam megoldani, pedig lehetséges egy videókártyával is, csak akkor nincs kép, míg a host rendszer tölt be. Végül szégyen szemre natív Win10-et tettem fel egy külső SSD-re, azokhoz a játékokhoz, amelyek nem, vagy nem jól futnak Wine-ből, pedig már vagy 4-5 éve nem windowsosok, nincs is fent Windows a gépeimen, vagyis volt egy rövid ideig egy játszós laptopom, de az meg beadta a kulcsot. Pedig eredetileg Qemu KVM-es virtualizáltat akartam, hiába támogatja a gép a VT-x mellett a VT-d-t is, hiába tudtam neki minden más hardvert átadni, csak nem ment a GPU passthrough, noha még azt az árat is megfizettem volna, hogy nincs kép azután sem, hogy kilépek a virtuális gépből. Amúgy ahogy néztem, a hardveres virtualizáció lényegében natív teljesítménnyel fut, alig van overheadje, örültem volna, ha natív GPU-s megoldással tudtam volna tolni. Nem akartam partíciókból lecsípni, meg dualboottal gányolni, csak azért, hogy néha régebbi windowsos játékokkal is toljam.

Igaz én elég régi Intel IGP-n próbáltam HD3000, ami az i7-2620M-be van integrálva.

Az ilyen ütemezőkkel varázslásokban nem hiszek, ha hoz is némi teljesítménynövekedést, az közel van a mérési hibahatárhoz. Nem ez fog számítani, ha sok hiányzik ahhoz, hogy a játék normálisan fusson. Ha meg eleve normálisan fut, akkor meg azért nem kell vele trükközni. Ezt a CSMT és NINE párost ki fogom próbálni Wine-n.

[ Szerkesztve ]

GPU-nak és az alaplapnak/chipsetnek is kell támogatnia a passthrough-t. i5-2400k-m van, az alaplap meg túl régi hogy ilyen technológia legyen benne. Nem néztél valamit félre?

Szép munka, de a saját dolgodat is megkönnyítetted volna, ha szerepelteted a tengelyeken, hogy mit tartalmaznak, vagy legalább a mértékegységeket. Esetleg egy sima "FPS - t; Live For Speed" szöveget hozzá lehetett volna adni a diagramok címeihez. Így hiába van odaírva az első oldalra, hogy mit mértél minek a függvényében, ha valaki esetleg linkeli máshova az eredményeidet kép formában, ott nem fogják tudni kitalálni, hogy ezek valami százalékos értékek, lag, memóriakihasználtság, hőmérséklet vagy esetleg az egy földrajzi területre jellemző napi átlagos csapadékmennyiség.

Számszerűen már nem tudom de annyira kis eltérések voltak, hogy töröltem a cikket róla, mert nem volt értelme.

Nem néztem félre, biztosan támogatja a VT-d-t. Szerintem csak én voltam balfax, hogy nem tudtam a futó host OS-től elvenni, utána ment volna. Meg próbáltam egy USB-s háttértárat is átadni, az átadódott, de a Windows 10 nem teljesen ismerte fel, nem tudta hozzá a rendes beépített drivert telepíteni, pedig olyan eszközről van szó, amit alapból kezel.

De így utólag nem bánom, hogy natívan tettem fel, mivel 1080p-s netflixezésre is jó a Win10. Linux alatt az összes natív megoldás a Mozilla-féle Widevine DRM-plugint használja, az meg csak max. 720p-re van korlátozva, mindegy, hogy Firefox, Chrome, vagy Kodi 18 alatt használja valaki.

Lehet neked meglepő, de igenis foglalkoznak még a régiekkel is, kis teljesítmény-javítások időnként érkeznek hozzájuk is (r600g).

Ez alapból is támogatja, Intel6/C200-as chipsetnek írja (ThinkPad X220), az UEFI BIOS-ban is lehet kapcsolgatni ki-be, természetesen be van kapcsolva.

Ettől régebbi, C2D-s chipsetek is tudták. A VT-d elég régóta jelen van.

(#37) taiji: a noop, deadline, cfq, bfq stb IO ütemező.

(#38) CPT.Pirk: angol nyelvűből van egy elég jó, ha valaki nem beszélné a nyelvet a Google is segít. Ilyen szempontból nem jó a duplikátum, senki sem tartja karban reddit

(#42) ubyegon2: tartalmazza a kernel, de célszerű kicsit állítgatni, mert az első mainline implementációk a blk-mq értéket rosszul kezelték.

(#49) lev258: időként látom én is a commit-okat, de már messze nem kap olyan figyelmet mint a GCN alapú kártyák szoftveres részei.

DX9-es játékok már kb. natív teljesítménnyel futnak Wine alatt, elég sok windows-os játékomat elég volt csak telepíteni, és megy hiba nélkül.
3-5 éve, amikor elkezdtem linuxot használni, még közel sem volt ilyen jó a helyzet.

Natív (vagy linuxon is támogatott) játékból is egyre több van, hála a Steamnek és a GoG-nak.
A teljesítmény is egyre közelebb van a Windows-oshoz, az AMD már csak kis lemaradásban van főleg mulltiplatform címeknél, az NV-nél meg kb. ugyanaz a teljesítmény.

Szerintem egyébként open source játékokkal nem egészen fair tesztelni, mert az ismertebb címekkel szemben sokkal közelebb szokott lenni a teljesítmény a két rendszer között.
Ettől függetlenül egy nagyon jól megírt cikk, köszönjük!

(#7) ubyegon2
Hova kéne fgeltámadnia a linuxnak?
Él és virul, köszöni szépen.

[ Szerkesztve ]

Ilyesmire gondoltál? Nekem ez a szint már magas, de már amúgy is túl vagyunk a 4.12-n, persze bevallom, ki se próbáltam még. Amennyire értem az írást, nekem az jön le, hogy az SSD_t nem érinti ez a gond.

(#54) pengwin

Te vagy a második, aki ezt írja, de én egy szóval se említettem, hogy fel kéne neki támadni, ha kontexusba helyeznétek azzal a hsz-szal, amire válaszoltam..... az első kifogásolásra azért nem reagáltam, mert egyrészt nem írtam ilyet, másrészt a desktop Linuxokról volt/van szó. Annyit én is tudok, hogy milyen eszközökön fut Linux kernel alapú rendszer. Persze, van Linuxos telefon is, ha még van.....de mindegy, ezekkel tisztában vagyok valamelyest.

Él és virul, köszöni szépen.

Amúgy kösz, hogy szólsz, fel sem tűnt az utóbbi 5 évben.

[ Szerkesztve ]

Nem gőzöl be senki, azonban maradjunk a tényeknél!
Kezdjük azzal, hogy a platformválasztás -amennyiben játékról van szó-, nem úgy működik, hogy az OS határozza meg, mivel játszhatok. Linuxon ugyanis ez a helyzet. Előszeretetttel ferdítenek ezzel sajnos, mert bár valóban vannak játszható játékok linuxra, tehát az az állítás nem igaz, hogy linuxon nem lehet játszani, mert lehet. Csak baromira behatárol a rendszer, mert bár a natív portok jól futnak természetesen, csak azokból marha kevés van. A Wine pedig eleve egy kompatibilitási listával indít, mert nem mindent képes futtatni. Ezt általában élből elfelejtik hozzátenni. De ami fut, az sem feltétlen stabilan, ez saját tapasztalat.

Vagyis Linuxon a játék úgy néz ki, hogy felteszed az OS-t és azzal játszhatsz ami van, ami éppen elfut Wine alól is, vagy a listájában szerepel. Nem pedig fordítva! Márpedig a user nem azzal akar játszani, ami véletlenül éppen fut linuxon is, hanem azzal amit szeret és ami Windows-on biztosan el fog indulni (most nyilván a bugok miatti problémákat ne keverjük ide)!
Azzal sajnos nem sokra megy a játékos, ha ő mittudomén a Subnautica-val akar játszani, de linoxon az nem fut, cserébe kap egy listát, hogy válassz ebből barátom.

Fizikailag tehát lehet játszani Linuxon, de fentiek miatt távolról sem alternatíva a Windows-al szemben, ferdíthet a kérdésben bárki, bármit!

[ Szerkesztve ]

Ebben igazad adok neked. Aki gamer, mindennel akar játszani, annak még nem opció a Linux. Azért dobtam fel én is egy Windowst a külső SSD-mre (kb. 8 másodperc alatt átbootolok rá, visszafelé meg olyan 6 másodperc a boot a fő rendszeremre, az Arch Linuxra). Viszont nem játszol, vagy olyan játékkal, ami ott van a támogatott natív vagy Wine-s listákban, akkor Linuxon is szépen el lehet játszogatni. Egyébként meg marad a Windows futtatása hardveres virtuálizációval (a fizikai GPU passthrough-hoz viszont két GPU kel), dualboottal vagy külön lemezre téve.

(#54) pengwin:
Milyen open-source játékra gondoltál? A LFS closed source, néhány lelkes brit fejlesztő munkája.

(#55) ubyegon2: nem, a korai beállításoknál hibás volt az alapértelmezett érték a kernel konfignál. A fejlesztő talált egyéb hibákat is, ezekről itt olvashatsz többet:
Linux 4.12 I/O Scheduler Benchmarks: BFQ, Kyber, Etc ; Linux 4.12 I/O Scheduler Tests With A HDD & SSD.

[ Szerkesztve ]

Így már értem, elnézést.

Amúgy nem merült fel, hogy csináljatok egy Linux GAMING topicot a Linux abszolút kezdőknek topic mellé? Nem lenne rossz egy külön gyűjtő az ilyen témájú problémáknak.

Ez a phoronixos tesztes cikk is megerősíti, hogy össze-vissza szórnak ezek az I/O schedulerek, egyik programban az egyik, másikban a másik ad jobb eredményt. HDD-nél nincs is nagy különbség, SSD-nél is sokszor elég közel vannak. Nem látom értelmét ezzel bohóckodni, persze ingyen van megpróbálni, de sok munkát nem tennék bele ilyenbe, pedig SSD-m van. A default schedulerrel sem volt soha problémám, nem lassú a gép vagy ilyesmi. Ennek is kb. annyi értelme van, mint a low latency kerneleknek.