• Input lag'o testas

Posted: **2018-10-25 21:38**

Taigi prieš maždaug savaitėlę užvirė mintis apie prietaisiuko gamybą kad n kartų paspartinti ir palengvinti input lag'o testavimą, nes su filmuota medžiaga kadrais skaičiuoti input lag'ą yra kančia. All-in-all prietaisą pasidariau, veikia taip kaip ir norėjau. Tačiau validacijai gaunamus rezultatus vis dar filmavau telefonu.
Pabandžiau CS:GO porą scenarijų, su uncapped framerate ir Radeon Chill, kiekvieno po 7 bandymus. Lag'ą skaičiavau nuo pelės paspaudimo (apačioj kairėj pusėj užsidega oranžinė lemputė kartu su paspaudimu) iki ugnies pasirodymo ekrane (daviklis sureaguoja į šviesos pokytį ir oranžinė lemputė užgesta).
Na ir rezultatai tokie, kad nekokie

Pasirodo, peržiūrėjus filmuotą medžiagą matosi, kad kartais ant ginklo matosi jog pirmiau nuspaudžia gaiduką, o tik po to ugnis pasirodo (12ms vėliau su Chill, 8ms uncapped fps), kartais abu kartu su Chill, kartais ugnis anksčiau 2ms su Chill. Uncapped fps pastoviai 8ms vėliau, bent iš 7 bandymų.
Taigi prietaisas tinkamas bent jau kaip atskaitos taškas filmuojant telefonu. Variantas dar vienam palengvinimui filmuojant su telefonu būtų - tiesioginis milisekundžių skaičiavimas ant ekrano, taip nereikėtų skaičiuoti kadrų ir iškart matytųsi rezultatas kiekviename kadre.
Tačiau kolkas bandysiu susitvarkyti su nepastovumo problema. Gal staigus pelės pasukimas suveiktų? Gal kas kokių įdėjų?

Posted: **2018-10-25 21:56**

Tikslus tas tavo prietaisas be filmavimo? Už kiek tokį gali padaryt pardavimui?

P.S. pažiūrėjau video, matau, kad rodo 44 ms, kai su filmavimu sakai pamatavęs 8 ms.

Posted: **2018-10-25 22:51**

Katonas wrote: ↑
2018-10-25 21:56
Tikslus tas tavo prietaisas be filmavimo? Už kiek tokį gali padaryt pardavimui?

P.S. pažiūrėjau video, matau, kad rodo 44 ms, kai su filmavimu sakai pamatavęs 8 ms.

8ms tai skirtumas tarp piršto ekrane pajudėjimo iki ugnies atsiradimo.
Tikslumas labai jau toks santykinis dalykas ir priklauso nuo šviesos intensyvumo, bet labai didelės paklaidos nebus +-1ms jei taip grubiai imant, čia skaičiuojant nuo kodo starto iki signalo atgal gavimo. Bandžiau su pačiu prietaisu matuoti patį prietaisą tai rezultatas 460 micro sekundžių (0.46ms). Galima aišku pridėti kalibracijos režimą, tiksliau reikėtų pridėti jei būtų planuojama pardavinėti. Na o šiaip klausimas kiek tikslus pats filmavimas kai vieną kadrą telefonas padaro per 2ms

Tie aprašyti testo rezultatai buvo atliekami prietaisą pajungus prie usb pelės, kas nėra patogu, reikia ardyti ir lituoti laidus. Šiuo momentu esu jau pasigaminęs kitą prietaisą, kuris jau pats emuliuoja pelės paspaudimą per usb, tai atkrenta būtinybė pelės ardymui ir litavimui. Tik su šiuo dar neatlikau testų. Prieš testus pirmiau bandau pasigamint padoresnį daviklio tvirtinimą prie monitoriaus.

Posted: **2018-10-25 23:09**

Tvirtinimui jaučiu paprasta guma iš kelnių gerai tiktų. Laukiam rezų nujos versijos, toks daikčiukas apžvelgiant monitorius būtų pasaka

Taip žinau, kad kamera 480 fps su 2 ms paklaida, šiek tiek ir pats skaičiuoti moku

Posted: **2018-10-26 18:48**

