Page 38 of 44

Re: flood's input lag measurements

Posted: 13 Dec 2016, 22:49
by flood
to be resumed on weekend probably
lexlazootin wrote: Flood, what CS:GO team you on?
none, no time. although i'd probably make time for it if i found the right people.

Re: flood's input lag measurements

Posted: 17 Dec 2016, 21:31
by flood
lexlazootin's map, max graphics settings, 1600x1200
mqm0: ~280fps
mqm1: ~280fps
mqm2: ~400fps

so not entirely gpu-limited (otherwise they'd all be nearly the same framerate)

@lexlazootin do you mind making a more graphically complicated map with a black/white box? (or should i just learn how to myself :P)
edit: nvm, i achieve the same effect by underclocking

Image
Image

mqm0 and mqm1 are virtually identical

Re: flood's input lag measurements

Posted: 17 Dec 2016, 21:48
by flood
stirner wrote: And out of bullshit curiosity: Mind checking whether running Steam/CS:GO in admin mode changes anything? Likewise, running Steam from a shortcut with the "-no-browser" parameter to prevent the web helper from being co-launched. These probably change next to nothing/negligibly affect performance at most, but hey, they are easy enough to test and I take it you want to test.
running in admin mode:
admin = np.loadtxt("csgomax_steam_admin.txt")

admin.mean()
Out[26]: 8826.6839546191241
200us slower than the measurements in the previous post, but that's more likely related to random inconsistencies every time i alt-tab/restart csgo.

-no-browser:
inconclusive.
Image
fps was 285-290 for each.
i have to restart steam and csgo each time. not sure if the variability is related to that or if -no-browser really makes it slightly better somehow.

for sure if i don't restart csgo, the repeatability is within 100us:
http://forums.blurbusters.com/viewtopic ... 350#p23470

Re: flood's input lag measurements

Posted: 17 Dec 2016, 23:59
by flood
k
old pc
gpu underclocked in afterburner (416 core, 324 mem)

max csgo settings at 1600x1200, lexlazootin's map

uncapped fps: 95-97

6 measurements
A: mqm0, uncapped
B: mqm1, uncapped
C: mqm2, uncapped
D: mqm0, capped with fps_max 80 (actual fps ~79.5 or so)
E: mqm1, capped with fps_max 80 (actual fps ~79.5 or so)
F: mqm2, capped with fps_max 80 (actual fps ~79.5 or so)

Image
Image
Image

[x,y] means uniformly distributed random variable between x and y.

A: lag = 2 * (frame time) + [0,frame time]
B: lag = 2 * (frame time) + [0,frame time]
C: lag = 3 * (frame time) + [0,frame time]
D,E,F: 1 * (frame time) + [0, frame time]

so my subjective evaluation was 100% correct :P
http://forums.blurbusters.com/viewtopic ... =10#p23575
apparently i just realized i posted that in the wrong thread tho

conclusions:
1. mqm0 and mqm1 are identical in all measurements so far.
2. when gpu-limited, setting fps_max to lower than the uncapped framerate can potentially reduce lag. (this is not a recommendation to use fps_max XYZ though. in actual gameplay, framerate fluctuates so much it's not obvious whether there's a single value that would be effective)

Re: flood's input lag measurements

Posted: 18 Dec 2016, 00:04
by lexlazootin
Welp, my plan failed. I thought i would just be able to spam blocks but i hit a "Too many blocks" limit before hitting any sort of GPU limit.

http://i.imgur.com/kVABlF5.jpg

So instead i just got de_nuke which is pretty much the most GPU hungry map to date and i added a blackwhite box. I didn't bother rendering the lighting or whatnot because that would of took 8-16hours.

It's a fps killer:
http://i.imgur.com/5FVJd3p.jpg
http://i.imgur.com/TD7VQiM.jpg

Map: http://www.mediafire.com/file/mx2k082nd ... _custom.7z

You might also need to extract the models from from this pack for the map to work (not 100% sure): http://www.mediafire.com/file/544ddcqp3 ... e_nuke.zip

Re: flood's input lag measurements

Posted: 18 Dec 2016, 00:15
by flood
cool, thanks.
i actually edited the post to say that it's not necessary since i can also force the rendering to be gpu-limited by underclocking
but this will still be useful

Re: flood's input lag measurements

Posted: 18 Dec 2016, 00:23
by Vols and Jezuz
You can potentially eliminate another variable by making sure Steam overlay is circumvented entirely. Even if you have it disabled, it still launches GameOverlayRenderer.dll from the Steam directory whenever CS:GO starts up and hooks a bunch of stuff (check GameOverlayRenderer.log for proof if ya don't believe me). I think this can cause extraneous instances of Steam browser-related processes to be spawned, so I could see that causing variability or explaining the improvement with -no-browser. Not to mention that its hooking routines are notorious for causing games to crash on startup when they don't get along with other hooks.

To truly keep Steam overlay from meddling around, you'll want to rename GameOverlayRenderer.dll to something like GameOverlayRenderer.dll.off before you launch CS:GO. Then remove the .off extension after you close the game if you want overlay to be available again. Steam will download a fresh GameOverlayRenderer.dll copy the next time it restarts if it notices that it's not there.

Re: flood's input lag measurements

Posted: 18 Dec 2016, 09:03
by stirner
200us slower than the measurements in the previous post, but that's more likely related to random inconsistencies every time i alt-tab/restart csgo.
-no-browser:
inconclusive. i have to restart steam and csgo each time. not sure if the variability is related to that or if -no-browser really makes it slightly better somehow.
Nicenice.

Try disabling the NVIDIA Container service next?

Btw.: Are you doing LCD or CRT tests rn?

Re: flood's input lag measurements

Posted: 18 Dec 2016, 22:13
by flood
crt
if i wasn't clear, i am drawing no conclusion from the 200us difference in admin-mode on/off, since you get similar to a 200us variation each time you restart csgo

too busy with stuff to work on this for the rest of the year probably :P
anyone want to take over? i'd be willing to give this rig away to anyone who
1. is curious and has more free time than i do
2. has a crt monitor
3. understands psychological biases and is careful with drawing conclusions from data
4. is reasonably knowledgeable in basic programming, electronics, data analysis, etc...
5. is not epileptic (during measurements, the screen flashes black/white 10-40 times a second in a dark room)

Re: flood's input lag measurements

Posted: 19 Dec 2016, 07:26
by lexlazootin
Hell, i would love to take over but i don't have a crt and only know very basic code.

It'll be sad to see you go :cry: