Processzor és alaplaptesztelés hardverlaborunkban

Bevezetés a tesztelésbe

A PROHARDVER! hasábjain rendszeresen jelennek meg alaplap- és processzortesztek. Ezekhez megfelelő mérési alapokat kell biztosítani, ami sokszor nem könnyű feladat, és a programok kiválogatása mellett arra már nem feltétlenül marad idő, hogy a mérések pontos metodikáját is felvázoljuk. Pedig érdekes témáról van szó, ezért úgy gondoltuk, hogy kisebb kulisszatitkokat érdemes megosztanunk az olvasóinkkal, erre igény is mutatkozott fórumaink alapján.

[+]

Az első bekezdésben említett két komponens mérése nagyon hasonló módon történik: alaplapoknál ugyanazzal a processzorral vizsgálunk több lapot, míg processzorteszteknél az azonos platformot jelentő tesztalanyokat ugyanabban az alaplapban mérjük le, ugyanazokkal a programokkal.

Teljes részletességgel nem mutatjuk be a folyamatot, bár az igazi ínyencek bizonyára szívesen olvasnának arról, hogy mi minden előzi meg egy teszt létrejöttét. Kiindulási pontként felvázoljuk a teszttermékek kiválasztásának alapszempontjait:

• A nagyobb gyártóktól lehetőség szerint közel azonos számú résztvevőt vonultatunk fel.
• Nem eresztünk össze nagyon eltérő kategóriájú termékeket, elkerülve azt, hogy bármelyik oldal felé "húzzon" maga a teszt.
• Árkategóriában a lehetőségek szerint homogén felhozatallal választjuk ki a résztvevőket.

Sajnos sok esetben a tesztelhető termékek csak korlátozott ideig állnak rendelkezésünkre, így elég komoly ütemezés húzódik meg a háttérben, tehát nem érdemes úgy elképzelni a tesztlabort és a környező helyiségeket, hogy az ENIAC óta készített valamennyi számítógép-alkatrész itt van a kezünk ügyében.

Dióhéjban a tesztlépések

Vezérfonalként a 2017-ben készült tematikus vizsgálataink szerkezetét fogjuk felhasználni, de a részletek előtt még essen szó nagy vonalakban magáról a tesztelés folyamatáról, lépésekre bontva a tevékenységeket:

1. Hardverelemek előkészítése, lehetőleg úgy, hogy több szereplő esetén könnyen át lehessen állni egyik konfigurációról a másikra a mérések minél gyorsabban lebonyolítása érdekében.
2. Az aktuális tesztrendszer összeállítása, ha kell, frissítések elvégzése, illetve bizonyos beállítások alkalmazása, így például az operációs rendszer energiagazdálkodását teljesítménycentrikusra kell állítani, de vannak tesztek, ahol ez kivétel, és ezt jelezni is fogjuk.
3. Elsőként a Cinebench R15-öt, illetve a Prime95-öt futtatjuk, ezzel ellenőrizve a pasztázás, illetve adott esetben a túlhajtással kapcsolatos beállítások eredményességét.
4. Lebonyolítjuk a többi vizsgálatot is. A sorrendiség fő vonulata, hogy az egymásra épülő teszteket egy batchben hajtjuk végre. Ezzel egyrészt biztosítjuk a tesztalany skálázódásának kimutathatóságát, másrészt a SPECWPC csomag tesztjeit annak keretprogramja futtatja le egymás után.
5. Mérési adatok kigyűjtése, felvitele a felhasznált táblázatainkba.
6. Diagramok előkészítése, azzal a céllal, hogy a teszteredmények ellenőrzése megtörténjen. Ha valahol látszólag gond van, akkor a kérdéses tesztet természetesen ismételni kell.
7. A következő lépcső a fotózás, az elkészített képek szerkesztése.
8. Ezen a ponton, a teszt tapasztalataira építve megírhatóvá válik a cikk, amely némi utólagos ellenőrzés után már publikálható is, hacsak nem szükséges valamilyen embargó betartása.
9. A teszt utáni teendők közé sorolható a fórumozók visszajelzéseinek nyomon követése, és az építő jellegű kritikák feldolgozása, ezen belül is a tesztelési metodika szüntelen felülvizsgálata a visszajelzésekre, illetve az adott teszt tapasztalataira építve.