Katonas wrote: ↑
2018-10-25 23:09
Tvirtinimui jaučiu paprasta guma iš kelnių gerai tiktų. Laukiam rezų nujos versijos, toks daikčiukas apžvelgiant monitorius būtų pasaka

Taip žinau, kad kamera 480 fps su 2 ms paklaida, šiek tiek ir pats skaičiuoti moku

Išbandžiau nauja versiją. Bet šįkart emuliaviau pelės judesį per 50 taškų dešinėn ir atgal (kad nepamest pirminės pozicijos). Kadangi rezultatai nustebino, tai pabandžiau ir su LMB emuliavimu.
Su pelės pasukimu: vidurkis 19,75ms.
Su LMB: vidurkis 40,06ms.

Negaliu atsakyti ar čia žaidimas duoda tokius skirtumus tarp paspaudimo ir judesio, ar čia mano įrengimo veikimo principas. Bandysiu pasidomėti forumuose kas kur kaip.
Bet viena dalyką pastebėjau, kad skirtumai tarp kameros ir įrenginio parodymų jau ženkliai tolygesni su nauja versija +-2ms. Senosios versijos paklaidom greičiausiai daug įtakos turėjo išorinės pelės naudojimas LMB paspaudimui. Tiesa tuo pačiu pastebėjau kad kartais kamera buginas, pvz 3 kadrai ekrano viršuj lieka užfreezine, o apačia veikia toliau.

Edit: arba įtariu kad tai Adobe Premiere grybauja dėl užfreezintų kadrų, nes filmuota medžiaga eina ne standartiniu fps, o 28,xx fps.

Posted: **2018-10-26 20:06**

Stipena wrote: ↑
2018-10-26 18:48

Katonas wrote: ↑
2018-10-25 23:09
Tvirtinimui jaučiu paprasta guma iš kelnių gerai tiktų. Laukiam rezų nujos versijos, toks daikčiukas apžvelgiant monitorius būtų pasaka

Taip žinau, kad kamera 480 fps su 2 ms paklaida, šiek tiek ir pats skaičiuoti moku
Išbandžiau nauja versiją. Bet šįkart emuliaviau pelės judesį per 50 taškų dešinėn ir atgal (kad nepamest pirminės pozicijos). Kadangi rezultatai nustebino, tai pabandžiau ir su LMB emuliavimu.
Su pelės pasukimu: vidurkis 19,75ms.
Su LMB: vidurkis 40,06ms.

Negaliu atsakyti ar čia žaidimas duoda tokius skirtumus tarp paspaudimo ir judesio, ar čia mano įrengimo veikimo principas. Bandysiu pasidomėti forumuose kas kur kaip.
Bet viena dalyką pastebėjau, kad skirtumai tarp kameros ir įrenginio parodymų jau ženkliai tolygesni su nauja versija +-2ms. Senosios versijos paklaidom greičiausiai daug įtakos turėjo išorinės pelės naudojimas LMB paspaudimui. Tiesa tuo pačiu pastebėjau kad kartais kamera buginas, pvz 3 kadrai ekrano viršuj lieka užfreezine, o apačia veikia toliau.

Edit: arba įtariu kad tai Adobe Premiere grybauja dėl užfreezintų kadrų, nes filmuota medžiaga eina ne standartiniu fps, o 28,xx fps.

Lauksiu naujos info

Posted: **2018-10-26 22:36**

Tu man geriau, kol lauki, papasakok kaip tikrini monitoriaus latency?

Posted: **2018-10-26 23:13**

Stipena wrote: ↑
2018-10-26 22:36
Tu man geriau, kol lauki, papasakok kaip tikrini monitoriaus latency?

Laukiu, kad padarytum ir man parduotum jei kaina bus įkandama. Monitorių latency netestuojama, nes nėra su kuo. Akis testatorius yra

Posted: **2018-10-27 13:01**

Taip matuoti monitoriaus latency nelabai tikslu, nes toks matavimas rodo sumini latency is daug daliu, kuriu tik viena yra monitorius. Galima nebent bandyt nekeisti nieko sistemoje, tik monitoriu, ir tada lyginti deltas tarp skirtingu moniku, bet gausis ne absoliutinis ivertinimas, o kazkoks nuokrypis nuo reference point'o.

