2019. május 25., szombat

Gyorskeresés

Egerek tesztelése

Írta: |

[ ÚJ BEJEGYZÉS ]

Ez az írás az egeres topik összefoglalójának kiegészítése. Azon kevés érdeklődőnek készült, akit mélyebben érdekel a téma, és szívesen elmerül egy egér alapos letesztelésében.

DPI, polling rate beállítása

Ha az egér viszonylag kevés DPI-opcióval rendelkezik (1-5), javasolt mindegyiken végigmenni. Ha túl sok (pl. 50 / 100-asával állítható), akkor érdemes kipécézni a gyári alapértelmezetteket (natívat), többszöröseit és töredékeit; illetve a maximumot. Pl. egy natívan 800 DPI-s, maximálisan 4000 DPI-s egérnél 400, 800, 1600, 3200, 4000. Ha gyárilag több DPI közül válogathatunk on-the-fly, az egy jó kiindulópont.

Általában a teszteket érdemes 500 / 1000 Hz-en végezni, amelyiken stabil, vagy több rate-en is. Ehhez érdemes próbaképp ránézni a mouserate-re és néhány MouseTester grafikonra, azokon látszani szokott, ha valamelyik nem kóser. 125 Hz nem javasolt, pl. a jittert elrejtheti, nem derül ki.

Paint-teszt

A Paint-teszt előkészítéséhez Windows-ban is kell egy-két beállítást módosítani: Windows-csúszka középen, EPP off, lásd V. fejezet. Ha nem ilyen beállításokkal csináljuk, bizonyos hibákat elrejtenek, és más hibákat okozhatnak. Mindenképp PNG-ben mentsünk, a JPG minőségromlást okoz.

Ezen leginkább a jitter-t és az angle snapping-et figyelhetjük meg. A jitter teszteléséhez normál sebességgel karikákat, íveket szoktunk rajzolni, én kézzel írott a betűket szoktam, igyekezve arra, hogy tényleg kör legyen. Az AS-t pedig vízszintes-közeli vonalakkal tudjuk lebuktatni: ha gyanúsan egyenes vonalakat rajzolunk, az bizony AS.

Az itt látható rajzok nem "helyben" készültek, sokkal több mintából lettek összeválogatva a legjellemzőbbek.

Erről első ránézésre annyi derül ki, hogy 900-on nincs jitter, 1800-on minimális, 3500-on ronda. AS egyáltalán nincs benne.

Ezen sokkal több mindent figyelhetünk meg. Egyrészt azt, hogy 125 Hz-en darabos a mozgás. Másrészt azt, hogy 1800 DPI-n jitterel, érdekes módon 500 Hz-en jobban, mint 1000 Hz-en. Harmadrészt az 1800 DPI-n fellépő jittert is elrejti a 125 Hz. Negyedrészt az erős angle snapping-et.

Polling rate vizsgálata

Erre a tesztre több program is rendelkezésünkre áll. A legegyszerűbb minden bizonnyal a mouserate, a használata sem okoz fejtörést. Indítsuk el, és mozgassuk az egeret az ablakon belül, folyamatosan, lehetőleg körbe-körbe. Hirtelen állítsuk meg, mert a lassú mozdulatoknál a polling rate is csökken, ezért nem biztos, hogy látjuk, szépen tartja-e. Íme két PNG-mentés: (a program saját Save funkciója)


Az első képen láthatjuk, hogy egerünk szépen tartja az 1000 Hz-et, a második viszont azt mutatja, hogy már sok neki az 1000 Hz, próbál "visszaesni", ilyenkor javasolt visszább venni.

Szintén alkalmas rá az Enotus MouseTest, ez nem a pillanatnyi értéket mutatja, hanem a stabil, átlagolt értéket, így talán jobban értelmezhető.


Az első képen az MX300 tudja tartani az 500 Hz-et, a második képen az MX310 nem.

Szintén alkalmas lehet ezeknél pontosabb adatok begyűjtésére az OxyPlot MouseTester Interval vs. Time és Frequency vs. Time grafikonjai is, de meg lehet élni nélküle is.

PCS, MFS kiderítése

Erre sajnos alkalmatlan az Enotus. Nem lehet megkülönböztetni a kiugróan magas értékeket, hibákat a valódi sebességtől. Helyette erre MouseTester-t használunk, azon belül is az xVelocity vs. Time grafikont. Az xCounts vs. Time arra jó, hogy a data path-ból eredő clipping-et lebuktassuk.

A program használata elég triviális, kis próbálgatással hamar rájön az ember, pláne, hogy angolul ki is írja, mit kell csinálni.

Az egér a PCS eléréséig szépen le kell, hogy kövesse a rántást, példa:

Ezen annyit látni, hogy a PCS legalább 4,4 m/s. Hogy afelett hogy viselkedik az egér, az ebből nem derül ki. Addig kell gyötörnünk, amíg hibát nem csikarunk ki belőle, ez kétféle lehet.