Mivel jelen cikkünkben mindenképp a tesztelésre és a mérési adatok előállítására fókuszálnánk, az előző listánkból a harmadik lépéstől az ötödikig járjuk körbe a témát, illetve némi magyarázathoz egy nagyon picit a hatodik lépésből is igénybe veszünk elemeket.

A teszteredmények előállításának módjai

A teszteredményekre vetítve háromfajta vizsgálat létezik, az elsőben direktben olvashatjuk ki az eredményeket, a második típusnál állományokban kell bolyonganunk, de meghatározott helyen meglelhetők a keresett értékek, a harmadik kategóriában pedig konverzió segítségével, általában több ezer mérési adat feldolgozását jellemezzük mérőszámokkal.

Hirdetés

Játékoknál újabb szempontokat is meg kell említenünk, melyek közül az egyik magától értetődő: ha van beépített benchmark modul futtatására lehetőség, akkor azt érdemes alkalmazni. Azonban ne feledjük el, hogy ebben a kategóriában az egyik mérőszámunk a minimum fps, amelyet nem minden benchmark jelez konkrétan vissza, ekkor a keletkezett fájlokban kell kutatni az eredmények után. Ennél a pontnál kanyarodik vissza a már említett háromfajta vizsgálathoz a történet, így az előbbi bekezdés itt is igaz.

Sajnos vannak azok a játékok, amelyekben nincs benchmark. Ilyenkor az OCAT, illetve a PresentMon segítségével nyerünk mérési eredményeket. A két program igazából nagyon hasonló, sőt mára alig van különbség közöttük, ugyanis mindkettő nyílt forráskódú, és fejlesztéseiket is összehangolták. Az OCAT előnye a grafikus kezelőfelület, míg a PresentMon valamivel gyorsabban fejlődik. A választás attól függ, hogy az adott konfiguráció, illetve alkalmazás melyik mérőprogrammal mutat jobb kompatibilitást.

Mérőprogramjaink I.

Mint említettük, tesztsorozatunkat a Cinebench R15 programmal kezdjük, a CPU-k vizsgálatánál egy 2000 tárgyat felvonultató, fotórealisztikus jelenet elkészítését hajtjuk végre. Az egyik vizsgálatnál a CPU teljes erejét igénybe vesszük, míg a másiknál egy maggal végzi el a program a feladatot. Ezen felül processzorunk pasztázásának sikerét, illetve a tuningbeállítás stabilitását tudjuk még ellenőrizni. Ha minden jól alakult, akkor a program felületéről lejegyezhetők az eredmények.

[+]

Ezután a Prime 95 Small FFT tesztje jön, ami tisztességes terhelésnek teszi ki a processzort, a teljes rendszer fogyasztását pedig a Voltcraft Energy Logger 4000 kijelzőjéről olvassuk le. Ennél a mérésnél a legtöbbször felbukkanó teljesítményértéket jegyezzük fel.

A Prime 95 beállítása és főablaka futás közben [+]

Ezzel megkezdtük a fogyasztásmérési vizsgálatsort, amelyet az AIDA64 stabilitástesztje követ, ugyanis a nagy terhelés biztosítása a cél, legyen szó CPU- vagy alaplaptesztről. Ebben a programban a StressCPU-FPU-Cache-System memory beállításokkal indítjuk el a tesztet.

AIDA64 stabilitásteszt [+]

Ezek után a Windows energiagazdálkodását kapcsoljuk át "teljesítménycentrikusról" "energiatakarékos" sémára, előkészítve a Windows asztal futása alkalmával mérendő teljesítményt, illetve DXVA tesztnél egy pár perces részletet indítunk el az MPC-HC x64 videólejátszóval.

Energiasémák közötti váltás; a képen az energiatakarékos sémát állítottuk be a Windows 10-ben [+]

Mivel ezen a módon teljesen feltérképeztük aktuális rendszerünk teljesítményviszonyait, visszatérhetünk a teljesítménycentrikus energiasémára, és folytatjuk tesztjeink sorát.