Net jeigu ir lyginti deltas, yra visokiu niuansu, del ko ji gali svyruoti. Kai paspaudi pele, pirma suveikia fizinis mygtukas ir jo debounce'ingas. Tada peles kontroleris detect'ina paspaudima ir suformuoja/siunica USB komanda i PC motke. Laikas sugaistas iki cia kazkiek priklausys nuo peles tipo (wired/wireless) ir konkretaus modelio. Toliau PC motkes USB kontroleris gauna signala is peles, ji apdoroja ir generuoja interrupta'a procui. Kiek tas uzims laiko gali siek tiek varijuoti nuo konkretaus chipset'o ir MB modelio. Toliau, CPU apdoroja interrupt'a, t.y. ivykdo USB ISR'a, ir USB event'a propaguoja per visa USB layer'i i windows/UI manager'i. Sitas laikas priklausys nuo CPU apkrovos ir OS kernel'io scheduer'io parametru. Tada window manager'is perduoda event'a i foreground'e vykdoma programa, siuo atveju - zaidima. Zaidimas gauna event'a ir ji handle'ina pagal savo logika, kaip implement'intas game loop'as. Tarkim, jeigu kalba eina apie multiplayer zaidima, jame dar sukasi network'o kodas, kas reiskia, jog nebutinai animacijos pasikeitimas rodo tiksliai ta momenta, kada issiunciamas kazkoks paketas i serveri. Animacija gali suveikti siek tiek greiciau, arba siek tiek veliau, nei kazkokia kitokia logika + dar salia viso to sukasi collision detect'ionas. Zodziu, ka noriu pasakyti, kad zaidimai event'a gali handle'inti ivairiai, ir viskas priklauso nuo to, kurioje atkarpoja tas latency matuojamas ir ka tiksliai norima ismatuoti. Kai zaidimas baigia atnaujinti scena, jis siuncia draw calls'a i GPU per PCIE. Cia prisideda latency'iai pacio PCIe bus'o (kontroleriai, driver'iai ir vel OS). Nu ir tada dar egzistuoja latency pacioja vaizdo kortoje, iki signalo isejimo per porta, ir tada va jau latencis lieka grynai pacio moniko: jo kabelyje + PCB/chip'e + matricoje.

Mano galva grynai monitoriaus latency geriausia matuoti paciam generuojant DVI/HDMI signala ir detectinant pasikeitima ekrane, nenaudojant jokiu PC ir peliu ar dar kazko. Tokiu atveju butu matuojama grynai moniko atkarpa. Arba bent jau minimizuoti viska PC pusej su kokiu real-time SBC, nes tikslus matavimas in general yra didelis issukis, visas metrologijos mokslas apie tai yra. Aisku gamintojai nurodo panel'es latency, kas bus maziau, nes ji neitraukia signalo keliones iki moniko kontrolerio ir jo apdorojimo. Jis itraukia tik grynai fizines paneles latency.

Posted: **2018-10-27 16:36**

kernel wrote: ↑
2018-10-27 13:01
Taip matuoti monitoriaus latency nelabai tikslu, nes toks matavimas rodo sumini latency is daug daliu, kuriu tik viena yra monitorius. Galima nebent bandyt nekeisti nieko sistemoje, tik monitoriu, ir tada lyginti deltas tarp skirtingu moniku, bet gausis ne absoliutinis ivertinimas, o kazkoks nuokrypis nuo reference point'o.

Net jeigu ir lyginti deltas, yra visokiu niuansu, del ko ji gali svyruoti. Kai paspaudi pele, pirma suveikia fizinis mygtukas ir jo debounce'ingas. Tada peles kontroleris detect'ina paspaudima ir suformuoja/siunica USB komanda i PC motke. Laikas sugaistas iki cia kazkiek priklausys nuo peles tipo (wired/wireless) ir konkretaus modelio. Toliau PC motkes USB kontroleris gauna signala is peles, ji apdoroja ir generuoja interrupta'a procui. Kiek tas uzims laiko gali siek tiek varijuoti nuo konkretaus chipset'o ir MB modelio. Toliau, CPU apdoroja interrupt'a, t.y. ivykdo USB ISR'a, ir USB event'a propaguoja per visa USB layer'i i windows/UI manager'i. Sitas laikas priklausys nuo CPU apkrovos ir OS kernel'io scheduer'io parametru. Tada window manager'is perduoda event'a i foreground'e vykdoma programa, siuo atveju - zaidima. Zaidimas gauna event'a ir ji handle'ina pagal savo logika, kaip implement'intas game loop'as. Tarkim, jeigu kalba eina apie multiplayer zaidima, jame dar sukasi network'o kodas, kas reiskia, jog nebutinai animacijos pasikeitimas rodo tiksliai ta momenta, kada issiunciamas kazkoks paketas i serveri. Animacija gali suveikti siek tiek greiciau, arba siek tiek veliau, nei kazkokia kitokia logika + dar salia viso to sukasi collision detect'ionas. Zodziu, ka noriu pasakyti, kad zaidimai event'a gali handle'inti ivairiai, ir viskas priklauso nuo to, kurioje atkarpoja tas latency matuojamas ir ka tiksliai norima ismatuoti. Kai zaidimas baigia atnaujinti scena, jis siuncia draw calls'a i GPU per PCIE. Cia prisideda latency'iai pacio PCIe bus'o (kontroleriai, driver'iai ir vel OS). Nu ir tada dar egzistuoja latency pacioja vaizdo kortoje, iki signalo isejimo per porta, ir tada va jau latencis lieka grynai pacio moniko: jo kabelyje + PCB/chip'e + matricoje.

Mano galva grynai monitoriaus latency geriausia matuoti paciam generuojant DVI/HDMI signala ir detectinant pasikeitima ekrane, nenaudojant jokiu PC ir peliu ar dar kazko. Tokiu atveju butu matuojama grynai moniko atkarpa. Arba bent jau minimizuoti viska PC pusej su kokiu real-time SBC, nes tikslus matavimas in general yra didelis issukis, visas metrologijos mokslas apie tai yra. Aisku gamintojai nurodo panel'es latency, kas bus maziau, nes ji neitraukia signalo keliones iki moniko kontrolerio ir jo apdorojimo. Jis itraukia tik grynai fizines paneles latency.

Tu kaip visada labai techniškai ir protingai viską surašei. Tik problema, kaip tu pamatuosi, kada žaidimo šūvio signalas pradeda eiti kabeliu, gal ir įmanoma, bet aš nežinau kaip ir net jei žinočiau nesugebėčiau padaryti. Ne vienas input lag matavo taip kaip Stipena, tik vien su kameros pagalba ir reiktų šį matavimą, kaip tu sakai, visos sistemos input lagu vadinti, o ne vien monitoriaus. Patestavus daug monitorių, bet būtinai su tuo pačiu kompu, būtų galima kažkokius suprantamus duomenis gauti, bet jei windows užsiapdeitina ar žaidime kas pasikeičia ir gali suvaikčioti kur nors kelios ms.

Posted: **2018-10-27 17:12**

Manau is praktines puses uztektu tiesiog nekeisti testinio PC parametru ir lyginti su kazkokiu reference rezultatu viska, nes isvertinti visus galimus velinimus paskirai per daug painiavos. Koki sena PC su tam tikrais Windows'ais "isaldyt" ir neinstalint i ji nieko, naudot tik matavimams.

As asmeniskai tai daryciau kiek kitaip: nusipirkciau koki pigu SBC su Intel Atom ar ARM'u, kad turetu reikiamus video port'us. Tada jam sukompiliuociau smarkiai nustrip'inta Linux kerneli su isjungtu viskuo, ko nereikia. Palikciau tik tiek, kad uzsikrautu board'as. Isjungiau SMP, kad butu naudojamas tik 1 branduolys. Tada sudiegciau real-time patch'us, kurie linux kerneli privercia veikti realiu laiku, t.y. faktiskai neleidzia uzdelsti system calls'u.

Tada pasirasyciau nedideli kernelio moduliuka, kuris opereruotu tiesiogiai GPIO ir GPU frame buffer'iu. Ant vieno GPIO pakabini mygtuka, ant kito davikli. Kai paspaudziamas mygtukas, tas modulis, pavyzdziui, i frame bufferi suraso duomenis, kad uzsidegtu juodas ekranas, tada surasytu duomenis, kad degtu balta spalva ir patrigger'intu auksto tikslumo timer'i, o tada daviklio GPIO generuotu interrupta, kuris sustapdytu timer'i ir parodytu rezultata.