Remekül felismerhető a clipping: ilyenkor pont olyan, mintha a grafikon tetejét levágták volna. Ez azt jelenti, hogy a MFS valahol afelett van. A képen nagyon jól felismerhető, de gyakran előfordul, hogy nem ennyire lapos a "tepsi", kicsit púpos, ilyenkor további tesztelést igényel, hogy kiderítsük: tényleg az-e, vagy csak annak hisszük. Okozhatja a data path-ból eredő limit is, ilyenkor majdnem teljesen sima a "teteje", az xCounts grafikonnak pedig teljesen, jellemzően 2-hatványnál.

Sokkal furább képet ad a MFS elérése. Egy darabig szépen leköveti a rántást, majd hirtelen megáll a kurzor, 0-ra csökken a sebesség, majd a szenzor hülyeséget közvetít. A képen az első rántást lekövette, míg a másodiknál elérte a MFS-et. Ebből, és az előző képből meg lehet állapítani, hogy a PCS és a MFS is 4,4 m/s.

Acceleration

...azaz gyorsulás. Leginkább úgy érhető tetten, hogy ugyanazon a fizikai távolságon FPS-játékban egyszer lassan, majd gyorsan végigvezetjük az egeret - oda, vissza. Optimális esetben ugyanoda kell visszaérkeznünk. Pozitív accel esetében gyors mozdulatnál többet fordulunk, mint lassú mozgásnál - negatív gyorsulásnál persze pont fordítva.

Illik egy olyan játékban tesztelni, amelyikben az egérkezelés jó, pl. Quake-sorozat, UT-sorozat, CS. Kevésbé jó a CoD, BF-sorozat és társai. Ennek oka a szoftverfejlesztésben keresendő, és túlmutat ezen összefoglalón.

Smoothing, input lag

Ez az, aminek a mérésére sose volt elfogadott módszer, de alakulóban van. Igazából "érezni" lehet, amit viszont az emberek nehezen hisznek el. Messziről jött ember azt mond, amit akar. Elég vitatott téma pl. az A9800-as és az S3988-as szenzornál: azt hallani, hogy smoothing-osak, persze mérni nem lehet.

Mint említettem, alakulóban van. Ebben a hozzászólásban részletesen kifejtettem. A használt szoftvert jelenleg folyamatosan fejlesztem, aki akarja, innen letöltheti a forráskódot, lefordíthatja, és kipróbálhatja. Persze egyelőre még nincs használati utasítás sem, de igyekeztem egyértelmű felületet összerakni. Amint lesz stabil verzió elegendő tapasztalattal, természetesen update-elem a bejegyzést.

Hozzászólások

(#1) twollah1976


twollah1976
(őstag)
LOGOUT blog

Multkor az egyik macska egy egerrel jatszott, meguntam es rakartam az egerre egy teglat, utana a macska boldogan befalta a puhitott egeret.

\m/ Minden lehetséges, kivéve forgóajtón átsíelni... \m/

(#2) MaTpr0F


MaTpr0F
(senior tag)

Talán itt lesz a legjobb helye a kérdésemnek:

Gondoltam gyakorolni kéne az egér behatóbb tesztelését.
Mouse testerben mit csinálok rosszul, hogy ha az xVelocity vs time grafikonom gyakorlatilag egyenes?
Egyszerűen nem tudok olyan szép ívet produkálni, 2 egérrel is próbáltam.

(#3) dobragab válasza MaTpr0F (#2) üzenetére


dobragab
(PH! addikt)

Posztolj egyet, abból többet látok. :)

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

(#4) MaTpr0F válasza dobragab (#3) üzenetére


MaTpr0F
(senior tag)

Tessék.

Bár lehet maga a metódusom rossz. Milyen mozdulatot kell végezni az egérrel? Mekkora távon?

(#5) dobragab válasza MaTpr0F (#4) üzenetére


dobragab
(PH! addikt)

Nem a metódusod rossz, a pollinggal nem stimmel valami. A grafikonon a függőleges tengelyről le tudod olvasni a rántásaid sebességét, amit posztoltál, az kb. 4 m/s volt (szép érték). Az egyetlen kiugró pötty (~95 m/s) mérési hiba, konkrétan véletlenül 1 usb frame alatt 2 packet-et küldött az egér ugyanazzal az értékkel, így minimális ideig (1 tick-ig) nagyon nagy sebességnek tekinti a mousetester. Ez igazából játék közben senkit sem zavar, de a tesztelés agyhalál lehet tőle, lásd Cougar 300M teszt. Csak az vele a baj, hogy a grafikon skáláját nagyon eltolja, így kb. értékelhetetlen lesz tőle a teszt.

Érdemes más polling rate-en megpróbálni, 500 / 1000-re váltani. És addig próbálkozni, amíg tudsz egy "tiszta" grafikont. :(((

Tudom, tudom, akasszak a tökömre egy lámpát, hogy sötétben is tudjak kaszálni.

További hozzászólások megtekintése...
Copyright © 2000-2019 PROHARDVER Informatikai Kft.