Mérőprogramjaink II.

VeraCrypt, HWBot x265

Felhasználói programcsomagunk következő szereplője a meghajtók titkosítását végző VeraCrypt. Itt a Tools/Benchmark menüponttal nyíló ablakban a hash algoritmus tesztet választjuk ki, és többek között SHA-2 algoritmuscsaláddal is teszteljük az aktuális processzorunkat, a pufferméretet mindenképp a maximális 1 GB-ra állítjuk be. Az eredmények közül, az SHA-256 és az SHA-512 mezők értékeit jegyezzük fel.

A vizsgálódás a HWBOT x265 tesztprogramjával folytatódik, amely x265/HEVC kódolással készít videókat. Ezt mind 1080p-s, mind 4K-s beállítással lefuttatjuk tesztrendszereinken, és feljegyezzük az eredményeket.

A HPET nem aktív a HWBOT szerint [+]

[+]

SPECwpc 2.1

Eljutottunk a SPECwpc 2.1 tesztkörnyezethez, amelyből a futtatott programok száma a 2017-es évben jelentősen lecsökkent. A 7Zip, a Blender és a Handbrake állta ki az idő próbáját, a többiek kedvéért teszünk most egy kis kitérőt.

Elsőnek a Luxrendert ejtettük el, aminek problémája jól tetten érhető a Ryzen 5-7 processzorokat vizsgáló tesztünkben, azaz két jellemző érték köré rendeződnek a mindenkori versenyzőink: 4 maggal és alatta 182 másodperc környéki eredményekkel teljesítettek a processzorok, efelett pedig 92 másodperc tájékán végeztek a számításokkal – nem igazán reprezentatív eredmények.

A következő gondok az Autodesk Maya képességeit vizsgáló résznél adódtak, ahol egyértelmű jelek mutatkoztak notebooktesztjeinknél arra, hogy a GPU erejét is igénybe veszi ez a tesztlépés, ráadásul olyan módon, amire nincs ráhatásunk, így a Core i3-Ryzen 3 tesztünk idején fokozott figyelemmel néztük, hogy az asztali gépeket is érinti-e a jelenség. Beigazolódott a gyanú, méghozzá a teljesítményfelvételt látva (ami magasabb volt, mint a Prime 95 teszt alkalmával), majd reprodukálható volt a probléma, melyet MSI Afterburner segítségével értünk tetten:

A képen a jobb alsó sarokban látható a GPU emelt órajele, illetve a grafikus mag kihasználtsága [+]

Végül a Python SciPy tesztje hullott ki, mivel a SPECwpc 2.1-es verziójában valószínűleg megváltozott a teszteredmény kiszámításának menete, amely fura anomáliákat eredményezett. Jó példa erre egy kihagyott diagramunk a Threadripper-tesztből, vagy a Core i3-Ryzen 3 vizsgálódásunkból:

Anomáliákat tartalmazó teszteredmények [+]

Visszatérve a már megmaradt 7Zip, Blender, és Handbrake tesztprogramjainkhoz: közös vonásuk, hogy az általunk keresett adatok logfájlokból kereshetőek ki. A legelsőben a tömörítés idejét jegyezzük fel, míg leképezőtesztünkből a BMW1M lépéshez tartozó eredményt, a videókonvertálónál pedig a Handbrake.log és HandbrakeHQ.log állományokban lehet látni az átlagos kódolási időt.

Játéktesztelésről általánosságban

Vizsgálatainkhoz használandó játékaink összeválogatása érzékeny téma, mert szükséges, hogy összehasonlíthatók legyenek régebbi tesztjeinkkel az eredmények, így ugyanazokkal a játékokkal célszerű végigmérni az újabb tesztalanyokat is. Ha azonban a változtatás mellett döntünk, mert haladni kell a korral, akkor amennyire lehetséges, az összes olyan hardvert újra kell mérni, amelyek később még bekerülhetnek a tesztekbe.