Visa si reikala sukompiliuociau be jokio user space'o. Padaryciau, kad kai baigia krautis kernel'is, jis paleistu kokia dummy user-space programele, kuri nieko nedaro, tik sleep'ina tam, kad veiktu tik kernel-space kodas.

Toks variantas minimizuotu kitu sistemos komponentu itaka latenc'iui, gautusi faktiskai vien moniko input lag'as, nes tiksliai pats zinai, kada duodi signala monikui ir pats jie tiesiai skaitai

Bet jei jau tikrai tiksliai matuoti, tai reiketu su geru oscilografu tikriausiai, kad matyti pacius signalus ant moniko kabelio ir daviklio.

Posted: **2018-10-27 19:12**

kernel wrote: ↑
2018-10-27 17:12
Manau is praktines puses uztektu tiesiog nekeisti testinio PC parametru ir lyginti su kazkokiu reference rezultatu viska, nes isvertinti visus galimus velinimus paskirai per daug painiavos. Koki sena PC su tam tikrais Windows'ais "isaldyt" ir neinstalint i ji nieko, naudot tik matavimams.

As asmeniskai tai daryciau kiek kitaip: nusipirkciau koki pigu SBC su Intel Atom ar ARM'u, kad turetu reikiamus video port'us. Tada jam sukompiliuociau smarkiai nustrip'inta Linux kerneli su isjungtu viskuo, ko nereikia. Palikciau tik tiek, kad uzsikrautu board'as. Isjungiau SMP, kad butu naudojamas tik 1 branduolys. Tada sudiegciau real-time patch'us, kurie linux kerneli privercia veikti realiu laiku, t.y. faktiskai neleidzia uzdelsti system calls'u.

Tada pasirasyciau nedideli kernelio moduliuka, kuris opereruotu tiesiogiai GPIO ir GPU frame buffer'iu. Ant vieno GPIO pakabini mygtuka, ant kito davikli. Kai paspaudziamas mygtukas, tas modulis, pavyzdziui, i frame bufferi suraso duomenis, kad uzsidegtu juodas ekranas, tada surasytu duomenis, kad degtu balta spalva ir patrigger'intu auksto tikslumo timer'i, o tada daviklio GPIO generuotu interrupta, kuris sustapdytu timer'i ir parodytu rezultata.

Visa si reikala sukompiliuociau be jokio user space'o. Padaryciau, kad kai baigia krautis kernel'is, jis paleistu kokia dummy user-space programele, kuri nieko nedaro, tik sleep'ina tam, kad veiktu tik kernel-space kodas.

Toks variantas minimizuotu kitu sistemos komponentu itaka latenc'iui, gautusi faktiskai vien moniko input lag'as, nes tiksliai pats zinai, kada duodi signala monikui ir pats jie tiesiai skaitai

Bet jei jau tikrai tiksliai matuoti, tai reiketu su geru oscilografu tikriausiai, kad matyti pacius signalus ant moniko kabelio ir daviklio.

Ką gali programeris Linux to negali paprastas žmogus. Tavo būdas labai geras matuoti vien tik monitorių input lag, bet, kaip sakiau, ne man pasidaryti. Jei apsiimtum tą pigų Linux padaryti kiek tai maždaug kainuotų? Tik mano problema, nėra didelio greičio kameros, tad tas Linux kompiuteriukas nelabai kuo padėtų.

Posted: **2018-10-27 19:47**

Tokį pat maždaug atsakymą gavau ir arduino forume, pelės paspaudimas daug komplikuotesnis reikalas nei pelės pajudinimas. Tai realiai jei jau tiksliai matuoti tai matuoti judinant pelytę. Tai ar priimam device'ą kaip legit input lag'o testerį su pelės pajudinimu?

Aišku matavimas nuo pelės input iki monitoriaus vaizdo pasikeitimo. Pačio monitoriaus latency matuoti geriausiai būtų su osciloskopu kaip ir kernel minėjo. O kaip tai padaryti su Arduino ir foto tranzistorium, nežinau. reikėtų pasukt galvą.
Per išeigines manau galėsiu jau viską sukraut ant PCB, sulituot, sudėt į dėžutę. Tik va blyn reiktų užsisakyt plonesnių silikoninių laidų, o tai standartiniai kietoki trukdo montavimui prie monitoriaus.