A processzorok és az alaplapok tesztelésénél kulcsfontosságú az olyan játékok alkalmazása, ahol kimutathatóak a processzorok közötti különbségek, illetve minden esetben lényeges, hogy meg kell találni a tesztelés ideális módját, reprodukálhatóan, lehetőleg az emberi tényező kizárásával.

Az átlag és a minimum fps meghatározása

A következő táblázat azt foglalja össze, hogy a jelenlegi játékainkkal milyen teendőink vannak a tesztelés során, amivel sikerül kinyerni a hőn áhított fps-eket:

Amire rá szeretnénk világítani, hogy bár a processzor- és alaplaptesztek nem annyira építenek a játékokban mért teljesítményre, de ritka az a szerencsés helyzet, hogy benchmarkot futtatunk és lejegyezzük monitorról az eredményét. Felvetődik a kérdés, hogyan járunk el a kevésbé optimális programok esetében, amikor lényegében képkockánkénti eseményeket rögzítünk, majd ebből határozzuk meg két mérőszámunkat.

Egy kis elmélet

Amennyiben egy program nem biztosítja számunkra a feldolgozható eredményeket, akkor azt nekünk kell előállítani. Ez a megfelelő alkalmazás bevetésével nem túl nehéz, mivel a képszámítás lépései naplózhatók. A játékok futtatása közben csak be kell vetni a naplózást biztosító programok egyikét, amely generál egy kimenetet (ez legtöbbször egy csv állomány), amiben képkockánként előálló sorokkal (rekordokkal) találkozunk. Ezek a programok sok mindent mérnek, de számunkra igazából az az érték érdekes, ami a képkockák elkészültének idejére vonatkozik, jellemzően milliszekundumban mérve, amiből egyszerűen számolható az fps.

Példánkban most a PresentMon kimenetén keresztül mutatjuk be az utófeldolgozást. Szemléltetésként egy 4 GHz-es órajelen üzemelő AMD Ryzen Threadripper 1920X-es processzor Doom közben rögzített teljesítményét használjuk fel. A kimenetnek az MsBetweenPresents oszlopának adatait vesszük alapul, amit egyszerű átlagolni. Ebből még diagramot is készíthetünk a jobb láthatóság kedvéért, amiben jelen esetben ábrázoltuk az átlagot is.

Pillanatnyi, illetve átlag-fps ábrázolása a PresentMon kimenete alapján [+]

A diagramból látszik, hogy vannak benne tüskeszerű minimumértékek, de a játékban nyújtott teljesítménybe egyéb tényezők is közrejátszhatnak, amelyek esetleg egy hosszabb ideig számolt képkockát eredményeznek. Ezt sajnos nem feltétlenül a tesztelni kívánt hardver okozza, tehát bőven lehet, hogy csupán az adott mérésben fordult elő. Erre az esetre találtuk ki azt, hogy a minimumérték 110%-át nézve legalább 10 mérési eredményt feleltetünk meg ennek az értéknek. Ez mindig elég szigorú a minimumot tekintve, de jobban reprezentálja a valós játékteljesítmény minimumát, nagyrészt kizárva a nem kívánatos eseményekből eredő extrém értékeket. Ennek meghatározásához növekvő sorrendbe rendezzük mérési eredményeinket, majd ábrázoljuk azokat.

Pillanatnyi, illetve átlag-fps ábrázolása a Presentmon kimenete alapján, rendezve [+]

Már közelebb vagyunk a valósághoz; ebben a diagramban 150 fps környékén látszik "törés", de a nagy számosság miatt még nem lehet precíz értéket meghatározni. Ebben lesznek segítségünkre a rendezett fps-einken a további műveleteket bemutató diagramok, amelyekkel az előfordulást jelenítjük meg az első 79 sorra nézve, mivel ebben biztosan benne lesz a keresett minimumérték.

Az fps-minimumok előfordulási függvényei [+]

A függvényekből látszik, hogy a rendezett halmazunkban a kérdéses minimumunkat (amely legalább tízszer fordul elő) az ötödik sorban találjuk meg. Ebben az esetben 153,069 fps-t kapunk, míg átlagunk 197,0114 fps.

Részlet a munkafájlból

Játéktesztek I.

Beépített benchmarkkal rendelkező játékok

A játékteszteket az előző oldalon található táblázatban lévő sorrendben szoktuk elvégezni, ebben a leírásban viszont most a tesztelési metodika szerint csoportosítottuk őket. Első két címünkre az igaz, hogy a játék menüjéből elérhető benchmarkokat futtatjuk le, és ezt a részt nem is ragoznánk túl. A Rise of the Tomb Raider esetében az eredmény leolvasható a képernyőről – a processzoroknál a Geothermal Valley eredményeit jegyezzük le.

Rise of the Tomb Raider benchmark eredmény [+]

Az Ashes of the Singularity: Escalation is rendelkezik ugyan benchmarkkal, de az eredményablak nem tartalmazza a nekünk szükséges információkat.

[+]

Szerencsére az alkalmazás menti a futtatott teszt kimenettét, ami megtalálható lesz a "C:\Users\*felhasználónév*\Documents\My Games\Ashes of the Singularity - Escalation\Benchmarks" mappában. A lényegi információk a 291. sortól érhetőek el, a 3. oszlopban vannak milliszekundumban megadva a korábban leírt módon átalakítandó adatok.

Az Ashes of the Singularity: Escalation naplózó állományának részlete [+]

A rend kedvéért itt a minimum fps 14,59830764, az átlag pedig 26,99304903 lett. Még nem esett szó a kerekítésekről, de erre egyértelmű matematikai szabályok vonatkoznak, így magától értetődik, hogy mi történik ezekkel a törtszámokkal, mielőtt egész számokként bekerülnének diagramjainkba.

OCAT vagy PresentMon használata

Ezt a két programot akkor alkalmazzuk, ha nincs beépített benchmark. Ahogy említettük, a kompatibilitást dönt, de az utóbbi időben a PresentMon került előtérbe nálunk, mert a tavasszal megjelent Windows 10 Creators Update nem igazán szívlelte az OCAT-ot. Azóta persze vannak frissítések, de ma már igazából mindegy, hogy melyik mérőprogram szolgáltatja a tesztalapot, mert egymásra épülnek.

Maradva az alapelvek ismertetésénél, mindkét alkalmazásnál ki kell jelölni a vizsgálandó játék futtatható állományát, a szükséges beállításokat végrehajthatók a játékon belül (felbontás, részletesség), majd Doomnál a nyitójelenetet töltjük be, míg a Prey esetében egy mentést a játék elejéről, a helikopterben utazós jelenet előtt. Mindkét esetben viszonylag rövid ideig tartó részeket választottunk ki, amelyeknél minimális a felhasználói interakció, így megfelelő reprodukálható mérésekre.

A Doom és a Prey tesztelési kezdőpillanata [+]

Beállításfüggő, de mi az F11-re tettük rá a rögzítést indító parancsot. Ezt akkor aktiváljuk, amikor már egyértelműen a grafikus motor fut, minden tesztalanynál ugyanott, a beállított idő lejártával pedig elkészül a kimeneti állomány.

Játéktesztek II.

Dota 2

Ez a játék akkor került látóterünkbe, amikor mindenképp egy olyan címet szerettünk volna processzor- és alaplaptesztjeinkben látni, amelyik nem igényel annyira erős GPU-t, de nem is a már unalomig ismert kategóriákból származik. Ekkor jött az ötlet, hogy egy MOBA cím is kellene a repertoárba, de a műfaj sajátosságai miatt nem lehetett az előző két módon vizsgálni. Aztán eljutott hozzánk egy leírás, hogy hogyan lehetne mégis, de túlbonyolított volt, sok konzolparancs bevitelét igényelte, mi pedig Vulkan, illetve DirectX 11 API-val is szerettünk volna mérni, és több hardvert felvonultató teszt esetén az idő jelentős részét biztosan csak ez az egy vizsgálat vitte volna el. Így maradt a kombinálgatás, amely végül egy relatíve egyszerű, jól reprodukálható tesztet eredményezett, ennek lépéseit mutatjuk most be, képekkel is illusztrálva:

Előkészületek a játék indítása előtt