Posted: **2018-10-27 19:50**

Čia kaip veikia su pelės pajudinimu

Posted: **2018-10-27 22:26**

Įdomia programėlę BC00 parodė, pagal testus labai artima oscilografu, ryt reiks pasibandyti.

http://www.tftcentral.co.uk/articles/input_lag.htm

Posted: **2018-11-02 01:38**

Nu ką, nepatingėjau šiandien porai valandų prisėsti ir pažiūrėti kas gaunasi ant CS:GO

Posted: **2018-11-02 10:07**

Stipena wrote: ↑
2018-11-02 01:38
Nu ką, nepatingėjau šiandien porai valandų prisėsti ir pažiūrėti kas gaunasi ant CS:GO

Nepatingėjai čia pritestuoti.

Posted: **2018-11-02 11:47**

aga, saunuolis. Tik va klausimas, koks input lagas be jokiu free-syncu, bet su vsycnu 60 fps, gai games varo kokiu 100 fps

Posted: **2018-11-02 14:48**

vacoum wrote: ↑
2018-11-02 11:47
aga, saunuolis. Tik va klausimas, koks input lagas be jokiu free-syncu, bet su vsycnu 60 fps, gai games varo kokiu 100 fps

Įtrauksiu į testavimo sąrašą ir Vsync su 60Hz

Posted: **2019-11-02 10:57**

oof... buvau grįžęs vasaros gale prie projekto. Sulitavau, sudėjau viską į dėžutę, kad būtų tvarkingai. Dar norėtųsi padaryti mygtukų apšvietimą ir pakeisti laikiklį ant monitoriaus. Abu darbai nėra sunkiai atliekami, bet va tinginį nugalėti yra kažkas nerealaus

Besižaisdamas su rezultatais kai įjungtas Vsync pastebėjau anomalijų. Galvojau kažkas blogai su kodu, tad teko daug kartų viską permąstyti, perrašyti, supaprastinti operaciją iki minimumo. Tačiau, galų gale dašuto tuščioj galvelėj jog per vienos sekundės ciklą yra prarandama 2ms, galimai dėl pačio arduino kvarcinio rezonatoriaus.
Supratus anomalijos priežastį, paaiškėjo dar vienas dalykas, kuris turi įtakos rezultatams, tai yra pastovumas. Visada gaunamas tas pats rezultatas. Tarkime, kai turi 60fps, tai vieno kadro taip vadinamas "frame time" yra 16,67ms. Naudojant įrenginio atomatizavimą, naujo rezultato ciklas visada pradedamas iškart užbaigus senąjį t.y. kadro pradžioje, pvz. 3ms po senojo užbaigimo. Jei GPU užtrunka 3 kadrus po 16.67ms kol pateikia rezultatą į monitorių tada gauname pastovų rezultatą 16,67-3+16,67*3=63.68ms. Techniškai viskas gerai, tačiau męs ne robotai ir visada į tą patį taktą nepataikome, ypač kai kalba eina apie milisekundes. Kai žmogus nuspaudžia mygtuką ciklui pradėti, tai vieną kart gali pataikyti pvz. 9ms po senojo kadro, kitą kart 15ms, dar sekantį 1ms ir taip kaskart gauni skirtingą rezultatą atitinkamai 57.68ms, 51,68ms ir 65,68ms.
Taigi, kad išspręsti pastovumo problemą, galvojau apie "random" funkcijos pridėjimą į kodą kad ciklą pradėti kaskart kitoje vietoje. Tuo pačiu reikia pridėti tų 2ms per 1s kompensavimą. Galėjau jau rugsėjo mėnesį viską padaryti, tačiau vėl tinginys aplankė

Nežinau kada rasiu jėgų užbaigti projektą, bet iš esmės jis funkcionuojantis.
Tiesa kad dar sumažinti darbo reikia ir Google Spreadsheet arba MS Excel formą pasidaryti. Taip pakaktų serial output'o rezultatus copy-paste, kuriuose jau būtų nurodyti visi reikiami nustatymai spreadsheet'ui bei rezultatai.

Input lag'o testas

Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas

Re: Input lag'o testas