• A program letöltésén túl a Steamben, a játék indítási beállításánál a -console -vulkan kapcsolókat kell megadni. Értelemszerűen DirectX 11-nél -dx11 kapcsoló kerül a Vulkan helyére.
• Az operációs rendszer beviteli módját át kell állítani angolra, így az "ű" betű leütésénél, magyar billentyűzeten a konzol csalogatható elő.
• Előkészítjük a játék telepítési mappáját, a Steamből, a játék tulajdonságainál, a Helyi fájlok fülről jutunk a "Helyi fájlok böngészése" feliratú gombhoz, onnan pedig navigáljunk a \game\dota útvonalon át abba a mappába, ahová majd kimentjük a teszt végén az eredményeket.

A tesztelést megelőző teendők

Elindítjuk a játékot, és beállítjuk az alapvető jellemzőket (például felbontás és részletesség). Ezután a "Hősök" fülre kattintva kiválasztjuk Monkey Kinget, és a felbukkanó ablakban megnyomjuk a "Hős demózása" feliratú gombot.

[+]

Innentől a lépések a következőek:

• Megállítjuk a játékot "F9" gyorsbillentyűvel, méghozzá azonnal, amint megkapjuk az irányítást. Így elkerüljük, hogy a hősünk csatlósai elinduljanak ellenfelet keresni.
• Beállítjuk a képernyő bal oldalán a "Szabad varázslás" és "Sérthetetlenség" opciót, majd aktiváljuk őket.
• Lenyomjuk a "Legmagasabb szint" menüpontot, amivel középen lent aktiválódik az Adottságfa.
• Maximalizáljuk hősünk képességeit a felnyíló menüben.

• 
  [+]

• Kurzorgombokkal és egérrel kiválasztjuk a helyszínt úgy, hogy legyen még víz a képen és hősünkre tüzeljen majd a torony, legjobb választás egy kontúros kőre állítani az egérmutatót (a képen pirossal jelöltük ezt a helyet), középső egérgombbal tovább finomíthatjuk a navigációt.

• 
  [+]

• Aktiváljuk a konzolt, az alapértelmezett "\" (magyar klaviatúrán az "ű") billentyű lenyomásával, majd beírjuk a következő parancsot: "clear"
• A fentiek után az "exec_async perftest" utasítás következik, de az enter leütése előtt még meggyőződünk róla, hogy jó pozícióban van az egérkurzor, igény esetén módosítjuk (persze kikapcsolva a konzolt), és rákészülünk, hogy az "F9"-et majd rövid időn belül le kell nyomni.

• 
  [+]

• Elindult a teszt és az F9-cel elindult a játék is, nincs más hátra, mint hősünket a már kijelölt kőre navigálni jobb egérgombbal, majd ha pozícióba érkezik, akkor a "Q" billentyű és a bal egérgomb felváltott használatával az Őrtornyot támadjuk, amely intenzíven visszalő. Ezzel a ténykedéssel várunk olyan 10 másodpercet, majd a konzolt aktiválva láthatjuk, hogy az első blokk, amelyből fel kell jegyeznünk az adatokat, biztosan készen van. Az említett blokkból két infórmációra van szükségünk: a képkockák elkészítésének átlagos idejére, amit az "1000 frames: " bejegyzés mögött találunk, illetve a minimumra, ami pedig a "240 frames:" sorban lévő "max_time:" szöveg mögött van. Ezekkel a milliszekundumban megadott értékekkel kell elosztani az ezret, hogy megkapjuk az átlag és minimum fps-t.

• 
  [+]

• Végül kivárjuk a teszt végét, majd a konzolban kiadjuk a "condump" parancsot, ami a konzol tartalmát fájlba írja.

A tesztelési szakasz itt véget is ér, az adatok összesítése megtörténik két céllal, egyrészt hogy előálljanak a könnyen értelmezhető diagramok, másrészt hogy a sok különböző forrásból egy helyre kerüljenek összegezve az adatok. Példának felhozzuk legutóbbi processzortesztünk összegző oldalát, ahol láthatjuk az x86-os számítási teljesítményt játékok nélkül, ugyanezt játékokkal, majd végül a számítási teljesítmény / fogyasztás grafikonokat.

icon